Prefer MetadataProvider enum as provider id key over arbitrary strings

[Shadowghost]

The key of provider IDs can be set to arbitrary strings from external sources like NFOs.
To properly handle cases where these strings resemble internally available a value in the MetadataProvider enum we should use those values and not the string for best compatibility.

[almightiest]

This doesn't work with Kodi NFO exports and the newest TheMovieDb python scraper they recommend to use. Long story short, they set the type as "themoviedb" instead of "tmdb" so the enum doesn't match. May need to have some kind of dictionary lookup to map from themoviedb to the tmdb enum?

[Shadowghost]

I can only see the long name being used by the rating and that one we handle (not properly but we handle it and use the rating)

[almightiest]

Their new scraper sets both the rating name and uniqueid type to "themoviedb" from what I'm seeing. When I clear out the provider id in my Jellyfin metadata, update the NFO to use the new format, and initiate a Jellyfin metadata replace for the movie, it doesn't import the external id. Once I change the uniqueid type back to "tmdb" (overriding what Kodi exports) it imports again in Jellyfin 10.8.0b3.

[Shadowghost]

I tried all available metadata scrapers in the Kodi 20 alpha and the NFO was never written with themoviedb as a uniqueid.

[almightiest]

Weird, maybe something else caused it to get changed. I did look at the Kodi video119 database (from Kodi v19) and the uniqueid type exists as themoviedb after scanning in a movie with their TMDb python scraper. Maybe the uniqueid.type is getting translated to tmdb on export in v20?

[almightiest]

I re-ran some tests and isolated it to just Kodi and their newest python scraper, and it did as you said, uniqueid=tmdb and rating=themoviedb. Sorry for the trouble!