[Milhouse]

since movieset art set/change is a manual process in the GUI, and one whose changes do not propagate to other clients via shared mysql db, can texturecache.py be used to set the art (specifically that used in Movies/Thumbnail view) for all existing moviesets to a single /path/to/image.png?

The changes to Movie Sets most certainly do "propagate" to other clients in a shared MySQL setup.

You could use texturecache.py to set your Movie Sets artwork, but you're most likely better off using the Movie Sets Artwork Addon.

[hanlon]

The changes to Movie Sets most certainly do "propagate" to other clients in a shared MySQL setup.

The MovieSet's name, and its members, yes.

Not the artwork assigned to it.

texturecache.py seems far more robust, and less opaque, of a tool that the add-on. I guess I'll poke at it some and see what I can figure out.

[Milhouse]

The MovieSet's name, and its members, yes.

Not the artwork assigned to it.

You are incorrect. The artwork for a Movie Set is stored in the media library, and in the case of a shared MySQL setup the Movie Set artwork will be common to all clients using the shared MySQL db.

[hanlon]

You are incorrect. The artwork for a Movie Set is stored in the media library, and in the case of a shared MySQL setup the Movie Set artwork will be common to all clients using the shared MySQL db.

Theory's fine.

You can call my observations 'incorrect' if you like, but I'm telling you what I'm experiencing.

All clients here access the shared DB just fine.

But not MovieSet art. Set it on one machine, and NO other machine picks up the setting.

[Milhouse]

Then your systems are broken, and you should fix them.

Use "texturecache.py jd sets" to view the Movie Sets artwork urls on each of your clients, and - if your clients are all using the same videodb schema - you'll see the urls are all the same on each client. If the urls are different on some or all clients then those clients are not using the same MySQL server or schema you think they are, and you need to fix that.

Assuming the urls are correct on your clients, if any client is not displaying the correct images in the GUI then that is most likely a caching issue rather than a media library issue (try "texturecache.py C sets" on such clients).

[redglory]

Are you using same Kodi/XBMC version?! It's important when sharig MySQL Shared library.

[Brian Garratt]

Hi,
I've written this script to manager my kodi thumbnails and it does exactly what I want. I hope it will do what you want also.
Brian.

#!/usr/bin/python
# filename: flush.py

# As a safeguard stop kodi before use.

import sqlite3
import sys
import os

# Set up home directory
home = os.getenv("HOME")

count = 0

# Connect sqlite3 to database
try:
conn = sqlite3.connect(home + '/.kodi/userdata/Database/Textures13.db')

choice = conn.execute("SELECT DISTINCT url from texture") # get distinct entries from database
for row in choice: # as a guide to which to flush
print row[0]

category = raw_input("Please select a keyword from above list for which category to flush >>> ")

cursor = conn.execute("SELECT id, url, cachedurl, imagehash, lasthashcheck from texture")
# read database
for row in cursor: # loop through all entries in database
target = row[1] # get url as target
if category in target: # test if target contains our category
record = row[0] # yes, get record id number
print "Deleting record no.", record
conn.execute("DELETE from texture where id=?",(record,)) # delete this entry
conn.commit() # commit change
file = home + '/.kodi/userdata/Thumbnails/' + row[2] # get cachedurl filename
if os.path.exists(file): # make sure it exists
print "Removing file ", file
os.remove(file) # remove file
count += 1 # count how many thumbnails have been removed
print "Number of thumbnails removed ", count

# Failed to open database, report error
except sqlite3.Error as e:
print "Error %s:" % e.args[0]
sys.exit(1)

# That's all folks
finally:
if conn:
conn.close()

[Milhouse]

Hi,
I've written this script to manager my kodi thumbnails and it does exactly what I want. I hope it will do what you want also.
Brian.

Or you could use "texturecache.py purge all <category>", which also has the advantage of being able to run against remote clients, and doesn't require direct Textures13.db or filesystem access.

[hanlon]

Assuming the urls are correct on your clients, if any client is not displaying the correct images in the GUI then that is most likely a caching issue rather than a media library issue (try "texturecache.py C sets" on such clients).

i verified that all instances were using the same build version and DB version #s.

the urls reported were identical as reported by texturecache.

exec'ing a

"texturecache.py C sets"

apparently fixed all 4 clients.

I'm completely confused as to why that works, but completely deleting the clients' Thumbnails/ folder didn't.

Anyway, now changes made in the master are seen in the clients.

Thanks. Don't know what I'd have done without this tool.

[Milhouse]

I'm completely confused as to why that works, but completely deleting the clients' Thumbnails/ folder didn't.

Probably because you didn't delete Textures13.db as well.

[un1versal]

@Milhouse, that freeze on scan initiated via script is completely fixed... Neither freeze nor stutter nor blocking input of anything during video playback (smooth like butter)... Just as it should, in fact you cant tell at all anything is going on.. Perfect, , say thx to Sasha for me fantastic fix and quick too. Cheers bud.

[QuattroGam3r]

Milhouse, i've been running your script remotely lately and noticed a huge lag. Just a simple texturecache.py C movies "whatever" takes about 3.5 minutes to complete. Running the same command locally through SSH only takes about 30 +/- seconds. I'm just curious if this is expected behavior. This is on a Pi, so maybe it has to do with being underpowered. Any thoughts?

[Milhouse]

@garderd4me: Upload texturecache.py logfiles (one for local, one for remote) as that would indicate where the delay is occurring. Check your Pi is not running out of memory, although this is much less likely to happen when using the script remotely, so the behaviour you're seeing is a bit odd. Maybe your network is having problems.

[QuattroGam3r]

Ok, sorry for the ghetto logs, but I can't be bothered to pay pastebin to fit the entire log in one go. I've split each log and removed the middle parts containing all of the actual image locations. If you need those I can make more logs, just let me know.

Here you can see the runtime result for LOCAL:
Threads Used: 2
Min/Avg/Max: 0.10 / 0.53 / 1.40

Loading: 00:00:00.13
Parsing: 00:00:00.01
Comparing: 00:00:09.78
Downloading: 00:00:19.04
TOTAL RUNTIME: 00:00:28.99

Local-log:
http://pastebin.com/tUf9AuGf
http://pastebin.com/FLfqFeis

Here is the runtime result for REMOTE:
Threads Used: 2
Min/Avg/Max: 0.01 / 0.22 / 0.89

Loading: 00:01:20.02
Parsing: 00:00:00.00
Comparing: 00:01:26.68
Downloading: 00:01:38.25
TOTAL RUNTIME: 00:04:24.96

Remote-log:
http://pastebin.com/7W0BF5Ej
http://pastebin.com/0Z3z6rYU

edit: memory stayed at about 30% while running remote and local scripts. Cpu was around 60% during remote and jumped to 96% when the images re-cached. Cpu was around 76% during local script and jumped to 97% when re-caching images

edit 2: I see a 1 minute 20 second timeout every time there's a RPC connection established with IPv4, just not sure what's causing it.

[Milhouse]

edit 2: I see a 1 minute 20 second timeout every time there's a RPC connection established with IPv4, just not sure what's causing it.

Yes, establishing the rpc connection seems to be the problem. Setting @rpc.ipversion=4 would fix the issue.

The default script behaviour is to try and establish an IPv6 connection first, then fall back on IPv4.

The script uses a short connection timeout initially (when the script is initialising), which would explain why you're able to establish an IPv4 connection fairly quickly at the beginning, but subsequent connections don't specify a timeout (using the system default timeout) and connections take much longer to establish as it's taking 80 seconds for the initial IPv6 connection to timeout.

I've pushed a fix (v1.8.9) which will re-use the same IP version once the first rpc connection is established, so you should automatically use IPv4 for all connections.

As to why IPv6 connection are taking so long to fail on your network is anyone's guess, maybe a network configuration/router issue.