Shouldn't thumb.ext be landscape.ext in XBMC compatibility mode

[cracksloth 28]

I might be missing something but shouldn't "thumb.ext" be renamed "landscape.ext" when using XBMC compatibility mode?

[Luke 42077]

@@sfnetwork

[Luke 42077]

please be more specific with an example - are we talking movies, series, seasons, artists, albums, or everything?

[cracksloth 28]

My apologies - specifically movies. I have not delved into the others yet so cannot speak to whether they are also effected.

[sfnetwork 514]

thumb.ext is a thumb which is different from a backdrop (fanart.jpg)

 

Thumb:

 

Backdrop (fanart.jpg):

[sfnetwork 514]

same example for movie:

 

Thumb:

 

Backdrop:

[cracksloth 28]

Yes but I am speaking of landscape.ext not fanart.ext.

http://wiki.xbmc.org/index.php?title=Add-on:Artwork_Downloader

They seem to be the same scraped image.

[Luke 42077]

and what is landscape.ext?

[cracksloth 28]

it is the MB3 equivalent of thumb.ext

[sfnetwork 514]

Yes but I am speaking of landscape.ext not fanart.ext.

http://wiki.xbmc.org/index.php?title=Add-on:Artwork_Downloader

They seem to be the same scraped image.

I see, in this example, it uses landscape.ext for thumbs...

Still, XBMC Frodo reads thumb.jpg (which is what MB XBMC saver creates)...

So I guess both work in XBMC...

Edited December 21, 2013 by sfnetwork

[Luke 42077]

Yea i think I originally had it saving as landscape but in your testing you had me change it back

[sfnetwork 514]

I'll do more tests to confirm anyway later.

But if XBMC reads thumb.jpg as thumb, there is no point of changing anything IMO...

 

Anyway, I'll confirm later...

[sfnetwork 514]

Yea i think I originally had it saving as landscape but in your testing you had me change it back

I think you are confusing with backdrop.jpg (changed to fanart.jpg) BTW (if I'm not the one confused here lol)

Edited December 21, 2013 by sfnetwork

[Luke 42077]

Yea I think I am confused. In any event, can you test it out and let me know if anything should be changed? Thanks.

[cracksloth 28]

I can work with that - I just am trying to cut down on the number of duplicate images.  Ideally in my mind, the files would be named such that scrapers (whether run from XBMC or MB3) would not download duplicates. For now, I'll just delete all landscapes.

[sfnetwork 514]

Yea I think I am confused. In any event, can you test it out and let me know if anything should be changed? Thanks.

yeah, I'll do this soon and report back.

[sfnetwork 514]

I can work with that - I just am trying to cut down on the number of duplicate images.  Ideally in my mind, the files would be named such that scrapers (whether run from XBMC or MB3) would not download duplicates. For now, I'll just delete all landscapes.

If you're using MB server to generate the image files with xbmc saver), the only reason to use artwork donwloader (IMO) is, with the option "local files" to only add the images to XBMC database (if using centralized SQL environment like logos, etc.. for other XBMC that didn't run the library updates).

Edited December 21, 2013 by sfnetwork

[Luke 42077]

if landscape is an alias for thumb then i can add that so that we don't download a duplicate.

[sfnetwork 514]

if landscape is an alias for thumb then i can add that so that we don't download a duplicate.

yeah, pretty sure that will be the conclusion... if MB server can read thumb.jpg and landscape.jpg as thumbs, and avoid conflicts (duplicates), that should make everyone happy (but wait until I can really confirm it....not home yet)

Edited December 21, 2013 by sfnetwork

[cracksloth 28]

I certainly think that would work, but wouldn't it be preferable for XBMC compatibility mode to adopt the default naming conventions that its scrapers use? Currently, there are a few examples where even in XBMC compatibility mode, MB3 will opt for a compatible naming convention but not the default naming convention which introduces naming inconsistencies into a collection (and by extension a potential for duplicates which otherwise would not have existed).  In my mind, adopting the default naming convention offers the greatest interoperability and simplicity in the long run for users.

[Luke 42077]

Yes it would be, but how you define default? The article you linked to is coming from an add-on, not the official xbmc documentation. then the xbmc docs are not even up to date because some of the image file names listed haven't worked and xbmc users have confirmed it. So what is the default? (I don't want you to tell me, I want to read some xbmc documentation, and then actually have it work when we go to test and verify).

[sfnetwork 514]

It follows the XBMC Frodo naming convention and doesn't seem to be different from what Arwork downloader creates... Besides thumbs (based on the addon)

And the saver should rely on XBMC naming convention mainly, not an extra fetcher addon.

 

Still, I think as for the supported files that MB server reads, we can add the ones created by the artwork downloader (for the few different ones) so that it won't create duplicates. But as for the saver plugin, as long as it's officially supported and works in XBMC, I don't see why we should change it.

[sfnetwork 514]

Yes it would be, but how you define default? The article you linked to is coming from an add-on, not the official xbmc documentation. then the xbmc docs are not even up to date because some of the image file names listed haven't worked and xbmc users have confirmed it. So what is the default? (I don't want you to tell me, I want to read some xbmc documentation, and then actually have it work when we go to test and verify).

We follow 100% Frodo standards: http://wiki.xbmc.org/index.php?title=Frodo_FAQ#Local_images

 

Thumbs aren't mentioned so it's not official I guess.

Still thumb.jpg works fine.

But if landscape.ext also work, we can simply add it as "supported thumb file name" in MB saver to avoid duplicates...

[cracksloth 28]

Given the state of XBMC documentation, I would encourage adopting a more real world definition of what the default is because in the end, it's the names XBMC uses when "exporting the library" that will define what people really have on their harddrives.  But i appreciate that this is a difficult problem.

[sfnetwork 514]

Just to chime in on this, I've had issues with skins trying to use the thumb.jpg image instead of poster.jpg. I posted in the XBMC forms here for a specific skin thread,

 

(http://forum.xbmc.org/showthread.php?tid=139712&pid=1564810#pid1564810)

 

but the response was "This is because Aeon Nox uses ListItem.Art(poster) for their image where as Immersive uses the all-inclusive ListItem.Thumb." 

 

I just wanted to pass this information along to see if it helps in determining where to go next. It seems that Mediabrowser would want to use the all-inclusive naming, as I've had the same issue on a few xbmc skins, but I'm not sure if this would be a better option down the road

This is skin specific... Other skins (like Ace and MQ5) don't have this issue. It all depends on how they call their images I guess.

I had those issues in the past but I only had (moviefilename)-poster.jpg and folder.jpg. With those, thumb.jpg will take over.

 

But I'll do some test with this skin (Immersive). It peaked my interest 

I'll also test changing to landscape.ext (the thumbs)

Edited December 26, 2013 by sfnetwork