This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12125 - Use persistent dircache without HAVE_EEPROM_SETTINGS
|
DetailsThe patch allows to use the persistent dircache even in targets that do not define HAVE_EEPROM_SETTINGS.
Starting trying to implement such a feature for my iPod Video, I "discovered" the functions dircache_load/save (I have a slight knowledge of the RB software). Investigating why it was not used on my target, I saw that it's conditioned to the define HAVE_EEPROM_SETTINGS without an apparently reason to limit them just to some targets. So, I simply "detach" the functions definition and use from the define. I'm using it since an hour, starting up and shutting down the DAP various times, jumping back and forth inside the dynamic play list, and I got no problems at all. If I guess correctly the code, the dircache should be updated also when changing the DAP content, if the USB connection is done by RB and not the OF. It's applied to r29907. |
This task depends upon
So I generated tools/dircache with the only purpose, for now, to scan the current directory and build the dircache just like the FW does.
The tool compiles, but, due to my very poor knowledge of the software architecture, it segfaults.
Anyway, I put here the patch, so if someone want to give some hint or continue the development, he/she has some base.
Unfortunately, I haven't sufficient spare time to study the FW, so my development will advance extremely slowly, but I think the advantages got by the feature are enough to involve someone with more knowledge! :-)
Having said that, how hard would it be to make dualboot 'not a problem'. E.g. by persisting some sentinel information across rockbox boots, that the dualboot/OF is known to remove. (for example, ipod (at least ipod 5g) is known to persist iram contents across boots, could we encode "rockbox has shutdown" somewhere in there, and if on rockbox reload that information is still there we assume dircache is still valid?)
(noting
FS#11149, naturally)