Rating Nfo tags

[GrimReaper 3881]

Will 4.6 conform to Kodi wiki guidelines:

https://kodi.wiki/view/NFO_files/Movies#nfo_Tags

for nfo multiple-sourced ratings read/write? 

I assumed current 4.5.4.0 stable does not, just judging by the nfos generated by Emby itself, where only <rating> and <criticrating> are written. Upon testing, looks like it doesn't, it just takes the default one, regardless of source name tag, and it applies it on <rating>. 

Had same question about <uniqueid>, which Emby doesn't write at all, and is actually required (one of the only 2 required tags), <id> is discouraged - but found my answer under another topic. 

Thanks

[pünktchen 1343]

There's a big problem when it comes to write multiple ratings, that is Emby only has one providerless community rating.

Imagine you have a nfo with IMDB as default rating and TMDB as additional rating. Emby reads the default and stores the value without any provider info. Now you refresh the metadata in Emby or just make any change that results in a nfo rewrite. What should Emby write as rating provider? Is it TMDB or IMDB?

[GrimReaper 3881]

On 3/11/2021 at 1:06 AM, pünktchen said:

There's a big problem when it comes to write multiple ratings, that is Emby only has one providerless community rating.

Imagine you have a nfo with IMDB as default rating and TMDB as additional rating. Emby reads the default and stores the value without any provider info. Now you refresh the metadata in Emby or just make any change that results in a nfo rewrite. What should Emby write as rating provider? Is it TMDB or IMDB?

Yes, hence the query for multiple providers to be supported (and a bump in FR few weeks ago: 

 

 

). 

At the moment, if stable release version was to read an 'official' Kodi nfo containing only 3 tags: title, rating and uniqueid, result would be:

- One imported correctly

- One imported partially (and possibly incorrectly, depending on the rating provider) 

- One not imported

That's barely passable (if at all). 

But aside all that, my goal is to have self-sustained media and its metadata, all stored locally, as I suppose plenty users do (due to specific circumstances, irrelevant now). Without Emby nfo metadata saver, for obvious reasons. Even as such, it DOES mostly import everything correctly besides critics ratings - they are not imported at all, regardless of source: default one (even if it was Metacritic or RT) gets sticked to community one, others got ignored. Besides manually rewriting nfos to conform to Emby, I don't see how would that be possible without Emby respecting proper nfo tags.

Edit: Btw, your PeopleBackup plugin goes a long way towards that goal, Cast images were the biggest hurdle before: TMM scrapes, plugin imports. Cheers. 

Edited November 18, 2022 by GrimReaper
Append

[pünktchen 1343]

1 hour ago, GrimReaper76 said:

Even as such, it DOES mostly import everything correctly besides critics ratings - they are not imported at all, regardless of source: default one (even if it was Metacritic or RT) gets sticked to community one, others got ignored

RottenTomatoes should be imported as critic rating. Until three weeks ago TMM did write a custom provider name for RT that wasn't used neither by Kodi nor Emby. But this is fixed now in TMM.

[GrimReaper 3881]

2 hours ago, pünktchen said:

RottenTomatoes should be imported as critic rating. Until three weeks ago TMM did write a custom provider name for RT that wasn't used neither by Kodi nor Emby. But this is fixed now in TMM.

I agree, that's why I brought this up. Even if @Luke is reluctant to add writing capabilities, multi-sourced reading is a prerequisite, and subsequently binding can be done:

IMDB, TMDB, Trakt, RT Audience >>> Community rating, <rating>

Metacritic, RT Critics >>> Critics rating, <criticrating>

Note: Yeah, saw your post there regarding tomatometerallcritics. 

Edit: Or just add few columns in the db table. 

Edited March 11, 2021 by GrimReaper76
Append

[pünktchen 1343]

So have you tried RT? The nfo plugin has the code for it already.

[GrimReaper 3881]

2 hours ago, pünktchen said:

So have you tried RT? The nfo plugin has the code for it already.

 

On 2/24/2021 at 5:33 PM, GrimReaper76 said:

