Upgrade to XBMC 13 has binned my fanart
#1
Hi,

Upgrade to 13 has gone well mostly - I use a shared mysql database and was using profile redirected thumbs before the 13 upgrade, but decided to copy the thumbs and textures onto the local PC and do away with redirected thumbs.

All has gone well, except that after opening, and going into the music library, XBMC said it needed to update the tags in my music library. I said yes, and now it's going through and removing all my fanart, one by one.

It seems like XBMC knows there should be fanart there, (I'm using transparency at the moment) It doesn't show the default 'you have no fanart so I'll display this image instead' image, it shows a predominanrly black background.

Where has my fanart gone?!
Reply
#2
Anyone help me with this? All the little logo thumbnails for artists stay, it just gets rid of all fanart, regardless of skin.
Reply
#3
You likely have stale links in the textures database. You could try renaming the latest version of Textures**.db in userdata/Database
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
Reply
#4
Thanks I'll try that. How do I make XBMC re-download fanart once the textures file is removed?
Reply
#5
Right I think I've found the problem.

I got myself a copy of MySQL workbench and had a rummage through a newly created database, soon homing in on the 'art' table.

It appears that XBMC is creating an incorrect path to fanart and I've no idea why.

Here's an example of a line that correctly maps a thumb for an album

'43', '22', 'album', 'thumb', 'smb://<username>@<ip address>/albums/Beth Orton - Trailer Park/folder.jpg'


The albums are stored on a network share, (in)secured simply by a username. It's getting that path from a shared sources.xml file. It references the server directly by IP address, rather than server name, as I have no internal DNS or WINS servers and this databaae is shared with a Pi, that sometimes struggles to resolve names.

Anyway that's an aside - the line above is good and, sure enough, thumbnails appear without issue in the database.

Obviusly that refers to a jpg picked up locally so here's a row for an artist thumb that it's picked up from an external source.

'48', '17', 'artist', 'thumb', 'http://assets.fanart.tv/fanart/music/87c5dedd-371d-4a53-9f7f-80522fb7f3cb/artistthumb/bjrk-4ff4117ff3585.jpg'


For fanart it's a different story. Here's a db row for a fanart reference

'44', '16', 'artist', 'fanart', 'smb://<servername>'


So what you're noticing here, of course, is no actual path is stored - just the name - NOT the IP address - of the server. This is consistent throughout the 'art' table. Every line that references fanart simply stores the name of the server and nothing else.

Here's the line from the shared sources.xml that links to the albums share

<source>
<name>albums</name>
<path pathversion="1">smb://<username>@<ip address>/albums/</path>
</source>

Again edited but you get the idea.

It also appears as a location in mediasources.xml

<location id="1">smb://<username>@<ip address>/albums</location>

And all this redirecting is done in a relatively small advancedsettings.xml that has 2 entries at the top for the mysql databases, Here's the line that substitutes sources.xml as an example No surprises.

<substitute>
<from>special://profile/sources.xml</from>
<to>smb://<username>@<ip address>/XBMCData/sources.xml</to>
</substitute>

So how and why is this happening and why doesn't if affect anyone else. I can consistently recreate it with brand new profiles. The albums share contains nothing but folders, media files and folder.jpg thumbnail files from a previous XBMC library export. There are no info files or fanart.jpgs.

Please help!
Reply
#6
I dunno why it would think you have fanart at that URL. There's nowhere I can see where it checks for an image where it's not actually an image.

I'd refresh the information for that artist, and if prompted, tell it to ignore all local information and see what happens.
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
Reply
#7
That works and it will download the fanart and store it correctly.

I don't want to do it for hundreds of artsists though.

Having taken XBMC's sensible advice of backing up my 32 database before the upgrade, I restored it last night to have a look.

In that database, all the fanart entries have true working paths.

So upgrading and then 'updating tags' as XBMC insisted on doing on its first run, has binned all my fanart, placing in its stead paths that it seems to have invented itself.
Reply
#8
The rescan is a rescan. It doesn't make any difference at all whether you start with an existing database or start fresh in that regard.

The trick is figuring out where those URLs come from. When you refreshed the artist, what happens if you don't tell it to ignore local information (assuming that is an option?)

At any rate, what you may want to do is just remove the database completely and rescan from scratch and see if the same thing happens. If so, we can get it reproducible and fix the fault.
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
Reply
#9
It doesn't ask about using local.

I've started afresh with a totally fresh profile and database a couple of times and it happens every time. The weird thing, and the thing I'm focussing on at the moment, is it only fails for one share - I scan 2 shares, both from the same server with the same access credentials into the XBMC database - albums and compilations.

Compilations works fine - all the different artists from all the different compilations (well the ones it can find fanart for anyway) get their fanart and display it without exception.

Apart from the name, I simply can't tell any difference between the two shares. I've even tried copying the entire albums folder, giving it a different name, a new share, deleting all the folder.jpgs from it but to no avail - issues still persist.

I've done a bit of debug logging - here are a few lines that suggest an issue. I've left a couple of lines either side for context.

Tired of swapping out server names and IPs so 5.2 is the server that holds the music shares, MySQL server and shared, substituted profile files. Its computer name is bigbox and it's Windows Server 2012. This XBMC is running on Windows 8.1 connected over a 1gb wired network. I haven't introduced other networked XBMC devices into the equation yet, want to get it working on this one first, as I intend to have this machine running library updates, and other slower devices sharing the resulting library database.

My guess is it's not correctly parsing an smb:// address that contains a username but no password.

Quote:09:14:59 T:2952 DEBUG: Mysql execute: DELETE FROM discography WHERE idArtist = 11
09:14:59 T:2952 DEBUG: Mysql execute: INSERT INTO discography (idArtist, strAlbum, strYear) values(11, 'Sequel to the Prequel', '2013')
09:14:59 T:2952 DEBUG: Mysql execute: INSERT INTO discography (idArtist, strAlbum, strYear) values(11, 'Shotter\'s Nation', '2007')
09:14:59 T:2952 DEBUG: Mysql execute: INSERT INTO discography (idArtist, strAlbum, strYear) values(11, 'Down in Albion', '2005')
09:15:29 T:4356 INFO: XCURL:Big GrinllLibCurlGlobal::CheckIdle - Closing session to http://search.musicbrainz.org (easy=03BC8858, multi=03B8A6F0)
09:15:31 T:2952 DEBUG: Trying to connect to \\192.168.5.2 with username(TV) and password(XXXX)
09:15:31 T:2952 ERROR: XFILE::CDirectory::GetDirectory - Unhandled exception
09:15:31 T:2952 ERROR: XFILE::CDirectory::GetDirectory - Error getting smb://[email protected]/
09:15:31 T:132 NOTICE: Thread JobWorker start, auto delete: true
09:15:31 T:2952 DEBUG: Mysql execute: UPDATE art SET url='smb://BIGBOX' where art_id=27
09:15:31 T:132 DEBUG: CTextureCacheJob::GetImageHash - unable to stat url smb://BIGBOX
09:15:31 T:2952 DEBUG: Mysql execute: INSERT INTO art(media_id, media_type, type, url) VALUES (11, 'artist', 'thumb', 'http://assets.fanart.tv/fanart/music/8e1e03fe-ebbc-467a-b541-857144db10fb/artistthumb/babyshambles-50e600739fe2b.jpg')
09:15:31 T:2952 DEBUG: Mysql execute: update path set strHash='D49CDC7BC8D4072A58C5531382477AB6' where idPath=16
Reply
#10
What do you have in advancedsettings.xml ? Please pastebin that.
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
Reply
#11
The m3u thing at the bottom was a Yatse thing for the pi - sending m3u playlists from Yatse resulted in XBMC trying to open them as photos.

http://xbmclogs.com/show.php?id=204322
Reply
#12
Can we get a bit more of a Debug Log? I can't seem to figure out exactly what paths it's trying to query.

Additional detail that would be useful is what is on smb://BIGBOX and what exactly (from root to songs) are the paths of the songs of an artist that shows this behaviour?

I think what is happening is it's going up too many directory layers and then accidentally hitting a weird case where you get an empty string match, but until I can reproduce it won't be able to do much about it.

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
Reply
#13
I'll get on with that now. bigbox has a share called albums on it. The albums folder shared simply has folders called artist - album name, with the media files stored within that folder.

I connected up the Pi, running OpenELEC 4.01 so roughly the same XBMC version and a library update on there put smb://WORKGROUP in the fanart field. Weird hey?

I'm wondering if something in mediasources.xml is throwing it, I'm going to clear that file temporarily.

The really weird thing is another share on the same server with the same folder structure - compiltations - works perfectly.

I'll get some logs together.
Reply
#14
OK here we go. As simple as I can make it - brand new XBMC profile folder, brand new database. Mediasources.xml is empty, sources.xml just has a few links to the BIGBOX server (internal address 5.2). Ran XBMC, enabled debugging, checked 'download additional info' in music library settings, closed, opened again and here's the resulting log.

After it had put a few of the erroneous messages in the mysql database I just grabbed the debug.log and uploaded it. There should be enough logging in there - let me know if you need more.

http://xbmclogs.com/show.php?id=205080
Reply
#15
I've tried this again in RC1 and the problem is still there. It is independent of scrapers too - same thing happens with theaudiodb.
Reply

Logout Mark Read Team Forum Stats Members Help
Upgrade to XBMC 13 has binned my fanart0