+- 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)
- tetsuo55 - 2009-06-28 16:55
Like AnalogKid said, the naming scheme for movies is something that has little to do with the issues raised in this thread.
Imho a new thread should be opened to find the best solution for the movie naming problem, which seems to be pretty big.
Finally i really like the zip+xml idea!
- Gangsta - 2009-06-28 18:36
I have to agree, the naming of the media files themselfs are outside the remit of this thread, and really does deserve a thread of its own, as this thread is about the artwork names.
I think the pack (zip+xml) ideas probably needs its own thread too, so I wont mention it again in this thread.
In the meantime im going to write a script to rename a copy my current artwork using the new schema and see how hard it would be to impliment this strict nameing structure for artwork in code.
- AnalogKid - 2009-06-28 20:12
Gangsta Wrote:I have to agree, the naming of the media files themselfs are outside the remit of this thread, and really does deserve a thread of its own, as this thread is about the artwork names.
I think the pack (zip+xml) ideas probably needs its own thread too, so I wont mention it again in this thread.
In the meantime im going to write a script to rename a copy my current artwork using the new schema and see how hard it would be to impliment this strict nameing structure for artwork in code.
Right BUT...
the issue is how we 'tie' the artwork to the media.
This is where the name issue stems from. But, to my mind, we let XBMC do it's work to deduce the movie title (as it is today)
And our schema simply uses the title that XBMC deduces.
With the one caveat, that in XBMC it's possible to have TWO movies with exactly the same same title. In this instance, they either share the same art, or the user pulls his finger out and renames one.
We have a proposed solution for complex movie name and foreign characters too... so this is no longer an issue (even on fatx)
Regarding that solution of 'truename.txt' - I'm definitely open to smarter solutions, but at least we have one in the bag.
- Ninjamawwe - 2009-06-29 09:34
AnalogKid Wrote: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!
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).
- kortina - 2009-06-29 10:30
I really like the idea of the media pack zips. The zip can be created by someone (or some app) and contain all of the useful stuff relating to a movie (fan art, director, title, year etc).
The zips could be stored in a read/writeable share so that XBMC could query the location to try and match then retreive data, then populate the XBMC database with the info.
Zips could also be downloaded in bulk, or shared around. (SVN, torrent, robocopy, rsync, portable media or DVD).
All installs of XBMC in your home network could reference ONE set of zips, avoiding any issues of scraping multiple times, or scraping after every upgrade.
The zip can be well named for regex matching.
The only issue then is for XBMC to match the filename with the zip name. With some good regex this should be able to be done. Matches could be maximised by users NOT having so many zips for movies that they dont own.
EG: matches for "Ghost" would only match:
Ghost (1990) http://www.imdb.com/title/tt0099653/
because the user would not have a local zip for:
Ghost town (2008) http://www.imdb.com/title/tt0995039/
The Ghost (2010) http://www.imdb.com/title/tt1139328/
This is much more ideal than scanning a remote (internet) location, where the matches would be vast.
With all of the detail in the XML within a zip, Library mode would be populated with great data, allowing skins to sort by Genre, Year, actor AND most importantly by REAL movie name.
This would remove the need to have strictly named files on a filesystem.
This would remove the issue of storing multiple files along side your movies.
This would remove the many matches you get from Internet based scrapers.
This would remove scraping your 2tb collection every time you upgrade.
This would remove scraping 4 times, one for each XBMC install in your home.
I cant really see any down sides...
- xexe - 2009-06-29 11:31
If this is the direction you are going simply cache raw scraped data in a human readable way and forget all these extra complications.
- tetsuo55 - 2009-06-29 11:33
Yes i think the "everything" in a zip approach, this would make it really simple to name the files inside, it could be a simple as fanart1.jpg or as elaborate as longname (date) fanart (1).jpg.
the zip file itself could be named anything too, either in code or with full names, regex compatible.
All XBMC would have to do is recognize that the zip file is related to a certain media, and by reading everything inside it would have all the info needed.
Using things like pngopt and torrentzip, the images and zip files could be made as small as possible, as long as the same images are used the zip file should have the same CRC.
This also gives you the option to add "alternative" names in XML format thus supporting all possible name variations of a media based on user preference (like country or language).
- xexe - 2009-06-29 12:34
Reading inside a zip file is not practical. It wont scale and will make XBMC slower and slower as your collection scales. You could cache the data but since other apps might be editing this is not practical either.
I just dont like all the "name the zip whatever it doesnt matter" comments. As soon as you do that you go from a "share you zip collection" to "useful only to me scenario" unless you use a tool to rename them.
Since you are relying on XBMC library mode use a UNIQUE id. Movie name is not unique in the slightest.
This is why every scraper, tv site, movie site and api in the world has a unique id.
- kortina - 2009-06-29 14:47
xexe Wrote:Reading inside a zip file is not practical. It wont scale and will make XBMC slower and slower as your collection scales. You could cache the data but since other apps might be editing this is not practical either.
I just dont like all the "name the zip whatever it doesnt matter" comments. As soon as you do that you go from a "share you zip collection" to "useful only to me scenario" unless you use a tool to rename them.
Since you are relying on XBMC library mode use a UNIQUE id. Movie name is not unique in the slightest.
This is why every scraper, tv site, movie site and api in the world has a unique id.
I dont agree about zip files not being practical, XBMC would not need to refresh the data from the zip each time, you dont scrape every time. Re-building your XBMC database would be a bit slower, but would still be much faster than most users internet connections.
I dont agree with your comments on the cache. When exactly are the zip files ever going to have their contents modified? Its not like the year, genre, actors or name of the movie ever change.
- Gangsta - 2009-06-29 14:55
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.