[SOLVED] GPM sync is effectively broken [#16276]

Post a reply

:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

Expand view Topic review: [SOLVED] GPM sync is effectively broken [#16276]

Re: GPM sync is effectively broken [#16276]

by Barry4679 » Fri Jan 31, 2020 8:41 am

Initial GPM sync slowdown fixed

Re: 2220 - GPM sync is effectively broken

by Ludek » Mon Jan 20, 2020 6:28 am

Thanks for reporting Barry, I will look into it, tracked as https://www.ventismedia.com/mantis/view.php?id=16276

[SOLVED] GPM sync is effectively broken [#16276]

by Barry4679 » Sat Jan 18, 2020 1:34 am

The duration of the initial sync of a GPM library (only include matching content, and do not download track contents) has blown out to where it it is not currently fit for use.

It seems to be taking approx 1/3 seconds per track ... so what was a 9 minute job is now 5+ hours.

Once I noticed this, I turned run the Debug Logger for a while. Much of the delay seems to be due to waiting for a db lock
DB lock took 266 ms : DELETE FROM DeviceTracks WHERE ((DevicePath=? AND DevicePath <> '') OR (SyncID=? AND SyncID<>'')) AND IDDevice = ?
A similar thing for the same query, for every track.

I left it running overnight ... logging turned off

It didn't complete. You excelled yourself with this diagnostic message ... all you have to do is look for, and fix, something "unknown". :D
No log. No attempt to dispatch a crash dump to you.

? Maybe my PC's power plan caused this ... it is set to sleep after 2 hours inactivity.

I restarted the job in the morning and it ran for a further 2 hours, and completed OK

I have debug logs if you need them, but I suspect that you don't.