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.
WUS installed some updates and instead of postponing the reboot I hit reboot without first pausing/shutting down SAB (this thing is so stealthy that I forgot it´s even there ).
After the reboot 2 rar files where corrupted (each missing 1 block in quickpar). The rar files where the ones active downloading during the reboot.
1. Is this a known one? Windows shutting down is killing the SABnzbd in a harmful way?
2. Does install SAB as a service help here?
When SABnzbd receives the reboot signal from Windows
it will flush its article cache to disk and finish its other work (like assembling a file).
If takes longer than Windows want to wait, there might be a problem.
shypike wrote:
When SABnzbd receives the reboot signal from Windows
it will flush its article cache to disk and finish its other work (like assembling a file).
If takes longer than Windows want to wait, there might be a problem.
I still do have this in RC1. I basically just do a logout. After logging in the queue has only one active entry in it - the one that was downloading at the time of the logoff. All others are missing. I found them i the status/queue repair dialog as orphaned jobs. Click repair and all is perfect again.
I did check the log and it looks like SABnzbd did not got/cached the logoff or a shutdown signal at all. Therefore no saving postproc queue. The last debug log was a "DEBUG::[decoder:92] Decoding" message.
The default WaitToKillAppTimeout is 20 seconds. This should be plenty to start the shutdown proc. At least there should be some queue saving entries in the debug log.
I'm not sure if that will solve the problem.
BTW, I will add one fix.
When SABnzbd reads the queue start up, it reads and removes one file from the __admin__ folder of each job.
This file is only written back when the queue is saved.
I will make SABnzbd leave the file on disk, so that the job will not be lost due to a premature stop.
Last edited by shypike on April 7th, 2011, 1:55 pm, edited 1 time in total.
shypike wrote:
I'm not sure if that will solve the problem.
Holy pepperoni. As a service it worked! After rebooting all the jobs where in place - no orphaned - just as it should be. The log also agreed with ":WARNING::[__init__:156] Signal 6 caught, saving and exiting... ". So happy camper here. I had planned to install it as a service - only should have done it much earlier. Thanks for this great program.
shypike wrote:
OK, so it looks like Windows has more patience with services.
Think it´s not a question of timing. As a service SABnzbd can catch the shutdown event (entry in the log) and in normal mode it do not get the event. Instead SABnzbd got a shut in the head. Your fix would solve the orphaned records (maybe - I will check this) but will not solve the corrupted articles resulting in the violent kill of SABnzbd.
andygr wrote:
but will not solve the corrupted articles resulting in the violent kill of SABnzbd.
Nothing will prevent corruption in the case of a violent kill.
SABnzbd does handle a soft kill properly (like an ^C from a command prompt).
Also noral termination signals from the OS will result in a graceful shutdown.
Killing from the task manager and an impatient system shutdown cannot be handled.
).
