FS#9319 - changing dynamic playlist locks boost_counter at 1
Opened by Ryan Sawhill (ryran) - Monday, 25 August 2008, 02:47 GMT
Last edited by Nicolas Pennequin (nicolas_p) - Tuesday, 02 December 2008, 21:07 GMT
Detail: You know how when you mess with the contents of the dynamic playlist (deleting/moving tracks; changing repeat/shuffle modes), the buffer is cleared except for the currently playing track and then either starts refilling when you return to the WPS or when you get to the end of the track? Well, at least on my 5G ipod, it also bumps up boost_counter to 1 as soon as the buffer is cleared, even if the refill doesn't begin immediately.
As in: 1a) Insert tracks into current playlist, OR 1b) Change repeat mode from the file browser and don't go back to WPS, 2) buffer is cleared except for current track, 3) CPU is boosted for duration of track, 4) near track end buffer refill begins and when it finishes cpu returns to normal.
Mostly, not a big deal. Three or four minutes later you're back to normal. Unless your first track is an hour long. In which case your cpu will be boosted for an hour (assuming it fits in your buffer). At any rate, it just seems to me the premature boosting is more like a bug than a feature. My FEELING doesn't mean much though, since I haven't looked at the code. :)
Lastly, perhaps obviously, you can drop down boost_counter to 0 from the debug menu and it behaves normally (auto-boosting, etc).
This has been going on for a while--not sure how long. I haven't tried to go back and isolate it. Still present in r18341.
Tuesday, 02 December 2008, 21:07 GMT
Reason for closing: Fixed
Additional comments about closing: Should be fixed in r19304.