SABnzbd Forums

kvoorhees wrote: ↑March 8th, 2019, 12:04 pm I don't think it is a 2019 issue specifically to be honest. I had a similar experience after upgrading from 2012 to 2016 years ago. Unfortunately it persisted until I wiped the box clean and installed the OS fresh. I am very much hoping it doesn't come to that this time. I actually wiped my install of SABNzbd yesterday. Deleted everything in appdata and program files and installed fresh. Worked great and downloaded a bunch of stuff, an hour ago, same error.

My VM install was a completely fresh 2019 and SAB, with only the .ini file transitioning between old and new.

Trying the beta 2.3.8 as well...

We don't have a version with Python 2.7.16 yet.. Our build platform (appveyor) doesn't support it yet so we have to wait for that.

OK, I wrote a quick PowerShell to monitor the API for warnings containing the error condition, so things are at least functional over time.

For now, clearing the warnings and restarting SABNZBd seems to work...

I created a test-build of 2.3.8Beta1 that uses Python 2.7.16:
https://github.com/sabnzbd/sabbuild/releases/tag/test3

Could you guys test if this helps?

Sure. I was on travel this week, so I didn't have access to the machine.

Do you still want to test it, or is it already rolled in the the RC? I've already loaded it, if this is a good target.

The RC also has Python 2.7.16!

Nothing definitive to report, but no cherrypy failures in the first 16 hours of operation on RC1.

Follow up: Sometime during the evening of the 24th hour, the problem recurred with 2.3.8RC1. Interestingly, the script works a few times, but later I can see clusterred temp file request failures in cherrypy even after clearing the warning log and restarting SABNZBd. Would you like a full log?

Note: I'm not sure I've ever seen the SQL errors reported by the OP.

Too bad, hoped this would fix it..
Maybe you can copy paste the errors here? Not sure what I can do about it. Maybe you can somehow give the Sab process/service more permissions?
Or maybe it's a problem of too active cleaning of the temp directory by this new windows.

Interesting line of thought. Windows 10 1809 (and Server 2019) have a built-in tool that seems to automate cleanup of temporary files. I've turned all of the features off and we'll run through it again. I'll update you in 24 hours or so.

After a little more than 24 hours of running without incident, it looks like there is a setting that remediates the problem described in this thread...

Both Windows 10 (1809) and Server 2019 (1809) automatically delete temporary files that "apps aren't using". There is no apparent configuration parameter to tune this functionality beyond turning it on and off. The setting is buried under storage management along with a bunch of other storage related settings. Default behavior is to let the system automatically manage temporary files.

• Under Windows 10 Settings/System/Storage, select "Change how we free up space automatically"

• Uncheck "Delete temporary files that my apps aren't using"

This is a per user setting that can also be set by GPO or registry, if you want to dig...
I'll advise if I see the problem reoccur.

NunyaBzness wrote: ↑March 17th, 2019, 1:25 pm Both Windows 10 (1809) and Server 2019 (1809) automatically delete temporary files that "apps aren't using". There is no apparent configuration parameter to tune this functionality beyond turning it on and off. The setting is buried under storage management along with a bunch of other storage related settings. Default behavior is to let the system automatically manage temporary files.

Thanks for posting. I had no idea Windows did this.

Well hell, after about 28 hours, the CherryPy error returned for a blip. Will keep monitoring.