Bug 125955 - Shared collections with user specific statistics
Summary: Shared collections with user specific statistics
Status: RESOLVED INTENTIONAL
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Local (show other bugs)
Version: 2.3-GIT
Platform: Slackware Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 124126 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-20 15:12 UTC by richlv
Modified: 2015-04-02 05:46 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
report in dynamic mode (17.66 KB, text/plain)
2006-09-11 12:19 UTC, richlv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description richlv 2006-04-20 15:12:36 UTC
Version:           revision 531369 (using KDE KDE 3.5.2)
Installed from:    Slackware Packages

it would be nice if amarok had support for keeping user stats separately from the collection database. that would allow several users to use single collection db (unified collection info, no repeated rescanning for every user + unique scores/ratings etc).

this probably is possible if using postgresql, but it should be easier to set up and possible with all backends.

the simplest solution i can imagine is like this :

amarok has configuration for db access. host, database and user can be specified.
now, unique tables should be identified and a single additional parameter in db setup is required - table prefix. common tables would not have this prefix added.
this way each user would get his own data in every backend used and could use a single, common collection.
Comment 1 Laszlo Pandy 2006-04-24 23:59:47 UTC
The whole point of a collection is to store all the data in a quick, easy to access place. In this proposed situation, what would happen if one person changed a tag on a song. Would each database keep its own metadata or would the change affect all collections? If not then you would have basically many collections all merged together, and share few if any tables.
It just seems it would be a lot easier to make several collections then trying to put many in one file? Is there a particular reason in your case that you can't just make separate collections?
Comment 2 richlv 2006-04-25 09:46:43 UTC
i proposed to separate only statistical data, so in case a tag is modified, it would be modified in common tables, thus the change would be propogated to all users.

why the need for a single collection with separate stats ?
if several people are using a single collection, that gives the benefits of tag fixing to all the users. this includes song data corrections, compilation status and preferably album covers. also collection rescanning can be done once for all users.

currently each user has to manage separate collection, which involves rescanning it for every instance of amarok, download album covers separately etc. this might be acceptable with small collections, but once they pass hundred gb, it is pretty annoying and takes a lot more resources.

note that postgres howto includes information on making this possible with db means, but having a unified approach would allow also mysql users to use this feature.
Comment 3 richlv 2006-09-11 12:19:12 UTC
Created attachment 17712 [details]
report in dynamic mode
Comment 4 richlv 2006-09-11 12:28:23 UTC
Comment on attachment 17712 [details]
report in dynamic mode

crap. attached to the wrong report.
Comment 5 Alexandre Oliveira 2006-12-31 22:08:20 UTC
*** Bug 124126 has been marked as a duplicate of this bug. ***
Comment 6 Steven Elling 2007-01-13 08:50:32 UTC
I would really like to see this feature implemented.

I have different listening habits based on where I am listening to music at and would like stats for these different locations.   I would also like it if all the different stats were aggregated into stats for the collection as a whole---possibly into the existing table(s) for stats.

I would go a step further with this feature request and want the ability to create separate "user profiles" for storing stats, as well as, allowing users to create different "stats profiles" for their different listening habits with aggregated stats for each user and the collection as a whole.

I realize the might be complicated but it would be a really nice feature.
Comment 7 Tim Lepes 2008-05-04 22:15:56 UTC
Here are my thoughts.  I was going to create a new bug, but figured this is the same vein.  I posted this all on the Amarok Wiki as a page linked off the proposals page...

== Multi-user support ideas... ==


There are a few multi-user scenarios to consider....

* More than one user at the same computer accessing the same collection, but maintaining individual preferences, ratings, etc.

* Multiple users on different computers accessing a central music store on a server, maintaining individual preferences, ratings, etc.
	There are notes on the Postgres how-to about ways to do this

* Multiple users on various computers accessing a shared library on a server plus their own private (local?) collection.

As an example, let me describe the set-up at my home.  We have a server on which we host a communal music share.  Most our music is there, but we each have some particular tastes all our own.  One of us really likes power metal from european bands, and has a largish collection on his local computer since the rest of us would rarely listen to it.  I am a dead-head / jam-band fan and keep many live show sets on my computer.  Then there are some specialty things like audio-books, lectures, and radio plays that are best left out of the main collection.  Even so, we still find common ground enough on some 42,000 tracks.

The way we do it today, the server music share is read/write to everyone and we all use our own players.  This is becaus I am the only Linux desktop user - the others insist on their games, go figure.  So even though I run a db back-end on my server, I am it's only user at present.  I am hoping this will change when Amarok 2 becomes viable on Windows XP.  I already have the rest of the household interested, as they hate the players they use for various reasons.  Winamp is a hog, and buggy but has the best media library they say.  Windows Media Player just peeves them since they know how fond MS is of phoning home and DRMming down your musical experience, and other players have failed them in various ways.  Amarok on Windows (with DAP-support/mp3 transcodes) would be a godsend to them.

Once A2/Win is out, I am presently planning the hack suggested by the Postres how-to... creating an overlay schema, basically, allowing multiple users access to public tables (collection) and personal versions of the user-centric tables (ratings, etc).  My only real concern for this is if I were to list both music from the central archive and music on my local computer in the database.  Other users would have problems when they came to my private tracks in the listing.  Likewise if they started adding their own local music to the database.

Amarok could take this all to another level with a well-thought out approach to multiple user scenarios.

If A2 can support multiple collections, then the problems of listing local tracks on the central db go away.  This might be tricky juggling multiple db's and trying to present a unified view.  But if A2 were user-aware in the db, it could manage public tables for the public music, private tables for the private music, and have the db present a unified view.  It would also be handy to have migration tools to put part of your local collection into the public pool, perhaps even moving/copying files for you.

There is one more scenario worth considering...

The usual mode around the house is going to be "to each his own", listening locally to tracks hosted on the server or locally.  But when we entertain, we want to be able to do a party mix.  We can do this with one computer in the living room or rec room, which is not a bad approach.  The only caveat is that the song preferences, ratings, etc. would revolve around one user.  Unlesss we create a separate partymix user account.  What would be even better is a party-mix mode where Amarok weighted all the users' ratings, etc. to bring up a mix that we could all agree on.  In the database, I suppose since private tables are private to the user and public tables are available to all users, another specail 'partymix' user on the db could have access to all the private tables, too. This would allow reading and processing the listening preferences of all the users by the partymix db user.

Now I have also been giving serious thought to Ampache or just MPD or something on the server to stream music for party mode.  The idea is to have all the computers streaming the music, so the house is full of the same music.  In the past, streaming to multiple computers in the house has been problematic as you have a noticable latency difference between machines, and so when between to rooms you hear the music out of sync.  Pulseaudio holds some promise here as it takes the network latency into account and is supposed to support Windows machines as network sinks.  The partymode would be best if there was an easy UI to include/exclude users from the mixed ratings.

I know that Amarok is gaining support for things like Ampache, but I don't really understand how that integration is done in the database, or if it even is at all.  Perhaps it's as simple as making Amarok a remote control for Ampache and tuning the stream... not integrated into Amarok's collection?!?  Not sure but watching to see what comes.

I suppose to recap:

* Multiple users each with both public and private music collections, personal ratings & such, individual listening.
* Single user playing in partymix mode with access to other users's ratings for sensible mix
* Multiple users streaming the same partymix
* Users can log in to the db from different computers to play shared music with their preferences (such as listening in the kitchen)

Well thank you guys so much for such a great player!  Amarok FTW!!!  ;) - mojo
Comment 8 Paulo Fidalgo 2008-07-17 12:41:26 UTC
I have a similar wish.
I have a portable usb disk with all my mp3 collection, and I would like to have the collection on this disk, because I use it on different computers.

This is already been discussed on mailing lists, but I don't know what is the actual state.
http://mail.kde.org/pipermail/amarok/2008-March/005406.html

If you think this is another wish, please tell me, and I will open another report.

Best regards!
Comment 9 Seb Ruiz 2008-11-27 23:57:58 UTC
I have given this feature some thought. It is certainly a noble goal, to have a common database backend to serve multiple users.

However, I think that the most versatile solution would be to have a totally different application which can serve music to multiple locations. You might want to look at the Ampache project, which provides lots of these features. Amarok 2 has an interface to Ampache.

It is limited in this regards in that you can't edit tracks or store metadata ratings, but Amarok's collection interface would allow this if Ampache (or a similar service) ever did.

I can't see this being implemented by one of the developers in Amarok anytime soon, but we would be open to receiving patches and ideas.

Leaving the report open since it's quite a common issue, and certainly a feature which I think could be useful to lots of users.
Comment 10 Ralf Engels 2010-11-04 11:39:53 UTC
I agree with Seb.
This does not seem to be a common use case.
If you really have different users with different listening habits; why not use different playlists or dynamic playlists?
You could also use labels for that e.g. "Ralf hates it" and filter for those.
Comment 11 Alan Ezust 2010-12-17 22:05:29 UTC
I want to write tag data only for rating and not for playcount or the automatic score. This way, tags are changed on the actual file only when I want them to be, and not when I play or skip the track.

I want everything else (automatic scores, play counts, etc) stored in my database. 

I don't think there is a way to choose that yet.
Comment 12 Matěj Laitl 2012-09-17 14:14:05 UTC
This won't get implemented by current Amarok team in forseeable future.

Note that you can point 2 Amarok instances of 2 different users to the same music collection. Or you should be able to start multiple Amarok instances even under a single user by using different KDEHOME environment variables. (haven't tried though)
Comment 13 Steven Elling 2012-11-20 06:10:35 UTC
Removed my votes for this bug as I quit using Amarok a long time ago and KDE shortly afterwards for its bloat.
Comment 14 Tim LePés 2015-04-02 05:46:02 UTC
Well thanks for listening; IANAP so no patches to offer.  I completely understand that not all feature ideas from users are necessarily feasible.  I like the idea of using Ampache on the back end,, and may some day suggest they add features allowing the editing of track metadata and ratings by clients.  My how things change, and how they stay the same.  I am no longer in the same living situation, but am once again interested in building out a media access network in my present home.  For now, though, my focus is on making the living room computer do dual-seat using separate video cards, and configuring an autologin session on the second seat to go right into Kodi.  But this isn't the place for that.  I will say that I am also giving KDE a go and still play with AmaroK, and also the Clementine "Amarok 1.4 (?)" spin-off on Windows.  Some of my favorite features are the web integration allowing me to find guitar tablature and lyrics.  I have also been playing with the Tomahawk music player.  I really like what they are doing there.   Not just the aggregation, but especially the intelligent automatic playlist feature, much like using Pandora or Spotify's "radio" features.  I believe it is because they integrate with Echo Nest, which Spotify has aquired about a year ago.  I'm also looking for some solution to semi-automated very-large metadata library and collection management.  Ugh.  Again, not related to this bug report. So please no one be tempted to reply with a suggestion.  You can send me a private message.  In any case, thanks for all the great work over the years.