OK, I think both are the same bug, related to reshuffling interfering with
existing playback. Try this (tested on today's CVS):
- create or use a folder with 3 audio files.
- enable shuffling and shuffle-repeat
- play, then skip tracks twice (ie. to the last track in the list).
- on the last track, fast forward to near the end to let it end naturally.
When the end is reached, nothing will happen, the WPS is still updated but
the track never finishes, another track never plays. You may be able to
press some buttons (eg. skip forwards/backwards), the WPS may still update,
but nothing will play. Going to the fileview usually crashes instantly, or
when you try to load another file. Either way, a hard lockup is imminent.
Glancing at the code, I notice that sometimes
audio_flush_and_reload_tracks(); is called after randomise_playlist(), but
sometimes it isn't. So far haven't found the exact spot where it locks - if
somebody knows what they're looking for, please try, else I will play with
it again in the next few days.
--
gl
----- Original Message -----
From: "gl" <[EMAIL PROTECTED]>
To: "Rockbox development" <rockbox-dev@cool.haxx.se>
Sent: Tuesday, March 28, 2006 9:58 AM
Subject: Re: Track skipping & shuffling cause hard lockups.
How long is "long periods" because I took a post-tagcache build on a four
hour drive, and shuffled the whole time without a lockup on an H120, so
whatever problem you're having with lockups *may* be target-specific.
Also, have you tried non-shuffle for long periods to see if it locks up
to (with the same or a recent build?) Just wondering if it could be
something else (maybe an aging HD, or who knows what....)
Well mine's an H140, so same target. I left it running overnight on
repeat-all (non-shuffle), and that survived fine. I've seen shuffle fail
after about 6 tracks, but it often takes more. I didn't update yesterday
though so I'll test it again later.
--
gl
