+- 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)
- szsori - 2009-06-08 22:27
AnalogKid Wrote:I've also wondered about making the 'NFO' hold all the artwork info. In this case, we'd create an XML element <Artwork> and define to our heart's content all the artwork we wanted! This way, a user can use any damn naming scheme they like, XBMC wouldn't care... it would just read the tag info to find the artwork.
I actually like this option. It's simple and straightforward, and could be maintained by any of the media management apps. The main question is how fast XBMC can read this on the fly.
- digitalhigh - 2009-06-09 00:54
I'd like to point out that MIP/serenity supports DVD cover images pulled from freecovers.net. Right now, it only works on locally stored media, but it would be nice to see this included too, despite the fact that it's not an Aeon feature.
Right now, these files are stored in the format of
moviename/extras/
CD1.jpg
CD2.jpg
front.jpg
inside.jpg
inlay.jpg
MIP then writes a flag to the "skin tag" that says which images are present, and my skin displays them accordingly.
This would work out nicely with AnalogKid's suggestion of leaving everything up to the .nfo tag, as it leaves things a tad more open-ended to those of us who do not, in fact, use Aeon.
On the same lines, it would be very useful (at least to me) to be able to know which titles have what images available, as then the user display could be auto-configured to show the proper images. This would also be applicable in the instance of wide banners versus posters for TV shows, as it would not restrict the user to just one or the other...
- jmarshall - 2009-06-09 01:06
As far as XBMC is concerned, a couple of points:
1. I don't care how stuff is laid out - the only interest I have is in efficiency of XBMC's code.
2. Movies in separate folders is IMO the _best_ method of storing stuff. It makes stuff like stacking fast, and the new library will be optimized for this method of storing movies.
3. Unfortunately, movies in separate folders is also the most inefficient in terms of finding artwork on the fly while browsing, as each subfolder needs to be fetched in order to find everything (or alternatively stat several tens of files to check stuff). I wouldn't want a separate folder (such as movie_folder/extras/stuff_goes_here) as that would make it even worse. With filesystems that correctly propogate ctime/mtime to the folder when a change is made that at least means we don't have to fetch the folder unless things have changed.
4. Filenames and extensions should definitely be standardized, but XBMC will ofcourse allow a power user to alter these. The defaults simply need cleaning up. I definitely want to get rid of the tbn extension and the nfo extension for xml files. Obviously the power user can use them if they really want to.
5. One thing to concern yourself with is that filesystems don't allow complete character sets, so compromise has to be made with file naming. Length of filenames should be kept to a minimum (xbox for instance) and some chars simply aren't allowed.
6. Whatever we do, it has to be easily extensible. I'm currently erring on the side of NOT including this info in the main video database (saves having to update it all the time) and instead having a separate dedicated artwork manager. I may well change my mind, depending on how things go.
7. As I said earlier, the new library is my top priority, so what little time I have will be spent on that before I even start to think about this stuff. Whether others want to take it up or not I'm not sure.
Cheers,
Jonathan
- digitalhigh - 2009-06-09 01:15
jmarshall Wrote:As far as XBMC is concerned, a couple of points:
2. Movies in separate folders is IMO the _best_ method of storing stuff. It makes stuff like stacking fast, and the new library will be optimized for this method of storing movies.
3. Unfortunately, movies in separate folders is also the most inefficient in terms of finding artwork on the fly while browsing, as each subfolder needs to be fetched in order to find everything (or alternatively stat several tens of files to check stuff). I wouldn't want a separate folder (such as movie_folder/extras/stuff_goes_here) as that would make it even worse. With filesystems that correctly propogate ctime/mtime to the folder when a change is made that at least means we don't have to fetch the folder unless things have changed.
6. Whatever we do, it has to be easily extensible. I'm currently erring on the side of NOT including this info in the main video database (saves having to update it all the time) and instead having a separate dedicated artwork manager. I may well change my mind, depending on how things go.
Cheers,
Jonathan
2. I couldn't agree more. It would also make things a lot easier to handle for the creators of the media manager programs, as it would mean less variables to account for. I recently pointed out a method here that allows for pretty simple automation of the creation of subfolders for every movie in a collection...
http://forum.xbmc.org/showthread.php?tid=47071&page=122
3. I wasn't necessarily saying that I want the extras folder...just that it would be nice if these other images were taken into consideration as well. We just picked an arbitrary location for them so that I had some kind of standard to work with while doing my designing.
6. It would be very cool to have a concise and dedicated system for artwork that works uniformly for all media on all levels. If done properly, it would alleviate the issues with music fanart not showing for album/song levels, or how TV show fanart is sorted out. Could also be used to help promote the little-seen artwork specific colortheme feature (TVDB)...something I'd still really like to see in action.
- szsori - 2009-06-09 07:47
digitalhigh Wrote:Could also be used to help promote the little-seen artwork specific colortheme feature (TVDB)...something I'd still really like to see in action.
May become deprecated due to non-use and less than perfect results in the few instances it's used. It's a big internal debate I'm having.
- digitalhigh - 2009-06-09 13:01
szsori Wrote:May become deprecated due to non-use and less than perfect results in the few instances it's used. It's a big internal debate I'm having.
Please don't. I think it's a really great feature in concept...it just needs some pushing and explanation for people to take advantage of. And maybe if you gave a few people the ability to go through and edit the themes that are already there...it could work better.
- AnalogKid - 2009-06-09 14:41
OK, here's a revamp of two ideas now... one for filenaming, one for NFO usage.
I personally can't decide between the two... each has merits and issues...
Filenaming Schema
note:
Fanart = Large image / wallpaper, usually full screen representing the media
Coverart = The image you'd expect to see on the front of the box (DVD, CD case)
Banner = A highly oblong image usually landscape representing the media
Framegrab = A snapshot of the media (screen shot) of the playing TV show or movie, not applicable to Audio
Discimage = The image you'd expect to see printed on the DVD or CD media (a round image)
Logo = A 'symbol' associated with the media, usually an iconic logo or symbol
Genre = A general classification for the category/style of media. e.g. Comedy, Rock, Horror, Jazz, Documentary.
<n> = Some number to allow multiple instances of artwork types. e.g. Starwars.movieframegrab.001
MediaInfo = 'Flags' as they are termed today. I felt the term MediaInfo was easier to understand
HasBeenPlayed = 'Watched', but a more generic term to cover Audio and even Images
<moviename>.movie.fanart.landscape.<n>
<moviename>.movie.fanart.portrait.<n>
<moviename>.movie.coverart.landscape.<n>
<moviename>.movie.coverart.portrait.<n>
<moviename>.movie.banner.portrait<n>
<moviename>.movie.banner.landscape<n>
<moviename>.movie.framegrab.<n>
<moviename>.movie.discimage.<n>
<moviename>.movie.logo.<n>
<tvshow>.tvshow.fanart.landscape.<n>
<tvshow>.tvshow.fanart.portrait.<n>
<tvshow>.tvshow.coverart.landscape.<n>
<tvshow>.tvshow.coverart.portrait.<n>
<tvshow>.tvshow.banner.portrait<n>
<tvshow>.tvshow.banner.landscape<n>
<tvshow>.tvshow.framegrab.<n>
<tvshow>.tvshow.discimage.<n>
<tvshow>.tvshow.logo.<n>
<tvshow>.<season>.tvshow.fanart.landscape.<n>
<tvshow>.<season>.tvshow.fanart.portrait.<n>
<tvshow>.<season>.tvshow.coverart.portrait.<n>
<tvshow>.<season>.tvshow.coverart.landscape.<n>
<tvshow>.<season>.tvshow.banner.portrait<n>
<tvshow>.<season>.tvshow.banner.landscape<n>
<tvshow>.<season>.tvshow.framegrab.<n>
<tvshow>.<season>.tvshow.discimage.<n>
<tvshow>.<season>.<episode>.tvshow.fanart.landscape.<n>
<tvshow>.<season>.<episode>.tvshow.fanart.portrait.<n>
<tvshow>.<season>.<episode>.tvshow.coverart.portrait.<n>
<tvshow>.<season>.<episode>.tvshow.coverart.landscape.<n>
<tvshow>.<season>.<episode>.tvshow.banner.landscape<n>
<tvshow>.<season>.<episode>.tvshow.framegrab.<n>
<tvshow>.<season>.<episode>.tvshow.discimage.<n>
<artist>.music.fanart.landscape.<n>
<artist>.music.fanart.portrait.<n>
<artist>.music.coverart.<n>
<artist>.music.banner.landscape.<n>
<artist>.music.banner.portrait.<n>
<artist>.music.discimage.<n>
<artist>.music.logo.<n>
<artist>.<album>.music.fanart.landscape.<n>
<artist>.<album>.music.fanart.portrait.<n>
<artist>.<album>.music.coverart.<n>
<artist>.<album>.music.banner.landscape.<n>
<artist>.<album>.music.banner.portrait.<n>
<artist>.<album>.music.discimage.<n>
<artist>.<album>.<track>.music.fanart.landscape.<n>
<artist>.<album>.<track>.music.fanart.portrait.<n>
<artist>.<album>.<track>.music.coverart.<n>
<artist>.<album>.<track>.music.banner.landscape.<n>
<artist>.<album>.<track>.music.banner.portrait.<n>
<artist>.<album>.<track>.music.discimage.<n>
<genre>.genre.fanart.landscape.<n>
<genre>.genre.fanart.portrait.<n>
<genre>.genre.coverart.landscape.<n>
<genre>.genre.coverart.portrait.<n>
<genre>.genre.banner.landscape.<n>
<genre>.genre.banner.portrait.<n>
<genre>.genre.framegrab.<n>
<audioformat>.mediainfo.audio.light
<audioformat>.mediainfo.audio.dark
<videoformat>.mediainfo.video.light
<videoformat>.mediainfo.video.dark
<resolution>.mediainfo.resolution.light
<resolution>.mediainfo.resolution.dark
<studio>.mediainfo.studio.light
<studio>.mediainfo.studio.dark
<source>.mediainfo.source.light
<source>.mediainfo.source.dark
<played>.mediainfo.HasBeenPlayed.light
<played>.mediainfo.HasBeenPlayed.dark
NOTES:
*The very wordy examples given above should be abbreviated at some point, they are here to make the examples more readable. So, for instance, MusicFanart might end up being abbreviated to MusicFA or similar.
*I had envisaged that a user COULD omit the .landscape and .portrait elements, so if they wished... they could simply have a filename like this
Southpark.Season01.tvshowcoverart.jpg
This would give the SAME cover art in both landscape and portrait modes
*The . delimiter might have to be changed to help parsing the filename (because some Media titles use . in the name)
*The seemingly redundant .movie . tvshow .music etc are needed to prevent namespace collisions where Movie / TVshow / Artist items have the same title.
*We might need a way to figure for unicode characters to be encoded in the filename (for the titles). But this problem must already exist with all media right? We just need to clarify how it's resolved / handled
*For MediaInfo files, it's unclear if there needs to be one mediainfo file for EVERY (say) studio, or if it would be possible to create a "disney.mediainfo.studio" file that would be found for any studio containing the word "Disney"
*MediaInfo have "light" and "dark" options, this is because the typical usage of this type of art is to act as an overlay / icon / indicator. Since some skins are light, and some dark... the icon would need to be visible in both cases... hence two versions... I could have relied on these images being monochrome and therefore 'invertible' but I felt this was too much of an assumption. So this way, you can have colour ones if you wish.
NFO schema
<Artwork>
__<Movie>
____<Fanart>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______</Item>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______<Item>
____</Fanart>
____<Coverart>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______</Item>
______<Item>
________<Default>C:\My Images\someartwork.jpg</Default>
________<Landscape>C:\My Images\somelandscapeartwork.jpg</Landscape>
________<Portrait>C:\My Images\someartwork.jpg</Portrait>
______<Item>
____</Coverart>
__</Movie>
</Artwork>
I didn't want to go through the entire XML!... it's only a mockup... but.. in making the XML, some things crossed my mind....
There's a bunch of different ways to do the XML schema...this is quite a primitive but simple way. But it's wordy (as XML is), and requires XBMC to find the NFO, parse it, then find the content specified within it.
For this simple example... it's not so bad... but IF we really wanted different posters / fanart per track... then we'd either have a complex XML, or an XML per track. I don't much like either of those options. Something feels 'clever' but 'wrong' about it...
Summary:
For me personally, the filenaming still seems the easiest and best option, even if the elegance of the XML holds some appeal too.
I can't help but think of the extreme cases.... where if I said "give me fanart for Madonna, Ray Of Gold, Track 3".... it would just be easier to find the file than the NFO/XML, parse it, THEN get the file. This would be especially true if a user stored all their art in one folder (flat).
I'm erring still on the side of the filenaming for the above reasons... it's just so much easier in most OS to search for "Madonna.Ray Of Gold*.jpg" and see all the artwork you have associated.
I really like the idea of a user storing all the art in one flat folder... but, I am a stickler for organised media.... which flies in the face of this.. since I like to keep all my associated artwork and meta info WITH my actual media. Regardless, the filenaming schema works wherever you stick it.
Finally I have a question for anybody who might know the answer... what happens in XBMC if the fanart existed in two locations across multiple sources? which takes precedence?...
- jmarshall - 2009-06-10 01:35
XBMC will prefer the filenames I should think. Obviously source to artwork will be supported in the normal XML nfo files like it is already. If we need to add more types, then it's done on the scraper side of things.
The big problem will be how the thumb loader caches stuff. Things have to be cached to ensure fast loading, but we don't want to cache too much. There's going to have to be some sort of balance here I think.
Cheers,
Jonathan
- AnalogKid - 2009-06-10 09:51
jmarshall Wrote:XBMC will prefer the filenames I should think. Obviously source to artwork will be supported in the normal XML nfo files like it is already. If we need to add more types, then it's done on the scraper side of things.
The big problem will be how the thumb loader caches stuff. Things have to be cached to ensure fast loading, but we don't want to cache too much. There's going to have to be some sort of balance here I think.
Cheers,
Jonathan
I can definitely appreciate this aspect. I would guess there are a few choices to be made along the following lines:
a) If the file is a 'common' artwork... e.g. CoverArt it's a candidate for caching, whilst a Screengrab probably isn't (this is making some big assumptions about a skin though).
b) If the file is large in storage size, then it might be a candidate for caching
c) This could be overkill, but... if the file is accessed regularly, it could be a candidate for caching (although this could be tricky to count access requests for per file)
When we use the term 'cache' are we talking about copying remote media to a local store, or are we talking copying it AND optimising it (lowering resolution, storing it in decoded/'display ready' format) too?
I've also wondered about the need to hash the files to detect changes and therefore update the cache... the only reason I can see to do this is to improve the performance of 'update library'. Off the top of my head, I'm asking myself... is it worth it? I don't mind waiting a little longer as long as the job gets done. There's probably other reasons I've missed, just thinking aloud here!
Finally, for skinners... I wonder if it's possible to request a preference for 'cache' vs 'original' artwork? The only issue here is that if skinners choose 'cache', then what have they gained? and if they choose 'original' what's the point of the cache?
Maybe in the future they will have some way of using cache for general browsing...and when the user focuses on a specific media and needs detailed rendering, then the skin requests 'original'.
For me... this is moving into a slightly different realm about how XBMC optimises the use of artwork. Solving the first issue of how to best find it is the primarily goal (although it could be that they are inextricably linked).
I've been thinking much more about the XML content to find artwork, and I'm increasingly coming to the conclusion that it's overly engineered. One of the reasons I started this thread was that so many end users where having trouble figuring how artwork worked, and even amongst the experienced folks, there were too many possible schemas. Putting the artwork references inside XML is neat, but I feel it will only make matters worse still.
"Keep it Simple" is still the right way to go I believe, and for that reason I'm more and more in favour of the filenaming scheme.
I've also come across a few other threads where it's suggested folks (skinners?) would like more and more info on the artwork... like dimension size etc. Well.... there has to be a cutoff point somewhere. For me, that cutoff point should be that the filename should only describe what the artwork does and to which media it belongs.
Does anybody disagree?
Finally, let's say we DID elect to change the filenaming scheme. Would we deprecate the old scheme over a couple of releases, or be merciless and simply enforce a new scheme (but provide some scripts to help people make the transition and give scraper and skinner folks lots of notice)?
I would guess initially, skins would not be broken, they simply wouldn't be able to utilise the new flexibility.
The consequences are clearly quite large... the wiki instructions, and scrapers would all be affected (but this doesn't make it a bad thing... and it will only get worse the longer it's not addressed).
We're a long way off this yet... I appreciate that... just raising the point :-)
- AnalogKid - 2009-06-14 17:25
Extended the scheme to include Media Flags, Genres etc...
For me, the file naming scheme seems to be coming together.
Jim seemed to suggest the file naming scheme was the possibly the preferred option, and having thought about it a lot, I'm in agreement.
Would still be interested in hearing counter arguments - or other possibles naming schemas...
Sadly, it seems most folks are too excited by new skins, and rushing ahead to find new ways to enhance the skins with 'tricks' rather than take a step back and fix the naming schemes... but I'm going to carry on until the skin fans finally say "hey, we need to neaten up the filenaming!"