+- 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)
- xexe - 2009-06-27 10:58
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 11:10
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 11:16
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 12:44
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 12:52
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.
- xexe - 2009-06-27 13:06
I still say a central repository organized by scraper id. As far as I can tell it solves every problem still being faced with the only down side it wont work in file view mode (but it will work in file view mode if you also have library mode set up).
Based on what I am hearing XBMC is becoming more library orientated anyway.
IMHO its the way to go.
- AnalogKid - 2009-06-27 13:44
xexe Wrote:I still say a central repository organized by scraper id. As far as I can tell it solves every problem still being faced with the only down side it wont work in file view mode (but it will work in file view mode if you also have library mode set up).
Based on what I am hearing XBMC is becoming more library orientated anyway.
IMHO its the way to go.
I don't think this is really about file mode vs library, I know for me personally, library mode is the far superior.
This is really more about taking a brand new installation and having XBMC gather all the media and art into the library, preferably without relying in a scraper, and certainly without having to manually configure stuff.
Today, even with a superbly organised library (no art), a scraper will pull art for a movie (but it's often not the choice of art the USER wants, so they have to then manually override the scraper choice).
Also, it's great that XBMC can export it's library, but... the thumbs it exports are low res, not original artwork.
A lot of the additional scraping tools really come from a world (that I support) where folks simply cannot trust IMDB etc to always be around, and so we like to scrape the best quality artwork to our systems and know they are 'safe'.. we have them forever then.
I have seen instances were art that WAS available online has been removed, and potentially lost forever.
- digitalhigh - 2009-06-27 18:10
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 remain
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
As the biggest Aeon Fanboy out there...lol...
You're right. I devised some interesting hacks to get the coverscans and disc images to work in Serenity. But, in order to do so, the files have to be "locally stored". I recently got mad at my HTPC and grounded it to the closet and putting my Xbox back in service. This means that all my "coverart" doesn't work anymore, because I can't map a network drive on an xbox.
So, my hack is now useless for me.
Also, there is no easy way of going <visible>image.exist(IMAGENAME)</visible> so that I can have configurations based on what media images I had for that specific movie. Having this stuff committed to a DB would (theoretically) make it very simple to determine if that image were available. Then you can ensure you have no blank images, you know?
As far as "forcing users to fetch images"...that should really be up to the user. I would really like to see a day where you can have either/or as far as banners/posters. I believe I even made a feature request for this a long time ago, and it was shot dead. This schema would allow for a person to have banners and posters side-by-side and have them available to a display without having to go through and replace everything.
I understand where you're coming from...but with the advent of HD, I think that the current standard is (like AnalogKid implied) starting to become a tad cludgy. It works, yes, but it could work a lot nicer. That's all we're trying to do.
And honestly...if enough users are going against the "standard", can it really be considered standard anymore? I don't think the rules should go out the window entirely...just be expanded a bit.
- tetsuo55 - 2009-06-27 20:54
xexe Wrote: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'm used to detection based on hash codes like CRC, this doesn't work for movies though. The only thing left really is a file/folder name.
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.
The way the file name is chosen is something that has to work 99% of the time.
The basic regex we are using now "name" "(date)" is pretty good.
How do you chose the name can be decided through several conventions, the current one being IMDB
Can you explain why any would not want to name the movie accurately?
- xexe - 2009-06-27 23:09
AnalogKid Wrote:I don't think this is really about file mode vs library, I know for me personally, library mode is the far superior.
This is really more about taking a brand new installation and having XBMC gather all the media and art into the library, preferably without relying in a scraper, and certainly without having to manually configure stuff.
Today, even with a superbly organised library (no art), a scraper will pull art for a movie (but it's often not the choice of art the USER wants, so they have to then manually override the scraper choice).
Also, it's great that XBMC can export it's library, but... the thumbs it exports are low res, not original artwork.
A lot of the additional scraping tools really come from a world (that I support) where folks simply cannot trust IMDB etc to always be around, and so we like to scrape the best quality artwork to our systems and know they are 'safe'.. we have them forever then.
I have seen instances were art that WAS available online has been removed, and potentially lost forever.
File mode artwork relies on either having one movie per folder and using whatever artwork is there OR using regex to match the artwork to the video name.
However if you use library mode it will, using various mechanisms we dont need to care about, know what the movie is based on the scraper. Once you know what the movie is you can easily imagine a situation where you have your own central repository of images organised by movies ids (id based on whatever your favourite scraper is).
This is better as you do not need to worry about movie identification from filename as part of this project. It is also perfectly scalable and by definition 100% accurate.
The driving goal as I see it is to have human readable, 100% accurate, organised artwork that other tools can manipulate. Absolutely nothing says they have to live beside the video files and it makes alot more sense to have them in one place rather than spread all over the FS.
Once you have the central repository other tools can manuipulate it in any way users like. if they want them beside the videos then other tools can do it. If they want something else something else can do it. Having the data centrally makes alot more sense.
It also covers situations you guys havent even discussed yet, like the fact XBMC is multi user capable via profiles. By the time you add all current and future variables to you artwork filenames its going to be completely silly. I could go on all day finding examples that cause problems like hows this for a legitimate movie name that wont work on fatx:
Night of the Day of the Dawn of the Son of the Bride of the Return of the Terror (1991)
But i predict that someone will say "well how often does that happen?". Well my answer is once is too many.
Or "This is a silly movie no one will have".... Well how about "To Wong Foo Thanks for Everything, Julie Newmar (1995)" nominated for two golden globes.
As i have said before take a step back and look at what I am saying.