[Karellen]

Thanks @sualfred

I have tested the ratings feature for movies, yet to test for TV Shows or look at the music changes.

1. Newly scraped movie
TMDB and IMDB rating existing. IMDB UniqueID available but not default.

IMDB- Rating updated. Votes updated but does not match the IMDB entry. Website shows 535,833 votes but scraped 531,255 votes
TMDB- Rating and votes updated.
Metacritic - Rating added and correct. No votes scraped
tomatometerallcritics- Rating added and correct. No votes scraped

Log here... https://paste.kodi.tv/emusuyodoy.kodi

Ratings from scraping

xml:
    <ratings>

        <rating name="imdb" max="10" default="true">

            <value>7.900000</value>

            <votes>535850</votes>

        </rating>

        <rating name="themoviedb" max="10">

            <value>7.500000</value>

            <votes>11046</votes>

        </rating>

    </ratings>

Ratings after running your add-on

xml:
<ratings>

        <rating name="imdb" max="10" default="true">

            <value>7.900000</value>

            <votes>531255</votes>

        </rating>

        <rating name="metacritic" max="10">

            <value>8.100000</value>

            <votes>0</votes>

        </rating>

        <rating name="themoviedb" max="10">

            <value>7.500000</value>

            <votes>11046</votes>

        </rating>

        <rating name="tomatometerallcritics" max="10">

            <value>9.400000</value>

            <votes>0</votes>

        </rating>

    </ratings>

Another issue I noticed is if there are no TV Shows when updating all library, then the add-on throws an error. Also shown in the above log.

[sualfred]

Thanks. 
The slightly difference between the votes are caused by the caching of OMDb. I'll take care of the exception. 

The nfo was correct? Because the rating updater also touches the uniqueid to add missing ids etc

[Karellen]

I had writing to nfo files disabled. But I just tested quickly again and could not see any problem with what was written to the nfo file.

Any idea why the 0 votes?

[sualfred]

OMDb doesn't return votes for Metacritic.
For Rotten it's possible with a undocumented argument but only as XML return. Would have to change the parsing of the data.

[sualfred]

@Karellen 

New version pushed.

- fixed exception with empty movie/TV show library
- switched to xml parsing for omdb to get tomatometerallcritics votes. 
- added tomatometeravgcritics and votes

[nessus]

Hi sualfred

Sorry for delay but i was out for the weekend.
Will try to do some testings today

Thanks
Nessus

[DaveBlake]

Votes -> FYI it works for albums, just not for songs. I'll remove the votes field on my end and add it back when you have fixed it.

