If anyone wants to take charge and assign some tasks for who tests what (given that it takes time to reproduce) we may narrow this down faster.
I reproduced it on Win10, torrent client via mount - just re-checking loads of existing data.
It took a very long time though, and that may be due to Plex being far more aggressive in multi-threading it's requests? That might be a factor.
I had this after updating the beta (see here)... I thought I cleared it by recreating everything, but the issue came back. I ended up reverting back to a previous stable and assumed I'd cocked something up and so just stayed on the stable 1.49.1 which seems to run OK for me.
Testing that now to see if I can reproduce using this.
EDIT: This version claims it does not have a "mount" command? ...? That breaks a bunch of my scripts so that quite inconvenient to test from. Is this intentional @ncw ?
Until otherwise instructed - testing this instead:
It did seems able to recover from the failure though, but it did generate an I/O error to the OS. Not the exact same error, but I assume it's related since I've never seen these problems before recently.
Thanks! If that is OK then I'll wrap it up into a release.
This will come to bite us again when I release 1.50 as that is currently building with go1.13 so hopefully the go team have a fix here: https://github.com/golang/go/milestone/116
That would be a good thing to test later, to see whether 1.49.4 works or not with the not yet release go1.13.2 compiler...
Yeah, the general problem I've been having is recreating it without breaking my primary system (which I don't want to do).
I've tried a number of things to replicate, but can't seem to do it.
The problem statement seems to be related to a good number of open files (10-25ish) and a lot of quick open and closes on those files.
I tried rescanning a mount with just the problematic version, but the problem didn't reoccur. I tried running multiple ffprobe/mediainfos spawning off 20-30 at a time and couldn't get the problem back.
It's always possible the new http2 and those few days were just of a problem on the API side too. It's hard to tell for sure.
I just know for about 48 hours on that version, I was dead in the water.
For me, the problem did reoccur the next night when I ran a scan again, and even during the day when some people were streaming. This is when I was still on the latest beta. Yesterday, I switched to the build with the fix, and no more issues. Ran a full scan overnight, unprimed mount. Not a single error.
No errors on this so far but... all the other times it took a lot of time to manifest, so I wouldn't call this conclusive until I've seen it stable for significantly longer. I haven't really found any way to trigger it outside of putting the system under load for a long time.
