[Milhouse]

That's a lot of errors... What kind of images are failing? Embedded images (eg. image://video@nfs etc.) are a known problem but by default they should be ignored (cache.ignore.types property). Some web sites might be limiting concurrent downloads, but with only 2 threads that shouldn't be a problem.

The script is asking XBMC to perform the actual download, so any communication errors will be logged in the XBMC log file. The script (if you enable logging for texturecache.py) will only report that it wasn't able to download an image from XBMC, it won't know why as only XBMC knows that for sure.

By the way, what version of XBMC are you running on your iMac - I noticed in the log you posted that you're running v6.5.2 of the JSON API, which would suggest a fairy recent Gotham build and might explain the difference between your system and mine with respect to those empty folders (I'm still running Frodo 12.2, with JSON API v6.0.3).

[wishie]

Never thought I'd be so happy to get 0 output from a command:

localhost:temp wishie$ ./texturecache.py missing tvshows "TVShows"
localhost:temp wishie$ ./texturecache.py missing movies "Movies"
localhost:temp wishie$

Now to just check the artwork is all ok, then rejoice!

---

Yes I'm running a recent nightly... I didn't really want to, but since I use my iMac for development, its currently running OS X 10.9 DP2.. Frodo 12.2 doesn't run on it, so I needed to move to a nightly. I have installed the same build (except of course for ATV2) on the ATV2's.

As for artwork, Ive got it down to the following on my iMac:

localhost:temp wishie$ ./texturecache.py c movies
Need to cache: [ fanart ] for movie: Happythankyoumoreplease
Need to cache: [ poster ] for movie: Happythankyoumoreplease

Caching artwork: 0 items remaining of 2 (s: 0, m: 0), 2 errors, 2 threads active (03.66 downloads per second, ETA: 00:00:00)

The following items could not be downloaded:

[poster ] [Happythankyoumoreplease ] image://nfs://192.168.1.10/mnt/user/Movies/Happythankyoumoreplease (2011)/Happythankyoumoreplease .2011.DvDRip.x264.Feel-Free-poster.jpg/
[fanart ] [Happythankyoumoreplease ] image://nfs://192.168.1.10/mnt/user/Movies/Happythankyoumoreplease (2011)/Happythankyoumoreplease .2011.DvDRip.x264.Feel-Free-fanart.jpg/

Cache pre-load activity summary for "movies":

| fanart | poster | thumb | TOTAL
--------------+-------------+-------------+-------------+-------------
Cached | - | - | - | 0
Deleted | - | - | - | 0
Duplicate | 53 | 46 | - | 99
Error | 1 | 1 | - | 2
Ignored | - | - | - | 0
Skipped | 1535 | 1556 | 30 | 3121
Undefined | - | - | - | 0
======================================================================
TOTAL | 1589 | 1603 | 30 | 3222
Download Time | 00:00:00.41 | 00:00:00.40 | - | 00:00:00.41

Threads Used: 2
Min/Avg/Max: 2.44 / 3.66 / 4.87

Loading: 00:00:03.60
Parsing: 00:00:00.05
Comparing: 00:00:00.86
Downloading: 00:00:01.00
TOTAL RUNTIME: 00:00:05.54



NOTE: I fixed the above error by removing the bad filenames and images for that movie, and rescraping it into the database


As for the ATV2's, I will try with them again later.

[fnwc]

Thanks for writing this, MilhouseVH. This solves a lot of my problems when I'm trying to refresh non-standard images (such as TV season fanart).

[Ned Scott]

Kept meaning to do this before, but made a wiki page for this to list it with the other supplementary tools: Texture Cache Maintenance (wiki). Feel free to do with the page as you wish.

[wishie]

Well, I ended up getting it all sorted on the ATV2, but now I have a new toy.. a RaspberryPi running OpenELEC..

I seem to be getting errors for every image download attempt.. here is a log file excerpt:

http://pastebin.com/N7yQE6Dp

Thanks in advance

[Milhouse]

