- Status Closed
- Percent Complete
- Task Type Bugs
- Category User Interface
- Assigned To No-one
- Operating System All players
- Severity High
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Version 3.0
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Rockbox
Opened by Steve Bavin - 2006-10-06
Last edited by Nils Wallménius - 2007-11-20
Opened by Steve Bavin - 2006-10-06
Last edited by Nils Wallménius - 2007-11-20
FS#6129 - Pressing stop on startup with auto-resume crashes
As reported (by Deb) as a secondary issue to FS#5536 :
“play a track and stop it in the middle and then shut down the player
start the player (auto-resume is on) and while it’s resuming (but before it resumes) press stop. it freezes completely and need a reset”
I have reproduced this on an H340 too.
Closed by Nils Wallménius
2007-11-20 15:55
Reason for closing: Fixed
Additional comments about closing:
2007-11-20 15:55
Reason for closing: Fixed
Additional comments about closing:
works for me too now :)
I added
FS#6317as a related task as it appears to be the same issue but in different situations.is this still happening? I just checked on my h300 (with the resume point at about 15min into a 20min track) and it didnt crash.
I managed to trigger it with a cvs build from 30 decmber so it seems to still be here.
edit: with my h320 and a flac file about 20 megs.
I would expect lockup while resuming to still exist, sure. I never found the need for an urgent bandaid fix since it’s easily avoided. After the holdidays and associated obligations I gotta get my head back in the game and continue the playback reworking that I started a few days before xmas.
I reopened this because I can still trigger it reliably on my h320 with the latest current build, this time playing vorbis.
If i press stop as soon as I see the wps on startup, bang, every time.
This could probably be fixed in the short term if codecs get a reply while waiting for the audio thread but all have to behave predicably when the buffer callback returns false. Atm you can get a bunch of codec failures after forcing them to exit like that. Will investigate that. It could have another reason in playback.
Has this been fixed now? Seems ok here…