Kodi Community Forum

Full Version: Understanding Music Ratings Philosophy
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Awhile back @DaveBlake helped me tweak MyMusicXX.db to display ALAC ratings.  In the thread Dave explained how in V17 Kodi processes tagged music ratings to the UserRating column.  Previously in V16 the process was to incorporate the value to the Rating column.  I am presently using a graphic-rich skin (Aeon MQ7 Mod and/or MQ8) that includes code to display song ratings in several different screens as both numeric and graphical star values.  Two of these screens are the fullscreen musicvisualization.xml and a particular view for songs inside albums (WideView.xml). 

By my (limited) understanding, MusicPlayer.Rating and MusicPlayer.UserRating each provide different results.  Per InfoLabels Section 8.1 MusicPlayer.Rating provides "Numeric Rating of current song, also available are "MusicPlayer.offset(number).Rating" offset is relative to the current playing item and "MusicPlayer.Position(number).Rating" position is relative to the start of the playlist".  MusicPlayer.UserRating provides "The rating the user gave to the currently playing song".  These each possess valuable features but one cannot be used like the other.

For instance, attempts to use the "offset" feature of "MusicPlayer..offset(1).Rating" to display the rating of the Next Up song does not work when applied to MusicPlayer.UserRating (i.e.  MusicPayer.offset(1).UserRating).  So if a skinner wanted to display the rating of the Next Up song in V17 it will display "blank" under the current Kodi db processing rules because there is no value in the db Rating column.  I've confirmed this under tests.

Likewise, if I modify my db (using DB Browser for SQLite) to copy the UserRatings into Ratings, and then recode the View or Visualization to read Rating instead of UserRating the dispaly will not properly display any changes to the displayed rating because Kodi uses UserRating to allow a user to +/- a song rating.

As far as graphically displaying ratings as stars, only the $Info[MusicPlayer.Rating] works as a resource.  Using $Info[Music PlayerUser.Rating] as a resource does not work.

Can someone explain why there are two music ratings functions, correct me if my logic is faulty, or possibly consider program changes to process ratings simultaneously in both columns?

Thx.
I guess the general theory for both video and music is that "rating"  is from an external source that can be scraped, while userrating is from the UI.  In the case of music, the rating typically is obtained from within the metadata tags, and various tagging software have implemented different schemes for music ratings,  while different tagging formats have also attempted to provide specifications for ratings.  See for example in ID3 tags the "popularimeter" tag aka POPM.

I will have to play with the MusicPlayer.offset(n) infolabels to see how they are working.  Keep in mind the design/programming for the labels was refactored after Kodi 18 alpha 1 so there could be latent bugs from that.

scott s.
.
This is also skin dependant. Estuary usually only display either "Rating" or "My Rating". A skin like Estuary Mod v2 for Leia by guilloz is able to display both rating types at the same time. IMHO it would make sense for this to become the default for basic Estuary as well, with "My Rating" taking precedence over (third party) "Rating".
Thank you both for your responses.  I ask that you also look at the functionality of the two different functions for the same user-expected "rating" and consider why they both exist and why one must differ from the other.  Whether a skin is outdated should not be an excuse.  If so, then the change from V16 to V17 left those Skins depending on the functionality behind, likely unintentionally.  As it stands, "Ratings " and UserRatings" do not coexist well.
(2019-03-18, 01:08)scott967 Wrote: [ -> ]I guess the general theory for both video and music is that "rating"  is from an external source that can be scraped, while userrating is from the UI.  In the case of music, the rating typically is obtained from within the metadata tags, and various tagging software have implemented different schemes for music ratings,  while different tagging formats have also attempted to provide specifications for ratings.  See for example in ID3 tags the "popularimeter" tag aka POPM.

I will have to play with the MusicPlayer.offset(n) infolabels to see how they are working.  Keep in mind the design/programming for the labels was refactored after Kodi 18 alpha 1 so there could be latent bugs from that.

scott s.
 
@scott967 , thanks again for your offering to look at offset functionality and how it could better integrate Rating with UserRating.  If I can help let me know.  ~jasn
Honestly ratings is one of the music libaray topics I hate the most. For v17 someone decided to try and make music rating handling the same as video 8405 (PR) and the transition has been painful for skinners and users.

The end result was that for v17 onwards albums and songs have two fields - rating (and related votes) and userrating. Both now held internally as a score out of 10, although rating is a decimal and userrating an integer.

For albums rating and userrating can be set via NFO files or using JSON API AudioLibrary.SetAlbumDetails.

For songs rating and userrating can set using JSON API AudioLibrary.SetAlbumDetails. Userrating is initially populated with the value scanned from the RATING/POPM tag embedded in the music file and converted to a number out of 10 depending on the tag format. It can also be adjusted via GUI and possibly Python script for the currently playing song.

There are MUSICPLAYER and LISTITEM info labels for both values. Both can be used as sort order and in smartplaylist rules.

However if you think about it then you will realise that the song rating field is pretty useless (unless you have something maintaining it via JSON API and a skin that shows it). I would expect  $Info[MusicPlayer.Rating] to be blank, and only $Info[MusicPlayer.Userrating] to have values.
 
