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: 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
2008-01-08 23:49
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
Fixed in r16028.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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)
#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.