The file "queue" which holds the queue is empty (zero bytes). The system crash is most likely responsible for that.
When updating queue on disk NZBGet tries to do that safely:
- queue saved into temporary file queue.new;
- then existing file queue is renamed to queue.old;
- then queue.new is renamed to queue;
- then queue.old is deleted;
In your queue directory there is only "queue". Neither queue.old nor queue.new are there meaning the saving was completed without error.
What could cause the lost of queue file? May be the system buffers or hard drive buffers were not flushed? Or the file system got corrupted and were repaired after reboot and some files were lost.
What NZBGet can do about this? I can offer keeping of older queue-files (one, two or more copies). But I don't know if it will really help. During download the queue file is updated frequently (after every downloaded inside nzb). All backup files may be very fresh and all may still be cashed and then get lost. Having a backup of queue-file only is also bad because there are other important files in the directory and all files are related.
My understanding is that the system must flush files on closing. How can programs be sure about writing if the system writes data when it wants. I'm still not sure if this is what has happened. What is the file system used? How about putting queue-directory on another partition with another (better) file system?
I do have crashes now and then during development but never lost queue.
What you can do:
- in your NZBGet startup script add code to make a backup of queue-directory:
Code: Select all
zip -r queue-$(date +%Y%m%d_%H%M%S).zip /path/to/queuedir
- write a scheduler script, which will make backup of queue-directory. The script should pause NZBGet before doing backup.