Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Playlists
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Critical
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by fml2 - 2008-06-22
Last edited by nicolas_p - 2008-06-29

FS#9110 - Player hangs near playlist end

Experienced with r17749.

I started playback by selecting the first file in a directory (so that the playlist was created ‘on the fly’). All files are mp3’s encoded at 128 …(don’t remember the unit).

There are 18 files in the directory (it’s ‘Chess’ by Andersson & Ulvaeus).

The last track was playing when playback stopped. There were still 1:28 in the track to play.

Player still reacted to some key presses (backlight went on). I tried to shut the player down. The splash ‘Shutting down…’ appeared but the player didn’t shut down.

It seems that this bug only shows up if the playlist is long enough since I didn’t experience it when I started a directory with the third from the end file.

Closed by  nicolas_p
2008-06-29 11:52
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Should be fixed by r17875. Reopen if not.

Same bug as  FS#9049  I think

fml2 commented on 2008-06-25 17:55

I can still reliably reproduce the bug. Now with r17783.

fml2 commented on 2008-06-25 17:58

PS. The player reacts at button presses, I can call up the menu and even show the rockbox version. I can change the state from ‘playing’ to ‘paused’ and back and do Fwd/Rew. But I can’t change the track by short left click. And when the status bar shows ‘playing’ it doesn’t actually play, the elapsed time also stands still (as well as the progress bar).

fml2 commented on 2008-06-25 18:18

Here are some data from the debug menu:

Buffering thread:


pcm: 0 / 529200
alloc: 28142252 / 28166688
real: 14226 / 28166688
usefl: 8117 / 28166688
data_rem: 1395936
track count: 1
handle count: 10
cpu freq: 30 MHz boost ratio: 0.0% (30.0MHz)
pcmbufdesc: 0/21

CPU frequency


Frequency: 30000000
boost_counter: 0

Selecting another track via file browser starts the playback again.

fml2 commented on 2008-06-25 18:27

And here is the output of ‘ls -l’ in that directory (removed unneeded columns).

6713472 01_Merano.mp3
6125696 02_The Russian And Molokov _ Where I Want To Be.mp3
8960128 03_Opening Ceremony.mp3
2224256 04_Quartet (A Model Of Decorum And Tranquility).mp3
5300352 05_The American And Florence _ Nobody’s Side.mp3
5580928 06_Chess.mp3
4534400 07_Mountain Duet.mp3
2785408 08_Florence Quits.mp3
1448064 09_Embassy Lament.mp3
2930816 10_Anthem.mp3
4829312 11_Bangkok _ One Night In Bangkok.mp3
3358848 12_Heaven Help My Heart.mp3
1779840 13_Argument.mp3
4087936 14_I Know Him So Well.mp3
3756160 15_The Deal (No Deal).mp3
5296256 16_Pity The Child.mp3
10434688 17_Endgame.mp3
10051712 18_Epilogue_ You And I _ The Story Of Chess.mp3

I have now been able to reproduce the bug too on a H300. Here are some observations:

The occurrence of this bug seems to be influenced by the size of the available playback buffer. In order to reproduce the bug with a particular album i either have to enable “Load To RAM” (database) and Dircache or artificially decrease the buffer by increasing the PLUGIN_BUFFER_SIZE to 0×160000.

Observations in the buffering thread screen that as far as i can see differ from normal operation:
During playback of the last song rebuffering occurs, but the buffer did not get filled with the entire remaining data of the song (even though there was enough space left to buffer the entire rest of the song).
Shortly before playback stops, when the usefl buffer gets very low the real buffer also starts to decrease quickly, first a big jump and then multiple smaller jumps in rapid succession (i think during normal operation the real buffer only decreases occasionally in larger chunks at track transitions or shortly before rebuffering).

then playback halts with 55 seconds remaining in the last song with the disk spinning. rockbox stays responsive until you press STOP, then it freezes.

mp3 (lame,vbr) on H300 with r17791.

I was now able to reproduce the issue in the H300 uisimulator (r17802) with default settings except for “repeat”, which i had to set to off.
In the files buffering.c and playback.c i uncommented the ‘#define LOGF_ENABLE’ line (i guess the messages from those files might be of interest). No other changes.

The console output is attached. Hopefully this helps to find the cause for this behaviour.

Ok, after staring at the log for a while and comparing to a working album i think i have found a reliable reproduction recipe for this bug:

In preparation you have to find 3 tracks that meet the following criteria:
- The added size of tracks 1 and 2 needs to be smaller than the audio buffer.
- The added size of all 3 tracks needs to be bigger than the audio buffer.
Then put the files in a separate folder, start the Player, reset settings, turn off repeat and play that folder.

To save time i would recommend to use files with a low compression like flac.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing