Universal Media Server | Forum

I'm using UMS to play music on my media player (Sangean WFT-3) and use the Android app "Hi-Fi Cast - Music Player" to select and play the files. In this app I can select UMS as the media server and my Sangean as the media player. UMS is instaled on a Windows 10 pc and the shared folders are also on this pc.
This combination works perfect.

One thing I noticed now is that folders where I played music from cannot be deleted on the pc, even when the app is no longer playing files from that folder. The files themselves can be deleted, but when I try to delete a folder that contains played files there's an error on the Windows pc that I am not allowed to remove that folder. I have to shutdown UMS, remove the folder (now that works!) and restart UMS again. It is obviously not the app that's holding the folder open. Even when I close the app or shutdown my phone (on which the app is installed) I cannot remove the folder. The only way to delete the folder is to quit UMS.

Is this normal behavior? Or is there easier way to delete a folder from which no music files are played that moment?

JDN

This is probably caused by shared folders being "monitored". You can try to disable "monitoring" on the shared folder in question and see if that helps, although I'm not sure if that completely disables monitoring.

"Monitoring" means that UMS opens a "subscription" with Windows to receive notifications for all changes to that folder. As long as this subscription hasn't been revoked, Windows will prevent the folder from being deleted.

Do you mean the checkbox "Monitor played status of files" in the "Shared Content" tab?
I unchecked the checkboxes and restarted UMS, however the problem is still there.
Every time I played files with the app, I cannot remove the folder in Windows until I shut down UMS.
I tried another DLNA media player app: BubbleUPnP, and with this app the same problem.

What in UMS is preventing the folder from being deleted? Why must I shut down UMS before I can deleted the Windows folder?

Its probably the Media Library keeping track of all your files, holding open the folders looking for any changes. Maybe try disabling that.

As I said, UMS "subscribes" to changes in the shared folders, and the mere existence of such a "subscription" prevents the folders from being deleted. This is a known problem with Windows itself, and will apply to all applications that utilize folder monitoring.

I did mean "Monitor played status of files", but I also suggested that turning this off no longer fully disables folder monitoring. As such, there is nothing much you can do other than finding another "routine" so that you don't have to keep deleting folders within your shared folders.

I have noticed this too but not every time. Sometimes I can delete it and sometimes not. Usually it frees it up eventually for me. But yes like Nadahar said it is a problem with Windows itself, I have looked into fixing it before. If anyone knows of a fix please let us know.

It is not the checkbox "Monitor played status of files", this setting has no effect on the problem.
But I discovered another interesting thing using the tool Process Explorer that I ran on the Windows pc where UMS is running.
https://docs.microsoft.com/en-us/sysint ... s-explorer

Everytime I browse UMS folders in my BubbleUPnP app, the folder (including all subfolders!) is shown in Process Explorer as folder that is in use by the process "javaw.exe". When a music file is played, that file is also shown as file in use by javaw.exe. However, as soon as the music file has been played (or stopped playing) it vanishes from Process Explorer (no longer in use by javaw.exe), but the folder remains visible as in use by javaw.exe. Even when a music file is played from a total different folder, the former folder remains open in javaw.exe. Even if I close the BubbleUPnP app the folder stays visible in Process Explorer as in use by javaw.exe. Shutting down UMS (or stopping the Java process) is the only way to unlock the folder.

This explains that you can delete files without problem, but the folder can't be deleted because it is still in use by javaw.exe. So, it seems a kind of a bug in UMS that folders are kept open unnecessary.

As we tried to explain already, this seems to be a problem with the operating system itself. We are asking Java to monitor the folder for changes, and Java is asking the operating system (Windows) to monitor for changes, and Windows is choosing to lock them even though we don't want it to lock that folder.
That is my current understanding of the problem anyway; we don't have any code in UMS that is locking the folder, we are only asking Java to use a feature it has.