Kodi Community Forum

Full Version: Poor MySQL Performance (since Frodo)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi there,

since Frodo was introduced, i ran into the issue, that Images (Poster/Fanart) where not shown when watched or resume flag was set when stopping/finishing a movie. The thumbnail cache or texture.db seemed to be to slow. When i first posted the issue here years ago, i was told by a Team Member, that my MySQL device is to slow. I was using a Synology DS211j, which just had 1,2ghz and 128mb of ram, so i just lived with it.

Recently i switched to a real linux device which has an a6 3500 processor (3x2,1ghz) and 4 gigs of ram + ssd, but the issue is still the same. No matter if i use MySQL or MariaDB, when i'm in database mode and stop one of the movies that have been added recently - the fanart/poster is not shown until i reenter the database. I cannot believe that still my MySQL device is blamed for that. Just a side note: My movie database contains only about 400 movies, so its not that big.

Does anyone here have any suggestions to speed things up? I'm using Ubuntu, MariaDB and the extreme-innodb.cnf for 4GB devices as my.cnf[/b]. It can be seen here.

Else: Team Kodi, i'm not a coder at all, but would it be possible to add a feature like 'load thumbnails first, then set watched/resume"?

I cannot understand why Thumbnails are saved locally when they are requested through MySQL everytime the DB is shown. What advantages does the cache have then?


Noone around with a good my.cnf that could help?

Here is my new one, which makes it better, but still not good:

port = 3306
socket = /var/run/mysqld/mysqld.sock

port = 3306
socket = /var/run/mysqld/mysqld.sock

bind-address =

key_buffer_size = 384M
max_allowed_packet = 1M
table_open_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8
server-id = 1

max_allowed_packet = 16M


key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

I'm sorry but your issue is really vague to me. To be fair it sounds like it could be a skinning issue as well as an SQL issue.
It doesn't sound like an issue I've seen before.

You provide hardly any details in your question for me to do anything with so I'll just respond to your last remark:
The Kodi client requests the name/location of the fanart file, not the file itself. The file itself is cached locally on each client because different clients might have different sizes / optimalisations.
Let me try to explain a little bit better:

I use a MySQL/MariaDB database on an Ubuntu system, all clients are connected to that server through advancedsettings.xml
I also use the default Confluence skin (but i tried others as well), so i don't think this is a skinning issue.

I share all files through NFS and that works fine. When i enter the movie database, all fanarts/posters (depends on the view i use) are shown fine. When i highlight the last added movie (in the list of over 300 movies), switch back to the home screen and reenter the movie database it takes a second for the fanart to show up. Beware: I do not talk about "recenlty added", but the full movie database. The later a movies was added, the longer it takes for the fanart to show up. And whenever i add a few movies to the database, i run the Texture Cache Maintenance utility.

When i start watching one of the last added movies - again: not in recently added, but from the full database - and stop it after a while, the "resume" flag is set, but the fanart does not show up. I was told earlier by jmarshall, this happens when MySQL is to slow. I was using a very poor device earlier, so i just accepted this behaviour. But now i use a powerful system (4gb ram, system is on a ssd), but still have the same issue. All fanarts/thumbs are local on each client, so it should be now problem to get them way much faster.

If you want to, i can record a video of the behaviour i describe.
Please do. A full debug log for that session would help as well.
Video: https://dl.dropboxusercontent.com/u/1245...G_1567.MOV

Log (on my MacBook, but i got the same behaviour with all other clients (HTPC, FireTV): http://pastebin.com/rWeh7uzx
Looks fishy. It is re-caching the images all the time. Will have to check the code and try to reproduce.
Yes, exactly. And i do have this since Frodo, no matter which device i use. On the FireTV it is not that bad, but this seems to be due to the fact that it takes a few more seconds to return to the library again.