2025-12-05, 02:39 PM
(2025-12-04, 08:40 PM)JF2025 Wrote: @raulo1985 : I tried a combination of settings as you suggest. As I remember, I had an extremely slow and error prone scan with a setting of 1. The combination that worked for me was the "empty" parallel tasks input (system core count) with the Optimistic property in the xml. Yes, my processor has multiple cores. Full scans still take some time. With a large music collection, I expect that when doing the replace metadata on the full library. Update scans, normalisation scans, etc. are relatively fast on newly added files.
Exactly how the application manages database access would be an answer that the developers could explain much better than I could. I just settled on the settings that no longer gave me log errors associated with locking, while improving overall performance.
Also, it might be helpful to add that I did a fresh install of v 10.11.x I did not try migrating from the previous version as database migrations after refactoring can be problematic in any application. I just waited out the rescan, as my media files have good embedded tags.
If those settings work out for you, then go for it. Db locking apparently happens in a very inconsistent way and case by case so far, surely there are some things that the devs need to polish. In my case, I tried migrating and also starting from scratch (Linux Mint, bare metal), and never had db locking issues (default NoLock, and I always set parallel tasks to 1). I’ve had a very good experience with the new releases, just minor things (like the local intros not working, but it hasn’t worked since 10.9. And also took some trial and error to make my WebOS client work as expected without playback issues).