Kept meaning to do this before, but made a wiki page for this to list it with the other supplementary tools: Texture Cache Maintenance (wiki). Feel free to do with the page as you wish.

That's excellent Ned, many thanks!

---

Well, I ended up getting it all sorted on the ATV2, but now I have a new toy.. a RaspberryPi running OpenELEC..

I seem to be getting errors for every image download attempt.. here is a log file excerpt:

http://pastebin.com/N7yQE6Dp

Thanks in advance

Hmmm... Have you enabled the web server in XBMC? Is your Pi connected to the internet? Can you check your XBMC log for errors?

[wishie]

Webserver is enabled, JSONRPC is enabled.. Checking out XBMC logs now, here is an excerpt:

http://pastebin.com/qfKYps7h


Code 28 = CURLE_OPERATION_TIMEDOUT (28)

Seems strange. Internet is working on the box. WLAN is working well.

Testing on the cmdline it seems like the machine is taking a long time to resolve IPs.. something DNS related maybe?

I have just added cf2.imgobject.com to my hosts file, so save the machine doing that DNS request. Checking now to see if that helps.

[wishie]

That seems to have helped ALOT. I am still getting some errors, but most downloads are succeeding now.. Now to figure out why DNS lookups are taking so long, causing CURL to time out

[Milhouse]

Yes, DNS resolution seems to be a problem that several people have experienced, if you find a cause it would be useful to know. Adding hosts manually is a temporary workaround, but certainly not a permanent fix! As to a cause, maybe there's a problem with UDP on your network?

I run a headless Pi with Raspbian for my network services, using dnsmasq for DHCP/DNS and have no problems so if it's an incompatibility with your ISP router (which I'm assuming is also handling DHCP) then that might be one possible solution. Manually setting your DNS to avoid your router might also help (try 8.8.8.8 and 4.4.4.4 for Google DNS).

[wishie]

I will give those a go once this run of the script finishes.. I will keep you updated, thanks

[wishie]

So the issue ended up being related to WiFi, but not in the usual way..

Basically, I noticed that doing a DNS lookup to *any* external name server was taking roughly 5 seconds.. This is WAY too long, and XBMC gives up long before that..

Now, while my RPi was working perfectly well for pings/downloads/uploads etc, it seemed to be failing hard on DNS (UDP) stuff. My WiFi N USB adapter was basically dropping a LOT of packets whenever doing UDP lookups.. TCP stuff seemed to go through without issue. I haven't found the actual cause for this yet though. I have the RPi plugged in via ethernet while I do the texturecache.py run. Once its complete, Ill test with the RPi next to the router, over WiFi and see if that makes a difference.

The fact it only seemed to be dropping UDP stuff is what confuses me.

[Milhouse]

Version 0.8.7

• Add: .strm to default non-media files for missing option
  
• Add: Pre-delete artwork before starting download threads. Cache deletion functionality can now occur in the main thread to prevent database locking when accessing Textures13.db via a mounted filesystem. Pre-deletion will be the default if a mounted filesystem is detected. Disable/Enable with download.predelete=yesno. When disabled, deletions will take place in each download thread, but this may cause SQLite locks depending on the locking protocol used by the network filesystem (SMB/CIFS seems particularly prone to this problem, NFS less so). Should not be required for local file systems.
  
• Add: Artwork (payload) download is now optional when caching, as Files.PrepareDownload appears to be sufficient to populate the cache, rendering the actual download superfluous. Re-enable with download.payload=yes.
  
• Chg: Modify retry behaviour of failed artwork downloads - previously retried download 10 times, which is a little excessive. Specify number of retries (both Files.PrepareDownload and/or payload download) with download.retry=n. Default is now 3.
  

[CaptainKen]

Please explain what I'm doing wrong as none of the commands are working.

[Milhouse]

You should be able to run the script without entering Python, as the script should find the Python interpreter and use it automatically.

The following should work:

Code:

C:\Python27\texturecache.py config

[CaptainKen]

Still no luck.