Separate changed speed from uneven playback
Note whether dialogue and action proceed consistently faster or slower after pressing a rate button. That is different from intermittent stalls or motion judder. Record the rate shown by the player where available and the exact button used.
Use a permitted local sample for a simple comparison. If playback changes predictably after the command, preserve that relationship. Do not attempt to solve a deliberately selected speed by increasing internet bandwidth, since the command is altering the local playback task.
Choose the intended increment
Consult the maintained clsid2 README and the installed build’s rate options for the current control. Restore normal speed first, then select a suitable step if you need smaller adjustments. Keep the original setting noted so a later experiment can be reversed.
A hypothetical learning-video task may need a modest speed increase rather than a doubling. That preference differs from a sports session intended to stay at normal speed. Avoid assuming another viewer wants the same rate or that every live source permits arbitrary seeking and speed changes.
Keep source limitations separate
After restoring normal speed, replay the same passage. If the original problem remains as stops, audio drift or missing frames, describe that separate result rather than continuing to call it a rate-step problem. A clear command-and-result record is more useful than a general report of bad playback.
Include the player fork and version, source type, selected rate and button behaviour when asking for help. Keep private URLs out of logs. This article reports a documented default and an editorial comparison; it does not claim to have tested a particular MPC-HC build or guarantee speed control for every network stream.