search

andrewrk / groovebasin

Music player server with a web-based user interface.
MIT License
1.89k stars 119 forks source link

abstract file system interaction and let users supply their own storage backend #440

Open andrewrk opened 9 years ago

andrewrk commented 9 years ago

Currently Groove Basin depends on the file system for the music collection and for the database. It should be possible for users to provide their own storage backend for the music collection. One person for example wanted their music to be stored on S3 instead of their own hard drive. Another person is writing their own content storage mechanism and they want to use it with Groove Basin.

thejoshwolfe commented 9 years ago

Groove Basin also depends on file system change notifications. Would that be required for an alternate backend?

andrewrk commented 9 years ago

It could be an optional component. If you implement it then we can take advantage of it, otherwise manual rescans will be necessary.

alaricsp commented 9 years ago

Guy who's written his own content storage mechanism and filled it with music here ;-)

My use case is that I have an API that can be asked to do stuff like "Tell me the file IDs of all things with artist=U2" or "Find me all values of the "album" property where artist=FOO" (to find albums by FOO), "tell me all the metadata of file ID BAR", and "stream me the content of file ID BAR" (I could do seeking, too, but haven't had the need yet). It supports arbitrary key=value metadata, and it's for storing all sorts of stuff, not just music - it's a general storage system for my read-only files, such as family photos and downloaded installers and interesting PDFs and archived customer projects.

More info here: http://www.snell-pym.org.uk/archives/2014/10/26/further-progress-on-ugarit-archival-mode/

The weakest level of integration would be for me to query my API for a list of all music files, and then let GB do its own thing of seeking into them to read the tags and build its own library index, and have it subscribe to updates I can give when new files appear. Or disappear.

The strongest level of integration would be for GB to not maintain its own database at all, except maybe as a cache, and to directly hit my API with metadata queries to find stuff. That'd avoid having to keep the local index synched and stored safely, and would mean that my interface for hand-editing metadata in the archive will still work (as those changes don't get written to ID3/ogg metadata tags...)