bug: Rockbox (randomly) freezes during playback

[Lear]

If you have your player in a pocket while walking, the disk may have problems reading, which would cause the drop-out. Increasing the anti-skip buffer a little can help, if that's the case. (That's why Miika set the max value to 10 minutes, which I thought was excessively large... ).

Codec failure could be caused by a bad file, though it doesn't sound like it in this case...

[petur]

If you have your player in a pocket while walking, the disk may have problems reading, which would cause the drop-out. Increasing the anti-skip buffer a little can help, if that's the case. (That's why Miika set the max value to 10 minutes, which I thought was excessively large... ).

This I can't believe....

I use my h340 on my bike (it sits in my pocket) and have never ever experienced dropouts. anti-skip buffer is set default afaik.

If the player is bumping so much it starts skipping, prepare for some serious HD damage soon

[pabouk]

I have noticed a new bug invoked uder similar conditions as the old one. How to reproduce it:
1. Play an MP3 file (not the last one in a directory).
2. Seek near to the end of the file (i.e. 30 seconds before the end).
3. Stop the playback. (Resume point is stored.)
4. Resume the playback by pressing PLAY.
5. Seek before the time point of resume. (Rockbock will rebuffer.)
6. Wait till the beginning of the next track.
7. Sometimes the beggining of the file will be played twice. During the first playback the displayed time will show 0:00 or a nonsensical time.

[dunno]

does this occur with 'Auto Change Directory' enabled or disabled ?
is crossfade enabled or disabled ?.
have you tried the same thing with the DEFAULT rockbox settings ?

[Rincewind]

If you have your player in a pocket while walking, the disk may have problems reading, which would cause the drop-out. Increasing the anti-skip buffer a little can help, if that's the case. (That's why Miika set the max value to 10 minutes, which I thought was excessively large... ).

Codec failure could be caused by a bad file, though it doesn't sound like it in this case...

I don't jog with my player, so this isn't the case. And I don't have corrupt mp3s either, failing mp3s work when I select them directly.

I think the cvs updates of today should fix my problems, they started approximatly when I began using the runtimedb.

[pabouk]

does this occur with 'Auto Change Directory' enabled or disabled ?
is crossfade enabled or disabled ?.
have you tried the same thing with the DEFAULT rockbox settings ?

I would have mentioned any "fancy" settings. BTW 'Auto Change Directory' should not affect this bug. You can try it yourself, it is very easy to reproduce.

[dunno]

does this occur with 'Auto Change Directory' enabled or disabled ?
is crossfade enabled or disabled ?.
have you tried the same thing with the DEFAULT rockbox settings ?

I would have mentioned any "fancy" settings. BTW 'Auto Change Directory' should not affect this bug. You can try it yourself, it is very easy to reproduce.

Have you tried to reproduce this bug with rockbox DEFAULT settings, and
Have you done a CLEAN install of ALL files.


p.s. i can reproduce this bug, and I have informed the playback dev of this bug, so hang in there, a fix is in the pipeline.

[dunno]

nope that commit wasn't for this bug

[Rincewind]

ok, i found a way to reproduce my codec failure bug. It has something to do with automatic folder skip and the file browser.

To get this bug (only tested on the Iriver H120) you have to do the following:

1. Enable automatic directory change
2. Play the last file in a directory
3. When the file plays, enter the browser by pressing Navi, but don't select a new file
4. When playing file ends, the disc spins up and tries to load the first song in the next folder but it is not starting, instead I get the splash "codec failure!" or "can't load codec". Then Rockbox tries to load a different file and fails again and so on. If you enter the wps when this is happening (by pressing PLAY) the WPS says "No file!"

My guess is, that directory change needs some data from the wps thread but doesn't get it because we are in file browser.

I was getting this error because I didn't use hold when putting my player in my pocket and NAVI got pressed accidentally.

If someone can confirm this, I post a bug report to Flyspray.

[bascule]

Confirmed exactly as described.

If you go back to the WPS it does eventually calm down and start working, but many folders later...

Tested on H120 with CVS060807

[MoD]

If someone can confirm this, I post a bug report to Flyspray.

With CVS build 060807-1823 for iHP120 I wasn't able to reproduce your freeze. 

I tried directory switches like ../ -> ./nextmusicfolder_in_row/*.mp3 and ../../ -> ./next_artist_folder_in_row/first_album_folder_in_row/*.mp3 . Both worked for me while being in the file browser.
I also tried to play directories where codecs switches occur (mp3 -> ogg, ogg -> mp3) from one directory to the other.  The only bug I found was the next song tag didn't appeared in the WPS while playing the last song of the first directory.

[Rincewind]

I submitted a bug report:

http://www.rockbox.org/tracker/task/5797

bascule and MoD, maybe we can compare our settings and see what is different with our configuration:

crossfade: off
crossfeed: on
eq: on
directory change: on
Tagcache is loaded in RAM (but view is set to "all files")
gather runtime data: on
File Types: only mp3

[MoD]

Your right, maybe it has something to do with the settings, here are mine:

crossfade: off
crossfeed: on
eq: on
directory change: on
Tagcache is not loaded in RAM (but view is set to "all files")
gather runtime data: off
File Types: mp3, ogg

Additional configs maybe also important concerning this issue:

Follow playlist on
Replaygain on

[bascule]

I set the necessary options ('cause I normally use tag cache), rebooted and can still reproduce this bug.

I guess it's one of two things:
Either loading the buffer is disrupted by the file browser being open/in use
Or the file browser itself cannot cope with needing to dynamically change directory view

The only problem I have with the first one is that *I would have thought* that the buffer refill code would check to see if Autochange Directory was set when choosing which songs to bring into the buffer, i.e., it could pre-fetch from the 'next' directory when refilling the buffer near the last song of a folder.

However, it doesn't appear, from my limited testing of playing folders with few songs in and checking the audio thread, that this happens, so when it reaches the end of the last song, it always has to access the disk to fill the buffer and the combination of the buffer fill with the file browser open causes the error.

I've added some of my other config choices that may be relevant...

crossfade: off
crossfeed: off
eq: off
shuffle: off
antiskip: 30s
follow playlist: on
all voicing/talk options: off
dircache: on
directory change: on (obviously )
Tagcache is loaded in RAM (but view is set to "all files")
gather runtime data: on
File Types: mostly .ogg

[Rincewind]

so far, only the tagcache in RAM thing is different for MoD

other options I forgot:

follow playlist: on
dircache: on
no voiceing
replaygain: on

tomorrow I do more tests with disabling options and maybe I have look in the code, too. But the whole playback engine is magic for me.