File/Folder-Naming Conventions for FanArt and Posters?

[billyad2000]

I was wondering if someone could state catagorically the naming conventions needed by XBMC for fanart and posters with stacked filenames.

Media Companion currently uses the following format :-
88 Minutes (2007)\88 Minutes (2007)-pt1.nfo
88 Minutes (2007)\88 Minutes (2007).tbn
88 Minutes (2007)\88 Minutes (2007)-fanart.jpg
Which seems to work ok for most people.

When I started Media Companion I used :-
88 Minutes (2007)\88 Minutes (2007)-pt1.nfo
88 Minutes (2007)\88 Minutes (2007)-pt1.tbn
88 Minutes (2007)\88 Minutes (2007)-pt1-fanart.jpg

This worked ok for the .nfo and .tbn files, but the fanart wasn't seen by XBMC

I then started using stacking for fanart :-
88 Minutes (2007)\88 Minutes (2007)-fanart.jpg
Which worked fine.

Then I got the report that from build 16609 the .tbn also had to be stacked, so I changed MC to output the filename :-
88 Minutes (2007)\88 Minutes (2007).tbn

According to my information and the XBMC Manual, both of the above should work fine yet I am continuing to have complaints from some that it is not working.

If I change it either way then I get complaints from others that XBMC is not seeing posters.

What I would like to know is what is actually supported by XBMC. Once I have this information then I can make sure that Media Companion outputs the files with the correct filename and ask anyone having issues to post a bug report for XBMC.

This issue may not only apply to the XBox Version of XBMC, but since most of the feedback I have been getting are on the XBox platform I have posted this here.

[fekker]

I think the answer is part of the question, it all depends on the version of XBMC that they are running, and if it's in a folder or not.

There have been a ton of changes in the svn builds for the library portions, movie.gif even works now as a valid image.

I don't remember the rev number, around 16400 ish, movie.tbn, fanart.jpg, fanart.png, movie-trailer.<ext> where added, a few weeks prior to that movie.nfo and I think .xml was added (that's what tiggered my idea of the movie.tbn and other files), later those where updated without the extension requirements.

In the current svn build, stacking everything works.
myhappymovie-cd1.avi
myhappymovie-cd2.avi
myhappymovie.nfo
myhappymovie.tbn
myhappymovie-fanart.jpg

In older builds, it didn't. What I do is configure MIP to output everything for folders by default, that way it'll work for many different versions. And for stack errors, I recommend updating xbmc.

