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+2
Last edited by Thomas Martitz (kugel.) - Wednesday, 10 June 2009, 19:16 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To Nicolas Pennequin (nicolas_p)
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Version 3.1
Due Date Undecided
Percent Complete 100%
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

Closed by  Thomas Martitz (kugel.)
Wednesday, 10 June 2009, 19:16 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r21244.
Comment by Bertrik Sikken (bertrik) - Friday, 16 May 2008, 12:33 GMT+2
Possibly related to  FS#8964 
Comment by Martin Ritter (MartinR) - Friday, 16 May 2008, 13:45 GMT+2
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+2
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+2
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+2
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+2
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+2
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+2
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+2
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-data.txt (85 KiB)
   logf.with-gather-runtime-data.txt (84.7 KiB)
Comment by Steve (TheBashar) - Thursday, 27 November 2008, 09:17 GMT+2
Nicolas, I think this bug is related to one I filed recently,  FS#9576  and I narrowed the problem down to being introduced between r17103 and r17111. I have not yet tested the builds between those, but right now I suspect the problem was introduced in your buffering rework patch committed in r17109. I'm trying to set up a dev env now to verify.
Comment by Jonas Häggqvist (rasher) - Thursday, 11 December 2008, 04:36 GMT+2
Does this still happen after r19304, which is supposed to have fixed  FS#9576 ?
Comment by Nicolas Pennequin (nicolas_p) - Thursday, 11 December 2008, 07:47 GMT+2
Yes, this one is not the same issue and I still haven't managed to find the cause of it, despite having investigated a few days ago.
Comment by Thomas Martitz (kugel.) - Monday, 16 March 2009, 16:33 GMT+2
The "stays boosted" portion should be fixed, but I think the buffer still doesn't advance sometimes
Comment by Martin Ritter (MartinR) - Monday, 16 March 2009, 17:48 GMT+2
No, I can still reproduce also the "stays boosted" portion. But you have to skip quite quickly now, as buffering has become much faster due to the various optimizations in the meantime.

Loading...