Rockbox

Also, this appears to happen to the database, as well, although refreshing is simple enough.

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.

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.

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).

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.

On the contrary, reverse-engineering means that you *don't* have the code, which is why it is a difficult task.

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.