Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

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

Attached to Project: Rockbox
Opened by Steve (TheBashar) - Tuesday, 25 November 2008, 01:35 GMT+2
Last edited by Nicolas Pennequin (nicolas_p) - Tuesday, 02 December 2008, 22:07 GMT+2
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Player Type Sansa c200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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, 22:07 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed in r19304.
Comment by Steve (TheBashar) - Thursday, 27 November 2008, 02:15 GMT+2
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, 08:48 GMT+2
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, 11:23 GMT+2
Confirmed first occurs in r17109.
Comment by Nicolas Pennequin (nicolas_p) - Tuesday, 02 December 2008, 22:03 GMT+2
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...