I guess this issue is created by having multiple threads open to the DB, where one could take a significant longer time than another. It seems that once the DB get “locked”, it messes up any future requests and my system keeps hanging at 100% I/O on one CPU thread. If this issue can be resolved another way, that’d be a better solution.ĮDIT: The attempt didn’t seem to solve the issues, they returned after I added another serie. I’m not really looking forward for the hundreds remaining. I think in the end, sonarr was able to correctly handle everything, but it took about 7 minutes for 13 episodes that I just imported. My statistics of my I/O wait have now gone from 100% continuous to an interrupted stream of 100% I/O. The “|Trace|Owin|SQLite error (5): database is locked” error is without a doubt related to my high I/O results.ĪTTEMPT: So I tried running the sonarr instance as root and saw a much cleaner trace log, although “database is locked” errors still persisted. Could it be that the sonarr user doesn’t have the correct permissions to access the cloud drive or something? But wouldn’t the logs reflect such an issue then? I can try to run sonarr as root perhaps to try and import my existing series maybe, see if that helps? Adding non-existing shows to sonarr works without issues, the importing of existing makes it go crazy. I’ve done numerous fresh installs, and as soon as I point sonarr to a mounted drive to import already downloaded series, it immediately jumps up to 100% I/O wait on one CPU core. No changes have been made to the mount or the way sonarr uses the drive, just same old settings that always worked like a charm.ĮDIT: I’ve found a new error that occurred, an I/O write error, but I’m fairly sure that’s because from the moment the ‘refresh disks’ segment starts running, it takes up an entire CPU core.ĮDIT2: After further research, it appears I can ignore the above mentioned error.ĮDIT: After further investigation, it seems that sonarr really has an issue with importing series from a mounted drive. So I would be surprised if the drive would be the issue, it has never failed before with sonarr, so it would be strange to just fail without any reason. The mount has worked perfectly before and is set up in a way that sonarr can correctly analyze it. ![]() I’m using a mounted cloud drive, but never experienced any issues up until now. Only manually stopping the service from commandline eventually frees up my CPU. It has a continous 100% I/O wait, taking up the entire CPU. The problem is that this error is causing a 100% load on one of my threads from my CPU and it doesn’t automatically shutdown. Sonarr is always run by its own user, and program data is saved in its own folder, I haven’t done anything out of the ordinary for installation. I’m really in the dark here how such thing could have happened. I tried to reinstall and only add shows one by one to see what causes the issue, but all to no avail. Tried to remove sonarr, including all its config files in the ~/.config folder, checking my mono install, checking mysql install and reinstalling those services. I have no clue how to resolve this anymore. Until today, where database troubles arose. I haven’t changed anything in the settings of sonarr, only manually added some media, but it always picked it up after a refresh of the disk files, without any troubles. For some reason it always reports that the database is locked. Something changed overnight where sonarr has critical errors accessing the database. ![]() Mono version (if Sonarr is not running on Windows): 4.2.3
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |