After a long odyssey through the realm of musicplayers i settled with mopidy, beets and rompr.
I am almost happy.
For now i am stuck with 3 separate repositories, a sqlite database (beets), a json file (mopidy) and a mysql DB (rompr). Keeping these repos in sync is more hassle, than it should be. While it is relatively easy for unidirectional replicable information like filepath etc. it becomes tricky with playcounts, ratings and tags.
I discussed this already at some length with the developer of rompr. (http://sourceforge.net/p/rompr/discussion/general/thread/91fcff55/)
We came to the conclusion a backend extension, that gives mopidy access to the rompr DB might be a good idea.
I will try to describe this idea in more detail.
Rompr has a menu item that starts a scan over all available backends and stores that collection in a mysql db. This allows for a speedy presentation of the navigation tree and the ability to tag and rate any track no matter what backend. This concept obviously breaks when rompr is not the only client being used. Being able to access mopidy through different clients is the main advantage over other more monolithic setups. I like the fact that i can use beets autoplay or use a lirc remote to send some mpc commands. Therefore me thinks information like ratings, tags, playcount, skipcount etc should be handled by the player(mopidy) and not (exclusivly) by the client.
I would like to look at writing a backend extension that would provide the following features:
- global scan.
While this already can be done through rompr, a cmdline tool would be nice as it allows for nightly cronjobs.
- find or create
If a playing track can not be found in the DB write it to the DB.
- playcount
increment the playcount
- skipcount
When a song is skipped (next song while playing) increment a skipcount. I like to use skipcounts to autorate tracks for compiling random playlists.
- rating
Allow clients to send a 5 Star rating request
- tagging
send clients a list of existing tags.
Allow clients to send a tagging request.
- nav tree
allow other clients to query DB for building a Navigation tree.
This should roughly sum up the basic concept.
What are your thoughts on that?
I’m still not sure why you’re using the beets database and mopidy’s json database. If all your local music is in beets and you run mopidy-beets, rompr will create its collection directly from mopidy via mopidy-beets. So that only gives you two databases to manage. It’s still not ideal but it’s better than what you’re doing. If you access mopidy from different clients they’ll use mopidy-beets too, so mopidy’s local files database is unnecessary for you. So the ‘central repository’ that you’re talking about is your beets database.
A nightly cron job to update rompr’s database via some kind of mopidy extension is feasible but currently this requires the mopidy HTTP API - it cannot be done via the mpd backend.
You also need to bear in mind that rompr’s database only stores a subset of the tag information in the files. I’ve no need to store genre, composer, perfomer, etc because I get those from mopidy’s playlist when I need to display them. All rompr stores is enough information to display the collection, along with tags and ratings, so this may not work well with other clients. Expanding the database to store all tag information would cause performance and maintenance headaches that I’ve no desire to get into. So mopdifying beets to use rompr’s database is a no-go.
A mopidy extension to access metadata via rompr’s database is a good idea, but this would require mopidy to have a metadata API which does not currently exist.
I am using beets for my files that are recognized and can be auto tagged via musicbrainz.
And i use mopidy local for recordings, podcasts, radio dramas etc.
You are right this could probably all handled by beets alone.
But this still leaves my play counts and ratings in beets and my play counts and ratings in rompr unsynced.
I therefore still think storing play counts and ratings should be stored through mopidy.
So i think Mopidy-Local-SQLite could be extended to store play counts and ratings.
Files that are not in the db could be added when played, just as rompr does it.
Setter and Getter Methods could be exposed via Mopidy-Http.
Clients could store their Ratings in their repo and send a setter request to mopidy.
Starting with playcounts should be easier.
If all your local music is in beets and you run mopidy-beets, rompr will create its collection directly from mopidy via mopidy-beets.
This is good to hear, but unfortunately not (yet) working for me. I will elaborate in the rompr forum.
Expanding the database to store all tag information would cause performance and maintenance headaches that I’ve no desire to get into.
ACK. Does that also mean i will not see a collection structured by genre in rompr in the near future?
A mopidy extension to access metadata via rompr’s database is a good idea, but this would require mopidy to have a metadata API which does not currently exist.
Is this something that can be provided by an extension via Mopidy-Http or does this require changes in core?
Thank you, for providing this information. These discussions help me a lot to better understand where in the beets-mopidy-rompr setup a specific functionality can best be achieved and why all this duplication is needed.