Yeap.
I feel very ambivalent about votes for song ratings. Originally songs had a rating out of 5, read from tags. To somewhat arbitrarily "make it like video" this was converted to out of 10, a user rating field and a votes field added. User rating can be set via GUI, but only since v18 are the values exportable so can be kept between installations otherwise it is just transient data and a great waste of user effort. No facility was added to actually set votes (no GUI, songs don't have nfo files, not in JSON, not in embedded tags). Having 2 "ratings" fields has caused users no end of confusion, as did the change in max value of the original. But hey we are consistent with video and that us what matters, right?

Votes for song ratings - is there such data out there? If there is a source of such data and user requirement to use it then a facility to set it can be added of course, meanwhile it makes more sense to be to remove the votes field from the song table (if I change anything, and I'm not rushing at it). Removing the votes field on your end makes the most sense while we wait for users to request the facility (or not).

Artist labels -> Yeah, I've noticed the artistid and artistalbumid table. I'll remove it. I mean, I could update it for all other items as well, but with the limited JSON cmds that will be a pita and cause very loooong processing times.

What are you talking about here @sualfred ?
AudioLibrary.SetXXXDetails does not let you set artist/album/song ids, that would be bonkers! The setting of Musicbrainz ids is acceptable, not sure in what way you would have to update for all items or take a long processing time? The db indexing will reject duplicates, but you don't see that in the JSON results.

However setting mbids is unlikely as something a user would want to do manually. Better that they tag their music using Picard with matching pairs of names and mbids consistenly throughout an album than try to botch it in manually later. It is more likely to get users in a mess than anything helpful.

Note: when JSON returns "OK" for setting call, this just means that the request had correct syntax and was received. It does not mean that the data update was succesfull. This is common across much of the API methods, few actions are sychronous. "OK" is "Kodi got the request and understood it", nothing more.

---

@sualfred what is the purpose of this addon? My assumption is that you are making a nice tool to make it easier for users to make the library data additions/edits that they otherwise would have to do via manually editing NFO files. Do I have that right?

Music lib differs from video lib in some fundamental ways - folder structure and file naming is irrelevant, the and the library contents (songs, albums and artists) are created by processing the tag metadata read from the music files themselves. While you can recreate your video library from exported NFO files (at least I think you can), the export of music lib only captures the additional data that can be subsequently reapplied to a new library created from scanning the music files, it does not make the library.

While artists and albums can have NFO files and art providing data in addition to that formulated from the music files, songs do not. The JSON API provides a means to modify song data, but I do have doubts about how helpful it is to enable the user to do that other than for the song playcount, lastplayed and userrating values - those things that can change during use and are (v18 onwards) possible to export/import.

Genres, moods, etc -> How is Kodi handling the audio library scan? Does it rescan already added songs or does it just handle new ones and already added items have to be refreshed manually?

Library update checks folders/files for changes to a hash of size and timestamp and then rescans the contents and deletes existsing db entries prior to inserting new records. Edit the tags of a music file and the next library update it will be found and rescanned. Otherwise in the main if the files does not change it does not get rescanned untill the user does a fresh installation of Kodi, but odd things can change the folder hashes (clock change, or other software touching folder/files adding other files etc.) and sometimes things do get rescanned unexpectedly. Or users rearrange their files etc., drop a source and add it. Changes made to song data by JSON are not exportable to NFO or XML.

I guess the most popular song property to change will be genre - user tagged genre data is messy sometimes and they could want to slip in an correct something they mis-tagged. But it would be so much better to just fix the tags, otherwise if they do ever rescan their music (and there is a good chance that some time they will) then they will have to make those manual changes using your addon all over again.

Lack of permanence of changes to song data isn't my only concern. Changing things like artist(s), track number, title, year, etc. are pretty fundamental to the song identity. If they were wrong in the tagging then what kind of jumble is the library?

 But in the end it is up to you

[sualfred]

What are you talking about here @sualfred ?

Sorry, I'm always thinking in Emby dimension where we directly write to the sql file ^^ There is no json way.

The purpose of the tool? Nessus asked for it, I had time and Kodi has missing a metadata editor since forever. So why not, even if I can't really use it for myself (Emby reason again). The goal is to easily edit common metadata and update ratings without touching any external tool. Mainly targeted for video items. I just think that some music data fields make sense, even if it totally acts different for valid reasons.
Anyway, I've dropped 75% of all music editing fields. I just added it because someone maybe wants to edit it. Since Spotify I don't use Kodi for music anymore and personally I just want to offer a most complete "basic-solution". I kept genre, description editing for artists and albums. Sadly there is no artist.nfo and album.nfo available for me to trigger an update there for possible rescans.

Regarding the ratings field in general (OT talk):
It's not 100% ok for video items, too. While .nfo can have a "max=10" attribute and value, the database itself is limited to 10. I have to divide by 10 for Rotten and Metacritic ratings (OCD is tingling). And ListItem.Rating(foo) is only working in the info dialog. Everywhere else it's returning 0 or crap. The uniqueid table is another weird thing from a skinners POV: Why do we have this information stored, but cannot access it? And Kodi is setting a TVDb value to ListItem.IMDbnumber? But that's another topic for another day

[DaveBlake]

The music editing is a little bit strange and I don't know which values are save to offer as editing field. Editing the artist name to "blalblablbalbalbalbal" and it still shows albums of the artist "Metallica" looks like a messed up database. @DaveBlake  I know that the music DB is your playground. What values are save to be editable and which not?

SetArtistDetails with "artist" will only change the artist table value as seen in the artist lists, not the artist name displayed when showing albums and songs. This is because the tag processing allows for alias names (matching on mbid when available) and display names to be different from underlaying artist(s) too. You can change the artists credits of an album or song, and that will show for the song or album and add a new artist to the artist table if needed, but I have concerns about users doing  that. Artist names are complex things to edit consistently!

Here is my view on what music data can be useful for users to edit manually,  those with values initially derived from music file tags are marked with *, the rest are scraped online/nfo or changed during use. I have () around the less "safe" ones - the code/db will cope, but can the user

Artists

xml:
("artist"*)  

("musicbrainzartistid"*)

"sortname"*

"type"

"gender"

"disambiguation"

"description"

"instrument"

"style"

"mood"

"born"

"formed"

"genre"

"died"

"disbanded"

"yearsactive"

"art"

You could change an artist's name, but realise it will only change in artists lists, not as the display text for songs and albums etc.
Also what about changing the artist name, then later scanning some new music by the artist with the original name in tags (same as the other older music files). A new artist will be created in the library, and no you won't be able to edit that in the same way because you will get uniqueness conflicts.  Messey....
Musicbrainz Id will be used for scraping so adding it could be useful or disasterous if users get it wrong (16 chars easy to mis-type).
Both cases  the db won't apply anything that conflicts uniqueness, but you won't know without checking.

Albums

xml:


"title"*

"displayartist"*

("artist"*)

"type"*

albumlabel"*

"year"*

"description"

"genre"*

"theme"

"mood"

"style"

"rating"

"userrating"

"votes"

("musicbrainzalbumid"*)

("musicbrainzreleasegroupid"*)

Changing the artist credits (name/mbid pairs) for an album again could get users into a mess. The code will work if the data does not conflcit indexes, but why was it wrong in the music files?
Again, high error factor on entering mbids and low usefulness - get the tagging right!

Songs

xml:


"playcount"

"lastplayed"

"userrating"

I consider all the other data to be defined in the music files - edit the music file  tags!

Hope that is useful @sualfred

[sualfred]

Thanks, yes. That's basically what is left after my removals. I also removed MBID fields andy the basic title, artist ones. I agree that for music it's better to edit the stuff external and have a clean tagging of files and their included metadata.

Do you have any plans to add path/nfo path information for Kodi 19 (artist.nfo, album.nfo) ?

[DaveBlake]

Well gald you are including music in your tool. Export of music lib will make artist and album nfo files, but users can do with help sometimes to edit the scraped data with a UI.

I kept genre, description editing for artists and albums. Sadly there is no artist.nfo and album.nfo available for me to trigger an update there for possible rescans.

Well you can edit artist and album genre as much as you like, it is just a string field like the others. Only song genre values get used in Kodi filtering e.g. Genre > Artists gives those artists with albums with songs with that genre. Users are better changing that in the music files themselves

Totally confused by the rest. Music lib can scrape from and export to artist.nfo and album.nfo files, not sure how that relates to rescans?

[DaveBlake]

Do you have any plans to add path/nfo path information for Kodi 19 (artist.nfo, album.nfo) ?

Well album.nfo are located where they have always been - alongside the music files of that album (providing that music files for an album are in a unique folder of course).

The location of the Artist Information Folder is a setting, hence available to JSON but that doesn't tell you exactlly the artist folder name which may have had part of the mbid appended in the rare cases that artist name alone isn't unique.

Not exactly helpful...
I fear returning the exact path to the nfo/art as a JSON property kind of got lost off my todo list. But yes, adding it back now.

[sualfred]

Awesome. Looking forward to extend the .nfo writing for it.

[DaveBlake]

Awesome. Looking forward to extend the .nfo writing for it.

I was going to say no need,  music lib export creates album and artist NFO files so once you have edited data the user can just use the export facility. But does your addon create the NFO just for the item edited? Export does many items in one go with optional file overwrite, and a facility for single NFO creation would be useful. This will save me messing about trying to add single export to NFO facility to the info dialog (something I had considered).

[sualfred]

I only update them with edited fields. If no .nfo is there it does nothing.
Because different .nfo editing tools store different additional informations that Kodi isn't using. I don't want to remove those.

'file' is returning me the path where the movie, tvshow, episode, musicvideo is stored.

Code:


def update_nfo(file,elem,value,dbtype,dbid):
    if not ADDON.getSettingBool('nfo_updating'):
        return

    if dbtype == 'tvshow':
        path = os.path.join(file,'tvshow.nfo')
    else:
        path = file.replace(os.path.splitext(file)[1], '.nfo')

    UpdateNFO(path, elem, value, dbtype, dbid)

    # support for additional movie.nfo
    if dbtype == 'movie':
        path = file.replace(os.path.basename(file), 'movie.nfo')
        UpdateNFO(path, elem, value, dbtype, dbid)