0.7.0B3:
The gui shows me a warning with the category ERROR: SQL Command Failed, see log
However, when I check the logs I can only find:
2012-04-21 16:15:12,209::ERROR::[database:90] SQL Command Failed, see log
The entry before that is:
2012-04-21 16:13:57,740::ERROR::[downloader:526] Failed login for server newsreader1.eweka.*:119
Only thing I can add is that disks were under heavy load at this perticular time.
Incomplete log
Forum rules
Help us help you:
Help us help you:
- Are you using the latest stable version of SABnzbd? Downloads page.
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Re: Incomplete log
The two errors are (probably) not related.
Very occasionally the sqlite3 library gives these kind of messages.
I'm not sure if SABnzbd always handles this elegantly, I'll look into that.
SQLite is only used to store the download history.
Very occasionally the sqlite3 library gives these kind of messages.
I'm not sure if SABnzbd always handles this elegantly, I'll look into that.
SQLite is only used to store the download history.
-
Handyman1984
- Newbie
- Posts: 24
- Joined: April 11th, 2012, 5:20 am
Re: Incomplete log
Thanks for the response.
The only reason why I reported was because it happened a couple of times within the hour with a restart in between.
For as far as I'm considered the lack of information is the bug, and not the error itself.
What I did: I readded a bunch (+/- 80) jobs to the queue to be processed because I had a wrong par flag in the config.
These jobs obviously were done downloading very fast, since they were done to begin with.
So I'm assuming the error was because sab opens and saves the sqlite file in between calls which triggered a write lock.
The only reason why I reported was because it happened a couple of times within the hour with a restart in between.
For as far as I'm considered the lack of information is the bug, and not the error itself.
What I did: I readded a bunch (+/- 80) jobs to the queue to be processed because I had a wrong par flag in the config.
These jobs obviously were done downloading very fast, since they were done to begin with.
So I'm assuming the error was because sab opens and saves the sqlite file in between calls which triggered a write lock.