Rockbox

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

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#8999 - CPU stays boosted when skipping to the next track while buffering is still in progress.

Attached to Project: Rockbox
Opened by Martin Ritter (MartinR) - Friday, 16 May 2008, 12:22 GMT+1
Last edited by Nils Wallménius (nls) - Wednesday, 12 November 2008, 16:18 GMT+1
Task Type Bugs
Category Music playback
Status Assigned
Assigned To Nicolas Pennequin (nicolas_p)
Player type Sansa e200
Severity Low
Priority Normal
Reported Version current build
Due in Version Version 3.1
Due Date Undecided
Percent Complete 0%
Private No

Details

- start playing an album of mp3 files
- quickly skip to the 2nd track
- go to the view buffering thread screen

Buffering will stop prematurely and CPU remains boosted.
This doesn't seem to happen with VBR encoded mp3 files, though.
This task depends upon

Comment by Bertrik Sikken (bertrik) - Friday, 16 May 2008, 12:33 GMT+1
Possibly related to  FS#8964 
Comment by Martin Ritter (MartinR) - Friday, 16 May 2008, 13:45 GMT+1
Additional information:
- I was wrong: It also happens with VBR files, but not with all albums though. I wasn't able to figure out the difference yet.
- It also happens if the 1st track is very short, so that the 2nd track starts while still buffering.
- It doesn't matter whether or not album art is present.
Comment by Michael Sevakis (MikeS) - Saturday, 17 May 2008, 00:13 GMT+1
I've observed stray boost on the audio thread as well recently ("+" remaining next to the thread in View OS Stacks).
Comment by Nicolas Pennequin (nicolas_p) - Tuesday, 01 July 2008, 11:27 GMT+1
I don't really understand the issue here... I've posted a patch in  FS#8964 . Does it fix this issue too by any chance?
Comment by Martin Ritter (MartinR) - Wednesday, 02 July 2008, 10:39 GMT+1
Unfortunately the patch for  FS#8964  doesn't fix this one.

I was able to track it down to a point where tracks[track_widx].id3_hid is -1 in buffering_handle_finished_callback(). That's probably wrong and causes buffering to stop prematurely because Q_AUDIO_FINISH_LOAD is not fired. But here I stuck.
Attached are two logf dumps with and without skipping the first track. I added two logf lines in buffering_handle_finished_callback() below the existing:
logf("handle %d finished buffering", *data);
logf(" track_widx=%d", track_widx);
logf(" id3_hid=%d", tracks[track_widx].id3_hid);
Hope this helps.


   logf_noskip.txt (2.4 KiB)
   logf_skip.txt (1.5 KiB)
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 03 July 2008, 16:59 GMT+1
Thanks for the details, you've already found a lot. I'll try to investigate this ASAP.
Comment by Felix Egli (felix) - Saturday, 09 August 2008, 15:28 GMT+1
I see a problem with my X5 witch is probabely related to this bug.

When i have "Gather Runtime Data" enabled, sometimes the CPU stays boosted when one track ends and the next starts. I dont have to skip. What i also see is, that the buffers are not filled up.

With "Gather Runtime Data" disabled everything works fine, and i am not able to reproduce the bug.

It looks like, that the writing of the runtime data disturbes the reding of the mp3-file.
Comment by Felix Egli (felix) - Thursday, 11 September 2008, 22:10 GMT+1
I have this problem also with gather runtime data turned off, but only when i am navigating arrount in the database (with dbcache turned off) and modify the playlist while the buffers are filled up. It looks like that the fill up of the buffers stop at the end of a track.
Comment by Felix Egli (felix) - Wednesday, 17 September 2008, 21:48 GMT+1
I enhanced the logging a bit and attache the logfiles to this message. I hope, that the logs are usefull for someone.
   logf.without-gather-runtime-d... (85 KiB)
   logf.with-gather-runtime-data... (84.7 KiB)

Loading...