Posts: 524
Joined: Aug 2015
Reputation:
26
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.
Posts: 3,027
Joined: Oct 2012
Reputation:
189
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
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 3,027
Joined: Oct 2012
Reputation:
189
if you still have the logs - what is the first database error after you have cancelled the task?
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 524
Joined: Aug 2015
Reputation:
26
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?
Posts: 3,027
Joined: Oct 2012
Reputation:
189
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)
tinyMediaManager - THE media manager of your choice - available for Windows, macOS and Linux
Help us translate tinyMediaManager at
Weblate | Translations at 66%
Found a bug or want to submit a feature request? Contact us at
GitLab
Posts: 524
Joined: Aug 2015
Reputation:
26
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.