Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

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

Attached to Project: Rockbox
Opened by Marc Beeson (flagger) - Friday, 20 October 2006, 15:43 GMT+2
Last edited by Nicolas Pennequin (nicolas_p) - Wednesday, 09 January 2008, 00:49 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type SW-codec
Severity High
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

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.
This task depends upon

Closed by  Nicolas Pennequin (nicolas_p)
Wednesday, 09 January 2008, 00:49 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r16028.
Comment by Steve Bavin (pondlife) - Thursday, 07 December 2006, 09:09 GMT+2
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.
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 11:26 GMT+2
Steve,
I'm using daily 22/12 2006, the bug is still there
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 12:31 GMT+2
the bug occurs only if the directory of the autoresumed file was renamed.
the bug reproduces in the sim too.
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 12:34 GMT+2
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: 0x0
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: 0x0 bytes
First frame is at 0
We open the real file 'archos/.rockbox/codecs/mpa.codec'
---8<----
the display says 'Loading..' and its hung..
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 12:50 GMT+2
button-loops and queues are running but it seems like no one is around to answer them..
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 14:28 GMT+2
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!
Comment by Tobias Bengtsson (ydo) - Thursday, 28 December 2006, 14:41 GMT+2
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 0x08082599 in audio_new_playlist () at playback.c:3359

When I set start_play=true manually it works!
Comment by Steve Bavin (pondlife) - Tuesday, 31 July 2007, 15:57 GMT+2
Still a bug - and reproducible in the sim!
Comment by Daniel Stenberg (bagder) - Friday, 28 September 2007, 22:48 GMT+2
I removed the previous comment. Please stay polite and friendly.
Comment by Nicolas Pennequin (nicolas_p) - Tuesday, 27 November 2007, 19:51 GMT+2
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.
Comment by Brian Hall (brihall) - Monday, 07 January 2008, 16:35 GMT+2
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...