Problem scanning huge source (mem leak)?
#8
I need to get some leverage on all this, find the best place to stick the crow bar (I hope that translates!).
Here are my mumblings...

Eating up memory and getting slower to scan an album would seem to be related. Some kind of caching? Is there a step point in number of songs processed when it begins to slow, or is it gradual? Is it the large debug log?

The log files you sent are very moderate in size, scanning for hours where is the rest?

Don't think the name "Die Ärzte" is reason for timeouts, many of the SQL updates that timeout were on album_genre table. They were however repeats of the same genre, but that is normal.

These music files, before being tagged with mbids, loaded into music lib in Jarvis.
As one music source?
Debug off or on?
Picard tagging does add data - musicians, composer etc. so the db will be bigger. But are duplicated albums (same mbids) causing some issue?

What is calling a query of all unplayed songs on start up?
Estuary skin, try swap to Confluence? An addon? I can't replicate on my system.
Can the timestamp in the MySQL_slow.log be matched to entries in Kodi.log?

~~~~~~~~~~

At this point I need some more input. @Rusendusen maybe you have answers to at least some of the above questions?
Reply


Messages In This Thread
RE: Problem scanning source - by DaveBlake - 2017-02-12, 13:00
RE: Problem scanning source - by Uatschitchun - 2017-02-12, 21:51
RE: Problem scanning source (mem leak)? - by DaveBlake - 2017-02-13, 11:47
Logout Mark Read Team Forum Stats Members Help
Problem scanning huge source (mem leak)?0