Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#12467 : [Fuze+] Deleted/Lost Settings



FS#12467 - [Fuze+] Deleted/Lost Settings

Attached to Project: Rockbox
Opened by Tyler Johnson (HaloNachos117) - Monday, 19 December 2011, 00:43 GMT
Last edited by amaury pouly (pamaury) - Tuesday, 30 October 2012, 12:28 GMT
Task Type Bugs
Category Configuration
Status Closed
Assigned To No-one
Operating System Sansa Fuze+
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This bug seems to only affect the Sansa Fuze+ player. It seems that the settings and the current playlist stored on the device disappear at random. This bug has happened on multiple Rockbox builds, new and old. This is not 100% reproducible, except sometimes when updating to a new build. It also seems to happen when using the OF for an extended period (eg, charging the device). Perhaps it's a problem with the OF?

Workaround: keep a backup of all your settings. It might also be a good idea to backup important playlists. If you encounter this bug, restore the your backup settings (or playlist).
This task depends upon

Closed by  amaury pouly (pamaury)
Tuesday, 30 October 2012, 12:28 GMT
Reason for closing:  Out of Date
Additional comments about closing:  reopen if still a problem
Comment by Tyler Johnson (HaloNachos117) - Monday, 19 December 2011, 23:46 GMT
Also, this appears to happen to the database, as well, although refreshing is simple enough.
Comment by Tyler Johnson (HaloNachos117) - Sunday, 25 December 2011, 00:09 GMT
I've realized something yesterday... This seems to happen when the OF is forced to do a "reset', which is the manufacter's term for a forced shutdown. Now, I can reproduce this problem, and I think it can be avoided by backing up everything in Rockbox before rebooting into the OF.
Comment by Tyler Johnson (HaloNachos117) - Monday, 16 January 2012, 00:20 GMT
It seems, I have discovered more about the nature of this bug. When I tried to upgrade my build of Rockbox using the OF's MTP mode, some of the files (in particular, the RB config file) refused to copy, saying something about the file being in use. I've encountered this problem before, often there's something on the device's memory that it isn't displaying right now (I'll explain why in a minuet), so transferring a file with this same name in this same location won't work. Normally, the file would be overwritten, just as one might expect. However, the OF on this thing is so bad, MTP mode only displays files this thing "knows" about. Therefore, you must make this device "learn" about the configuration file, which might prove a difficult task, as this device's OF is crap when it comes to "learning" about files.

I think I've figured out two solutions (okay, there more like workarounds).

Solution #1 (this is the one that worked for me) Boot into the OF, and connect using MSC mode. Copy everything Rockbox-related onto your hard drive (including RB, itself. Coping the Bootloader won't be necessary). Then, delete the "hidden" *.dat files from the root directory of the Internal Memory. Unplug, and load OF. Wait for DB refresh. This might be faster if you remove your external memory card (assuming you use one). Please note: the OF's db refreshing is crap (which is probably why all this is happening in the first place), so it will take an unnecessarily long to do. Once it's done, however, the problem *should* be fixed for now. Just to be safe, I reconnected in MTP mode, and recopied all RB-related stuff manually. It's important to do this in MTP mode, as this thing is smarter about "learning" about files this way. IDK if it's necessary to do this at all, though. I just did it to be safe. Once I forced the OF to "reset", I noticed that nothing in RB changed, not even the DB, which was left in tact for once!

Solution #2 (Please note that I haven't tried this yet, so use at your own risk) Connect the OF in MSC mode. Copy everything Rockbox-related onto your hard drive (including Rockbox, itself). Then, delete everything you've just copied. Reboot into the OF. Be careful, though. I'm not sure what will happen if the bootloader tries to boot into a missing RB installation. It might be wise to temporarily reinstall the OF to delete the RB bootloader. Let the OF refresh. Then, reconnect in MTP mode. Re-transfer all RB stuff (Including RB, itself). Unplug and boot into the OF. Let the DB refresh. If you removed the RB bootloader, reinstall it now.

In conclusion: the OF's database sucks, so it might not know about files added on by RB, nor will it know about files changed in MSC mode (regardless of which firmware it's running), so It's best if you use MTP in the OF wherever possible. This is specifically important when modifying the DB or updating RB. Or, be prepared to delete the *.dat files on the root directory, and wait for a long DB refresh. Or, just avoid using the OF at all.

All the same, if Rockbox can be made to monitor the *.dat files on the internal memory, and update them when something inside RB changes, that might be a good permanent solution. It's too bad I know nothing about writing software, or I'd be glad to look into implementing something like this myself.
Comment by amaury pouly (pamaury) - Monday, 16 January 2012, 10:38 GMT
I don't see the point. This sounds like an OF problem. You don't even need the OF to transfers file since Rockbox has USB support. Furthermore, if it only happen on OF reset, it should never happen because you hardly need to reset the OF. You understand that we do not want to add extra code just because the OF has a strange behaviour, and anyway we don't know the OF database format (which might be complicated).
Comment by Tyler Johnson (HaloNachos117) - Tuesday, 17 January 2012, 06:43 GMT
Here I was afraid no one was listening. :D.

As I said before, a "reset" is the manufacture's word for a forced shutdown (eg pressing and holding the power button if the device freezes). Sometimes the device just shuts down without warning, especially when playing files that the device has, for whatever reason, failed to *properly* analyze the the file (especially *.avi videos). And yes, RB does have USB support, but unless you transfer RB-related files like I mentioned above, the OF will mess with them for some reason (thank goodness Rockbox's core files are left intact).

I always assumed that you had to reverse-engineer the OF to figure out how the hardware works (which, I assumed meant you had access to the entire source code, so you could figure out how *everything* works). I guess this just goes to show what I know :). However, I see your point with adding extra stuff to Rockbox, so I can respect that. In any case At least this workaround seems to work.
Comment by amaury pouly (pamaury) - Tuesday, 17 January 2012, 09:31 GMT
On the contrary, reverse-engineering means that you *don't* have the code, which is why it is a difficult task.
Comment by Tyler Johnson (HaloNachos117) - Wednesday, 08 February 2012, 03:31 GMT
Okay, it seems, judging from the lack of comment here and on the forum, I'm the only one having this bug. My workarounds DO NOT seem to work anymore. I've been backing up my config file on the External card, and removing it every time I force the OF to shut down. However, I just had a 45-minute bus ride today, and only spent 5 minute or so actually listening to music. The rest of the time was spent fighting the Fuze+. So, in my desperation, I reformatted the internal memory (after removing the card), and re-copied everything from my personal backup. Not only does the OF seem to boot faster, but this bug seems gone for now. I guess it wasn't really a bug after all. It seems my file system was corrupt (strange how many times I'd used Check Disk on it, and no problems were detected). I will keep experimenting, and see if this really fixes the problem, or if I just got lucky.

Admin, if you don't here from me in... oh let's say a week, fell free to close this thread.