[j114]

I don't have any shows split across multiple locations, which would explain why I am having different results than you. Do you have ALL of the artwork for each show at each location, or one location has all of the show specific art?

Does sounds weird, either way, just curious if the trigger is strictly having multiple locations, or if it's related to how your art is stored.

[xexe]

I don't have any artwork at all beside the video files. I allow XBMC to scrape the internet solely.

I suspect this could be a bug as a similar sounding issue can be seen here:

Thumbs missing in music library for items that exist multiple times
http://trac.xbmc.org/ticket/13588

[jmarshall]

1. Revert everything to Eden (delete Textures13.db, delete any video database > v60)
2. Update and check the Debug Log as you go. Episodes should definitely get art available to them.

I don't care about multipath tvshows having weirdness once you have updated correctly (there's known issues with shows from multipath sources that Eden had as well and will not be fixed in Frodo either). I care about it updating correctly first and displaying correctly in the library.

If there's a bug with episode art updating I need to know what it is so I can fix it.

Cheers,
Jonathan

[xexe]

jmarshall morning. I have been keeping an eye out for you in IRC for a while but have always missed you.

I have OpenELEC virtual setup side by side with Eden and can condocut any tests you need. Ping me with (xe) specifics as i have completed "Update and check the debug log as you go" several times now with different setups never with 100% results.

[xexe]

A small update.

I have tried to solve this issue by trying various options. The last attempt i made was using "XBMCSetup-20121129-e092099-master.exe" just in case it is a platform problem.

Using windows the process took appropriately the same time and reported to complete successfully however the end result is no art at all seen in the library.

I am half convinced this is an edge case problem caused by either my large library or the fact I have managed to upgrade and keep the same library for a long time (several XBMC versions).

Unless anyone has any insight I am going to abandon this effort and move to recreating the dbase from scratch and importing play count and watch status.

[jmarshall]

Do not abandon it.

If it's to be fixed, I need cases like this.

You can build yourself, right? So add a bunch of logging to xbmc/utils/EdenVideoArtUpdater.cpp and we can figure out what is going on.

[Martijn]

Or perhaps you could provide us the userdata folder so we can try ourselves to see what happens. Although that will probably be huge.

[xexe]

Thanks for the support. Give me a small while I am currently looking at some OpenELEC specific things. So much happening this now it is hard to keep up.

ta

[xexe]

Update.

Whilst looking into: http://trac.xbmc.org/ticket/13638

It seems that there are quite a few difference between my sql database that has been upgraded and one that is created new.

Most differences are related to:

upgraded (latin1_swedish_ci)
created new (utf8_general_ci).

However there are others such as:


upgraded (`strFileName` VARCHAR(512) NULL DEFAULT NULL COLLATE 'latin1_swedish_ci',)
created new (`strFileName` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',)

This could explain quite a bit

[jmarshall]

The collation stuff suggests that your db didn't get updated pre-Eden (about v43 I think it was).

That shouldn't really be an issue though, or at least I don't think it will be - the only thing we take from the database here is the <thumb> stuff and the paths, so the only possibly problem would be really, really long filenames (512 chars is very long).

Cheers,
Jonathan

[xexe]

...That shouldn't really be an issue though, or at least I don't think it will be - the only thing we take from the database here is the <thumb> stuff and the paths, so the only possibly problem would be really, really long filenames (512 chars is very long)....

True. However 512 is not very long when you take into account stacking and miltipath and url encoding.

Saying that it seems the longest I have in my non test v60 (and coresponding v74) database is:

path/srPath = 228 characters
files/strFilename = 416 characters

so whilst this may be interesting it likely isnt the direct issue. Since I seem to have an edge case problem (where everyone else upgrade seems to work flawlessly) perhaps something else is broken as well.

It is worth noting I have managed to maintain this mysql database from the very early initial days of mysql support until now so it has been through most upgrades.

Separately I am going to create a new install scanning the same source data but using a clean nightly install to see if i can remove a few of these gotchas and still recreate any art problems.

I cant match it 1:1 this now since I believe the IMDB scraper addon is still broken but I can work on the TV section

[henrike_]

I have a question on how XBMC-clients decides what art to download.

example:
- 2 clients with shared mysql-database

1. client 1 scrapes new movie into database
2. library ends up with 2 different fanarts for that movie in "art" table. (media_type = "fanart")
3. which of the 2 available fanarts will client 2 download?

I have tried to find out if it even is supported to have 2 different fanarts for one movie in the "art" table, but with no luck.

With the new sync in Frodo, my question ultimately is if it is supported/possible to have different fanart on each client but with shared mysql-database?

[Ned Scott]

Why would it have two different entries for fanart? Each episode/movie should only have one fanart entry. If you change the fanart on one client then the other client will eventually (once every X number of hours) check the database and change the fanart there too.

[henrike_]

Why would it have two different entries for fanart? Each episode/movie should only have one fanart entry. If you change the fanart on one client then the other client will eventually (once every X number of hours) check the database and change the fanart there too.

I am trying to understand how the new art-table is supposed to work, because I am building a stand-alone scraper that runs on my NAS so that all clients always are updated with new content on the NAS.
And to to avoid racing-conditions if 2 clients tries to scrape the same new movie (if they are started at the same time)
And third to skip all scanning of new content, which takes a while on big libraries.

So the art-table is only supposed to have ONE entry for each media_type for each movie/episode?

Possible improvements would be to allow multiple, and add options to choose which to use, but by default take first hit.

Since all different fanarts are stored in c20 in the movie-table, my first thought was that the art-table was replacing the column c20, but that seems not to be the case.

[supahfly]

Well yes, if you put no symlink from your thumbnails folder to your NAS, all fanart will be stored locally on the client itself.
But this is the case as well now in Eden already if I am not mistaking.
The difference lies within the scraping part. But I am also still confused a little with both setups concerning this ....