Rockbox Development > Feature Ideas

Seamless Memory Card Integration

(1/3) > >>

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:

--- Quote from: RChickenMan on January 10, 2010, 06:53:30 PM ---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?

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page