Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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

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:  

works for me too now :)

Nils Wallménius commented on 2006-11-12 13:33

I added  FS#6317  as a related task as it appears to be the same issue but in different situations.

Jonathan Gordon commented on 2006-12-27 06:21

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.

Nils Wallménius commented on 2006-12-30 19:39

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.

Michael Sevakis commented on 2006-12-31 04:45

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.

Nils Wallménius commented on 2007-03-14 22:37

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.

Michael Sevakis commented on 2007-03-15 14:22

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.

Steve Bavin commented on 2007-11-20 14:44

Has this been fixed now? Seems ok here…

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing