Is this expected behavior for missing files?

[CrashMonkey]

Sometimes, when network is unavailable or after a crash, files seem to "lose" location in mm.

For example;
Network share for video was unavailable, driveletter was disconnected during mm startup.
In mm files show up white as [Video]\path-to-video\video-name.avi
Check network share, and was able to start the video on the exact location. By doing this, networkshare was reconnected.
When double click in MM , it goes gray, and the first bracket [ is removed. Result: Video]\path-to-video\video-name.avi
Same happens for audio.
https://imgur.com/tVXJ6pc

What i can do now is, locate/missing files, and update there links. (Manual work)
Or close MM, start it up again. then all movies show up as available again but then with result T:\path-to-video\video-name.avi

So they lose location, but after a restarts find it again?
Is the removal of the [ intentend?
The progress as i describe it, is this the expected behavior. As i would think, if a networkshare is back online, double clicking a file that lost it's connection should be able to find the drive letter again after it is reconnected. As a reboot of mm does the same, and still knows that Video get the drive letter T. Could this be improved that doubleclicking a file that 'lost' a driveletter could check if the drive is back online, and then update all those [video] tags to the driveletter it self?

Why did i use the driveletters for these files in the first place. My mistake, i forgot that i need to add them as UNC path instead of with a drive letter.

---
MM also generates duplicated database items, i need to remove at least a few songs a month:
The one called [music]\Music\song.extension is a duplicated. Locate moved/missing items are never able to find the item on the exact location. As i assume the cause, the song is already in the database under the same name.
https://imgur.com/QyxeQvv

Whats the best action to capture/log something like this, as it is not something you notice while just using the app or expect after a crash. And so only seeing this when actually sorting all database items on there path value.

[Lowlander]

This is why UNC Paths are recommended instead of Mapped Drives. Mapped Drives are known to cause these types of issues with MediaMonkey.

And duplicates are expected if you scan the same file from both the UNC Path as well as it's Mapped Drive location. They're seen as separate locations as they have different Paths.

[CrashMonkey]

When clicking the white song in the picture, is it supose to remove the [ when turning gray?
https://imgur.com/jusWD5e

I think this should not happen?

[Lowlander]

No, but that's not the real issue. The problem is that MediaMonkey can't connect to the driveID. Either because the Mapped Drive isn't available or because Windows changed the driveID when reconnecting the drive. Either issue is avoided when using UNC Paths.

[CrashMonkey]

In my first topic i already explained that i did forgot for some items the UNC path. And that i solved it.
However i noticed some things that i could consider a bug, and thats why i am verifing that here.

So to prevent confusion about the missing [ do i need to report that, so it can be added in MM.
That would make it look beter, when it happens to people.

[CrashMonkey]

And duplicates are expected if you scan the same file from both the UNC Path as well as it's Mapped Drive location. They're seen as separate locations as they have different Paths.

Those duplicates where done by MM and not by me by rescanning, they where for 6months on the UNC path. and once in a while some items are duplicated and shown gray on a mapped drive.
Thats why i was asking how to debug this, as it is quite annoying if you have to clean duplicated items once in a while.

[Peke]

Hi,
It really depends on how you monitor your folders, MM will not add mapped drive letter tracks unless they are added to monitor or import playlists that contain tracks on those mapped letters.