Strange SABnzbd logging after restart after ungraceful SABnzbd stop

[sander]

Strange SABnzbd logging at restart after ungraceful SABnzbd stop

I see a strange history overview after restart after an ungraceful SAB stop.

At 04:33 this morning, a certain download (let's call it "breiers") was complete. I haven't got the history-overview, but it must be normal: the DVD contents are ok in the directory, and all intermediate files are gone (as requested)

However, at 11:30 this morning, I had a ungraceful SAB stop (power outage). After I had restarted my computer + SAB,  strange info appeared in the history overview: http://192.168.1.92:8080/sabnzbd/history/ says

2008-02-05 11:45:19 breiers False

Stage Par2
    [PAR-INFO] breiers: => Scanning "/media/sda3/sander/downloads/incomplete/breiers/breiers.vol000+01.PAR2"

That is all the information about "breiers'. The earlier info about "breiers" was gone.

Which is strange of course: that download had already been completed at 04:33 in the morning (7 hours earlier). That info was gone from history.
And the second strange thing: suddenly there was an extra directory in the complete-directory calles breiers.1. Which, BTW, was empty.

Code: Select all

sander@sander-amd64-8:/media/sda3/sander/downloads/complete$ ll | grep -i brei
drwxr-xr-x 3 sander sander  4096 Feb  5 04:33 breiers
drwxr-xr-x 2 sander sander  4096 Feb  5 11:45 breiers.1
sander@sander-amd64-8:/media/sda3/sander/downloads/complete


sander@sander-amd64-8:/media/sda3/sander/downloads/complete$ du -BM *breier*
4397M   breiers/VIDEO_TS
4401M   breiers
1M      breiers.1
sander@sander-amd64-8:/media/sda3/sander/downloads/complete$ 

So: strange SAB behaviour and history / logging stuff, probably triggered by the ungraceful SAB stop. However: root cause unknown to me. It looks like SAB is going to rescan older, complete stuff.

[shypike]

Do you have "Enable periodic Save" active in Config-->Switches on?
This saves the queue state after each file completes.

Ungraceful stops are by definition a problem. SABnzbd can only resume for the state it reads from the last saved state (stored in the cache directory). If those files have become corrupt because of the crash, it's guesswork what SABnzbd will do next.
On the other hand: by not having "Enable periodic Save" on, SAB will never save state (except on job completion), so proper resume is unlikely.
(I wonder If we should not remove the option and make it always enabled).

[sander]

"Enable periodic Save" is on Yes, so that can't be the cause.

The point is (IMHO): the job "breiers" had been completed 7 hours before the crash. So, apparently, SAB goed back in history? 

PS: it is not a big deal, as the contents are downloaded OK. It's just a matter of logging, and an explanation for earlier strange loggings.

[Patman666]

Same problem here, succesful download, parring, unrar. Purged history.
Reboot PC and restart SAB.
Last download is reoccurring in history with message scanning... and an empty dir in download dir.

[shypike]

Warning:

Any brute-force stop of SABnzbd can cause a restart to behave strangely.
When SABnzbd does not get a change to save it's internal state to disk before termination, then on restart there will be a mismatch between the state files (queue.sab & history.sab) and reality.

Unfortunately this is a design problem, which cannot be fixed easily.
Work on this will be done for 0.4.0 or later.

BTW: "Enable periodic Save" will not prevent this problem.

[nzb_leecher]

I had today the same behavior and i see now what is the cause of the double dir i sometime get. The double dir is an empty one  called blabla.1 .

[nzb_leecher]

Now that i think of it. Isn't windows always trying to shutdown programs in a nice way before it shuts down?
In that case could sab not be "shutdown aware" so that if windows signals "i am shutting down" that sab get the time to shut down in a nice (non brutal) way?

[shypike]

Windows may get impatient.
When SAB has a full article cache it needs to save all these in files.
That may take longer than Windows allows.

[nzb_leecher]

Sometimes i see a msgbox that proces A is still busy, that i have to wait until it finishes or to stop the proces with "enter"
Thats at least 10 secs, should be enough for most hd's to write the cache. Only for small and slow servers. But that whay you could stop a lot of computers from brute stop results.