(2019-03-18, 00:00)jasn Wrote: [ -> ]As far as graphically displaying ratings as stars, only the $Info[MusicPlayer.Rating] works as a resource.  Using $Info[Music PlayerUser.Rating] as a resource does not work.
That is the reverse of what I expect, are you sure you have it that way around becase I don't see it. Although
(2019-03-18, 01:08)scott967 Wrote: [ -> ]I will have to play with the MusicPlayer.offset(n) infolabels to see how they are working. Keep in mind the design/programming for the labels was refactored after Kodi 18 alpha 1 so there could be latent bugs from that.
is possible too.
(2019-03-18, 15:47)DaveBlake Wrote: [ -> ]Honestly ratings is one of the music libaray topics I hate the most. For v17 someone decided to try and make music rating handling the same as video 8405 (PR) and the transition has been painful for skinners and users.

The end result was that for v17 onwards albums and songs have two fields - rating (and related votes) and userrating. Both now held internally as a score out of 10, although rating is a decimal and userrating an integer.

For albums rating and userrating can be set via NFO files or using JSON API AudioLibrary.SetAlbumDetails.

For songs rating and userrating can set using JSON API AudioLibrary.SetAlbumDetails. Userrating is initially populated with the value scanned from the RATING/POPM tag embedded in the music file and converted to a number out of 10 depending on the tag format. It can also be adjusted via GUI and possibly Python script for the currently playing song.

There are MUSICPLAYER and LISTITEM info labels for both values. Both can be used as sort order and in smartplaylist rules.

However if you think about it then you will realise that the song rating field is pretty useless (unless you have something maintaining it via JSON API and a skin that shows it). I would expect  $Info[MusicPlayer.Rating] to be blank, and only $Info[MusicPlayer.Userrating] to have values.
 
(2019-03-18, 00:00)jasn Wrote: [ -> ]As far as graphically displaying ratings as stars, only the $Info[MusicPlayer.Rating] works as a resource.  Using $Info[Music PlayerUser.Rating] as a resource does not work.
That is the reverse of what I expect, are you sure you have it that way around becase I don't see it. Although
(2019-03-18, 01:08)scott967 Wrote: [ -> ]I will have to play with the MusicPlayer.offset(n) infolabels to see how they are working. Keep in mind the design/programming for the labels was refactored after Kodi 18 alpha 1 so there could be latent bugs from that.
is possible too. 
Thanks @DaveBlake.  I think I am mistaken about the $Info[MusicPlayer.UserRating] values being unpopulated.  I believe the inability to use it is skin related, as it functions in Aeon MQ7 but not AeonMQ8.  For whatever reason it fails to display for MQ8, and I do not know well enough to chase the problem down beyond a few .xml files.  I am, however, learnong a lot from the Wiki.

I follow also your background, re: how the change from V16 to V17 took place and how it has become complicated.  Chaulk it up to the change being "a good idea, but not a great idea"? Smile

If it were possible to assign "offset" functionality to UserRating as it is for Rating I think that would be a nice step.
(2019-03-18, 16:18)jasn Wrote: [ -> ]If it were possible to assign "offset" functionality to UserRating as it is for Rating I think that would be a nice step. 
I'm surprized that isn't working, or at least that one works but the other doesn't.  

I will wait for Scott to report back on his testing. I generally don't mess with skins at all, and don't use one that shows data about next song etc. to know one way or another
Greetings @scott967 and @DaveBlake.  Not at all surprised that music ratings is not a high priority, but if I could make a simple suggestion to allow JSON API AudioLibrary.SetAlbumDetails to populate both UserRating and Rating when scraping files that would be an easy solution.  Any reason why that would be a problem?

Thx
(2019-04-14, 00:10)jasn Wrote: [ -> ]Not at all surprised that music ratings is not a high priority, but if I could make a simple suggestion to allow JSON API AudioLibrary.SetAlbumDetails to populate both UserRating and Rating when scraping files that would be an easy solution.  Any reason why that would be a problem?
@jasn you seem to be confused. The JSON call AudioLibrary.SetAlbumDetails() can be used to set both userrating and rating, but JSON calls have absolutely nothing to do with scraping additional album information.

Both values can be set in album.nfo files and scraped from there. I think that the Universal Album Scraper sets rating to any rating value picked up from remote sites. That is correct, the rating being seen as an externally provided thing while userrating is a personal/local one.
Getting back to this after ingoring for a while.

I guess for the most part tags in songs were designed to record a user's rating, with the possibility that more than one user's rating could be saved in the same song (although I guess in practice it has been more used to separate different software in which the rating was done, rather than different users).

Then, I guess Apple decided to add an "album rating" which again was user defined (also "favorites" hearts), but also could be computed as the average of all rated songs in the album.  I don't know if the "album rating" is actually saved to any song tag?

Meanwhile various sites have compiled /published "community ratings, either for tracks or albums,  by experts or by user submissions that I guess are averaged.  So there is a concept of user rating and community rating / votes at both the track and album level.  I looked at the TADB API, it doesn't specify what data gets returned.   I suppose other sites could be scraped or api provided to get this data (it looks like musicbrainz has the ability to add a rating to tracks and release groups -- I don't know if it also has a "votes" field).  So maybe someone is scraping this data?

