Rockbox

Tasklist

FS#9576 - Boost locked when playing a list(?) of tracks

Attached to Project: Rockbox
Opened by Steve (TheBashar) - Tuesday, 25 November 2008, 00:35 GMT
Last edited by Nicolas Pennequin (nicolas_p) - Tuesday, 02 December 2008, 21:07 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Sansa c200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Noticed in r18341. Still seen in r19191. Probably existed prior to r18341 but I don't think it was there back in March 2008.

If I select a lone audio file to play, the system auto-boosts. If I select a file in a directory with about 8 tracks, the boost is locked on. If I select the root.m3u8 the system is boost locked on. If I use the database to select a lone file or two it auto-boosts. If I pick a selection with a lot of tracks, boost is locked on.

In the cases where boost is locked on, if boost is canceled through the debug menu the system returns to auto-boosting.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Tuesday, 02 December 2008, 21:07 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed in r19304.
Comment by Steve (TheBashar) - Thursday, 27 November 2008, 01:15 GMT
Most all my songs are MPC -extreme files.

The most reliable way to reproduce the problem is:
- Set repeat off
- Set shuffle on
- Play the root playlist
- Press menu and navigate back to the file menu to again play the root playlist
- Go to debug menu and see boost locked on in buffering thread or cpu freq views

I have seen this as far back as the 20080601 daily build. I'm trying to get older builds to test with to narrow it down to a commit.
Comment by Steve (TheBashar) - Thursday, 27 November 2008, 07:48 GMT
I tested archived daily builds and found that the problem was introduced between 080414 r17103 and 080415 r17111. If I were a betting man, I'd bet the problem was introduced in the buffering rework in r17109.
Comment by Steve (TheBashar) - Thursday, 27 November 2008, 10:23 GMT
Confirmed first occurs in r17109.
Comment by Nicolas Pennequin (nicolas_p) - Tuesday, 02 December 2008, 21:03 GMT
I believe this is a duplicate of  FS#9319  and that  FS#8999  is a separate issue.
I am about to commit a fix for the issue described here and in  FS#9319 .

Loading...