+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)
- Gangsta - 2009-06-27
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
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
<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
*cough* 42 character filename limit on fatx *cough*
NFO fallback tag - AnalogKid - 2009-06-27
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
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
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
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
@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
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.
- xexe - 2009-06-27
Jezz_X just fyi my only interest in this is to see if a scheme can be derived that results in artwork filenames being unique globally, unrelated to a users preferences, filenaming or any other factor.
Now to be fair most users in this thread are proposing "fileview" type solutions which are not of interest to me since i dont use any fancy skins, media managers (and anyone can see from my posting record I dont think there is a real need for these applications) or even store artwork beside the videos.
However many things become possible if blah.jpg is attributable back to its original source and to the video it represents in isolation to anything else.
At this point I still think the best solution is a "proxy cache" type solution which stores artwork and even XML zips independently and centrally that users can manipulate if they feel like and XBMC can optionally use to increase the efficiency of its scrapers.
- tetsuo55 - 2009-06-27
Imho we should only support standard naming:
Example:
Donnie Darko (2001) (folder and/or file name)
Donnie Darko The Director's Cut (2001) (folder and/or file name)
Source: http://wiki.xbmc.org/?title=IMDB#Additional_information.
The director's cut part is only needed if you want to be as accurate as possible, or if you have both versions of the movie as different files/folders.
Now if you have the same movie in SD/HD for example, you could still mark them correctly like this":
Donnie Darko (2001) (720p)
Donnie Darko (2001) (DVD)
Also the chosen words to describe the different art forms, like fanart would become FA or something like this. This would make it easier to deal with file name limitations
- xexe - 2009-06-27
tetsuo55 Wrote:Imho we should only support standard naming:
Example:
Donnie Darko (2001) (folder and/or file name)
Donnie Darko The Director's Cut (2001) (folder and/or file name)....
This is what we keep coming back to. There really is no such thing as standard naming. What you are proposing is IMDB specific naming for your country. It is to specific to be scalable and is not a good identifier as IMDB could change their policy on (TV),(V) type naming at any moment (if they cared to) breaking this entire scheme. Also MANY user simply will not rename folder or video files. I am one of those users, renaming is the simple way out, there is always a better solution.
I think we need to take a deep breath and re-evaluate the problem and the responses from XBMC devs to the proposed solutions.
I have been here long enough to know the current solution path is not going to be accepted.
- AnalogKid - 2009-06-27
Jezz_X Wrote: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 remainAbsolutely not about.
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 ?
The reason it's being proposed is many fold
a) Today's solution actually doesn't work in all cases. I can give you examples of where it's broken (and NO WAY is having to name a PNG file 'JPG' a good solution).
b) XBMC is a wonderful thing, and is starting to reach the home of more and more users. The users struggle to get artwork working properly, it's clear as day from the number of support requests
c) XBMC should be a continuously improving and evolving effort. If we didn't challenge what already exists today, we'd still be using BMP files and saying "works fine, so why a need for jpg?"
d) This work is totally skin agnostic, in fact it is trying to reign IN some of the skinning madness... we want to encourage innovation, but do it in a methodical manner. At the moment, some skins are pushing the boundaries but in 'ad-hoc' ways because XBMC core doesn't meet the needs.
Quote: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.
This is precisely what we want to reign in. Users do NOT have to fetch all these different arts, we are merely proposing how to store them IF the user wishes to do so.
Quote: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
The current system doesn't have a standard.... it's a mess. It's flexible, works in 95% of cases, but remains a mess. Movie.jpg, Starwars.jpg, movie.tbn etc etc. Now I don't say it is BAD... I just think it has evolved and over time become a mess.
We'd like to contribute by helping to neaten that situation up. Most of us are not coders, but we can still add thought as end users and skinners and say "ok, what we have is working, but is starting to creak, let's improve that and get us through the next couple of years until we find new creaks"
I personally think it's a great thing that we aren't just saying "please fix", we are thinking all of this through and working towards a solution too.... nothing is agreed yet, we're thinking out aloud. But surely it's a good thing when end users do this? We might one day actually come up with well considered request that the coders will think "you know what, I hate to break my working code, but this is a decent proposal".
Quote:P.S everything above is my personal opinion and does not reflect the team in general
That's cool, I think everybody knows that challenging the current implementation will be difficult. But I think with some sound, logical argument, eventually people will start to come on board.
If anybody can truly say the current implementation is perfect and beyond reproach, then I will have lost all faith.
- AnalogKid - 2009-06-27
Gangsta Wrote: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.
We think alike my friend.
This thread is hard reading to lightly skip over, but countless times in the 'spec' I've stated the rational for it, it still gets missed.
The really encouraging thing here though, is that I'm not actually hearing many voices say "we don't need it". This is good.
Most of the voices are about how to do it - This is excellent.