Posts: 1,394
Joined: Apr 2010
Reputation:
116
CrystalP
Team-Kodi Developer
Posts: 1,394
2024-05-25, 01:08
(This post was last modified: 2024-05-25, 01:14 by CrystalP. Edited 1 time in total.)
Thanks. It doesn't look like any of the steps failed.
The next step that I was trying to avoid would be to send your 121 db to attempt reproduction on other systems. I don't see much else that could be done.
format: zip of the db dump I suppose?
Just in case I checked again a 20.5 to 21 migration with a 10.11.7 docker and there was no performance issue afterwards.
edit: looking a little closer at the log, there are were a few db access to movie_view after the migration, and they took much less time than the reported problem.
CVideoDatabase::RunQuery took 1345 ms for 3852 items query: select * from movie_view WHERE (isDefaultVersion = 1) AND (((movie_view.playCount IS NULL OR movie_view.playCount = 0)))
CVideoDatabase::RunQuery took 710 ms for 10 items query: select * from movie_view WHERE isDefaultVersion = 1 ORDER BY dateAdded desc, idMovie desc LIMIT 10
I don't know if that matches the numbers when the db is created from scratch, but it would be weird to have normal performance and then a degradation.
Posts: 19
Joined: May 2024
Reputation:
0
Thanks again - I guess we should leave it there, since there are no other reports of the topic besides the two in this thread. Thanks for looking deeply - if the problem would manifest in more installations, I am more than happy to support at that time by providing data as needed.
Posts: 1,394
Joined: Apr 2010
Reputation:
116
CrystalP
Team-Kodi Developer
Posts: 1,394
sure. If you want to dig, it sounds a bit like the statistics of some tables are bad, causing the optimizer to choose the wrong execution plan.
The migration creates a new db and doesn't inherit the previous db stats. It's a different access pattern when migrating and when importing into a new db so maybe we hit a maria db bug somehow. Can't really say...