www.makemkv.com

If there is something that can be tweaked, I'd like to know about it.

In my case, it is the specific TASK that loses access. These are CMD windows, running under Windows. If the glitch happens when the particular window is writing, there is a 20% or so chance that the window is "dead" as far as network access until I close it and open another copy. But other CMD windows can be just fine.

That would be consistent with your case; MakeMKV can't access, but another window does just fine, even if both were OPEN at the time the glitch occurred.

Your work flow is similar to mine - all MakeMKV rips write to the NAS, then handbrake (often on a different machine) reads from the "rawvid" share and writes to the final location on the NAS for playback. The NAS even has the batch file for handbrake.

Random failure is the worst, far worse than what's bugging me, and it isn't like you can ask Microsoft to fix CMD.

For our situations to be the same, MakeMKV would need to succeed writing directly to the NAS 80% of the time and all the other apps that succeed would need to fail 20% of the time. The other apps always succeed, and so far MakeMKV has not made it past 2.6 gb in about 10 tests.

I'm going to focus on my correction from my last post by looking at my NAS logs. The fact that I can't delete the file in Windows without first rebooting ONLY the NAS tells me the NAS might have some detail about the problem. All my shares become inaccessible, so I'm thinking smbd.

I haven't built a Handbrake workflow yet, I'm just toying with it. Any recommendations/links on use?

My normal workflow is suitable for what I normally do - add anime series to the NAS, where there are 6 to several hundred episodes that all have the same characteristics. It isn't as workable for dealing with, say, 20 movies that have different audio and other characteristics between each. And it runs primarily from the CMD prompt as batch jobs.

But that is mainly on the handbrake side of the equation, which puts it outside of discussion here...

So, I ran across this issue recently when I switched from the Mac version, to the Windows version. Nothing against the Mac version, its just a switched up the system my BR's are connected to.

I couldn't see any mapped drives, however, I was able to access them via UNC path. If you don't know what a UNC path is, example: \\server\share\folder\ instead of z:\folder\

Turns out the issue is that windows decided to consider the Network the devices sit on a Public network. The solution is to switch the network from a Public network to a Private network, which is what enables the file & print sharing services on that network.

Here's MS's article on how to switch.
https://support.microsoft.com/en-us/win ... %20Private.