FanArt and Thumbnails Naming-Standard and File-Structure Convension Rationalisation?

  Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Lightbulb  FanArt and Thumbnails Naming-Standard and File-Structure Convention Rationalisation?
Post: #1
Since my last suggestion to rationalise the rather messy (and still growing out of hand) fanart / thumb management went down like a Led Zep...

How about a compromise that at the very least keeps the 'art' associated with Music, TV shows and Movies in a nice container?...


How about ONE folder per movie called <moviename>.XBMCMedia and within THAT folder is the fanart, the thumb, the nfo etc etc?

At least this way, it's very easy to isolate the movie from the additional artwork content. This will work in flat and hierarchical media lists, and just be a small step towards neatening up the situation.

For those that disagree with me saying the current situation is messy and continuing to grow out of hand.... have a look at how many users are struggling to get their artwork working properly, and the way Aeon skin is resorting to using its own technique for hi-res thumbs... the whole thing needs revisiting, but for the moment, at least a folder to contain the mess would help.

Is it just me that thinks this way?
(This post was last modified: 2009-06-09 19:50 by AnalogKid.)
find quote
spiff Offline
Retired Developer
Posts: 12,386
Joined: Nov 2003
Post: #2
it makes everything very xbmc specific for no other reason than your filesystem being slightly less cluttered (that argument only really applies to folder.jpg since the other stuff is xbmc specific anyways). the real argument against something like that is that we have to list two folders instead of one. which is extra slow on most filesystems, e.g. ftp would HATE it, samba will surely slow down, local won't notice it that much.

the fact that aeon is *able* to do those shenanigans just shows flexibility imo.
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #3
I can agree that FTP would be slightly slower, but surely only for scanning, not for playback, but still I concede that point.

Slowing down Samba? Tenuous argument there, and if that was truly the case, then why not mandate flat structures for all media?

I honestly do think it's getting messy. You could argue there is a lot of flexibility in having multiple naming conventions for artwork (folder.jpg, moviename.tbn etc), but in the long run I think its a) harder to maintain all the options and b) more prone to causing half the users to use one technique and the other half adopting the alternative technique... then when there's a bug... only half the users experience it.

To my mind the stricter and more clearly defined the convention is, the better. I reckon at least half the users of XBMC are duplicating artwork in their media folders just to make sure it gets scanned - this cannot be right.

Maybe I am in the minority!
find quote
spiff Offline
Retired Developer
Posts: 12,386
Joined: Nov 2003
Post: #4
i'm not going to go into details but;

every time you list a folder we need to check for thumbs for items that lack thumbs (and before you ask; how else would we detect the new thumbs). that explains the samba stuff i hope....
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #5
OK,

I will go back to basics and list what I consider to be slightly questionable policies on fanart and thumbs...


1) The use of folder.jpg
This is clearly a windows system file, and should be avoided like the plague... either xbmc wants to reuse this MS convention (which is lousy) in a non cross platform manner, or it wants to stick to its own convention (which seems to be the general XBMC policy, with which I agree). I'd drop use of this altogether

2) folder.png (needing to be renamed to folder.jpg)
Can there really ever be an excuse for disguising the true filetype, and worse still, renaming it to another format which is clearly is not?
This is a kludge surely and could be addressed (eventually)

3) Multiple tbn files in hierarchical structure
According to the current documentation it's possible to have the following:

Movies\My Movie 1.tbn
Movies\My Movie 1\
Movies\My Movie 1\folder.tbn
Movies\My Movie 1\folder.jpg
Movies\My Movie 1\movie.tbn
Movies\My Movie 1\My Movie 1.avi
Movies\My Movie 1\My Movie 1.tbn

Surely having to check for the existence of thumbnails across at least 2 depths and with multiple choices for the files is less efficient than checking for the existence of ONE file?
It would keep the code simpler too.... K.I.S.S. always helps! if 2 depths is OK, the argument against 3 depths is weakened (although still valid). My true motivation isn't to neaten up a folder... it's to rationalise the OTT range of fanart and thumb configs.

4) Movie and Music inconsistency
Movies may have 'folder.tbn / folder.jpg' , yet Music requires 'Foldername.tbn / folder.jpg'

5) TV Show fanart vs Movie Fanart
The TV Show fanart requires a hierarchical media structure and use of "fanart.jpg" per TV Show folder (according to the manual), yet Movies fanart can adopt either same OR the moviename-fanart.jpg convention for flat structures.

6) Hi-res thumb caching
Aeon's nicely managed a way to get hi-res thumbs - but in a skin specific manner.
This means that a UI is placing demands on the model / the data... that is specific to one UI. I love Aeon, but it's not the right solution long term.
I suspect in the future, there will be a longer term fix for this... perhaps an 'image cache quality' option allowing 'zero loss' as it's highest quality.

It may well be that some of the online manual isn't quite right, and in which case, apologies!... and I also accept the current code works... I use it every day, works like a charm.
However, I still maintain, somewhere down the line the thumb and fanart needs to be rationalised to have less options, and more consistency. Less options need not mean less capability. This would keep the code simpler, faster, and keep the user support much simpler too (not to mention scrapers, and 3rd party media info managers)
find quote
fekker Offline
Posting Freak
Posts: 1,545
Joined: Oct 2008
Reputation: 30
Post: #6
I think xbmc has the best support for images out of every other app i've seen. The dev's did an awesome job in the library and non-library modes for options and visuals. And best of all, none of it is required. XBMC has all of it built in with the scrapers that hit the same sites (and way more of them) then any addon / helper app has.

Nothing has to be in your movie folders, it's all optional. No nfo's are required, no images, no tbn's. it's all optional.

fanart.jpg and folder.jpg work very well in windows and in other applications as well. It's not limited to just xbmc.

Once it has a local cached image it doesn't check again. If it's missing it looks for it.

Sure, there's a bunch of tricks in skins being used for different areas, none of which are required, some of which are really unique to the skin. If you turn up the image size in the advanced settings, the visual difference seems minimal for the large images. Media Image support is in Serenity and is a neat addon (cd images, front, back covers, inserts, etc). Season level fanart is also in there, and if you don't have those extra items, it doesn't matter as it uses the defaults.

I guess I just don't understand the need for change of the current system. I would actually add more options, but that's just me.
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #7
don't get me wrong, as I've said, everything works fine so far... I'm not saying there are bugs, or feature limitations... far from it...

What it more and more clear is that folks struggle with fanart...

esp for Anally retentive folks like me, who build up their media on a server, use the scrapers once to gather the required artwork, then finalise a setup that can be reinstantiated in no time at all....

I use XBMC in portable mode, but if I lose my XBMC configuration I can rescan my entire library and retain all the images and thumbs I've chosen (not the ones tmdb thought I'd like)...

What I see with XBMC (with regard to fanart/thumbs) is that over time, it's been extended, and more and more possibilities / combinations of setup added.
In my opinion, that will become harder and harder to maintain, is already flawed in the case of artist thumbs for multiartists, and is creating far more support work that is necessary. I'm all for more features, I just think sometimes after a project's been going a couple of years you can stop and say "you know what, there's a simpler and quicker way to do it"... and for me, that applies to fanart and thumbs.

I am convinced it would simplify the code if fanart was sensibly rationalised to a totally consistent format across TV, Movies, Video and Music etc... and most importantly, Joe Bloggs on the street could have a simpler life.

Of course XBMC's the best there is... that's why I'm using it! it's on a par with MediaPortal for me... both stand out above the crowd, just offering my two-penneth on a potential improvement for the future!
find quote
jmarshall Offline
Team-XBMC Developer
Posts: 26,228
Joined: Oct 2003
Reputation: 177
Post: #8
First off, your last post didn't go down like a Led Zep - didn't I indicate that I'd be reviewing it after Babylon, or am I thinking of a different post?

At any rate, I'm in complete agreement that the system is too complicated. At the same time, however, it is very flexible. I'm all for simplicity if it can be attained easily.

As you suggest, there are reasonably sound reasons behind any differences among movies, shows, and music, though much of it has evolved over time without any real refactoring, so in some cases it's a compete mess. With music, for instance, we don't care what the users filesystem is, and thus we cannot make assumptions about where files may lay (or at least if we do, they have to be as general as possible). I think we have this pretty right for the most part.

With Movies/TV shows, it was decided that we needed to enforce some sort of filesystem structure in order to make sure that things were reliably picked up. This structure is pretty loose, however, which means we still have lots of things to consider, and don't always get it right (though I think we pick up local stuff reasonably well, if inefficiently).

The points that need addressing in any review are:

1. Filesystem structure, if any, that will be enforced.
2. Searching for images from the local filesystem.
3. Caching these images for fast retrieval.
4. Ensuring that the cached images are in-sync with the local filesystem.

Any comments at this stage are welcome, though they may not be acted upon for quite some time.

Cheers,
Jonathan

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
Bram77 Offline
Skilled Python Coder
Posts: 1,369
Joined: Feb 2008
Reputation: 32
Location: Netherlands
Post: #9
In this case I'd choose simplicity/uniformity over flexibility any time. If not, ... it starts with flexibility, progresses to complexity and ends in .... well ... a mess.

