Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System SW-codec
  • Severity High
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by flagger - 2006-10-20
Last edited by nicolas_p - 2008-01-08

FS#6215 - player crashes after trying to resume deleted music file

After deleting a music track and auto resume is on, player will crash if a new music file is selected after auto resume is attempted. current workaround is to start device, turn off auto resume, turn off device, turn on device, select new music file, turn auto resume back on.

Closed by  nicolas_p
2008-01-08 23:49
Reason for closing:  Fixed
Additional comments about closing:  

Fixed in r16028.

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.

ydo commented on 2006-12-28 10:26

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

ydo commented on 2006-12-28 11:31

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

ydo commented on 2006-12-28 11:34

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..

ydo commented on 2006-12-28 11:50

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

ydo commented on 2006-12-28 13:28

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!

ydo commented on 2006-12-28 13:41

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!

Project Manager

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing