Bugzilla – Bug 142
Make rating available to player UI and Web Interface
Last modified: 2012-02-02 21:55:47 UTC
I was wondering if it would be possible to bring through the rating for each song (it is in the xml file) into the UI (both player and web interface). It would be nice to be able to display in the "Now Playing" section. You might decide to re-rate a song while listening to it.
To write to the iTunes DB: Apple's iTunes COM SDK is available at http://developer.apple.com/sdk/itunescomsdk.html; its Applescript interface can be accessed via Script Editor.
*** Bug 329 has been marked as a duplicate of this bug. ***
This should be one of our first features to take advantage of our own database.
Me too! I use the ratings system in WMP and love being able to create playlists based on Ratings. Also, being able to re-rate files whilst playing on the SB would be great! WMP10 now stores trhe ratings in the WMA files somewhere!!
Just 2 notes: - this can leave independent of iTunes integration. Slim can have it's own ratings system, and as a bonus it would be nice to sync it with iTunes. - an import / export ratings feature (or script) would be greatly appreciated. By writing connectors this way we can manage to sync it with other than iTunes as well...
I have used a piece of software in the past on linux console which was ncurses based and it did the "scoring" as follows: All scores are at 50 by default, they can be set by hand to any value from 0 (least desirable) to 100 (most desirable). If a song played all the way through, 10 points were added to its' score. If a song was skipped, 10 points were removed from its' score. rob
I would *love* this... punch in 0 to 9 or something while it's playing... is there any "standard" system of rating? seems every piece of software does it differently. automatic inc/dec of rating might mess everything up if you do a lot of unattended random playing - if implemented should be an option.
Remember too that ratings in iTunes are on a 1-5 integer scale, so ratings implemented in any other way would still need a way of mapping to this rating system for those of us who manage our music library predominantly through iTunes.
Whilst I agree a ratings system would make a great addition to the Slimserver, please consider making the rating system an integral part of Slimservers database, and not dependant on iTunes or WMP. Oh, and the comment about WMP adding the ratings into the metadata in the actual music files. Lets _not_ do that, please :)
Why not add rating into file's metadata. I am fed up with Library systems that only store data in the library file and if you loose the library, or change platforms / applications - or transfer the file to another machine, that you have to recreate the data. If the data is in the file, then any system can read and add to it's own library / database?
i agree with Stuart. sure, on one hand modifying a file is not nice, on the other hand more and more mp player come up with smart- or dynamic lists which allow to query all mp3 files on their meta data. this allows to have an independent solution for rating. i think having both would be nice, to store the data within the tag or keep it external. (as usual, the customer wants everything ;-)
*** Bug 1390 has been marked as a duplicate of this bug. ***
Moving bugs that won't be immediately fixed in 6.1 release. Please review and update if this is an error or if this bug has already been fixed. Thanks.
thats one of my favorites it's a great idea and there are some products which can do that already. my point of view: should be in the tags of the file. is there a system for the voters to be informed when the feature is released? cu
add your email addy to the cc list on this form, then you get copied on any change in status of the bug.
One issue with saving ratings to tags is that some people have music libraries that are shared among several users. My rating of a song is not going to be the same as my husbands. If writing ratings to files is implemented, I'd be all for it as long as the ratings can be tied to a specific person.
In comment #6 I mentioned a player which does this. That player is cymbaline ( http://www.silmarill.org/cymbaline.htm ). I like this so much that I use cymbaline as often as I can. If I am in a situation where cymbaline isn't possible, I will revert to slimserver and its' streaming.
Just to second some things others have already said, I agree that putting the comments in the files themselves makes the ratings more portable and that either way this would have to be done in a way that supports multiple users. I think this is a killer feature. At least of all the various things I've been waiting for before buying a SqueezeBox it's the only one that hasn't been implemented yet.
There's a plugin, that should do this: http://forums.slimdevices.com/showthread.php?t=20533
Some iTunes users on the CC list for this bug might find the following forum thread useful... http://forums.slimdevices.com/showthread.php?t=21787 It explains one way to get your iTunes ratings into the database (if not how to access them via the UI). I use the imported ratings with the SQLPlayList and iTunes update plugins to good effect.
as of change 6539 (for 6.5 builds) a basic ui is added to show ratings imported from iTunes and MusicMagic. rating value is stored in the db as a value out of 100. trackstat plugin can view and set ratings using its own methods, so hopefully that can be modified to hook into this feature.
Created attachment 3047 [details] Rating support in CLI interface This patch implements the ideas described in this thread: http://forums.slimdevices.com/showthread.php?t=44208 The patch adds two new CLI commands: rating 123 60 # Set the rating to 60 on the track with id 123 rating 123 ? # Retrieve the rating of the track with id 123 The patch also contains functionality so plugins can register a function that handles the ratings. This way TrackStat can register it's rating function and the user can select to use the TrackStat storage instead of the standard SlimServer storage by registering with Slim::Schema::registerRatingImplementation The user selects the rating implementation in SqueezeCenter Settings/Behaviour Currently the rating storage handling is just used for the CLI commands, which is what is needed to make third party clients and plugins work with ratings. But a future version should also make the songinfo page in web interface and Jive interface use the selected rating implementation. To make sure ratings set by the CLI command is written to all rating storages, each plugin can subscribe on the 'rating' command and do their work when the command issued. I'm not sure if Slim::Schema is the correct place to have the rating registration function or if these should be placed somewhere else.
Andy, can you review this patch for 7.1?
I think if we want to implement ratings we need to do it completely, not with partial support such as this patch. A good start though.
Ok, great. What more needs to be added?
I guess we already have rating stored in the track table, but we need to make it survive a rescan, which would mean storing it elsewhere indexed by track URL. And we will need to add an interface to view/modify ratings to all UIs.
(In reply to comment #26) > I guess we already have rating stored in the track table, but we need to make > it survive a rescan, which would mean storing it elsewhere indexed by track > URL. And we will need to add an interface to view/modify ratings to all UIs. > Index by track url only will not be good enough, because it makes the ratings disappear if you restructure your library. In TrackStat I'm using track URL and optionally also the musicbrainz identifiers if they exists, this makes it work when renaming/moving files as long as you have musicbrainz tags in your music files. Ideally I think some kind of checksum of the audio data in the music files would be preferable, but I'm not sure how that would affect the scanning performance. Another issue is that ratings are overwritten today when you perform a scan with the iTunes or MusicIP integration, this must be handled some better way so old ratings from MusicIP/iTunes doesn't overwrite newer ratings in SqueezeCenter. Finally, you would also need a way to backup the ratings to an external file, the reason is that we sometimes instructs users to delete the Cache directory when debugging errors (which deletes the whole MySQL database including andy ratinsg in it). If you like me to develop som more patches for complete ratings support, just point me in the right direction and I'll try to do something. If you like one if the SqueezeCenter core developers to do it, that's fine too. This first patch was just a first version which main idea was to make it possible for third party plugins and third party client applications to provide rating support.
So, it seems we need: 1. A track table for additional metadata (starting with rating) that persists across wipe-and-rescan 2. Support from the scanners which imports the rating. 3. A UI that allows for viewing and editing the rating of tracks. 4. A persistent identifying mechanism for tracks that resists moving of files in the filesystem. 5. A mechanism for allowing the importers to bring in ratings but not overwrite the ratings that users have added. 6. A mechanism for updating external ratings (like in iTunes) when you adjust the rating in SC. Have I missed anything? Telling the user to delete their database by deleting the cache directory should (imo) cause a complete reset, including the ratings. I think it's a bad idea, architecturally, to start creating secondary databases. Let's just fix the one we have.
Adding to Dean's list... please include a way to generate a random mix based on ratings. Otherwise, for me, there is no point in having them.
Sue: how would you expect this to work? Would it be a random mix with the randomness weighted toward higher rated songs? Or would the mix be filtered on rating, as it is for genres now?
(In reply to comment #28) > Have I missed anything? As long as we think deleting the database is an acceptable solution when handling a support issue, I think we also need some way to export the ratings to a text file or some other kind of backup. Additionally there need to be a way to restore this backup. A user can spend a lot of time setting up ratings on his music, so loosing the ratings is a major problem.
(In reply to comment #30) > Sue: how would you expect this to work? Would it be a random mix with the > randomness weighted toward higher rated songs? Or would the mix be filtered on > rating, as it is for genres now? > My suggestion is to make it simple, just filter it based on ratings in the Random Mix plugin in a similar way as you can filter it by genres today. A more advanced solution should be handled through support for "smart playlists" to get the flexibility needed, but that can be added as a separate enhancement at a later time.
(In reply to comment #30) > Sue: how would you expect this to work? Would it be a random mix with the > randomness weighted toward higher rated songs? Or would the mix be filtered on > rating, as it is for genres now? > The first option would certainly be nice, but (for me) just being able to say, "give me a mix of songs rated 3 or higher" would be fabulous.
> I think we also need some way to export the ratings to a text > file or some other kind of backup. Additionally there need to > be a way to restore this backup. Agreed. This is also needed for moving the server to another machine. Currently you have no reason to preserve any part of the database - you just scan on first startup into an empty database. Then the next thing that becomes very nearly a necessity is an export/backup scheduler. You now have data that can't be recreated simply by running a rescan, so you should offer an easy way for users to protect that data.
Created attachment 3409 [details] Patch for persistent storage of ratings Here is a new patch to make the rating information survive a database rescan. The CLI rating patch attached earlier will need some small modifications due to this patch, but I didn't want to include them in this one in case you like to commit this one first. Description of patch: - rating, playCount and lastPlayed attributes has been moved to a new tracks_metadata table - The tracks_metadata table contains an additional "added" column which contains the timestamp of the file the first time it was added to SqueezeCenter. - The tracks_metadata table is join with tracks table using tracks.id=tracks_metadata.track - The tracks_metadata table also contains url and musicbrainz_id, the reason for this is to make it possible to connect it with correct tracks.id value during a full rescan. This means that the information will always survive a rescan if the music is tagged with musicbrainz tags, additionally it will also always survive a rescan if the music files haven't been renamed or moved. This was just the first part to make the database information survive a rescan, we still need the rest of the points Dean mentioned in an earlier comment to make a complete solution. Note! TrackStat and iTunes Update currently writes directly to the tracks table, so when this patch is applied these plugins also needs to be updated so they use the Slim::Schema::Track::rating function or the CLI command provided with the earlier patch. Let me know if you would like me to continue and provide patches for the rest of the points related to this or if you like some Logitech employee to do it.
Andy notes there is work going on which may make these patches not work.
(In reply to comment #36) > Andy notes there is work going on which may make these patches not work. > Is the plan still to include this in 7.1 ? Or will it be changed to 7.3 until we have the new database schema described in enhancement 8303 ? If the plan still is to include this in 7.1, I can try to update the patches. It would also be great to know the minimum functionality needed to apply the patches, I assume we don't need everything Dean mentioned in comment 28 for a first version ?
I think it would be good to have in 7.1, but it should use the new TrackInfo menu interface. I don't think we can have everything listed in comment #28, especially item 4. We'll just have to use URL as the key for now.
Created attachment 3509 [details] Rating support in CLI interface for 7.1 Updated CLI implementation patch so it works towards latest 7.1, The CLI implementation patch doesn't work with the latest "Patch for persistent storage of ratings". To make it work the defaultRatingImplementation needs to be modified so "$track->rating" is replaced with "$track->metadata->rating"
Created attachment 3510 [details] Patch for persistent storage of ratings Updated persistent storage so it works towards latest 7.1
Thanks, will look at this soon this week. Do we really need a 0-100 scale for rating? Isn't 0-5 enough?
(In reply to comment #41) > Thanks, will look at this soon this week. Do we really need a 0-100 scale for > rating? Isn't 0-5 enough? > 0-5 is IMHO enough in the user interface, but we should have 0-100 in the database. If we don't we might get into trouble in the future when doing two way synchronization with iTunes and other rating storages which use 0-100. The POPM rating tag in the MP3 standard uses 0-255. I'm using 0-5 in the user interface in the TrackStat plugin and I think the iTunes Update plugin uses 0-10. I think iTunes has 0-10 in the user interface with their half-rating concept.
Patches have been applied as 7.1 change 21383. I made a few minor changes: Changed the name of the new table from 'metadata' to 'persistent', since metadata didn't really describe what it was for. Combined the CLI query and command into one function as it was mostly the same code. When getting data from the persistent table, prefer MusicBrainz ID over URL. Only show the web UI rating option if there's more than one implementation installed. Now we just need a patch for a rating UI. :)
Created attachment 3523 [details] Incorrect collate on tracks_persistent It seems like the url and musicbrainz_id columns in tracks_persistent gets incorrect COLLATE compared to the tracks table. This patch corrects this. Without this patch, you can't run an SQL statement like this: select * from tracks,tracks_persistent where tracks.url=tracks_persistent.url limit 10; I'm using an Ubuntu machine with locale set to en_US. The SqueezeCenter web interface displays: SqueezeCenter Version: 7.1 - TRUNK @ UNKNOWN - Debian - EN - iso-8859-1 I know it looks a bit strange to set the column collate to utf8_unicode_ci when the table collate is set to utf8_general_ci, but this is how the database actually looks like. The alter statements in schema_4_up only changes the table collates, not the column collates.
Andy - this change has broken RandomPlay, which uses the lastPlayed value: [08-07-02 11:27:33.9726] Slim::Schema::Storage::throw_exception (70) Error: Error executing 'SELECT COUNT( * ) FROM contributors me LEFT JOIN contributor_track contributorTracks ON ( contributorTracks.contributor = me.id ) JOIN tracks track ON ( track.id = contributorTracks.track ) WHERE ( ( ( lastPlayed IS NULL ) OR ( lastPlayed < ? ) ) )': DBD::mysql::st execute failed: Unknown column 'lastPlayed' in 'where clause' at /Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/Storage/DBI.pm line 771. [08-07-02 11:27:33.9733] Slim::Schema::Storage::throw_exception (70) Backtrace: frame 0: Slim::Utils::Log::logBacktrace (/Users/mh/Documents/workspace/unstable/server/Slim/Schema/Storage.pm line 70) frame 1: Slim::Schema::Storage::throw_exception (/Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/Storage/DBI.pm line 773) frame 2: DBIx::Class::Storage::DBI::_execute (/Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/Storage/DBI.pm line 826) frame 3: DBIx::Class::Storage::DBI::_select (/Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/Storage/DBI/Cursor.pm line 79) frame 4: DBIx::Class::Storage::DBI::Cursor::next (/Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/ResultSet.pm line 888) frame 5: DBIx::Class::ResultSet::_count (/Users/mh/Documents/workspace/unstable/server/CPAN/DBIx/Class/ResultSet.pm line 849) frame 6: DBIx::Class::ResultSet::count (/Users/mh/Documents/workspace/unstable/server/Slim/Plugin/RandomPlay/Plugin.pm line 431) frame 7: Slim::Plugin::RandomPlay::Plugin::findAndAdd (/Users/mh/Documents/workspace/unstable/server/Slim/Plugin/RandomPlay/Plugin.pm line 724) frame 8: Slim::Plugin::RandomPlay::Plugin::playRandom (/Users/mh/Documents/workspace/unstable/server/Slim/Plugin/RandomPlay/Plugin.pm line 1177) frame 9: Slim::Plugin::RandomPlay::Plugin::handleWebMix (/Users/mh/Documents/workspace/unstable/server/Slim/Plugin/RandomPlay/Plugin.pm line 1204) frame 10: Slim::Plugin::RandomPlay::Plugin::handleWebSettings (/Users/mh/Documents/workspace/unstable/server/Slim/Web/HTTP.pm line 1065) frame 11: Slim::Web::HTTP::generateHTTPResponse (/Users/mh/Documents/workspace/unstable/server/Slim/Web/HTTP.pm line 938) frame 12: Slim::Web::HTTP::processURL (/Users/mh/Documents/workspace/unstable/server/Slim/Web/HTTP.pm line 749) frame 13: Slim::Web::HTTP::processHTTP (/Users/mh/Documents/workspace/unstable/server/Slim/Networking/Select.pm line 243) frame 14: (eval) (/Users/mh/Documents/workspace/unstable/server/Slim/Networking/Select.pm line 243) frame 15: Slim::Networking::Select::select (slimserver.pl line 512) frame 16: main::idle (slimserver.pl line 462) frame 17: main::main (slimserver.pl line 1024)
Created attachment 3526 [details] RandomMix patch Here is a patch for the RandomMix problem Michael mentioned. I've only done a quick verification of this, so it needs verification of someone that knows DBIx better then me to make sure it works completely correct.
Created attachment 3527 [details] RandomMix patch Sorry, attached the wrong patch file in previous post, here is the correct patch for the RandomMix problem Michael mentioned. It still needs verification from someone that knows DBIx better than me.
Re: Incorrect collate, the problem is that you just used the wrong collate value in the CREATE statement and I didn't spot it. :( I think I will just update the schema_6_up.sql file and anyone who used the bad one can just delete their database and restart.
Random Play should be fixed now in change 21433.
Created attachment 3536 [details] Patch to make it possible to change ratings from track info page This patch makes it possible to change ratings from the track info page, I'll post this even though it isn't completely finished because I feel that some decisions needs to be made regarding how things should be implemented and someone with better knowledge of the Controller interface needs to implement some code. The patch requires support for web.type == 'htmltemplate' as posted here to make the HTML interface work: http://forums.slimdevices.com/showthread.php?p=317421#post317421 The 'refresh' parameter currently doesn't work correctly in the Player interface when the item is in the 'moreinfo' group, so the menu isn't refreshed correctly. The Controller interface needs some additional correction to work correctly, the 'popback' and 'showBriefly' parameter in the OPML structure is currently not fully supported in the Controller interface. 'popback' isn't supported at all and 'showBriefly' enters and shows the popup instead of just showing the popup as it do in the player interface. Someone with better knowledge of the Controller code needs to fix this. I'll post some sample images for the rating stars for the web interface in a following attachment.
Created attachment 3537 [details] Sample rating stars
shouldn't this bug have the new schema keyword, and be listed as a block for 8303 if it isn't already? also, WMP writes ratings into tags. i think SC should support reading ratings from tags, of any app, itunes, WMP, MM, whatever. but are we suggesting that those tags could be updated by SC? if so, is this a departure from the idea that SC never writes to a users music files? i would be for it, but only in this one instance, (at this point anyway).
I disagree with writing to the MP3 file's directly. I think it should write to a text file, with Date & Time played and rating. That way you can use cripts to import into various players. If you start writing to mp3's rating and playcounts are used for the same thing. In reality for me Erlands plugins work ideally. Personally we need to pend time in cyncing Eralnd's plugins and common players i've been working on syncing with mediamonkey and have got a fair way. but there is more to come.
i think a user should be allowed to OPTIONALLY choose if they want SC to write limited things to a files tag, such as rating. i understand the SC philosophy, but it could be an "official" downloaded extension to give you the ability.
Your message was received at Tue, 09 Jun 2009 22:46:57 +0000: To: boren@bluebottle.com Subject: [Bug 142] Make rating available to player UI and Web Interface This account is protected by Bluebottle. Please click on the following link to have your address added to the recipient's allowed list and to ensure delivery of your email. http://www.bluebottle.com/verification/e1c54258ac35c1945c8c92d785cb9c60 Bluebottle is a trademark of Bluebottle Solutions Pty Ltd
Read the bug number.
what do you mean "read the bug number?" why is this resolved as won't fix? surely 40 bug votes matters?
Apologies, yes perhaps that was a harsh/immature reaction. Reassigning to Seth because I do not have the hours available to tackle this.
re-assigning Seth's bugs to Matt
Your message was received at Thu, 22 Oct 2009 18:39:01 +0000: To: boren@bluebottle.com Subject: [Bug 142] Make rating available to player UI and Web Interface This account is protected by Bluebottle. Please click on the following link to have your address added to the recipient's allowed list and to ensure delivery of your email. http://www.bluebottle.com/verification/eac4f4decd708f6c16af978711536e53 Bluebottle is a trademark of Bluebottle Solutions Pty Ltd
Matt Weldon doesn't work for us any more.
i just want to point out that the id3 spec uses POPM to do ratings, with a 0-255 range and that email addys can be used to store ratings from multiple users in one file. windows OS, WMP, and winamp all use POPM and the same ranges for stars. i am not sure how to support ratings for non-id3 types, like FLAC, but i see no reason not to at least support what microsoft/winamp do, that conforms to the spec. since this bug has 52 votes, it should be assigned to somebody.
LOGITECH, SLIM, this bug has 55 votes! it dates back to 2004. with 7.7LMS around the corner, with the variety of media people will VISUALIZE on a TV as well as in other ways, ratings will be very important for sorting, playlist creation, etc! surely, at this point, we can at the very least make the server competent at reading in ratings to the DB, for id3 (popm 0-255), vorbis 0-100, and itunes ratings. once we establish that, then we can figure out how to make use of them in the UI, but lets at least get this initial, preliminary step done.
Unassigned bugs cannot have a priority.
63 votes. POPM uses 0-255 by spec and many apps support it. FLAC/Vorbis now uses 0-100 in many apps as well. these are de facto standards. at the very least, can't LMS display this info if its in the tags?
(In reply to comment #65) > 63 votes. > > POPM uses 0-255 by spec and many apps support it. > > FLAC/Vorbis now uses 0-100 in many apps as well. these are de facto standards. > > at the very least, can't LMS display this info if its in the tags? Isn't FLAC/Vorbis alraedy supported if the tag is called RATING and has a value between 0-100 ?
> Isn't FLAC/Vorbis alraedy supported if the tag is called RATING and has a value > between 0-100 ? i guess it depends what you mean by supported, and i'm not only talking about FLAC/Vorbis. ignoring ratings is not good behavior for a music server imo.