It's not a bad thing for users and developers to be disciplined into a clear structure. Some might like it, some won't. But in the end at least we're talking about the same subject. The discussion will be about the way it is and not the way's it can be. Which will make it a lot easier to come to a definitive solution.

The same goes for local caching of all media related art (fanart, thumbnails, banners). XBMC shouldn't take responsebility for performance impact because of media art. At this point all images are stored locally (if I'm not mistaking). It would take some load off the developers and it would speed up scanning enormously if images wouldn't be cached but loaded realtime. And most importantly, it would make things clearer!

To avoid misunderstandings I'll explain differently...
I think all media related art should be loaded from the data directories at realtime (wherever possible). It seems like XBMC is a little '2003' about this. When internet connections where far from what they are now and 1Gb networks were a devs wet dream. Don't get me wrong, I'm running XBMC on my XBOX with a 100Mb network (happily). But I'm more then willing to upgrade for more 'Ajax-ability'.

.... On the other hand.... what am I whining about. XBMC is the greatest HTPC app there is Smile, and I've tried them all.

One side note about the updating of thumbs and fanart.... Shouldn't XBMC check if the size or date of a thumbnail has changed and update it accordingly? I haven't checked the code, but it seems like only the existense of a "folder.jpg" is triggering an update. If I change a thumbnail (folder.jpg) it seems like I have to delete all thumbnails to be able to update a single thumbnail (I wouldn't know how to figure out which image belongs to what media based on a filename, without consulting the database). I could be missing something! PLease tell me if this is the case!

[Image: widget]

Please add to my reputation if you find my posts usefull (+/- button below posts)
Ubuntu 12.10 minimal XBMC auto-install script :: XBMControl :: Xbmc XBOX Skins :: XBMControl for Android :: Owner of Sudo Systems
(This post was last modified: 2009-04-28 03:50 by Bram77.)
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #10
Aha... it actually sounds like we're singing from the same hymnsheet now...

I'm definitely not saying "do it now"... mostly just trying to get agreement that the issue exists (things are working, but at some point in the future it could use a rethink). It may well be that after a huge rethink, it's determined all the right choices were made first time around.

I shall be in the cafe eating my hat if this is the case though!... it's software right? you develop it, get it working like a dream... then rewrite it 2 years later in half the time, twice as well, and with half the bugs and wonder "what WAS I thinking the last time?"

I think there could be some merit in deprecating some of the range of filenames for thumbs and fanart. There's no real harm in saying "ok, it's moviename.tbn for all thumbs" since this will work in flat and hierarchical systems, and is unambiguous (no contention with folder.jpg etc). BTW, this was just an example!... I could live with folder.jpg and insist on folks keeping hierarchical structures... I think that's down to the XBMC dev team to decide upon, but narrowing the range of possibilities would be a great idea I think, and I reckon you could end up stripping out some code!

I'm curious actually to find out how the community itself feels about neatening up the way the fanart works. Is it possible to sound out some thoughts?
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #11
Hey Jim,

I wonder if you're back in the mood to discuss this topic?
I know you were snowed under with Babylon, and I expect you're already racing ahead with new ideas for the next release.... but I shall continue to haunt the forum!...

I'd love to be part of the discussion on how to rethink the fanart and thumb situation to hopefully be easier on the code, and less prone to error (I know 99% is working already and user is a big factor, but I still think this should be considered).

I'm happy to detail a whole bunch of discussion points to get the ball rolling if it helps.... I am an ex developer, but my hey day is well and truly behind me... so I can only contribute with what I'm good at... the logic and the extensibility / rationale... which means I have to get significant buy in from a developer to help make it happen.

And this certainly isn't a criticism of all the work that's gone in so far.... just a guy feeling it's been worked and worked to the point that its gotten a little TOO flexible... bulking up the code and leaving the end users so spoilt for choice they can't make it work, and of course we're seeing skinners being creative, but in a skin specific way!


Cheers,
The Kid
find quote
jmarshall Offline
Team-XBMC Developer
Posts: 26,228
Joined: Oct 2003
Reputation: 177
Post: #12
I'm busy researching the new video library. This is gonna be quite a while.

Others may be available to work on this. It is certainly something I'll bring up at devcon in 3 weeks time.

Cheers,
Jonathan

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #13
Marvellous...

If there's no objection, I'll write down some of my thoughts in this forum - I'm not expecting any to be acted upon, but it might later be used as a basis for some structured decision making.

(Anybody's welcome to add their own thoughts, but I just figure whoever codes it will have a much easier job if some hard thought has already been done and documented before hand).

(just a tad nervous of pi**ing off developers with a perceived condescending wishlist)
find quote
bidossessi Offline
Senior Member
Posts: 216
Joined: May 2009
Reputation: 0
Location: Algiers
Post: #14
@AnalogKid
I, for one, second your opinion, but i believe this subject really becomes important in a 'NAS-style' storage schema. And i think the Unified Media Manager should be able to solve that issue.
the fact that XBMC can handle several storage scenarios is a plus imho, and something that should be kept, but users should be encouraged to adhere to "media storage best practices" conventionally decided on a sticky somewhere in the forum; which practices could then be enforced by the aforementioned UMM.

Just my 2cents Smile

openSUSE 11.2 | SVN XBMC
I'm... dreaming... of a quiet... HTPC
find quote
AnalogKid Offline
Fan
Posts: 648
Joined: Feb 2009
Reputation: 141
Post: #15
ok, here's my initial stab at detailing some of the issues with art (fanart and thumbs etc).
Also I'm detailed some logical (imo) proposals to rectify them.


The fact that artwork can be specified in a number of naming forms would appear to be a good thing at first inspection, but we can see from the forums and scrapers that it's adding complexity to XBMC that probably doesn't need to be there. In addition, this can only increase the code complexity of XBMC also. We have some naming schemas that work in hierarchical systems only, and others that will work in flat or hierarchical. We also have NO way to work with portrait AND landscape artwork schemes simultaneously.

Suggested solution
Artwork MUST be unambiguously named, so that no matter where the artwork exists, it can easily be attributed to the associated media.

A suggested naming convention is given below:


<moviename>.moviefanart.landscape
<moviename>.moviefanart.portrait
<moviename>.moviecoverart.landscape
<moviename>.moviecoverart.portrait
<moviename>.movieframegrab.<n>

<tvshow>.tvshowfanart.landscape
<tvshow>.tvshowfanart.portrait
<tvshow>.<season>.tvshowfanart.landscape
<tvshow>.<season>.tvshowfanart.portrait
<tvshow>.<season>.<episode>.tvshowfanart.landscape
<tvshow>.<season>.<episode>.tvshowfanart.portrait
<tvshow>.tvshowcoverart.landscape
<tvshow>.tvshowcoverart.portrait
<tvshow>.<season>.tvshowcoverart.portrait
<tvshow>.<season>.tvshowcoverart.landscape
<tvshow>.<season>.<episode>.tvshowcoverart.portrait
<tvshow>.<season>.<episode>.tvshowcoverart.landscape
<tvshow>.tvshowframegrab.<n>
<tvshow>.<season>.tvshowframegrab.<n>
<tvshow>.<season>.<episode>.tvshowframegrab.<n>

<artist>.musicfanart.landscape
<artist>.musicfanart.portrait
<artist>.<album>.musicfanart.landscape
<artist>.<album>.musicfanart.portrait
<artist>.<album>.<track>.musicfanart.landscape
<artist>.<album>.<track>.musicfanart.portrait
<artist>.musiccoverart
<artist>.<album>.musiccoverart
<artist>.<album>.<track>.musiccoverart



What are the advantages of this schema?

1) The naming is COMPLETELY unambiguous and predictable
2) The files can exist ANYWHERE on a system (hierarchical, flat, even in a totally different folder or server)
3) For compilation albums where an artist exists on the album, but has no album of their own.... the artwork for that artist can still be discovered.
4) For the new skins that are using a mix of portrait and landscape artwork it's possible to switch skins WITHOUT having to reconfigure artwork (providing the user has provided both orientations)
5) The naming convention is hierarchical, so it's easy to figure that if there isn't an image at say episode level, one might exist for the season, or even the *show level.... so it's pretty granular(even though most skins do not support that level of granularity YET)
6) It's extensible.... so for instance, one day, it might be possible to have multiple fanarts for a movie..and cycle between them just by adding a .<n> suffix
7) It's relatively simple for existence user to port their art to the new format... a script would be easy to write to do this.... so any transition pain would be minimised.



Surely this would massively ease the burden on XBMC and scrapers... however, as far as I know, there would have to be a new API for skinners to use to specifically request portrait or landscape art (with legacy skins supported in the traditional way... with a default of portrait for thumbs and landscape for fanart).

I have also taken into account the possibility at some point some skins MIGHT want fanart and coverart even down to episode and track level. Nobody HAS to use them!

I would be very interested to hear feedback on this proposal....
find quote
Post Reply