Unable to access mapped drive

[mgolub]

I have a Synology drive array and I've created a mapped drive to the folder I want to store my videos. However, in MakeMKV, this mapped drive is not visible. What might I be missing?

Thanks in advance.

MG

[taylorwmj]

What OS are you using? (I'm assuming windows since you said "mapped").

In said OS, what method are you using to connect to this synology NAS drive? Do you know what service the synology is running for your OS to see it?

Are you able to see the synology drive via normal file explorer?

[mgolub]

Correct, Windows 10. Yes, I can see the drive in Windows Explorer. It is mapped with the Synology Assistant which shows a shared folder IP (\\192.168.1.138\movies) mapping to Y:, the drive letter I see in Windows Explorer

MG

[taylorwmj]

It is mapped with the Synology Assistant which shows a shared folder IP (\\192.168.1.138\movies) mapping to Y

Any way you can "undo" this action by the Synology Assistant? I'm not familiar with it, but perhaps something is going on with this. Can you just add the mapped network drive via Windows Explorer in the standard fashion?

Also, I have to admit, I've not used 10 a whole lot, but I do seem to remember some issues with MakeMKV users and Windows 10, but don't remember the specifics....

[mgolub]

When I open the drive in Windows Explorer it shows that it's already mapped. I disconnected and reconnected on another drive letter which is still not seen by MakeMKV. I don't know if this is a Win10 issue or not, I didn't try this prior to upgrading on this machine.

For now I'll just rip to a local folder and copy to the Synology. Just seems it should be seen as other programs can access the mapped drive. The Synology is serving Plex and it's a D415+. Don't know if this has anything to do with it either. MKV is today's version.

MG

[Woodstock]

Synology boxes work with MakeMKV, as long as the share is mapped as a drive letter. I have my "raw video" share mapped as Z:, and the share that contains processed (ready for media players) is V:.

I don't remember how well MakeMKV works with URI notation as opposed to mapped drive letters... Will have to test.

[mgolub]

As stated, the drive is mapped to Y: and other programs, including Windows Explorer are able to access the folders through the drive letter, even from the command prompt. This might be a W10 problem as I didn't try it prior to upgrading.

MG

[neilball]

No problems accessing shared folder on my DS1815+ via mapped drive in W10, but I mapped it in Windows using the '//server-name/shared-folder' notation not the IP address.

[taylorwmj]

Definitely would try and map it via IP instead. Can't go wrong there...usually.

[Woodstock]

I ran a test on 1813+ using URI access, and it worked fine on Win7, so the question is why mgolub's system is having issue with it.

Have tried WRITING to the share using explorer? Windows may be treating it as a read-only share.

[mgolub]

No problem writing to the share as I've been writing the ripped files to the C drive then copying to the Synology. I tried mapping with the IP and that didn't work. I can try \\servername\ and see if that works tonight when I get back home.

MG

[sasja]

I have the same problem. I've been able to write to my NAS from Windows before using makemkv, but now nothing I do works.

I've tried mapping the drive using both the synology tool and windows normal ip mapping (seems like you get exactly the same either way) and the //servername/sharedfolder notation. The mapped drive doesn't show up when browsing for a location, and trying to write to it results in an invalid error. I can write to my drive from Windows, so it's not read-only. Can it be because of the plex-server, I installed? Or is it Windows 10 (can't remember if I ran Windows 10 last time).

Please help - I don't have room on my pc harddisc for a full bluray movie, so I can't even use the obvious work-around.

Edit: Funny how writing your problem out can help. I uninstalled the plex server, and suddenly a popup showed in my windows network folder urging me to turn on map sharing. Now the //server/shared folder works like a charm. Thanks for being here ;-p I hope this will help someone else as clueless as I am.

[sleevemedia]

Setup:
MakeMKV 1.10.4 x64
Synology DS716+II
one WD MyBook on Synology's USB 3.0
Windows 10