Makes you wonder why hasn't this been implemented already?

As @Happy2Play stated, data is technically already there, it's just a matter of parsing same.

I'm positive the argument "When is enough?" will eventually pop-up again - well, I'd say presently is definitely NOT enough, what with IMDB ratings being almost mediocre across the board and review-bombing wars fought every now and then (applicable as well on RT), and RT Critics ratings being more irrelevant than ever, bordering on ridiculous - neither is actually a good indication of anything, least of all quality. 

I think you can surmise what is my stance about RT. It's Metacritic I'm after. 

Edit: And no, haven't tried it yet, my TMM version writes old version "rottenTomatoes" (and, tbh, it never occured to me that tag is wrong, TMM being overall solid as it is), so I was fighting with that, trying to get it at least shown when read by Emby and then manually rewrite values from Metacritic and with some custom CSS maybe replace icon in Web App - however, never passed step 1. 

Edited March 11, 2021 by GrimReaper76
Append

[Happy2Play 9280]

True as OMDB is the source of the majority of these ratings if they exist there.

But doesn't look like Emby writes the new rating format yet.  

[GrimReaper 3881]

Ok, to follow up (and it's all reading-related, as writing is secondary atm):

@pünktchen, yes, "tomatometerallcritics" is parsed correctly and assigned to <criticrating>. Also default="true" is respected throughout the <ratings> tree. 

So, in general, desired results CAN be achieved in certain scenarios, while failing in others:

1) Rating IMDB, default + rating RT Critics / parsed properly, <rating> and <criticrating> associated correctly

2) Rating IMDB + rating RT Critics, default / parsed properly, <rating> and <criticrating> associated correctly

3) Rating TMDB (or any other, irrespective of name tag, except RT Critics), default + rating RT Critics / parsed "mostly" (Metacritic again) properly, <rating> and <criticrating> associated correctly

4) Rating IMDB, default + rating Metacritic / parsed partially, <rating> associated with IMDB (default), <criticrating> ignored

5) Rating IMDB + rating Metacritic, default / parsed improperly, <rating> associated with Metacritic (default), <criticrating> ignored

To summarize, with multiple ratings (2 or 2+), tag "default" is looked and respected, irrespective of provider position (1st, 2nd, 3rd, 4th in the ratings tree), <rating> correctly associated (except when name="tomatometerallcritics", then <criticrating> gets correctly associated but <rating> gets the first one from the list, whichever "name" tag is present, even if IMDB is down the line, 2nd or 3rd or 4th).

So, for all intents and purposes it IS usable, and, for Emby's purposes, correct: all ratings except RT Critics bind to <rating>, latter to <criticrating>. 

That makes this whole topic kinda moot (although nfo writings is still pending), what remains is to push @Luke to recognize Metacritic tag (and associate <criticrating> appropriately, which shouldn't be a giant modification, if it's “Metacritic, default“ > associate, else RT Critics), but that can as well be done in appropriate FR thread. 

Thanks to both, you and @Happy2Play for your input, we'll see if anything will come out of it. 

Cheers

Edit:

 

 

 

Edited March 11, 2021 by GrimReaper76
FR Link

[pünktchen 1343]

The simple reason why Metacritics doesn't make sense for critic rating in Emby is that currently every Emby app shows a tomato icon for that rating.

Edited March 11, 2021 by pünktchen

[Luke 39296]

Right we will want to revamp our rating storage at some point so that it's more geared towards handling multiple ratings from different providers.

[GrimReaper 3881]

16 minutes ago, pünktchen said:

The simple reason why Metacritics doesn't make sense for critic rating in Emby is that currently every Emby app shows a tomato icon for that rating.

I'm aware of that (hence mentioned custom CSS, at least for Web app), but even without that, I'd much rather have RELEVANT number and INCORRECT icon than CORRECT icon and IRRELEVANT number, until below gets implemented:

13 minutes ago, Luke said:

Right we will want to revamp our rating storage at some point so that it's more geared towards handling multiple ratings from different providers.

 

Edited March 11, 2021 by GrimReaper76
Typos