[Uatschitchun]

The timeout occurred on some special albums, as far as I could see. Seemed like a duplicate album I've got under 2 different subfolders and with german Umlaute (Die Ärzte).

Kodi starts on music and there's a widget showing random albums, but this widget doesn't show up after starting kodi...

I started scanning yesterday morning and am now on a little less than the half (60MB DB size). Scanning one album takes longer and longer the further you go. Right now I'm at app 30-40sec per album. You can see what's added with

Code:

tail - f /storage/.kodi/temp/kodi.log |grep open

It's one source only, no chunks. The server's doing nothing but running vdr at 1-2%, serving nfs and Mysql. When kodi is adding to the db, Mysql is running at about 100% on a dual core (virtual quad, Intel atom).

There's no crash log, as it's kodi being restarted cause of memory issue. Journalctl gives kernel warnings cause of ram and stops services to keep alive

total number of records in the song table

I sadly don't talk sql, have you got the query on that?

The pvr updates are epg only as vdr has its own epg data, I don't use epg db.

In Jarvis I had that source added completely. Between Jarvis and Krypton import on a fresh db, I "only" tagged about 80% of the files with MB. (you know, 90% laptop 10% kodi 10ft :-)

As I'm writing here, I had 2 hang ups already with

Code:

watch - n1 free -m

being at 20MB free ram, no errors in kodi log. Only rebooted, waited till 'housekeeping' is done and restarted db update. So no timeouts in Mysql

Unfortunately MySQL timeout errors by default do not rollback transactions.

Hm... then, if that happens, no one knows about... :-(

I definitely can say from the last hang, there were no timeouts

Here's journalctl
http://sprunge.us/OVEU

There's nothing of interest, as far as I can see in debug.log. I'll send it to you

A crash log wouldn't be of any great help as no debug symbols are in LE's kodi. Maybe I can get some...