Rockbox

I tried again with a more recent build (from February 4), and was still experiencing the same problem. Power down, reboot, resume playback and often RB starts playing a different song than when I powered it off and even though the shuffle icon is on, it plays the songs in sequence.

It appears that Rockbox isn't writing the proper .playst_control file.

Some discussion about it here:
http://forums.rockbox.org/index.php?topic=20016.0

Is there a chance this could be fixed in 3.2? This is a pretty annoying bug for those of us who use playlist files to listen to our collection... Thanks!

For me, since 3.1 (and I don't know how far back before that) and thru r20230 for AJBR V1, it's not random. The problem Jeff described happens every time. I've dropped back to r13900-070715 (chosen because I had it on my HD and used it previously) and playlist shuffle works as expected. Note that the .playlist_control files looks identical comparing the one from the latest build I've and loaded and r13900-070715 . I'd really like someone to look at this as for me, this problem is a sev-1. The latest versions of RB are usless for me until this gets fixed. Please feel free to contact me if I can be of any help in finding & fixing this bug.

Hi Gary,

If you can get yourself a working compiler, you should be able to work out exactly which change broke this. Given that you can reliably repro the problem that would seem a good way forward.

Read http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling for Windows, or http://www.rockbox.org/twiki/bin/view/Main/LinuxSimpleGuideToCompiling for Linux if you need help.

FYI, this is still broken asof v3.2

There's another closed bug that's very similar to this (http://www.rockbox.org/tracker/task/9531).

According to info in that, this commit was the start of the problem:
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=18561

And it was supposed to be fixed here:
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=19723

But perhaps it didn't?

The bug definitely still exists in the 3.2 release for Archos V1 Recorders. SHUFFLE ON is ignored after a power down/up cycle and playback does not restart from the song that was playing at shutdown. I've dropped back to an older 2.x build.

At first glance, the problem is that the playlist control file isn't being written to disk. However, this was intentional: when shuffle was toggled, related settings were stored in NVRAM, and so there was no need to write the playlist control file. These NVRAM settings are no longer saved. First the random seed was removed via  FS#9408  in http://svn.rockbox.org/viewvc.cgi?view=rev;revision=18555 and then the first index was removed in http://svn.rockbox.org/viewvc.cgi?view=rev;revision=18561 (as stated above by zipr).

Targets with dircache have playlist_flush_callback(). It is registered as a storage idle function, and so the playlist control file is flushed when the disk spins down or when the idle functions are explicitly called. Targets without dircache only flush the playlist control file when other changes are made to the playlist, or when playlist_shutdown() is called at shutdown or USB connect time. I have verified that the shuffle line is added to the playlist control file at shutdown on my V2 Recorder. However, resume is still wrong after that.

Another problem which I'm able to reproduce on my 5G 30GB iPod: When I first start shuffled playback of a directory, the track I selected is the first track in the playlist. When I stop and resume playback, it may not be at the top. The order of tracks is the same because the randomize seed is the same; the playlist is just rotated. (eg. some tracks from the beginning should be at the end.) The same behaviour happens on my V2 Recorder, when I power down (to flush .playlist_control), power up, and resume.

I reverted FS #9531 / r19723 in r20641. This fixes the problem I described in my previous comment here.

To make Archos targets remember shuffle mode, I see two options:
1) Ensure that .playlist_control is flushed, maybe via playlist_flush_callback
2) Store the information in NVRAM like before. This means reverting  FS#9408  and related commits. Preprocessor directives could be added, so the code is only used on some targets.

option 1) sounds better to me

On my Archos Recorder (v1) the power shutdown is achieved by holding the 'stop' button for 2 seconds or so, I think from memory this forces a shutdown at the hardware level. Would a 'playlist_flush_callback' have time to complete here? Maybe the NVRAM option would be better if so. I'm not a programmer at all or really familiar with the internals of rockbox, so I could be wrong here...

It should be possible to cleanly shut down an Archos Recorder (v1) by: "Double tap Off when playback is stopped"
http://download.rockbox.org/manual/rockbox-recorder/rockbox-buildch3.html#x5-240003.1.2
In the sim, a single press of OFF causes "Press OFF to shut down" to be displayed. This message might mislead some people into holding OFF. It should say something like "Press OFF again to shut down". Holding off forces a shutdown or a reboot; only do that if the device is locked up.

When Rockbox shuts down cleanly, the playlist control file should be written to disk. After powering up, resume should work properly even now. The only exception is if the battery is so low that disk writes are considered unsafe. That would be when the battery icon is blinking.

With option 1, any new .playlist_control data would be written to disk before the next disk spindown. For example, if you enable shuffle, that's not saved immediately; the next buffer filling saves it. I think this is good enough. It will only fail if the Recorder is shut down before that happens, and the shutdown is forced or battery level is unsafe.

I like option 1 because it seems I could then remove all explicit .playlist_control flushing and let the storage idle function take care of it. This would simplify code and reduce code size. That would be a separate patch, after this bug has been fixed via option 1.

Here's a solution using option 1) above. It ought to be good enough for the v1 recorder, but I still want to see it tested on one.

Here's how flushing of playlist control lines which don't have to be flushed immediately and syncing of the playlist control file happens:
- If storage idle callbacks exist, then playlist_flush_callback() is registered when lines are added and it runs the next time those callbacks run.
- If the callbacks don't exist, but dircache exists, playlist_thread() periodically calls playlist_flush_callback(). (Dircache does not need to be enabled for this.)
- If there are no callbacks and no dircache, each line is flushed and synced immediately. This leads to correct resuming but it is not good. It results in multiple flash writes for every line, and it makes other code redundant. This case only happens on iFP7xx and sims without dircache. I put a TODO in the patch. Maybe the best solution is to have a minimal playlist_thread() periodically flush and sync.

If flushes can be delayed, a flush is performed when resuming. This ensures that the resumed playlist is up to date.