+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation? (/showthread.php?tid=49801)
- AnalogKid - 2009-06-24
bidossessi Wrote:We're scratching our own itches in the most civilized manner we can.
I really think your proposal is worth looking into. my only issue (which is not really mine anyway) would be lengthy filenames on some OSes.
need => suggestion => reflexion => proposal => adjustement => improvement.
That's how i see it anyway, so keep up the good workmile:
I agree and tried to mention it in the small print that once 'agreed' it could be abbreviated significantly.
If for some reason it HAD to fit a 8.3 filename limit, then I have a fix for that also... we'd just have to use some lousy .3 extensions e.g.
".234" = Fanart.landscape
".789" = Cover.portrait
Or piggyback on the NFO and have
<artworkfiles>
<fanart.portrait>tinyname.xyz</fanart.portrait>
<fanart.landscape>tinyname.123</fanart.landscape>
<artworkfiles>
this would be an EXTREME measure if it ever came to it... but it won't. I have a gun.
- bidossessi - 2009-06-24
remind me again why you dislike nfo files so much.
I think it an interesting way to store informations that could be used by many different backends, and since it moves with the media, it's pretty much as permanent as the media itself.
unless i got you wrong and you don't actually dislike nfo files.
i Think adding the artwork info to the nfo is a pretty darn good idea. as always i'm thinking of saving bandwith.
if a media manager could take care of, well, managing my data and populating nfo tags with *all* the possible options, then imagine how fast xbmc could scan my library and find artwork, info, thumbnails, trailers, whatever, all in the nfo file. it could even be ported to music management.
imagine further if xbmc's nfo became a standard that other media centers could use (moovida's hellishly slow and very bad at finding info for my moovies, mythtv has no scraper that i know of, neither does freevo, just to name those).
Now image a pc crash, and you have all your 6T of media with nfo and extra artwork safe on a raided NAS or something. imagine the joy of carelessly telling your wife: "no honey, i won't spend two weeks in the basement finding imdb tags for each and every one of them."
just imagine...
i don't imagine, i know. i don't have the internet at home. i do my scraping at work and bless nfo every day because i just take my portable HDD home, pop it in, transfer, scan, and it's all there!!!
- AnalogKid - 2009-06-24
bidossessi Wrote:remind me again why you dislike nfo files so much.
I think it an interesting way to store informations that could be used by many different backends, and since it moves with the media, it's pretty much as permanent as the media itself.
unless i got you wrong and you don't actually dislike nfo files.
i Think adding the artwork info to the nfo is a pretty darn good idea. as always i'm thinking of saving bandwith.
if a media manager could take care of, well, managing my data and populating nfo tags with *all* the possible options, then imagine how fast xbmc could scan my library and find artwork, info, thumbnails, trailers, whatever, all in the nfo file. it could even be ported to music management.
imagine further if xbmc's nfo became a standard that other media centers could use (moovida's hellishly slow and very bad at finding info for my moovies, mythtv has no scraper that i know of, neither does freevo, just to name those).
Now image a pc crash, and you have all your 6T of media with nfo and extra artwork safe on a raided NAS or something. imagine the joy of carelessly telling your wife: "no honey, i won't spend two weeks in the basement finding imdb tags for each and every one of them."
just imagine...
i don't imagine, i know. i don't have the internet at home. i do my scraping at work and bless nfo every day because i just take my portable HDD home, pop it in, transfer, scan, and it's all there!!!
I don't dislike them, I was 50/50 at one point about which way to go.... and started a mock up of the XML needed.... and that's where I discovered the issues....
I think on paper, XML is really elegant. Then you start writing it and see it's very long winded and mega inefficient.
But here's what I concluded:
1) Scrapers would have to start writing to the NFO file (I know many do already, but still...)
2) When there's only one instance of an artwork (say 1 fanart / backdrop for Star Wars), it's nice and neat, but if you have 10 of them, the XML gets big, and it's just that little bit more complicated to 'slideshow' through a list of them.
3) Jonathan Marshall (a significant developer I believe) expressed a view that the filename schema would probably be less code and more efficient to scan/search into the library. I wouldn't say he 'supports' my schema, just so far has been encouraging and I think he buys into the need.
4) There aren't NFO files for music (I don't think), or at least there aren't NFO files for every level of granularity (e.g. no NFO for a specific album track).
5) The filenaming schema works easily at every level... artist, album, track etc and the actual artwork files can all be put in one folder if need be (allowing for very easy caching and moving around). The files can be scattered absolutely anywhere and just scanned once (to find them). If they are in NFOs with a path to the file...it's messier to move without NFO tools
6) End users. A massive motivation for all of this was that there were too many ways to do art, the flexibility actually increased code size and created ambiguity about which file takes precedence over another etc. And, it made it harder to help an end user because so much depended on if they had flat or folder based media, if they chose movie.jpg, folder.jpg, or starwars.jpg etc AND finally the horrible need to rename a PNG file to JPG!... so with all this in mind I wanted to make it 100% easy and 100% unambiguous about artwork and what the art would do.
7) The filenaming scheme would be exceptionally easy for existing users to port to, regardless of their current scheme. And if need be, port back. I believe O/S scripts e.g. bat files could do this easier than creating and parsing XML... usually needing more advanced programming tools.
Bearing this in mind, I thought the XML was nice for techies, but not really helping John Doe.
Weighing all this up. Filenaming was easy to understand, good for the coders, good for the users, good for scrapers and efficient for all concerned.
The more and more I looked at the XML, the more and more I realised... this isn't giving me anything extra, other than to say it's XML.
There was one tiny road I went down with the XML though.... and I stopped as soon as I realised I was going down the path:
This was when a few folks said "hey we like the filename, BUT, would be nice if we knew the filesize, and bitdepth etc). The XML would have supported this with endless art info tags. At this point I drew a line and said the naming scheme was NEVER about image info... it is purely to match art to media, and to know what function the art is having.
So... definitely not against XML!... just went there and came back.
With the filenaming scheme, if you crash... you still have the art. XBMC can very rapidly rescan to the library. Today, when XBMC tries to find art, it has a lot of combinations and possibilities to try, and in the case of music it works on some smart algorithms to guess what art it should user (98% good Id say). But I wanted to make a way to make it 100% accurate, quicker to find and without ambiguity. With the filenaming, XBMC could rebuild everything art wise, without ever having to go to the internet!
The only time it would need to go to the net is for additional info (plot, director, review etc), and for this, the NFO remains intact.
Another motive for all this was that I like the scrapers BUT I refuse to depend on them. They could be gone tomorrow. So I want to get my art, and store it safely on my server forever. Once I've named the media and art correctly, I never need to download again, and I can rebuild as often as I like and get mega fast rescans (without human intervention) to find the art. The only time I would need a scraper then, is when I need art for new media, or want to change existing art.
- bidossessi - 2009-06-24
ok, i get your point. nfo's don't need to hold more than the textual info as far as i'm concerned, since the artwork is downloaded to the media folder itself.
my case may be specific, and that's why nfo works for me, but by no means do i hope for the nfo to hold all details about my media. i'd rely on a central database for that as well if at all possible.
But i do rely on the nfo to recover this textual data without connecting to the net if my database ever gets trashed. as for the rest; filename scraping is the perfect solution, since it is both human and machine readeable.
I think i went off topic, but this helped me understand a bit better the motivations and the scope of your project.
Thank you.
- AnalogKid - 2009-06-24
bidossessi Wrote:ok, i get your point. nfo's don't need to hold more than the textual info as far as i'm concerned, since the artwork is downloaded to the media folder itself.
my case may be specific, and that's why nfo works for me, but by no means do i hope for the nfo to hold all details about my media. i'd rely on a central database for that as well if at all possible.
But i do rely on the nfo to recover this textual data without connecting to the net if my database ever gets trashed. as for the rest; filename scraping is the perfect solution, since it is both human and machine readeable.
I think i went off topic, but this helped me understand a bit better the motivations and the scope of your project.
Thank you.
No you're bang on the money, you're precisely the same as me... I keep my media, NFO and artwork perfectly organised, for rapid rebuilds...
the NFO still needed... just for the usual stuff. I'm a fan of it. I just felt in the end it was the wrong choice to use it for artwork info too. Everything stays just as it is today, except for the naming of the artwork files. I just made it more consistent and extended the types of artwork supported.
I saw some new skins appearing using more types of art and found some niggles in music artworks, and noticed the number of users struggling with art and decided to fix the issue once and for all.
I didn't come up with this to suit me though, I had to take a 100% agnostic approach that worked for all possibilities.
The NFO's definitely still remain 100%
- xexe - 2009-06-24
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
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
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
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
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
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
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
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
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
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.