Seamless Memory Card Integration

[RChickenMan]

Hello Fellow Users and Developers,

Perhaps I am not the only one to purchase an old flash-based, microSD-equipped player with the idea of having a small, solid-state rockbox-compatible player with a crap ton of storage for very cheap (in my case, a Sansa e200).  The idea seems brilliant, until you realize that, especially for those of us who use folder-based as opposed to tag-based navigation, you don't have a single 24 GB music library, but two separate 8 GB and 16 GB libraries.  I hate having to make rational choices as to which media goes where (at this point I'm settled on using the 16 GB storage for albums, and 8 GB storage for compilations).  Surely I am not the only person out there who wants a list of ALL album/compilation folders in one browseable list?

I am proposing a feature as simple as allowing the merging the root directory of both the device's internal storage and the memory card for the file/folder browser.  If this is possible with what we have today (using some combination of clever tricks, i.e. the shortcuts plugin), I would love to hear about it.

I should point out that I do have a lot of developing experience (I am a developer by trade and by training), and am open to the idea of solving the problem myself.  I don't want to do this in baseline code, as it would make my life a living hell every time I want to upgrade.  In fact I haven't even looked at the baseline.  I would much rather do this as a plugin, however my understanding is that the plugin engine is good for little more than different types of file viewers and stand-alone applications, not changing the behavior of the system UI.

I also have to admit that I've never contributed to an open source project before.  If I did make a simple change to the baseline that would allow this feature to be configured, how hard is it for a guy off the street like me to actually check my changes into the source control and have them actually included in the baseline in future releases?

[yapper]

I also have to admit that I've never contributed to an open source project before.  If I did make a simple change to the baseline that would allow this feature to be configured, how hard is it for a guy off the street like me to actually check my changes into the source control and have them actually included in the baseline in future releases?

See http://www.rockbox.org/wiki/GeneralFAQ#I_want_to_join_the_development_t

[JdGordon]

everyone else seems content with the microSD slot coming up as <microSD> in the filebrowser, so unless you dive into the code its unlikely this will happen.

Also, it would probably be easier to do this in the core instead of a plugin.

[GodEater]

The only way I can think to do this is to implement something like UnionFS in Rockbox's core.

This present's several challenges, not the least of which being that "Implementing new filesystems" is on the Rockbox NODO list. Also, I can't see any way you could do this as a plugin, it would have to be in the core.

Edit:
Just to be clear, I find this idea quite interesting myself, but that NODO has been around for a long time and a lot of the developers would likely need a lot of convincing to ignore it in this case. The biggest issue with non FAT filesystem support is that FAT is ubiquitous, and virtually every PC operating system supports it. Other filesystems tend not to be so operating system agnostic, and UnionFS is no exception.

[JdGordon]

ignoring what I just said, and the NODO issue.... I tihnk this could actually be done pretty easily.

each time a directory is opened (/music) just open the same path on the microsd chip also and append the found files... rockbox doesnt support relative paths which should make this easier. doing a file open would be something like try opening /music/a.file, if thats not found then open <microSD>/music/a.file instead.

I have no idea how writing would work though.

[AlexP]

How would this play with dircache?

[saratoga]

The only way I can think to do this is to implement something like UnionFS in Rockbox's core.

This present's several challenges, not the least of which being that "Implementing new filesystems" is on the Rockbox NODO list. Also, I can't see any way you could do this as a plugin, it would have to be in the core.

FWIW this is something Llorean and I have discussed doing before after seeing it work in XBMC.  We don't need a new file system.  Instead when you load dircache, you just recursively merge folders in both volumes.  Writes go to whichever disk contains a folder, unless both do, in which case you just have a default disk.  I spent some time looking into it but never really got anywhere with it due to knowing so little about that part of rockbox.   

[JdGordon]

I would totally ignore dircache for now (the only multi-storage devices are flash and it can be argued that dircache acheives nothing on those targets).

I (very naively) think this can be done with only changing open() and dirread(). I might have a go this arvo at it...

[gulak]

I implemented something like this sometime in 2008. As far as I can tell is that I only made modifications in these three files:
filetree.c, onplay.c, playlist.c

everyone else seems content with the microSD slot coming up as <microSD> in the filebrowser

Not everyone.

[saratoga]

I implemented something like this sometime in 2008. As far as I can tell is that I only made modifications in these three files:
filetree.c, onplay.c, playlist.c

everyone else seems content with the microSD slot coming up as <microSD> in the filebrowser

Not everyone.

Post the patch.

[gulak]

Post the patch.

No I can't. Because I made too many changes to the original source. I don't know which one is really related to this issue and it was too long ago. You can download a patch with all my modifications here.
Look for everything between CUSTOM_MERGEMEM. The rest you can ignore.