Hi,
I have been using MySql with XBMC for about 18months now. When I upgraded to 12.1, I created fresh DB/Clean install on all of my devices.
I have a windows PC (Main XBMC) and 2 ATV2's.
I recently added a Raspberry Pi with OpenElec 3.0, and copied my advancedsettings.xml and sources.xml to the userdata folder.
On the Raspberry Pi I can see all my programs, watched, synopsys etc, however the Thumbnails are not showing (This is working fine on both ATV2's and the Windows PC).
I have been hunting for answers, but everything I have found refers to upgrading from Eden, and I am not too keen on dropping the DB and starting again.
I am a bit of a rookie when it comes to MySQL, I initially set it up using the guide in the Wiki. Can someone please help?
Try forcing the artwork cache to update by deleting
userdata (wiki)/database/Textures13.db
Thanks for your reply.
Is this something I should do on only the Raspberry Pi or on all of my XBMC instances?
Only do the problem one.
If that doesn't work delete thumbnails folder and the texture13.db from the Pi. Then copy those same ones from your main computer and paste where they were. Then reboot the Pi and you should be done.
At least that is what I did on all of mine
Raspberry Pi. That file keeps track of what artwork has been cached, so if it's missing then XBMC will force itself to look for and download the artwork for that specific device.
XBMC will check on its own every so often, but sometimes it takes a few days. Most of the time it seems to catch new stuff right away, so only later changes to art should take longer, but I'm not sure exactly how it works. Deleting textures13.db is a quick and dirty way (but safe) to force it to cache everything right now.
(2013-04-12, 02:26)Ned Scott Wrote: [ -> ]Raspberry Pi. That file keeps track of what artwork has been cached, so if it's missing then XBMC will force itself to look for and download the artwork for that specific device.
XBMC will check on its own every so often, but sometimes it takes a few days. Most of the time it seems to catch new stuff right away, so only later changes to art should take longer, but I'm not sure exactly how it works. Deleting textures13.db is a quick and dirty way (but safe) to force it to cache everything right now.
Thanks, I will give it a go tonight
You can use
this utility to query your texture cache (j options - perhaps determine if your Pi is trying to access inaccessible sources), even force it to re-cache (C option). Only delete the entire Textures13.db/Thumbnails as a last resort.
For instance to view the artwork details for Avatar, run:
Code:
./texturecache.py jd movies avatar
then look at the various artwork urls - are they valid from the perspective of the Pi?
To force the re-caching of all Avatar related artwork:
Code:
./texturecache.py C movies avatar
Should the Avatar artwork not be successfully cached, look in the xbmc debug log for possible reasons why.
(2013-04-12, 02:25)Tight_wad Wrote: [ -> ]Only do the problem one.
If that doesn't work delete thumbnails folder and the texture13.db from the Pi. Then copy those same ones from your main computer and paste where they were. Then reboot the Pi and you should be done.
At least that is what I did on all of mine
Problem here is that the Pi may be (in fact, most likely is) using different fanart/imagres resolutions for converted artwork, so it may still have to resize the cached artwork eventually (and until such time, it will be using sub-optimal artwork which may result in perform problems). Plus your main computer may be using DDS files which are not supported by default on Pis, so you've just cluttering up your Thumbnails folder unnecessarily.
If you want to pre-populate the texture cache on a Pi, use the script I've linked to above, this way there will be no problems with fanart/imageres mismatches. It might take a bit longer than a copy & paste, but at least it will be 100% spot on...
(2013-04-11, 13:37)Ned Scott Wrote: [ -> ]Try forcing the artwork cache to update by deleting userdata (wiki)/database/Textures13.db
(2013-04-12, 02:26)Ned Scott Wrote: [ -> ]Raspberry Pi. That file keeps track of what artwork has been cached, so if it's missing then XBMC will force itself to look for and download the artwork for that specific device.
XBMC will check on its own every so often, but sometimes it takes a few days. Most of the time it seems to catch new stuff right away, so only later changes to art should take longer, but I'm not sure exactly how it works. Deleting textures13.db is a quick and dirty way (but safe) to force it to cache everything right now.
Being the simpliest option, this is what I tried, and it worked a treat! Thanks for your help!
Glad you got it sorted, shame we'll never know what the problem was.
(2013-04-14, 01:19)MilhouseVH Wrote: [ -> ]Glad you got it sorted, shame we'll never know what the problem was.
Admittedly, I just wanted a quick fix for the Pi.
This had previously happened on one of my ATV2's, and I haven't resolved it yet. I think it happened when I went from 12.0 to 12.1, but that still doesn't explain why this happened. Am I right is assuming that your utility will work on iOS?
(2013-04-14, 02:44)alpha160a Wrote: [ -> ]Am I right is assuming that your utility will work on iOS?
Should do, as long as it has Python 2.7.3 or later.