Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Daydream]

To what degree does MC support (Kodi's) NFO files?

Best guess is 'just read' and... most fields that make sense without creating conflicts with MC's own metadata.  I wonder if <userrating></userrating> can be added to what MC reads; right now it doesn't work, even if created manually.

[blgentry]

Short answer:  I don't know but if you have tested and MC does not read NFO files, I am not surprised.

I think of MC as primary library management interface.  It's pretty darned good at extracting metadata from file names.  It's pretty good at looking up movies and tv shows based on whatever metadata you have filled in.  It's also a video player.

Something like Kodi is just a player and organizer.  It's not a metadata resolver in any real sense.  It's just a reader. Frankly Kodi is pretty awful at all of the tasks it does.  I used it for quite a while before switching to something else.

In the MC universe, you pretty much use MC for everything I listed above.

In other universes (like Plex and Kodi), you can use an external metadata manager and have Plex or Kodi read those NFO files as a way to interface between them.  I'm currently doing that with another product and it works well.

On the other hand, the MC developers are pretty open to non-invasive integration.  So perhaps they would spend the time to write and NFO reader/writer.  I kinda doubt it though since they have such a heavy investment being a metadata manager and lookup tool.

Best of luck,
Brian.

[eve]

NFOs work with my media files. In my case the NFO is the exact same name as the video file, just with the .nfo extension. I don't do movie.nfo. I've found this is easier since I end up with multiple versions of films.
JRiver picks up sensible things from the NFOs. For me personally, the important field is the ID of the media (since essentially how I interact with my library and playback isn't within JRiver itself).

I don't particularly love relying on NFOs but they're the easiest way to non destructively associate an id with a specific file that works across a bunch of different software.

[Daydream]

That's the thing. MC does support reading NFOs. The feature was added many moons ago (4-5 versions ago?) kind of like a silent surprise, and am not sure if anybody looked at it ever again. Not sure if it was meant to be maintained, or it was just a cool little thing the team cooked up in an afternoon .

But my main concern is <userrating>. It would be helpful to be added to what MC reads from NFO, in the sense that would help people moving from Kodi to MC, without having to redo a hell of a lot of personal ratings. Strategically, that should be an idea with some appeal to the devs .

[eve]

That's the thing. MC does support reading NFOs. The feature was added many moons ago (4-5 versions ago?) kind of like a silent surprise, and am not sure if anybody looked at it ever again. Not sure if it was meant to be maintained, or it was just a cool little thing the team cooked up in an afternoon .

But my main concern is <userrating>. It would be helpful to be added to what MC reads from NFO, in the sense that would help people moving from Kodi to MC, without having to redo a hell of a lot of personal ratings. Strategically, that should be an idea with some appeal to the devs .

Yeah, I think support for <userrating> might be wise. Not something I use but I can really see the appeal.

I'm *very* glad they support NFOs though, I was worried I was going to have to start generating sidecar files in my ingest pipeline.

[JimH]

But my main concern is <userrating>. It would be helpful to be added to what MC reads from NFO, in the sense that would help people moving from Kodi to MC, without having to redo a hell of a lot of personal ratings.

We'll take a look at it.

[Hendrik]

I've updated the NFO parser to use the <ratings> field for our Critic Rating field, like our own Web Scrapers do, and use <userrating> for Ratings.
Let us know if it works for your NFOs once the build is out!

[Daydream]

This is working very well! Big thanks guys!

[AnteBios]

Please allow me to hijack this thread since its title is approrpiate.

For me, I'm just tinkering with Kodi on a QNAP Nas, and using it as a media player via the QNAP hdmi out.
I didnt need this when JRiver was on QNAP HDStation, but this is now history.

I organise all my libraries with JRiver, it is my single source of truth, which gives me total control over the metadata. And I love it this way.
I would like Kodi to read the sidecars xml and use that information instead of the other way round. I do not care about what scraper Kodi uses to get the metadata - I want to have control over it, and that's what JRiver gives me. Kodi just makes guesses and takes the best one, which will work fine in 80% of cases, but for me that's not enough.

So ideally instead of having a .nfo import function in JRiver (which exists since v19 I believe), an export to .nfo would be much more useful for me, since Kodi will parse an nfo if it exists before using its scrapers (see https://kodi.wiki/view/NFO_files).
The trick would be matching the sidecar's tags with the nfo ones, for instance <Field Name="Description"> with <plot>.

I could write my own xml parser and converter in python and do all that in a batch on all my sidecars and run it manually for new files, but of course it would be nicer to have it embedded in JRiver.
Would that be feasible for the devs?

[eve]

Please allow me to hijack this thread since its title is approrpiate.

For me, I'm just tinkering with Kodi on a QNAP Nas, and using it as a media player via the QNAP hdmi out.
I didnt need this when JRiver was on QNAP HDStation, but this is now history.

I organise all my libraries with JRiver, it is my single source of truth, which gives me total control over the metadata. And I love it this way.
I would like Kodi to read the sidecars xml and use that information instead of the other way round. I do not care about what scraper Kodi uses to get the metadata - I want to have control over it, and that's what JRiver gives me. Kodi just makes guesses and takes the best one, which will work fine in 80% of cases, but for me that's not enough.

So ideally instead of having a .nfo import function in JRiver (which exists since v19 I believe), an export to .nfo would be much more useful for me, since Kodi will parse an nfo if it exists before using its scrapers (see https://kodi.wiki/view/NFO_files).
The trick would be matching the sidecar's tags with the nfo ones, for instance <Field Name="Description"> with <plot>.

I could write my own xml parser and converter in python and do all that in a batch on all my sidecars and run it manually for new files, but of course it would be nicer to have it embedded in JRiver.
Would that be feasible for the devs?

You answered yourself with my suggestion. It's like an afternoon of a project at most if it's something you want to do yourself with python or whatever.