+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)
- Paradise - 2009-06-26 00:15
Where can i see the specs your talking about (link)? I get lost in the wiki..., and everywhere i read they talk about .tbn not cover.jpg.
Your right, you can have the movie poster or the cover. Nothing wrong if we have this solution. For me i think everything has to look like i look into my DVD-rack
.Put than i also don't understand this 9:16 thing. Cause movieposters are not 9:16.
Sorry if i don't understand this thread if this is allready there
Frame? Really? All i know is this extrathumbs folder that forces me to make a extra folder for every disc in a boxset/discset...
- ccMatrix - 2009-06-26 02:14
Paradise Wrote:Where can i see the specs your talking about (link)? I get lost in the wiki..., and everywhere i read they talk about .tbn not cover.jpg.
Your right, you can have the movie poster or the cover. Nothing wrong if we have this solution. For me i think everything has to look like i look into my DVD-rack
Put than i also don't understand this 9:16 thing. Cause movieposters are not 9:16.
Sorry if i don't understand this thread if this is allready there
Frame? Really? All i know is this extrathumbs folder that forces me to make a extra folder for every disc in a boxset/discset...
Maybe it is best if you go to the very fist post of this thread and start reading. Page 3 has the proposed naming scheme.
- Paradise - 2009-06-26 05:16
@ccMatrix, your right, the "proposed" naming scheme. But AnalogKid is saying its allready possible what i want.
AnalogKid Wrote:Please read the actual spec first, it covers most of what you want
OH WAIT!!
Did he mean in his specification, his propose? That my propose is possible with his propose? He did not talk about the actual XBMC specs?
Holly sh... - i got you. Sh... this is embarrassing.
1000 times sorry AnalogKid, this was a communication problem.
Ok, so we need the BoxSet, DiskSet stuff and AnalogKid's propose and i can start putting my media into XBMC.
- xexe - 2009-06-26 09:54
AnalogKid Wrote:starwars.avi -> starwars.movie.fanart
starwars1.avi -> starwars1.movie.fanart
starwars-CD1.avi -> interesting case here IF starwars.avi exists also.
starwars-CD1.avi -> was this supposed to be CD2? otherwise this use case is invalid
starwars2.avi -> starwars2.movie.fanart
starwars2.mkv -> user would have to rename or we can fix with below solution
For the 'interesting cases' I think we can fix this easily in the spec with
starwars.avi.movie.fanart (incorporating the extension too)
starwars-CD1.movie.fanart (incorporating the stacking info but not too keen on this)
so, the movie stacking isn't an issue... but the case here (as you've described) is:
Starwars.avi
Starwars-CD1.avi
Starwars-CD2.avi
if the user renames Starwars.avi... the problem is solved
OR the schema needs to handle stacks slightly differently ie.
Starwars-CD1.avi artwork is found in the following
-- Starwars-CD1.movie.artwork
-- Starwars.movie.artwork
Starwars-CD2.avi artwork is found in the following
-- Starwars-CD2.movie.artwork
-- Starwars-CD1.movie.artwork
-- Starwars.movie.artwork
Of course, in your use case, the user cannot use 'starwars.movie.artwork' since this is used by starwars.avi
So, in summary, I think we can handle it, but.. I'm more in favour of having the user rename the file, since this is (imo) an artificial use case.
What do you think?... I think we can solve it, but just want find the best choice
I think that its complex. For this to be successful it should closely match how XBMC works both now and in the future.
If you need XBMC logic changed you stand a much smaller chance of getting it implemented unless you can code it yourself.
The devs also have very strong opinions on stacking etc so that should be kept in mind as well.
I would say that renaming should essentially never be considered. You should not have to rename your collection to cater for software... the software should cater for your naming.
XBMC does this by using the stacking regex and the stacked name nfo which we have seen in these examples.
Also what if a user has this sources setup
\\disk1\movies\
\\disk2\movies\
and each source contained starwars.1.avi with nfos that define what they are.
XBMC caters for this but you will have two identically named files for potentially two completely differrnt movies. This is the exact situation you want to avoid because it means your JPGs are folder/path sensitive.
Also now these helper applications need to not only be able to handle XBMC native stacking regex, XBMC user stacking regex they also need to be able to understand all the nfo type files XBMC does and be aware of the differnt sources paths to ensure it doesnt cache the files itself and create clash of identically named files.
So whilst this example may be artifical if XBMC handles it your naming scheme needs to handle it.
This takes us on to stacked naming. The only way to know what a movies stacks to is to use software or XBMC itself. You can guess on most occasions but not all. So now we have to teach users what stacking regex is and how to deal with it.
And TBH were not even at some of the potential really complicated edge cases yet.
So you/we are definately getting there but its easy to pick a scheme that works most of the time but it needs to work all of the time.
- Gangsta - 2009-06-26 11:12
Flexibility is good, but in the end, the users have to take some responsibility for their actions.
Having two films with the same name (excluding stacking, etc) could only happen if the user made the decision to put them in seperate directories/drives. Why is this - its because the clever folk who have been designing O/Ss for the last 40 years decided that having two files with the same name in the same folder would be confusing, therefore preventing it happening. It should be the same here.
I Think that XBMC should 'assume' that the first file with a name specified that it finds is the correct match to the artwork, and ignore any others.
The scrapers and media managers/scrapers can do a quick check, and if it comes up with potential clashes, bring up a box.
'You have more than 1 file called <filename>.<ext> - you should rename one of the files, to make it unique, possibly adding the year, or studio etc to the name.'
'Having unique filenames across all sources is best practice and essential for predictable results within your media centre'
Either that or a small script bundled with XBMC, that scans your library looking for potential problems and offering advice.
My last thought on the subject was adding a tag to the advancedsettings.xml something like <strictmediarules>
Using that setting as a simple switch in the code, if <strictmediarules> is turned on, it skips over all the existing filehandling code, to some new code that ONLY looks for the filenames, types etc defined in the schema. And we (the users supporting the new 'standard' and not doing stupid things like calling two movies the same name without distinguishing between them will benefit from the speed improvement (by only looking for one specific file for each purpose) and get the benefit of a more organised library too. If <strictmediarules> is turned off then the systems works exactly as it does now, but carries on in code to look for the new schema based artwork once it has exhausted folder.jpg, moviename.jpg, etc
Possibly my suggestion above about only using the first set of artwork with the first set of media files should only be enforced in strict mode - as it would be a requirement of turning on strict that you dont have duplicate file names.
Skins could take advantage of the setting, and behave appropiatly, if its on, then it can request very specific items, and look really smart - if the setting is off then it does what it can to make it look good with the unknown artwork its getting handed.
sorry if im rambling - im sooo tired
- xexe - 2009-06-26 11:22
Gangsta Wrote:...
I Think that XBMC should 'assume' that the first file with a name specified that it finds is the correct match to the artwork, and ignore any others..
...
This is not how XBMC currently works. I suspect it is unrealistic to expect the devs to change XBMC in this way to accomodate some nicer artwork filenames.
Edit: actually if you dont allow users to use multiple source but force them to use concatenated sources it might work this way. But its still a bit of a kludge.
Gangsta Wrote:...
'You have more than 1 file called <filename>.<ext> - you should rename one of the files, to make it unique, possibly adding the year, or studio etc to the name.'
'Having unique filenames across all sources is best practice and essential for predictable results within your media centre'
...
I agree it is bad practice but XBMC caters for it so this sceheme really needs to as well. I think it is unliekly you are going to convince a dev that they should stop catering for this making XBMC less capable.
Its all to much of a kludge solution to suggest this and they dont like kludges.
I am not trying to be negative but the devil is in the detail.
Abandon trying to accommodate file mode only users and this becomes easy
- AnalogKid - 2009-06-26 11:40
Gotcha!
I'm curious though...
How does XBMC handle TV shows in the current situation (across two sources)
Source1\\House
----- Season 01.tbn
----- Season 01.nfo
------S01E01.avi
Source2\\House
------Season 01.tbn
------Season 01.nfo
------S01E02.avi
Here we have a conflict with 2 thumbs and 2 nfos... which does xbmc choose in this scenario? Since it will render the season in a combined manner and can only have ONE thumb and ONE nfo for the season.
I know that for music, XBMC takes an informed guess and chooses the one containing most music for a given artist. (Still flawed, but work ok 90% of the time)
So, given the multipath / source issue and two media files of the same name... there's only a couple of options.
a) Users should avoid this (not a great option)
b) The artwork must share the same path (not ideal, but workable)
c) The user must be asked to choose the artwork (choose from list of multiple local thumbs) as it is today when the wrong artwork is shown.
d) The <moviename> (or music etc) must be a unique key (hence your IMDB proposal), but this is problematic for other reasons. The true movie name is almost unique, but not if someone has two copies of the same movie and wants exactly the same name for both versions too) - slightly artificial usecase, but possible. I have 'directors cut' and 'normal' versions of some movies, but the movie title is different as a result.
e) something else!
With multiple sources, we ALWAYS have the issue with two files of the same name, and potentially two conflicting thumbs and NFOs
xexe Wrote:I think that its complex. For this to be successful it should closely match how XBMC works both now and in the future.
If you need XBMC logic changed you stand a much smaller chance of getting it implemented unless you can code it yourself.
The devs also have very strong opinions on stacking etc so that should be kept in mind as well.
I would say that renaming should essentially never be considered. You should not have to rename your collection to cater for software... the software should cater for your naming.
XBMC does this by using the stacking regex and the stacked name nfo which we have seen in these examples.
Also what if a user has this sources setup
\\disk1\movies\
\\disk2\movies\
and each source contained starwars.1.avi with nfos that define what they are.
XBMC caters for this but you will have two identically named files for potentially two completely differrnt movies. This is the exact situation you want to avoid because it means your JPGs are folder/path sensitive.
Also now these helper applications need to not only be able to handle XBMC native stacking regex, XBMC user stacking regex they also need to be able to understand all the nfo type files XBMC does and be aware of the differnt sources paths to ensure it doesnt cache the files itself and create clash of identically named files.
So whilst this example may be artifical if XBMC handles it your naming scheme needs to handle it.
This takes us on to stacked naming. The only way to know what a movies stacks to is to use software or XBMC itself. You can guess on most occasions but not all. So now we have to teach users what stacking regex is and how to deal with it.
And TBH were not even at some of the potential really complicated edge cases yet.
So you/we are definately getting there but its easy to pick a scheme that works most of the time but it needs to work all of the time.
- Gangsta - 2009-06-26 11:43
I agree wholheartedly with your comments, but i am firmly in the camp of strict filename rules, following a predetermined schema, that way if I spend a tiny amount of time maintaining MY collection (yup, its my collection of media, therefore I expect that I should have to keep it updated and in a format that works in the mediacenter that I choose)
And in this world of strict filenames, it would be a moot point because I wouldnt have any duplicates, and XBMC would not expect my to.
But there are people out there who download all sorts of random stuff from the net, dump it in a folder, then expect the devs of the scrapers, and media managers to somehow decipher what they have downloaded and sort everything out for them.
I think my tuppence may be running out
- xexe - 2009-06-26 12:26
Not to labour the point but how you and we do it is only a subset of how all xbmc users do it. We need to cater for ALL if this has any hope of succeeding
if someone has:
/disk1/star.wars.dvdrip/movie.avi
/disk1/star.wars.dvdrip/movie.nfo
/disk1/star.wars.dvdrip/folder.jpg
and
/disk2/clear.and.present.danger.dvdrip/movie.avi
/disk2/clear.and.present.danger.dvdrip/movie.nfo
/disk2/clear.and.present.danger.dvdrip/folder.jpg
not only with XBMC currently work it wouldn't even matter if they were on the same disk, the naming scheme proposed here would give them identically named images.
this is a perfectly valid end user scenario.
Can i suggest another route for consideration coming back to a pth i talked about originally.
There is no reason to have to have these images all over the FS beside the videos. They could all be stored in one central reposiroty on the user PC or network.
This changes the model from one of artwork per video file to artwork per source. Movie X, tvshow Y and episode Z are always what they are regardless of end user file naming. So if you simple organise based on a unique identifier such as tvdb, imdb, tvrage, tmdb id as per the user scraper preferences you can easy have a structure:
Movies
-imdb
--tt123456
-tmdb
--ABCDE
This relies on the app knowing how to lookup this cache by say foldername, movie name or nfo scraping but it solves alot of problems. Gone is stacking regex. Gone are multiple copies of the same file for SD and HD sources etc
I admit it is not the direction being discussed here but it makes naming easy, sharing of caches easy, backup of cache easy, cross platform and application specirications and usage easy and guarantess on dupes.
Ponder it over. I would love to be able to uplaod my 1GB userdata image cache and have user automatically able to use it witout all the needless "every user hammer tvdb et al
The Story So Far - AnalogKid - 2009-06-26 21:23
OK, I just needed to do this for my own sanity and try and get back on track esp with xexe's input...
Filenaming Schema
The AIM:
This schema is designed to resolve a number of issues with the current plethora of possible artwork naming schemes AND improve skin functionality by:
1) Offering a totally consistent naming convention for art
2) Being completely unambiguous about what the art is doing
3) Is placeable ANYWHERE in the filesystem (does not 'have' to reside alongside the media, although it my if it wishes)
4) Allows a wider range of art than is currently possible
5) Supports different orientations of art (landscape and portrait)... so skins can pick up whichever style they require
6) Is possible to rapidly port the existing scheme to this proposed scheme via a script (which is also reversible!)
7) Allows for art at all levels of media (eg. Tv show, season AND episode level for all artwork types)
The Spec
note:
Fanart = Large image / wallpaper, usually full screen representing the media
Cover.Front =The image you'd expect to see on the front of the box (DVD, CD case)
Cover.Back = The image you'd expect to see on the back of the box (DVD, CD case)
Cover.Inner = The image you'd expect to see on the liner notes / inside the cover)
Cover.Sleeve = The unfolded back, spine and front cover all in one
Cover.Disc = The image of the physical disc label (usually a round image)
Poster = Usually a 'Promotional' poster... promoting a movie or album release.
Banner = A highly oblong image usually landscape representing the media
Framegrab = A snapshot of the media (screen shot) of the playing TV show or movie, not applicable to Audio
Logo = A 'symbol' associated with the media, usually an iconic logo or symbol
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
<n> = Some number to allow multiple instances of artwork types. e.g. Starwars.movie.framegrab.001
MediaInfo = 'Flags' as they are termed today. I felt the term MediaInfo was easier to understand
HasBeenPlayed = 'Watched', but a more generic term to cover Audio and even Images
Items in GREEN are optional
<moviename>.movie.fanart[COLOR="green"](.landscape/portrait).<n>
<moviename>.movie.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<moviename>.movie.poster(.landscape/portrait).<n>
<moviename>.movie.banner(.landscape/portrait).<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.logo.<n>
Examples:
Star Wars.movie.fanart.landscape.01.jpg
Superman.movie.coverart.portrait.jpg
Regex for the above is:
(.*)(\.movie.*)$
<tvshow>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>.tvshow.poster(.landscape/portrait).<n>
<tvshow>.tvshow.banner(.landscape/portrait).<n>
<tvshow>.tvshow.framegrab.<n>
<tvshow>.tvshow.logo.<n>
<tvshow>^<season>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.poster(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.banner(.landscape/portrait).<n>
<tvshow>^<season>.tvshow.framegrab.<n>
<tvshow>^<season><episode>.tvshow.fanart(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.poster(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.banner(.landscape/portrait).<n>
<tvshow>^<season><episode>.tvshow.framegrab.<n>
Examples:
Friends.tvshow.fanart.landscape.jpg
The Simpsons^S01E12.tvshow.framegrab.04.jpg
Regex for the above is:
TBD
<artist>.music.fanart(.landscape/portrait).<n>
<artist>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>.music.poster(.landscape/portrait).<n>
<artist>.music.banner(.landscape/portrait).<n>
<artist>.music.logo.<n>
<artist>^<album>.music.fanart(.landscape/portrait).<n>
<artist>^<album>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>^<album>.music.poster(.landscape/portrait).<n>
<artist>^<album>.music.banner(.landscape/portrait).<n>
<artist>^<album>^<track>.music.fanart(.landscape/portrait).<n>
<artist>^<album>^<track>.music.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<artist>^<album>^<track>.music.poster(.landscape/portrait).<n>
<artist>^<album>^<track>.music.banner(.landscape/portrait).<n>
Examples:
Madonna.music.fanart.landscape.jpg
Bon Jovi^Greatest Hits.music.cover.front.jpg
Regex for the above is:
([^\^]*)\^?([^\^]*)?\^?([^\^]*)?(\.music.*)
<genre>.genre.fanart(.landscape or .portrait).<n>
<genre>.genre.cover(.front/back/inner/sleeve/disc)(.landscape/portrait).<n>
<genre>.genre.banner(.landscape or .portrait).<n>
<genre>.genre.framegrab.<n>
Examples:
Rock.genre.fanart.landscape.jpg
Comedy.genre.fanart.landscape.02.jpg
Regex for the above is:
(.*)(\.genre.*)$
<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.color
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.color
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.color
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.color
<source>.mediainfo.source.mono
<source>.mediainfo.source.color
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.color
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.color
[/COLOR]
Examples:
mp3.mediainfo.audio.color
h264.mediainfo.video.mono
true.mediainfo.HasBeenPlayed.mono
fr.mediainfo.subtitle.mono
Regex for the above is:
(.*)(\.mediainfo.*)$
Issues:
*<Moviename> is currently an issue for a number of reasons:
1) The <Moviename> could refer to the movie title. If a user has two media files (say a directors cut and a normal version of a movie) - and INSISTS that both keep exactly the same movie title, then they will either both end up sharing the same art, or we have a problem
2) <Moviename> could in theory be an imdb number, but we have a problem if a movie doesn't have an IMDB entry. It's also not so human readable if a user wants to look through artwork files, or wants to manually create artwork
3) <Moviename> could match the actual corresponding media filename, however, this requires end users to have their mediafiles uniquely named across all folders and sources.
We are working in a solution to this in the thread!!!
*The very wordy examples given above should be abbreviated at some point, they are here to make the examples more readable. So, for instance, Music.Fanart might end up being abbreviated to MusicFA or similar.
*The ^ delimiter is used to allow media titles to have '.' character in them, and makes parsing very easy... although is movie has "^" in the title... we have a problem
*The seemingly redundant .movie ".tvshow" and ".music" etc are needed to prevent namespace collisions where Movie / TVshow / Artist items have the same title.
*When a movie or tvshow or artist has strange characters in their title, how can this be mapped to the filename?
*For MediaInfo files, it's unclear if there needs to be one mediainfo file for EVERY (say) studio, or if it would be possible to create a "disney.mediainfo.studio" file that would be found for any studio containing the word "Disney"
*MediaInfo have ".mono" and ".colour" options, this is because the typical usage of this type of art is to act as an overlay / icon / indicator. Since some skins are light, and some dark... the icon would need to be visible in both cases... hence two versions... I could have relied on these images being monochrome and therefore 'invertible' but I felt this was too much of an assumption. So this way, you can have colour ones if you wish.
Just to make this clear....
".mono" = White logo on transparent background... Any skin can then colourize the image to fit the skin theme accordingly
".colour" = Full Colour logo on transparent background... so a skin should just display the logo 'as is'