Login at Kodi Home

**mlaggner** · 2021-02-17, 08:43

not so good - looks like the db got corrupted somehow Sad

fortunately you have backups for your DB a few days back, so you can easily recover

I have to search their issue tracker for hints about this

tars · 2021-02-17, 09:16

Just checked the log and it seems the error started right after I had aborted "change data source" command for remaining queue while it was running.

**mlaggner** · 2021-02-17, 09:46

strange - operations from tmm to MVStore go through the same interface. BUT I may have a clue what happened (I will review that code).
Nevertheless I've compared the MVStore code to our database parameters and may found _better_ settings - a new build is being finished in a few minutes

**mlaggner** · 2021-02-17, 09:56

if you still have the logs - what is the first database error after you have cancelled the task?

tars · 2021-02-17, 10:12

Re-ran the same command for the remaining queue. It might have confused about the location of the aborted movie:

https://pastebin.com/RFVJ9kEg

**mlaggner** · 2021-02-17, 10:53

play, completely reproduceable - but I am unsure WHY this happens. For now the only _safe_ alternative would be to roll back to the MVStore internal compact algorithm, but with a lower "target" (so that it should not try that hard to reach the fill rate, but producing a slightly bigger file between massive operations and closing of tmm)

sorry for this bad news, but consistence of the database is more worth than a bit of storage Smile

Nevertheless I will keep track of the corresponding bug reports of MVStore

**mlaggner** · 2021-02-17, 11:18

something very interesting here: https://github.com/h2database/h2database/issues/227

this could be the case why there are some occasional DB corruptions which I could never reproduce. I may pick up my idea of doing lazy commits to the database (unfortunately I've dropped all my tests a few weeks ago :/)

tars · 2021-02-17, 12:41

Just tried with 4.0.7 and it never corrupts at several attempts. But with the current build, it corrupts at first attempt.
How could the original compact algorithm prevent the corruption? Does it doing something else constantly besides compacting?

**mlaggner** · 2021-02-17, 14:24

I increased the retention time due to the hint in the original code - but this may increases the chance of corruption. Nevertheless I have re-worked the persistence module of tmm to do commits more lazy (which should also result in much less DB I/O). I was no more able to force a DB corruption.

I will push that and build a new nightly for further tests (will be done within the next 30 minutes)

tars · 2021-02-17, 15:13

Thanks! I can no longer reproduce the issue with the new build.
And it uses less than 0.1% of CPU when idle and the db size no longer gets bigger while running.