I have done some testing, don't see a problem with the infoflables though I do see skin.widgets script hasn't been updated to correctly deal with album ratings.  I thought I would try to load some mp3 files with POPM as set by MediaMonkey but so far I can't get Kodi to read the POPM.  Not sure what's going on here.  I might need to bug Dave for a look.  I see that the raw hex does show the POPM is
which should be correct for MediaMonkey rating of 3.5.

It does seem to me that scanned POPM / rating from file metadata should be considered the userrating rather than rating.

scott s.
.
Thanks for taking a look at this @DaveBlake and @scott967.  Based on the lack of response by others (both here and on other skin threads) it appears I am one of a very few obsessed users focusing on Kodi's ability to process and display song ratings, even though the ability is included in many Fullscreen displays.  For the record, BTW, I don't care a hoot about album ratings, averaged or assigned.  Due to my lack of actual programming skills I also have the knack, when trying to focus a question or request about Kodi, to appear "confused".  If that's still the case here please send me back in the direction of my Keeper...

Since I've poked this snake I thought I would try to display an example of what my observation is re:  the different functions of MusicPlayer.Rating and MusicPlayer.UsedRating:

Image

Click on the screenshot above (taken from Aeon MQ 7 Leia MOD using a musicvisualisation.xml file modified by me) and you'll see the currently playing song has a (self-assigned) rating of 8 stars, which was generated from the code $INFO[MusicPlayer.UserRating].  On the right, you will see a display for the next song which has a rating of 10 stars, which was generated using $INFO[MusicPlayer.offset(1).Rating].  If I were to use the code $INFO[MusicPlayer.offset(1).UserRating] the "Next Up" graphical display will not work (nor would a numerical display if star graphics were not used).  The only way I got the "Next" song rating to display is because I manually populated the Rating column of my MyMusicXX.db to mimic my UserRating column.

My initial request was to ask if it were possible to add or correct the same "offset" ability to UserRating as it is for Rating so that, if a user does have individual song ratings and a Skin were to program for Next Song display it would work without having to mess with the db and use differnt codes for "Now Playing" songs and Next Up" songs.  The less-desirable solution would be to populate both Rating and UserRating when users scan their libraries with songs that include properly tagged Ratings data.

Thanks to you both (and also to @latts9923 for the skin)
(2019-04-15, 23:30)jasn Wrote: [ -> ]Thanks for taking a look at this @DaveBlake and @scott967.  Based on the lack of response by others (both here and on other skin threads) it appears I am one of a very few obsessed users focusing on Kodi's ability to process and display song ratings, even though the ability is included in many Fullscreen displays.  For the record, BTW, I don't care a hoot about album ratings, averaged or assigned.  Due to my lack of actual programming skills I also have the knack, when trying to focus a question or request about Kodi, to appear "confused".  If that's still the case here please send me back in the direction of my Keeper...

Since I've poked this snake I thought I would try to display an example of what my observation is re:  the different functions of MusicPlayer.Rating and MusicPlayer.UsedRating:


Click on the screenshot above (taken from Aeon MQ 7 Leia MOD using a musicvisualisation.xml file modified by me) and you'll see the currently playing song has a (self-assigned) rating of 8 stars, which was generated from the code $INFO[MusicPlayer.UserRating].  On the right, you will see a display for the next song which has a rating of 10 stars, which was generated using $INFO[MusicPlayer.offset(1).Rating].  If I were to use the code $INFO[MusicPlayer.offset(1).UserRating] the "Next Up" graphical display will not work (nor would a numerical display if star graphics were not used).  The only way I got the "Next" song rating to display is because I manually populated the Rating column of my MyMusicXX.db to mimic my UserRating column.

My initial request was to ask if it were possible to add or correct the same "offset" ability to UserRating as it is for Rating so that, if a user does have individual song ratings and a Skin were to program for Next Song display it would work without having to mess with the db and use differnt codes for "Now Playing" songs and Next Up" songs.  The less-desirable solution would be to populate both Rating and UserRating when users scan their libraries with songs that include properly tagged Ratings data.

Thanks to you both (and also to @latts9923 for the skin)

 OK I sorted out my POPM scanning problem and now have populated a bunch of song userratings ffrom POPM tags. All working. As you say, MusicPlayer.offset(n).Userrating and MusicPlayer.position(n).Userrating aren't provided.

scott s.
.
Thanks for confirming those offset deficiencies @scott967.  Knowing this, do you envision adding those features for UserRating info labels?
(2019-04-16, 19:32)jasn Wrote: [ -> ]Thanks for confirming those offset deficiencies @scott967.  Knowing this, do you envision adding those features for UserRating info labels?

Some more digging there appear to be bugs:

1.  MusicPlayer.Offset(n).Userrating returns the value for MusicPlayer.UserRating (but other info other than UserRating do work?)

2.  MusicPlayer.Position(n).xyz returns the value for MusicPlayer.xyz (this since 18 A1).

scott s.
.
Pages: 1 2