+- 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-24 21:31
So just to be clear you arent interested in the naming of the files in the XBMC cache at all
i.e. \userdata\Thumbnails\Video\3\3a0b5e7f.tbn
are specifically NOT the files you are designing a naming scheme for?
- AnalogKid - 2009-06-25 01:52
xexe Wrote:So just to be clear you arent interested in the naming of the files in the XBMC cache at all
i.e. \userdata\Thumbnails\Video\3\3a0b5e7f.tbn
are specifically NOT the files you are designing a naming scheme for?
Correct. This is for the local files manually or automatically downloaded and 'assigned' to a given media content.
It's totally about the way in which the "movie.tbn, folder.jpg, movie-fanart.jpg <movie>.jpg etc" mess can be rationalised into a consistent naming scheme AND extended to include all the new types of art that are appearing (XBMC was never built to handle much more than a single fanart and a thumb"). Also to work in ANY configuration (flat, folder, or scattered).
However, XBMC can then choose to cache these files in any way it chooses (for speed / resolution optimisation). But caching would occur below any abstraction layer and skins would never know. That's down to XBMC internals.
It just so happens that the naming scheme COULD be used for the cache too, and that it allows users to store ALL artwork for all media types in one flat folder if the user wants to (so the user COULD store all their art on a local machine, while the content exists on a remote server).
- xexe - 2009-06-25 09:28
That makes things much easier as the way XBMC caches relies on path and file name hashing which isnt conducive to your naming scheme.
So whilst the aim is to make this scheme platform and software agnostic how do you plan to get around the very specific XBMC and User stacking REGEX ? Are you making it a hard and fast requirement to use the one movie to one folder storage scheme?
- bidossessi - 2009-06-25 11:34
actually i would secong that requirement, which is easily met using any good media manager. I even wrote myself a bash script to migrate my video library from file-level strcture. i believe the benefits far outweight the inconvenience: structure is what makes storing easier, and each movie has all related media (nfo, art, trailer, thumbnails) right in it's own folder, so no <neologism>octopussing</neologism>.
What XBMC has that other MC don't is this slew of additional eye-candy that is totally user customizable in an easy way.
I think XBMC does it right, and that's why i've selected it as my HTPC app. I believe anybody who makes that choice will be ready to take the necessary steps to benefit from all it's capabilities. Especially knowing that the structures imposed upon him/her are sound and scalable.
- Ninjamawwe - 2009-06-25 12:25
I really like the initiative of starting to try and make a more structured way of organizing/naming images. I agree with most of what you have done, but But for those who have their media "properly" organized into one folder per movie/ one folder per album etc, it is quite cumbersome to have to use the "medianame" as the identifier. I really like just being able to add "folder.jpg" to say a season in a tv-show and it will stick. This may be directly against what you are proposing or trying to achieve, but I just wanted to say that I appreciate the flexibility that exists today. It wouldn't kill me to have to use the full naming convention that you are proposing, but I just wanted to voice my opinion that perhaps they can co-exist, but I guess it is up to whoever might try to implement this to decide if if will be to much of a hassle to support both.
On another note, I agree with digitalhigh about adding the "n" to thumbs fanart, cd's (discs) etc.
Nice to see someone working on this.
- AnalogKid - 2009-06-25 13:14
xexe Wrote:That makes things much easier as the way XBMC caches relies on path and file name hashing which isnt conducive to your naming scheme.
So whilst the aim is to make this scheme platform and software agnostic how do you plan to get around the very specific XBMC and User stacking REGEX ? Are you making it a hard and fast requirement to use the one movie to one folder storage scheme?
Absolutely not. There is no requirement on folder structure at all, since the naming scheme is designed to work in folder, flat, or scattered structures...
No matter where the artwork is placed, if XBMC can see it, it can very easily tie it to a movie / song / artist etc.
As for the stacking, that's easily covered...
Starwars-CD1.avi
Starwars-CD2.avi (and all similar stacking conventions)
This is resolved by XBMC into 'Starwars'. Therefore, the artwork will begin with Starwars.xxx.xxx.xx. (etc)
This really is precisely the same as things currently work, but with the new scheme, there are no alternative art file names (which removes all the confusion, conflict possibilities and extra code required by XBMC) e.g.
Starwars-CD1.avi
Starwars-CD2.avi
Starwars.movie.fanart <---- the only choice
Starwars.movie.cover <---- the only choice
Starwars-fanart.jpg <--- no longer possible
movie.tbn <--- no longer possible
folder.jpg <--- no longer possible
folder.tbn <--- no longer possible
Of course user who already HAVE 'folder.jpg' etc CAN still keep the files if they want to, or they can easily have them 'ported' to the new scheme... since we know the -fanart extension will be a fanart so we can rename it, and we know that today, folder.jpg, movie.tbn etc will transpose to 'movie.cover' (or even movie.cover.<landscape/portrait>)
Those current 'folder.jpg' and 'movie.tbn' filenames just don't cover enough artwork possibilities anymore (if you change skin from a portrait thumb to landscape thumb skin, you are screwed today). If you want to have multiple fanarts (cycled), you are again screwed. If you want to have movie framegrabs... skinners are inventing custom hacks to get this.
- AnalogKid - 2009-06-25 13:28
Ninjamawwe Wrote:I really like the initiative of starting to try and make a more structured way of organizing/naming images. I agree with most of what you have done, but But for those who have their media "properly" organized into one folder per movie/ one folder per album etc, it is quite cumbersome to have to use the "medianame" as the identifier. I really like just being able to add "folder.jpg" to say a season in a tv-show and it will stick. This may be directly against what you are proposing or trying to achieve, but I just wanted to say that I appreciate the flexibility that exists today. It wouldn't kill me to have to use the full naming convention that you are proposing, but I just wanted to voice my opinion that perhaps they can co-exist, but I guess it is up to whoever might try to implement this to decide if if will be to much of a hassle to support both.I agree entirely, it IS nice to drop a folder.jpg into a folder and it just works. That said, you still have to name a piece of art (folder.jpg). So might as well name it more clearly!... and we can make a script to do this for you if your stuff is already well structured (as my stuff is). The trouble is 'folder.jpg' just doesn't cut the mustard anymore... a skin can't tell if that is portrait or landscape art (without reading it first), and worse still, if you'd like BOTH portrait and landscape, you're screwed. Or if you want more than one instance of art... you're screwed again.
On another note, I agree with digitalhigh about adding the "n" to thumbs fanart, cd's (discs) etc.
Nice to see someone working on this.
Regarding the <n>, I think I have this for all artwork types now.... if you want more than one instance, you can have more than one. There is simply no harm in this at all. Skinners can do what they like with multiple instances of art (choose use the first, cycle through them, animate them... whatever!)
I do still sympathise with your folder.jpg ease.... however, I looked at the forums where folks had artwork problems, and you would not believe HOW hard it can be for newbies (and some experienced folk) to get a a definitive answer on how to make the right artwork appear on screen. You would probably tell a guy "it's easy, make a folder.jpg file in the directory". Then the user would say "I don't have a folder structure". Another guy would say "name it <movie>.tnb" another would say "name it movie.jpg (even if it's a png)" etc. The end user just gets confused!
On top of that, the scraping tools now have tonnes of options and code to deal with all the possible variations, and that causes no end of hassle too!
I'm just glad that folks are reading and contributing and saying "not sure about the syntax, but agree this needs improving". That's encouraging for me. And as I see the skins really start to break new ground, it just encourages and strengthens the case. DigitalHigh's been very helpful with just a few comments and insight!
Love the feedback guys, and it's not all my work... definitely a collaborative effort by you all!
- Ninjamawwe - 2009-06-25 13:44
On a side note, when using multipart archive files *.rar .*r01 etc, I suppose the "filename" part of the image will refer to the actual file inside the archive?
- AnalogKid - 2009-06-25 18:39
Ninjamawwe Wrote:On a side note, when using multipart archive files *.rar .*r01 etc, I suppose the "filename" part of the image will refer to the actual file inside the archive?
Hummm you raise a good point, and I'm open to ideas. The critical thing is that the stardard for naming is clear.
Off the top of my head, consider the following three situation:
1) Foo.rar (containing a movie called Starwars.avi)
2) Starwars.iso (containing a movie called video.vob)
3) Starwars.rar (containing a movie called movie.avi)
in situation 1) "Foo" is misleading... but the choice of this name is down to the user, and so they COULD fix it
in situation 2) "video.vob" is the DVD standard, so we cannot expect to be able to rename this... therefore we really SHOULD rely on "Starwars" from the archive name.
in situation 3) "movie.avi" is down to the user again, as is "Starwars.rar"
SO.... my conclusion is this:
We should use the ARCHIVE name in the following manner:
Starwars.iso (or rar)
Starwars.movie.fanart
Now, there is one minor issue I hadn't considered until now...
people that rip DVD content to a folder in the following fashion:
Starwars\
----video_ts\
------- video.vob
----audio_ts\
in this situation, it's just NOT possible to create "video.movie.fanart" - it makes no sense.
This means that we are forced to use 'Starwars.movie.fanart" even though the ACTUAL media file does not have the "Starwars" filename.
This isnt a big deal as long as everbody knows this rule.... it's just a shame that the dvd standard works this way... and you can't rename to media files (just the containing folder).
- Gangsta - 2009-06-25 19:23
Loving this discussion, as I really like to have an organised library too. I think you guys have done an awsome job with the schema so far.
I would like to hear a bit more from fekker, and something from billyad2000 regarding its implication on the media managers, as well as some input from the scraper devs.
Slightly OT. On page 3 or 4 of this thread, there is talk about the cache, my tuppenceworth would be this:- if possible cache the 'default' image as required by the current skin - eg frontcover or poster, in a ready to use format (already resized, mabey reduced quality etc) and use the cached image in the first instance to get the display drawn, then (if chosen in the skin settings) it pulls in the full resolution artwork from whereever local, network etc and updates the display with them assuming you stay on that page long enough, this will allow quick scanning through the library, and full resolution artwork at the same time.