+- 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)
- AnalogKid - 2009-06-26 21:42
I just posted the spec again with some more issues applies (thanks to xexe).
I've not really changed anything yet, just did it for my own sanity to keep it up-to-date with issues discussed so far.
As far as I can make out so far... the '.fanart.xx.xxx' stuff is generally agreed with. The trouble so far lies in the <moviename> field and how this is tied back to a specific media file. Xexes thought up some instances that we have to handle in a graceful manner, so I don't want to bury my head in the sand and hope the issues go away... they simply won't... so a good bout of hard thinking is required!
Problematic use cases: - AnalogKid - 2009-06-26 22:08
Problematic use cases:
Use case 1 - (user has two movie files of very similar filenames
\movies\
----Starwars.avi
----Starwars.mkv
\Artworks\
----Starwars.fanart
Issue:
How can xbmc know WHICH movie the fanart belong to if the <moviename> field is referring to the mediafilename (unless the are forced to share the same artwork).
Resolution options:
1) The user renames one of the movie files
2) The artwork file is named Starwars.avi.fanart
Use case 2 - (user has two movie files of exactly the same file name)
\movies1\
----Starwars.avi
\movies2\
----Starwars.avi
\Artworks\
----Starwars.fanart
Issue:
How can xbmc know WHICH movie the fanart belong to if the <moviename> field is referring to the mediafilename (unless the are forced to share the same artwork).
Resolution options:
1) The user renames one of the movie files
Use case 3 - (user has two movie files with the same title)
\movies1\
----StarwarsA.avi (usual movie version)
----StarwarsA.nfo (showing movie title as Starwars)
----StarwarsB.avi (directors cut version)
----StarwarsB.nfo (showing movie title as Starwars)
\Artworks\
----Starwars.fanart
Issue:
Two movie files (a normal, and a directors cut version) both have NFO file, but the TITLE is exactly the same 'Starwars'.
How can XBMC know which movie the artwork is for?
Resolution options:
1) The user renames one of the movie titles
Use case 4 - (user has two movie files with same name, but diff folders)
\movies\
----Starwars\
-------Movie.avi
----Superman\
-------Movie.avi
\Artworks\
----movie.fanart
Issue:
Two movie files of the same name exist but in different locations (folders). How can XBMC know which movie the artwork is for?
Resolution options:
1) The user renames one of the movie files
2) <moviename> stops using the filename and uses the movie title instead (e.g. Starwars.avi and Superman.avi)
One way that the above use cases COULD be solved without requiring the user to rename files. And this would be 'abandoning' the ability to have all the artwork in a flat folder. If the artwork was placed in the same folder as the movie, then the issue would go away.
The current problem is created by trying to allow a folder based movie structure to be represented by flat folder artwork. The folder structure allows multiple instances of the same filename, and a flat folder cannot.
However, if the <moviename> stops using filenames, and uses titles, then it helps a LITTLE. But the issue isn't completely solved. If the user insists on having a movie with precisely the same title, XBMC cannot resolve the artwork to use.
- Gangsta - 2009-06-26 23:38
good points there - but - RE:Points 1 & 2
I still cant get my head round trying to fix the two films with the same name. Is it *REALLY* too much to ask a user to who has say;
superman AND superman (directors cut)
to call them that if they want different fanart etc.
eg
Superman.avi
Superman (Directors Cut).avi
- digitalhigh - 2009-06-27 00:19
Okay, you guys are discussing a very interesting predicament. The idea was raised earlier of storing the image data in the xml file. What if, instead of storing this complex naming scheme in the xml file, it were possible to just add a <imageID>Starwars2007</imageID> tag to the XML file.
Then all related media images would be named starwars2007.movie.etc.
This tag wouldn't be mandatory, but would be very useful in providing a unique identifier as a solution without requiring that movienames be changed. This would mean that people wouldn't have to have .nfo files for things to work well, but that if this issue were to arise.
- tetsuo55 - 2009-06-27 00:44
Can anyone propose a really logic reason to:
1. Have the exact same movie on the same computer.
2. Want different artwork settings for both movies.
Use case1: See my questions
Use case2: See my questions
Use case3: Files are named incorrectly, i don't see why the naming standard has to support misnamed files
Use case4: This is a good one, basically, this option should only be allowed if folder names are different or something
- digitalhigh - 2009-06-27 00:57
tetsuo55 Wrote:Can anyone propose a really logic reason to:
1. Have the exact same movie on the same computer.
2. Want different artwork settings for both movies.
Use case1: See my questions
Use case2: See my questions
Use case3: Files are named incorrectly, i don't see why the naming standard has to support misnamed files
Use case4: This is a good one, basically, this option should only be allowed if folder names are different or something
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.
- AnalogKid - 2009-06-27 01:37
tetsuo55 Wrote:Can anyone propose a really logic reason to:
1. Have the exact same movie on the same computer.
2. Want different artwork settings for both movies.
Use case1: See my questions
Use case2: See my questions
Use case3: Files are named incorrectly, i don't see why the naming standard has to support misnamed files
Use case4: This is a good one, basically, this option should only be allowed if folder names are different or something
I agree that a couple of these are highly manufactured scenarios, but they do serve a purpose to make us think, and make the system more and more robust.
Even if at the end of the day, we just tell the end user of these cases and how to resolve them manually.
We can only make this work credible if we've looked at all situations and come up with a logical solution / decision (that's my view anyway), otherwise, the work will just be discredited sadly.
- AnalogKid - 2009-06-27 01:54
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.
I too have been thinking about the NFO as an escape route, but not mandatory... just as an 'override' if needed.
There's just one niggle I have with it.... and that is the user has to have the NFO at all.
I'd envisaged a scheme where the art and media might exist on a users system and they were setting up XBMC from scratch... how to layout the data so that XBMC can find all art and media rapidly and tie them together... but NFO's kinda need a download from a scraper / internet connectivity. I totally buy into having the NFO for the meta data, in case this is interpreted as anti NFO!
All of that said, this could also be considered little niggly, since the user has to download the art right? the user has to do SOME work, so making an NFO file might be ok too.
I definitely think the NFO will work.... so we have a solution in the bag for conflicts. I'd still like to figure (if possible) a way we can avoid that, but it's nice to have in reserve.
Then again, why NOT ask the user to rename a file, or change a movie title? These ARE esoteric use cases right? (apart from the 'movie.avi' in a folder structure).
From the feedback I'm getting I'm getting two distinct views
View A) Users need to have SOME discipline and rules otherwise the solution just gets so messy trying to create fancy code to resolve niggly use cases
View B) The system must be able to cope with every possibility, or it's a flawed system.
I'm in camp B, but still agree with camp A and starting to think B might not be technically possible without a kludge or two (i.e. the NFO idea)
- AnalogKid - 2009-06-27 01:59
Gangsta Wrote:good points there - but - RE:Points 1 & 2
I still cant get my head round trying to fix the two films with the same name. Is it *REALLY* too much to ask a user to who has say;
superman AND superman (directors cut)
to call them that if they want different fanart etc.
eg
Superman.avi
Superman (Directors Cut).avi
Agreed, and I believe most users could understand this and would just 'do it' without complaint.
But nobody's coding this solution yet (if ever) so we have time to see if we can better it still.
Actually, the proposed system is very primitive, but I think that's the beauty of it. If we get it right, it'll be really easy to use!
- digitalhigh - 2009-06-27 02:28
AnalogKid Wrote:I too have been thinking about the NFO as an escape route, but not mandatory... just as an 'override' if needed.
There's just one niggle I have with it.... and that is the user has to have the NFO at all.
I'd envisaged a scheme where the art and media might exist on a users system and they were setting up XBMC from scratch... how to layout the data so that XBMC can find all art and media rapidly and tie them together... but NFO's kinda need a download from a scraper / internet connectivity. I totally buy into having the NFO for the meta data, in case this is interpreted as anti NFO!
All of that said, this could also be considered little niggly, since the user has to download the art right? the user has to do SOME work, so making an NFO file might be ok too.
I definitely think the NFO will work.... so we have a solution in the bag for conflicts. I'd still like to figure (if possible) a way we can avoid that, but it's nice to have in reserve.
Then again, why NOT ask the user to rename a file, or change a movie title? These ARE esoteric use cases right? (apart from the 'movie.avi' in a folder structure).
From the feedback I'm getting I'm getting two distinct views
View A) Users need to have SOME discipline and rules otherwise the solution just gets so messy trying to create fancy code to resolve niggly use cases
View B) The system must be able to cope with every possibility, or it's a flawed system.
I'm in camp B, but still agree with camp A and starting to think B might not be technically possible without a kludge or two (i.e. the NFO idea)
Well, I still see the end usage of this scheme being primarily tied into media manager programs. XBMC could be capable of pulling all these images if the devs really put their backs into it, but I still forsee the majority of the legwork being done by an external program.
Under that assertion, I don't think that having one .nfo file in a collection of several hundred movies would really hurt much. That would be the bare-bones approach. I personally will still use every .nfo, simply because it is a pain in the ass trying to scrape every movie more than one time.
And really, the .nfo's aren't created by a scraper, but an external media manager program. That's one of the reasons for having them...as a fallback for the XBMC database. Whether you're scraping with XBMC or an ex. program, you still need some kind of internet connectivity to make it go.
I think that having the system just "know" how to cope with the exceptions would be preferable to having to rename a file...