Rockbox

Hi Marc,

Some changes to the audio initialisation sequence have been made - can you grab a CVS or daily build and see if this is still a problem for you? Please report back here either way.

Steve,
I’m using daily 22/12 2006, the bug is still there

the bug occurs only if the directory of the autoresumed file was renamed.
the bug reproduces in the sim too.

the folder ‘music’ was renamed to ‘mus’ This comes out when I choose the ‘new’ file.
—8←— We open the real file ‘archos/mus/Swing.mp3’ ID3V2 Length: 0×0 Header: fffb9044, Ver 0, lay 3, bitr 128, freq 44100, chmode 1, mode_ext 0, emph 0, bytes: 417 time: 1280/49
Space between ID3V2 tag and first audio frame: 0×0 bytes
First frame is at 0
We open the real file ‘archos/.rockbox/codecs/mpa.codec’ —8←— the display says ‘Loading..’ and its hung..

button-loops and queues are running but it seems like no one is around to answer them..

enters an eternal loop in audio_loadcodec (start_play=false) at playback.c:2577
2577 copy_n = MIN(conf_filechunk, filebuflen - buf_widx);
(gdb) n
2578 rc = read(fd, &filebuf[buf_widx], copy_n);
(gdb)

conf_filechunk == 0 ⇒ copy_n == 0 ⇒ reading forever!

setting conf_filechunk manually > 0 loads the codec and info comes up in WPS..
however, it does not play..

bt
#0 audio_fill_file_buffer (start_play=false, rebuffer=true, offset=0)

  at playback.c:2933

#1 0×08082599 in audio_new_playlist () at playback.c:3359

When I set start_play=true manually it works!

Still a bug - and reproducible in the sim!

I removed the previous comment. Please stay polite and friendly.

The crash appears to be fixed. In the test I performed, the following track was resumed at the same offset as where the deleted track was when I stopped playback.

I think this bug still exists, or at least I am experiencing a similar hang on resuming a non-existent file.

I see this frequently with podcasts- I will listen to one, delete it via rockbox, and on the next power-up it hangs when trying to resume the file. It looks like it is selecting the next file, but resuming at the position of the last (deleted) file. In the case of podcasts, the new file might be significantly shorter than the previous, maybe trying to resume far enough after the end of a file causes a hang?

The only way I’ve found to fix this once it occurs is to delete the playlist control file from a PC connection (reset doesn’t help).

Player is a H320. I’ve seen this problem on multiple builds over the last 3-4 months. Currently running r15989-080103.