tvshow and episode nfo files

From what i gather in the information i found on the forum, the episode nfo files only contain the episode information? And is thus connected to the tvshow.nfo in parent dir or something like that? The wiki is kind of outdated when it comes to nfo files, so it's a bit of a challange to find any reliable information on it.

But wouldn't it be easiser for everybody to include a:
<tvshow>showname</tvshow>
tag to the episode file? This way you can spread the shows over several drives and it also let's you use a diffrent kind of dir structure.

br

ps. just realised i was in the wrong part of the forum, sorry

it's not as simple as you suggest, and no it's not supported currently.
feel free to convince me otherwise, but i only accept arguments written in c++

never said it was simple, said it would be easier for everyone. To have the info imported from the same file must be a much better way to do it then to have it linked to diffrent dirs and files all over the place.

Btw, I don't argue in c++, it would just be stupid since i'd lose!

For a start, tvshow names are not unique, so you'd have to have the year information in addition to just the show name.

Currently tvshows are tied (at the database level) to the path they reside in. Clearly this is not as optimal as it could be, but it does make it much easier to code.

We have to get the tvshow name from somewhere. If we don't explicitly take it from the foldername as we do now, we'd need some other way to identify it. This is non-trivial to reliably identify.

I'm happy to take arguments in well-formed english, as I'll be rewriting the importing routines for shows at some point in the coming weeks. Note that I consider nfo file use an edge-case. The majority of users do not (and should not) bother with such a mechanism. Identify an algorithm that's going to work for everything, and I'm more than happy to consider it.

Cheers,
Jonathan

I personally tend to shuffle things around to keep them organised together, but I can see how in some instances they can end up split over several drives, such as those shows that are ongoing. Some people just aren't that organised.

TV Show titles are not unique, but it occurred to me that a single identifier that could be used would be the IMDB ID, it is also used by TVDB, a single additional tag within each episode nfo file eg <showid>tt0285331</showid>, would tie each episode to the correct tvshow no matter where the episode was located.
Equally difficult would be the initial scraping of the file, how do you let XBMC or any other companion program know that multiple directories are the same show. It is by no means impossible, but i'm not sure the benefit would be worth the work needed to implement.

jmarshall Wrote:Note that I consider nfo file use an edge-case. The majority of users do not (and should not) bother with such a mechanism.

Hey JM, can you please clarify this statement? Are you saying nfo files are a waste of time for the average user? If so, why?

XBMC should be able to do everything for the average user. They should not need to use some other program (or worse, hand editing some file) to get that sort of information into XBMC.

Cheers,
Jonathan

jmarshall Wrote:XBMC should be able to do everything for the average user. They should not need to use some other program (or worse, hand editing some file) to get that sort of information into XBMC.

Cheers,
Jonathan

Appreciate that. I can now see your point.

Does this mean XBMC will eventually be able to create, store, edit nfo type files?

Perhaps it will be able to add all the "Per Movie" settings to them as well (not sure if this is possible with export library??). It's annoying having to re-set all the settings when you rebuild your library - nice to have them stored in an nfo so they remain constant until changed - especially as the dB can become corrupted/overwritten/lost/rebuilt and then everything is gone.

imdbid and tvdb id is not an option - those are for a single backend and we support any backend people care to write a scraper for (only partially true for imdbid i know but my point is still valid)

NFO files are the devil's work, but sometimes, it's good to have the devil on your side.

They are a necessary evil at times in order for ANY media manager to associate metadata for a media file.

A media manager can only guess so much... either using the filename, folder name / path, or embedded metadata in the file. Arguably, 'duration' of a media file MIGHT be of some use too.... but basically it needs to get enough information about media file to be able to UNIQUELY deduce which movie / show / song etc it truly is (with the help of internet databases).

The problem is... those internet databases aren't perfect, often missing tonnes of titles, AND... they can come and go (so XBMC cannot ever tie itself to using any ID from these databases).

If there are two movies called "Heat" then it's impossible for XBMC / scraper to know which movie you mean. "Heat (1968)" MIGHT help. "Heat (1968) (133mins)" might help even more etc etc.... but ultimately the only GUARANTEED way of making sure XBMC , deduces the right data is by....erm... NOT letting XBMC deduce it!, instead you have to forcibly ram the truth down its throat! ... and that's done with that devilish NFO crap!

Mr Marshall is quite right.... end users shouldn't have to know or have an NFO. Sadly, there is no option if the end user wants total control and reliability.

It would actually help if people could SPELL. (That goes for torrent creators, end users and internet DB folks!)

"Hary Poter" is no help to anybody!


Oh, and whilst I'm on a rant, folks who store media in a mix of flat and hierarchical manners and using multiple naming conventions, probably deserve to suffer!
Why should anybody be bothered to code for that if the user can't be bothered to at least keep their media in some sort of consistent style?

It's not an XBMC issue... it's just life (all media managers have the same issue)


I am generally a very tolerant kinda guy. It's just that I think anybody who isn't as tolerant as me should be shot.