+- 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)
- kortina - 2009-06-29 15:13
Gangsta Wrote:I think storing all the artwork in zips would be a big step backwards - and it still doesn't resolve the main issue of this thread - how are the actual artworks named.
Can we recap on likes and dislikes on the proposed schema, mabey then we can start fixing some components within it. For example are there any bits we all agree on. then we can dicuss the bits we dont agree on.
I picture myself as a consumer of media packs, not a creator. So to be brutally honest I dont care about the internal schema. Yes it is important to nail a format, but I dont have a strong opinion on what it should be.
My focus as a consumer is to make sure I can:
1) get my media pack to "hook up" to my movie
2) stop re-scraping, making the same mistakes every time
3) share my media packs between multiple XBMC installs
- AnalogKid - 2009-06-29 15:44
Ninjamawwe Wrote:I really disagree with the solution of adding extra .txt files to this. For movies, tvshows etc (basically everything except songs) a .nfo exists which will be read by xbmc. I think it would be much better to try and get proper support for .nfo's for songs (and any other media types I'm forgetting).
I'm partly on your side with this view, and I would say LONG term the right solution would be the NFO file... absolutely.
That said, I also realised that NFO files do not yet exist for some media types and so had to figure something in the mean time.
I suppose though, we could still have an NFO for tracks (IF the user needed one for this issue) and it wouldnt matter if XBMC didn't support it (yet).
The solution is basically the same though.... except the NFO has to be side by side with the media, whilst the txt file is with the artwork.
I'm a little busy at the moment, but I'll put a proposal for the NFO version and the txt version... I don't mind either. If we can agree on which to go for, I will then add this to the spec!
- tetsuo55 - 2009-06-29 16:20
Sorry i forgot some of the ground rules for a moment, let me restate them:
-The file naming/storing system has to be platform independent(things like the xbox 43 char limit).
-The system has to be expandable for new artwork types.
-It should be trivial for other mediaplayers to add support for the artwork system.
-(i'm not sure i agree with this one)The system should use Built in OS functions (like folder.jpg) to it's maximum potential.
-System has to be human and machine readable
-system should be able to store the files next to the media or in a different folder altogether
Personally i think XBMC has a large enough user base to do things like .zip files with artwork inside (and the .nfo file could contain everything needed to point to the artwork zip file)
This would make the folder really clean:
Example:
Donnie Darko (2001)
--Movie.avi
--artwork.zip
--Donnie Darko (2001).nfo
I'm starting to understand xexe's point better and better the more i think about it.
And i'm starting to agree with him that we have to tackle the "movie naming and recognition" problem before moving on to artwork naming.
I like the idea for using unique id's, something like this:
"Random name (unique id)"
Donnie Darko (TT184639)
The system would look for the unique id in the random name part first, then in the ()part and finally it would read the random name to guess the movie (basically like it does now)
We could expand the current indexing at sites like themoviedb with versions of movies, like "directors cut" to get custom artwork for that version.
- Paradise - 2009-06-29 16:30
Everytime you want to change something (adding/changing images, trailer...) you have to unzip and then zip it again.
Also i like to browse my folders and see whats in there...
- Gangsta - 2009-06-29 16:39
When the media pack issue first came up - it was about having a portable format for 'HAND CHOSEN' media for a particular file, to maintain a nice asthetic, not that all artwork be wrapped in zip files.
A way to send or download artwork that someone has collated, not just a container for the mess we have now where the scapers download the first available image etc.
These days we all have more than enough hard disc space that we dont need to compress our artwork and slow our systems.
An an example there could be hundreds of mediapacks aimed at one particular movie.
Ironman (Filmclips)-Gangsta.zip
could be a pack I made containing fanart etc that was all screencapped from the film.
Ironman (Cartoon)-Gangsta.zip
could be a pack I made contaaining fanart, wideicons etc that were all in a cartoony style
etc etc
- xexe - 2009-06-29 16:56
This is one of the reasons i mentioned source attribution a while back.
if i pull say 80348-10.jpg and add it to my chuck TV show the name should still contain source attribution so that no matter where that file is in the global XBMC community it is still just a copy of:
http://thetvdb.com/banners/fanart/original/80348-10.jpg
as soon as we allow flexibility in naming chaos prevails and we will end up with hundreds of identical versions of this fanart named differently. This breaks the premise of XBMC as a community sharing internally.
Whilst this is not a real example it highlight my point
tvdb80348.tvdb80348-10.fanart.1920x1080.jpg
or
tvrage12345.tvdb80348-10.fanart.1920x1080.jpg
is not human readable but its a trivial format for an application to understand.
This is my personal preference for the general direction of naming.
There is another way to do this i have held back on as its way harder to setup and as such unlikely to come to fruition. We create a site that allows the lookup of artwork md5sums and name the artwork to include the sum.
- Gangsta - 2009-06-29 17:10
xexe Wrote:There is another way to do this i have held back on as its way harder to setup and as such unlikely to come to fruition. We create a site that allows the lookup of artwork md5sums and name the artwork to include the sum.
I had a kind of similar idea, but as it involved setting up a site, i gave up on it, as i was expecting the its reliant on a 3rd party argument
- AnalogKid - 2009-06-29 19:35
Gangsta Wrote:I had a kind of similar idea, but as it involved setting up a site, i gave up on it, as i was expecting the its reliant on a 3rd party argument
A unique ID is a piece of cake to create locally on a PC (just a hash of the full path to the media or a checksum of the file) but "182bHdgh.movie.xxxxx" is hardly nice for an end user, and needs additional software to compute the hash.
it's easier to use the NFO to say "file system friendly name = StarwarsB" and let the user name the art this way (but this is OPTIONAL), otherwise we can assume the artwork name matches the movie name.
If we HAVE to have a unique ID, why pull it from IMDB? might was well compute one locally (unless we want to share the art).
If we want to share the art, we have to have a GUID for every movie, in every language and every little variant. I believe this will never happen.
We are now trying to solve TWO problems and this is problematic.
Remember, when a user's media is first discovered, there is NO unique ID... just a media file. The only way ANY scraper can then figure out what the movie is is from the filename, foldername OR a manually created NFO.... the user HAS to try and tell the scraper what the movie is.
Even then, the scraper MAY find similar or duplicately named movies, and so the end user STILL has to choose.
FINALLY, a UID is found "ttxxxxxx"
Sadly the UID is not a GUID
Sadly the UID isn't meaningful to a reader (but this is a nice to have, not a MUST have)
The UID immediate then places a dependency on the scraper source to provide future UIDs. This is bad - it makes XBMC dependent on external entities.
What happens when the scraper doesn't find a match?
What happens if the user doesn't have a net connection?
So, you're left with the following 4 options:
Use a locally generated UID (LUID)
It will work without exception.. the LUID is algorithmically computed based on full pathname to the media OR a checksum of the media. I prefer checksum of the media, which then allows for the moving of that media (and not screwing up the checksum)
Does not need internet connection or 3rd party.
Rating 8/10
User a global UID (GUID).
Simply impractical since no 'authority' allocates a GUID to every movie / music etc
Rating 0/10
User a scraper UID (SUID)
I believe this is xexe's preferred option i.e. IMDBxxxxx. TMDBxxxxx.
I believe it's a worse solution than the Locally generated SUID since how can XBMC know that IMDB xxxxx belongs to "starwars.avi" ? It still has to look up Starwars.avi with IMDB and then ask the user which version of starwars they meant BEFORE getting the right IMDB.
Needs internet connection, and 3rd party.
Fails if the movie doesn't exist on the scraper source
Unclear how this will work across all media types (movie, music and TV)
Rating 7/10
Use the moviename as the UID (MUID)
It's easy to do, but needs additional NFO/TXT file if a user insists on duplicate movie names or there movie name cannot exist in the file system.
Does not need internet connection or 3rd party
Easy to share movie art packs with this technique
Consistent technique across all media types - Movie, Music, TV Show etc
Rating 9/10
I think the biggest flaw with the MUID, is that you need a 'fix' for duplicate movie names.
However, that fix exists, and can be avoided if the user is happy to differentiate two different movies.
The LUID option is VERY strong, it's just a nightmare for an end user to manage.
The GUID option is a non-starter
The SUID option suffers the same issues at the MUID, plus a few more. For the SUID to work, the user has to create NFO files, or rename movie/folder files AND has to manually intervene if the scraper can't resolve the movie name (i.e. it TOO needs a fix for duplicate movie names).
Comments?
- digitalhigh - 2009-06-29 23:36
Wow dude...wtf happened with this conversation? It seemed like it was only a few days ago where it appeared a consensus was within sight. Now you guys are talking about zip files and guid's and all this other stuff? Jesus...
My two cents:
No zip files. If you want to make a pack, make it, and people can just unzip it to their central folder or movie folder or whatever.
Hashing? Really? Again...why are we reinventing the wheel here? IMDB ID's are great, as there's this huge online database that everybody already has access to, and is totally universal. Use that and MOVIENAME as the unique identifier in a .nfo file (in the occurrence of multiple files with same name), and you should have something both human and machine readable.
Music .nfo files - ...why wouldn't we just make one .nfo for ALBUM, and put all the track data in that? I know we're trying to account for every possible artwork scenario, but even I wouldn't get high enough to want to make a piece of art for every song in my library.
IDK...I think this conversations seems like it's snowballing...
- Gangsta - 2009-06-29 23:57
Ive tried a few time to get it back on track with AnalogKid's original post.
I started a new topic to discuss the mediapacks, as I believe that these are waay seperate from what this topic is all about.
The thread about that is located here
http://www.xbmc.org/forum/showthread.php?t=53687
mabey a reposting of the schema with the suggestions to date so that people who are viewing the thread, but haven't read it from the start can get up to speed.