The xbox versions are usually behind by a week or two (total guess here based on what I've seen).. but those all vary too.

For folders, under the newer svn builds
movie.tbn
movie.nfo
fanart.jpg

That covers all of the different names, I still output <foldername>.nfo, <foldername>.tbn, and <foldername>-fanart.jpg by default to cover more versions.
and this works too it the (with the really new svn's.. i know I am not real helpful without the svn build numbers, i just dont' recall those.)
movie.jpg
movie.nfo
fanart.png

[billyad2000]

Thanks for you reply,
I think that if that is the case then it may be wise to just to give people the option of how they want to output these files, that way everyone is happy. Although I really don't see the need for all the different filenaming conventions, after all, it is just a filename, the content in all cases is identical.

[Kilack]

Hi,

Yeah I was one of the people that had problems with files being output in stacked format and xbmc not picking them up but in the format filename.cd1.tbn it worked.

As no one really is certain what versions are doing what it all gets quite confusing so I think your idea of being able to select what be a good addition and probably the option to convert from one file format to the other because it seems xbmc does different things in different versions .

A developer mentioned in another thread in this forum that he had fixed something to do with this in a very recent syn 17xxx.
Those syn builds aren't around for the xbox though and the t3ch builds are quite old now, their "stable" build is very old and that is probably what quite a few people run? which definitely doesn't like the stacked format..

[sho]

As you guys probably understand, XBMC is a very organic piece of code.
There is a lot of people working on it and regressions are introduced and fixed on a regular basis.

The goal of the docs has traditionally been meant to reflect the status of current SVN, but with the long awaited relase of a stable (8.10) I intend to change that.

Until I get the correct namespace support in our mediawiki installation the docs are meant to apply to 8.10 and nothing later.

Once we have namespaces in place I intend to start splitting 8.10 and SVN info.

Enough on that, perhaps the helper program authors should do something similar?

That is, publish a version of their program that is "certified" to work with the latest stable and anything beyond that is on an experimental basis only.

[billyad2000]

Originally Posted by sho

As you guys probably understand, XBMC is a very organic piece of code.
There is a lot of people working on it and regressions are introduced and fixed on a regular basis.

The goal of the docs has traditionally been meant to reflect the status of current SVN, but with the long awaited relase of a stable (8.10) I intend to change that.

Until I get the correct namespace support in our mediawiki installation the docs are meant to apply to 8.10 and nothing later.

Once we have namespaces in place I intend to start splitting 8.10 and SVN info.

Enough on that, perhaps the helper program authors should do something similar?

That is, publish a version of their program that is "certified" to work with the latest stable and anything beyond that is on an experimental basis only.

While I agree with what you are saying about the organic nature of XBMC I don't think this should have to apply to things like .nfo, .tbn, or -fanart.jpg naming conventions. As long as XBMC has a set naming convention then it doesn't really matter what the filename is, either way it could be consistant.

A good example of this would be the following.

movie cd1.avi
movie cd1.nfo
movie cd1.tbn
movie cd1-fanart.jpg

For multi-file movies it seems like a solid foundation to have the accompanying files named after the first media file. With the exception of fanart, all of the above work, at least until build 16609, then I was told that "movie cd1.tbn" no longer works. "movie cd1-fanart.jpg" has never worked even though the manual seems to say it does.

While eventually I could only release a new version of Media Companion after every stable point release of XBMC, at the moment it is still in early development and as such is going through rapid transition. In addition to this, as things stand, people with older versions of XBMC would either be forced to upgrade, or loose any added functionality from Media Companion.

The only way I can see to proceed is to continue to add all variations to Media Companion and let users set there preference.

[sho]

Originally Posted by billyad2000

While I agree with what you are saying about the organic nature of XBMC I don't think this should have to apply to things like .nfo, .tbn, or -fanart.jpg naming conventions.

Of course we should not have regressions or inconstancies with filenaming conventions, but sometimes shit happens like the recent tbn case proves.
It was btw fixed in r17247.

Originally Posted by billyad2000

"movie cd1-fanart.jpg" has never worked even though the manual seems to say it does.

That should be considered a bug, please open a trac ticket.

Originally Posted by billyad2000

For multi-file movies it seems like a solid foundation to have the accompanying files named after the first media file.

Yes, maybe all stackname support should be removed, both for nfo and thumbnails?
(Discussing with Spiff, he seems partial to that).

[billyad2000]

Originally Posted by sho

Of course we should not have regressions or inconstancies with filenaming conventions, but sometimes shit happens like the recent tbn case proves.
It was btw fixed in r17247.

That should be considered a bug, please open a trac ticket.

Yes, maybe all stackname support should be removed, both for nfo and thumbnails?
(Discussing with Spiff, he seems partial to that).

I didn't know that the .tbn issue had been fixed, thanks for the headsup

About stack names being used, I'm neither for or against it, there is a very small posibility of causing an issue if the stackname for a movie file is identical to an existing file but the chances of this happening is remote in the extreme.

I added a ticket for the fanart issue.

[o_dog]

i got a question thats kind of related. If you have a rared movie does the movie have to be namned after the rar file or the file that it contains? And of it contains CD1 CD2 in folders, should the tbn be locted in parent dir?

[spiff]

it's called 'make archives transparent' for a reason - the code never see's them .rar's, i.e. what is inside is what counts. i *think* it expects cd1/file.tbn, but i'm not 100% sure (no time to check)