My temp and complete folders reside on an external drive, this drive may not be connected while SAB is running.
"wait_for_dfolder" solves the issue when SAB starts, but it does not when the drive is removed while SAB was running normally.
The log gets spammed with "Cannot create directory Temp Folder" until the drive is reconnected and I'm not sure what happens to the RSS system, if matches keep happening but the job never gets added or if the RSS system stops functioning until the temp folder returns.
I was wondering if this option could simply revert SAB to it's "hung" state, preventing any RSS matches and downloads as it was when SAB was started without the temp folder accessible.
wait_for_dfolder should apply while SAB is running as well
Re: wait_for_dfolder should apply while SAB is running as we
The biggest issue with that option is that it hangs post-processing.
I understand your suggestion, but it would need to be done differently.
A major issue is that people can set different folders for each category.
What would need to be the proper reaction, stop the queue?
I have to think about this.
I understand your suggestion, but it would need to be done differently.
A major issue is that people can set different folders for each category.
What would need to be the proper reaction, stop the queue?
I have to think about this.
Re: wait_for_dfolder should apply while SAB is running as we
>>>A major issue is that people can set different folders for each category.
Wouldn't that only affect the "complete" folder? I was under the impression that wait_ext_drive for there for that, but that assumes that the temp folder is always accessible and the complete folder isn't.
Also,
I suspect most people wouldn't disconnect the external drive until the queue/post-processing is done. Which is usually what I do. I end up stopping sab and disconnecting the drive, and starting it up again after I reconnected the drive.
All in all, I think that if the temp folder is inaccessible, all operations should cleanly pause and wait for it to return, which includes active downloads, RSS feed refreshes/matching and adding new jobs externally. Those activities can safely be put on hold without any issues. It would also act as a protection mechanism if the drive gets suddenly disconnected by mistake.
However, if the external drive containing the temp folder is removed while post-processing is active, then it's the user's fault for not waiting until it was completed.
Spamming the log isn't needed either, maybe a simple "Temp/Complete folder missing" message on the main page would do. Could be in the same spot used to announce new versions.
Also as a side enhancement, this message section could also be extended to display common error messages in simple english, not saying to remove the status section since it's quite useful, but to bring the most common errors up front, that way users get a quick idea of why SAB isn't working.
Anyways, I moved the temp folder to the external HDD when I switched to an internal SSD, as leaving it on the system drive would wear out the NAND chips and eat into it's useable life.
Wouldn't that only affect the "complete" folder? I was under the impression that wait_ext_drive for there for that, but that assumes that the temp folder is always accessible and the complete folder isn't.
Also,
I suspect most people wouldn't disconnect the external drive until the queue/post-processing is done. Which is usually what I do. I end up stopping sab and disconnecting the drive, and starting it up again after I reconnected the drive.
All in all, I think that if the temp folder is inaccessible, all operations should cleanly pause and wait for it to return, which includes active downloads, RSS feed refreshes/matching and adding new jobs externally. Those activities can safely be put on hold without any issues. It would also act as a protection mechanism if the drive gets suddenly disconnected by mistake.
However, if the external drive containing the temp folder is removed while post-processing is active, then it's the user's fault for not waiting until it was completed.
Spamming the log isn't needed either, maybe a simple "Temp/Complete folder missing" message on the main page would do. Could be in the same spot used to announce new versions.
Also as a side enhancement, this message section could also be extended to display common error messages in simple english, not saying to remove the status section since it's quite useful, but to bring the most common errors up front, that way users get a quick idea of why SAB isn't working.
Anyways, I moved the temp folder to the external HDD when I switched to an internal SSD, as leaving it on the system drive would wear out the NAND chips and eat into it's useable life.
Re: wait_for_dfolder should apply while SAB is running as we
I misread your post.
The trouble with a disappearing temp drive is harder to solve though.
With the temp drive gone, most of the administration is gone too.
Given the high amount of parallelism going on during downloading, halting that is hard.
Why would the temp drive suddenly not be available?
The trouble with a disappearing temp drive is harder to solve though.
With the temp drive gone, most of the administration is gone too.
Given the high amount of parallelism going on during downloading, halting that is hard.
Why would the temp drive suddenly not be available?