I've had the NAS for a month, the WD has only been on the NAS external USB since Wednesday. I moved the WD from a direct USB 3.0 connection on the W10 PC to a USB 3.0 port on the DS716.

Today is the first day, after moving the WD from the W10 PC to the NAS, that I tried to use MakeMKV to write its output directly to the WD as a mapped drive in W10. It started great, in fact it flew - 4.1x BD rip. On one disc, wham, it stopped at 1.8 gig. On another, 2.6 gig.

"Stopped" means:
- OS error in the MakeMKV screen
- DiskStation can't delete the partial rip, but remains responsive to cancel the delete
- Windows Explorer stops responding not only if I try to delete the file, but even if I try to look at its properties, because the shares have disconnected
- Reboot W10 PC and the shares connect and I can delete the partial rip

Now I'm 80% done ripping the second disc to a local disk that didn't rip to the NAS directly. While the second rip was writing, I copied the first rip (33 gb) to the NAS share with no errors (100MB/s+).

This means:
- It's not file size, the 33 gig MKV copied nicely, one of my Acronis backups is 300 gig.
- It's not the BD discs, they ripped to local drives.
- The rip actually starts and writes more than a gig, so it's not permissions.

Anyone have any thoughts, anything I can rule out before pinging Mike?

[Woodstock]

This is a Windows issue, and I've been dealing with it in a different context (work network) for 2 years.

Windows does NOT like it when a network resource times out on a write. Timeouts happen - They shouldn't, but they do. Windows responds by taking the resource "off line", even if it isn't, and directory structures can be tainted by its response. Sometimes the mapped drive is simply not available until the Windows machine is reset.

In my case, I've had to log into the Synology web interface and use the file manager to delete partial files in some cases. Files that were being READ (rather than written) were deleted in the glitch. Our setup runs multiple DOS-based tasks on a single Windows machine, and only the tasks that were WRITING at the time of the network glitch are affected; anything that was paused continues on just fine at the end of their pause.

One suggestion - make sure your Synololgy is not configured to automatically apply ANY system or package updates. When it does an update, the various server tasks are momentarily interrupted. It may only be a second or two, but any connected Windows machines can get hopelessly confused. I schedule regular times to "quiet" the entire network before doing server updates (it isn't just a Synology thing), to avoid this issue.

[sleevemedia]

Thanks for the immediate reply. I wonder why the Explorer file copy of the resulting locally written MKV consistently works, my Acronis 300 gig backup that takes an hour and 40 minutes works, but MakeMKV's luck with getting Windows to do its job ends at 700mb, 1.8gb, 2.6gb - in other words, random points far faster than these other succeeding tasks. I would expect my backups to have no hope of succeeding. DSM resource manager shows that the backup is writing at gigabit Ethernet limits, same as MakeMKV.

Your answer is sensible, thanks, but isn't this still a bit odd?

I'm doing a test with Handbrake as I write this, pulling a 30gb MKV remote from the NAS, repackaging to MP4, resizing to 1920x800, then writing it directly back to the NAS. 45 minutes in, longer than a typical MakeMKV task, and no problems. Handbrake needs a lot more think time for this than MakeMKV does for its work, so the network traffic is much lower.

Maybe there's something specific that could be tweaked in MakeMKV to get around / not use the Windows method that causes it problems? To me, it seems that software that does similar work for similar or longer periods of time is not subject to the same problem as MakeMKV.

I have no intrusion detection/prevention between systems on my internal LAN. MakeMKV is whitelisted/excluded explicitly where necessary so that nothing stops it for malware-like behavior. Plus, as you know, it isn't MakeMKV getting stopped, it's the NAS gagging on what it is sent.

Correcting the sequence in my first post, I can't delete the partial file until I reboot the NAS. Even if I reboot Windows, it won't delete. If I reboot the NAS, I don't need to reboot Windows to delete the partial.