+- 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)
- Gangsta - 2009-06-27 03:07
digitalhigh Wrote:Case1: Maybe they have two machines, one capable of HD playback, and one that does not, but the movies are in a central location.
Case2: Could be a remake of a movie or something? The Hills Have Eyes, Last House On the Left, Halloween...
case3: I agree. This should have Directors Cut in the foldername, and the movies be in separate folders.
Case4: This would be a good instance of where a tag in the already present .nfo file would be perfect.
The nfo fallback idea is good, easy to understand, and if no better system can be found would be ideal. But I still have issues with case 1 and case 2.
Anybody with any sizable library will have already came accross this already - long before they get bothered by fanart etc.
Myself for example - I had 'The Italian Job' as one of my first films, a few weeks later I added 'The Italian Job' and up pops the 'The Italian Job already exists, do you wish to replace it' message - so I quickly change it to The Italian Job (New). All is well, then I scrape my movies and it starts getting complicated as the scraper is listing loads of Italian Jobs with dates. I have to check imdb, and get the years and choose from there. I think all is great.
Few weeks later I add the original king kong, and it starts again so this time I call it 'King Kong (19??)' the scraper finds it no problem on its own. Since then I have renamed all my files with the date included - why cos it makes MY LIFE EASIER, and the scapers handle it excellent too.
Its soooo much easier to rescrape my library now that I have used a little common sense at my end and included the year. I imagine it would be a very rare occasion for 2 movies same name same year. (HARD CANDY was renamed because another film used the name the same year)
As for the HD issue - well
Superman (1972).avi
Superman (HD)(1972).avi
or some variation of that would seem to solve the HD issue.
I am fully behind making things easy for the end user, but giving them too much freedom makes thing too hard for them.
If the schema (once settled on) is implimented, then it will be sooooo easy to help users - if they cant get artwork working - because everyone will be singing off the same hymmsheet. EG if you want a poster it MUST be called <moviename>.movie.poster (not accurate to the schema, but you know what I mean)
- AnalogKid - 2009-06-27 03:34
Gangsta Wrote:The nfo fallback idea is good, easy to understand, and if no better system can be found would be ideal. But I still have issues with case 1 and case 2.
Anybody with any sizable library will have already came accross this already - long before they get bothered by fanart etc.
Myself for example - I had 'The Italian Job' as one of my first films, a few weeks later I added 'The Italian Job' and up pops the 'The Italian Job already exists, do you wish to replace it' message - so I quickly change it to The Italian Job (New). All is well, then I scrape my movies and it starts getting complicated as the scraper is listing loads of Italian Jobs with dates. I have to check imdb, and get the years and choose from there. I think all is great.
Few weeks later I add the original king kong, and it starts again so this time I call it 'King Kong (19??)' the scraper finds it no problem on its own. Since then I have renamed all my files with the date included - why cos it makes MY LIFE EASIER, and the scapers handle it excellent too.
Its soooo much easier to rescrape my library now that I have used a little common sense at my end and included the year. I imagine it would be a very rare occasion for 2 movies same name same year. (HARD CANDY was renamed because another film used the name the same year)
As for the HD issue - well
Superman (1972).avi
Superman (HD)(1972).avi
or some variation of that would seem to solve the HD issue.
I am fully behind making things easy for the end user, but giving them too much freedom makes thing too hard for them.
If the schema (once settled on) is implimented, then it will be sooooo easy to help users - if they cant get artwork working - because everyone will be singing off the same hymmsheet. EG if you want a poster it MUST be called <moviename>.movie.poster (not accurate to the schema, but you know what I mean)
Could not agree more (I've put the year in all my movies, since scrapers didn't work so well without it), and where have two versions of the same movie, they still have different names, so to my mind it's not the end of the world to ask for unique names.
It's not like we are asking for a structure change, infact we're offering MORE ability than ever before!
- AnalogKid - 2009-06-27 04:08
<moviename> ... what does this mean?
Ok, bearing in mind some earlier statements saying this would match the MEDIA file name, let's take the alternative tack... that it matches the media TITLE.
So, in the following cases...
Movies Flat\
------ Starwars.avi
------ Superman.mkv
------ Psycho.mpg
Movies Folders\
------ The Birds\
----------- Movie.avi
------ Blade Runner
----------- Blade Runner.avi
------ Close Encounters
----------- Close Encounters.avi
----------- movie.nfo (with title = Close Encounters Of The 3rd Kind)
Starwars.avi = "Starwars"
Superman.mkv = "Superman"
Psycho.mpg = "Psycho"
This is because the above files are in a flat structure and have NO nfo, so the only way to figure the movie name, is from the filename itself.
Movie.avi = "The Birds"
Blade Runner.avi = "Blade Runner"
This is because the movies are in a folder structure with movie names being taken from the parent folder name
Close Encounters.avi = "Close Encounters Of The 3rd Kind"
This is because the movie has an NFO that takes ultimate precedence, and here the movie takes on the name "Close Encounters Of The 3rd Kind"
Now, to my mind, XBMC will do all this logic already. We don't really care how it does it, but it works out the true movie name (I THINK) with code like this:
If movie file has NFO then use NFO movie name
else
If movie file is flat, then use filename
else
If movie file is foldered, then use parent folder name
So if we name <moviename> according the movie title that XBMC has already deduced, we should be ok. Except for the following
If the movie title is exceptionally long, then there is a danger that the filename cannot match. I this case, I think a match on the first 128 characters or so would be pretty accurate! OR potentially the last x characters. Regardless, it would have to be a pretty big movie name AND we can still use the NFO tag fallback !
If the movie title has strange characters that the host filesystem cannot handle (this can ONLY happen with the NFO scenario), then either, there's a scheme to convert say "Mémo" to "Memo" OR we have the NFO fallback again
I can manufacture a case where "Máme.avi" and "Måme.avi" both resolve to "Mame" but wonder how often this is going to happen?.... and we STILL have the NFO ultimate fallback
- Gangsta - 2009-06-27 04:21
*cough* 42 character filename limit on fatx *cough*
NFO fallback tag - AnalogKid - 2009-06-27 04:43
Based on DigitalHigh's idea... (sort of)
but with a TWIST....
I propose the following solution for movie titles and artists with complex characters or exceptionally long names.
<moviename>.movie.fanart
<moviename>.movie.truename.txt <------ THIS
the contents of this file would be:
This is a very long movie name, or has strángé chars
This is VERY like DigitalHigh's idea to add this to the NFO, but here's why I propose a slight variation.
NFO files only exist for certain media types. They certainly don't exist for say individual tracks of an album...
So, if you have a complicated track with strange characters in it... there's no NFO to provide a fix for it.
BUT, using this suggestion, the problem is solved!
The Police^Zenyatta Mondatta^SWT.music.fanart
The Police^Zenyatta Mondatta^SWT.music.truename.txt
And the file would contain:
The Police^Zenyatta Mondatta^Some Weird Track Name
This now means that when XBMC finds media and then looks for related artwork, it does the following:
Look for an ABSOLUTE match in the artwork file
If no match found...then look for truename.txt files to file a match
Bear in mind however, that ALL truename.txt files would have to be read until a match is found.
(I thought about just having ONE truename.txt file holding a cross reference list too... but felt this might be worse).
Is this a crazy proposal, or workable?
I have niggles about it, but it's simple to understand
note:
In theory a user can do the following:
foo.movie.fanart
foo.movie.truename.txt
And the contents be:
"Starwars"
This would be madness but possible. I quite like it!
- AnalogKid - 2009-06-27 04:52
Gangsta Wrote:*cough* 42 character filename limit on fatx *cough*
I do believe we have an answer!... see "truename.txt"
Quirky, and yet.... elegant!
- Paradise - 2009-06-27 05:36
Hi,
i was on my way asking for "cover fanart".
But then i saw it is in the examples:
Quote:Superman.movie.coverart.portrait.jpg
Its just missing in the list:
Quote:<moviename>.movie.fanart(.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>
Ok, now my 50cent.
I don't like "movie.fanart". I think fanart can be a banner, a cover, a wallpaper...
djh calls the pictures in the background (the wallpapers) Backdrops. Why don't stick with it?
The banner is what we see at the bottom (what we can switch from flat to flow), what some call thumb
in the moment, right? We need to set a size i think. They are shown at the bottom and here (New "ClearArt")
if you pause. So they are never shown really big, right?
Logo is ClearArt, or is it another thing? And what is it in the last picture in the New "ClearArt" thread. Is it
the normal "tvshow.fanart" (lets call it backdrop *lol) or a special pause-mode-backdrop?
What about Teaser posters, Character posters and Film posters and Lobby cards?
I believe a lot here are movie fetichists, no that sounds perverse, movie collector. So wouldnt it
be cool to hit a button and see the 1939 "Gone With the Wind" Lobby cards?
<moviename>.movie.poster.teaser(.landscape/portrait).<n>
<moviename>.movie.poster.character(.landscape/portrait).<n>
<moviename>.movie.lobbycard(.landscape/portrait).<n>
There are also rerun posters:
<moviename>.movie.poster.rerun(.landscape/portrait).<n>
but this is just to mark/show somthing in the skin that we can see its the rerun poster.
So we can have then a view in the skin where we can make a slideshow or a switching where we can see
all kind of posters.
So a cover view where we have the covers on the bottom and one where we see the movie.poster in flat or flow.
The movie.poster we see at the bottom would be "movie.poster.portrait.01". So eberybody can set to 01 wat
he/she wanne see.
Please also see this thread:
List for resolution in respect to the aspect ratio for covers, posters, trailer...
Sorry but all this stuff is overlaping.
- Jezz_X - 2009-06-27 06:03
Paradise Wrote:........Ok, now my 50cent.Because as much as you AEON fanboys might not like to admit it AEON and djh don't dictate poilcy. Its been called fanart from day one all the sites we scrape it from call it fanart so fanart it shall remain
I don't like "movie.fanart". I think fanart can be a banner, a cover, a wallpaper...
djh calls the pictures in the background (the wallpapers) Backdrops. Why don't stick with it?
..............
I have quicky skimmed this thread for the first time and Basically its all about getting extra images to display in the skin right ? Because we allready have a standard for nameing these files and has worked for years. but it seems you guys want every possible image to be displayed including inside / outside covers disc scans and so on. So I have to ask why ?
Sure its nice to have a bunch of extra images and you can allready do most of this now with hacks and background loading but we don't need to support every variation of a format that someone comes up with.
EG: tvshows the default for many years was Wide Icons (and it still is) djh_ then decided to use posters instead (thats fine) then he changed his mind again and went for 16x9 cropped fanart style with a logo. Where does it end ? how many different types of icons should we force users to fetch just so XBMC can look decent.
Thats the whole point of a "standard" you have the default and thats what should be used. If skins like AEON decide to go against the "standard" then its up to their users to fix what ever so they can use it. Its not the responsability of XBMC to make sure it can fetch every single different Idea that anyone can come up with past future and present. Its the resonsibility of the skins to follow "the standard" and if not thats their issue
P.S everything above is my personal opinion and does not reflect the team in general
- Paradise - 2009-06-27 06:30
@Jezz_X, you ask why. Hm, to make it the all in one solution. I don't like to manage 6 different DBs/programms. If the DB in XBMC is not for organising and collecting everything i can use MPC. In the momend its like this why. Fire up my Movie Manager, chose what movie i wanne look and do it. Same with music, games, pictures... . Please don't get me wrong - XBMC is great.
- Gangsta - 2009-06-27 06:45
Hi Jezz_X
Im not fighting the corner for any specific skin (I use the PM3 standard res on the XBOX) or for the inclusion of any specific type of graphic (I only use wide banners for tv shows, and posters/dvd cover for movies)
My stance is purely that there should be one FIXED standard for what the various artwork files are called. eg, elimimate the folder.jpg, folder.tbn, <movie>.jpg etc all meaning the same thing nonsence - instead having just one for example a movie poster can only be called <movie>.movie.poster (adding the landscape/portrait bit if need be)
The end result being a nice neat library, readable & editable by humans. And as a coder I have to say that I can see the benefit to skinners, having a library of clearly defined artwork types to work with. And with the unlimited number <n> of any type of artwork as defined in the proposed schema - i do foresee some very interesting skins being developed.
Side note: from a coding point of view, the schema does not need to be fixed -
say for example some clever clogs decides that QVGA posters are a good idea in the future.
a skin could *request* <movie>.movie.QVGAPoster<n>
in which case XBMC either returns the poster if it exists, or returns a code indicating that file is not available.
Exactly the same code could process any part of the schema without having to know anything about its structure. It is therefore future proof, and doesnt involve programing the schema itself into XBMC.
It would then pass the responsibilty onto the skinner to decide what types of artwork to use. If a new style of logo, or whatever comes out AND a skinner wants to take advantage of it, they need only change the artwork request to include the new artworktype
<movie>.movie.fanart.<newstylegoeshere>
and if it exists on the users system, XBMC will return it to the skin.
I hope that makes sense.
I havnt had a chance to look at the XBMC code yet, but i think a system like this would be much more efficient in code, and more future proof than the current hardcoded -folder.jpg etc.
from a skinners point of view - when you develop your super duper new skin using new artwork etc. you could include an xml, detailing the artwork types that your skin requires.
if something like this was standardised - im sure it wouldnt take long for the media managers to catch up, processing the xml so that it downloads only the type of data required by your skin.