View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008863||MediaMonkey (current)||DB/FileMonitor||public||2011-12-15 00:06||2013-06-11 00:12|
|Target Version||4.1||Fixed in Version||4.1|
|Summary||0008863: FileMonitor: 'Remove missing items' deletes files if network tracks are inaccessible|
|Description||When MM Monitors UNC PATH and Remove Unavailable is Enabled, in case that Server/PC holding actual Files is not available at MM startup MM removes all previously scanned tracks in MM library and User loses all his statistics, playlists, ...|
Note: due the Some Linux CIFS/SMB sharing services sometimes you need to create UNC Path based on IP (eg \\192.168.1.100\Music). So if IP is not accessible apron MM startup All files are lost and needs to be rescanned.
Solution would be that in Case Server is not Accessible (\\192.168.1.100\) MM should GRAY ALL tracks instead of deleting them all where when IP gets accessible Remove Unavailable should kick in and work.
|Tags||No tags attached.|
|Fixed in build||1637|
|related to||0000863||closed||petr||Missing tracks should be deleted during a scan|
|related to||0005548||feedback||peke||Abandon handling Mapped Drives and force UNC Naming|
|related to||0003405||new||Ludek||File Monitor: Start up scans should trigger 'Remove missing tracks' dialog|
|child of||0010489||closed||Ludek||Clean-up / rationalize post-scan workflow|
Peke, afaik, this behaviour has been part of MM for the longest time--it's not new to MM4. Or, are you saying that this behavior is somehow exacerbated by UNC handling issues in MM4?
Note: I wonder if the best way to solve this would be to:
a) fix 0003405 for scans on startup
b) grey out all tracks for continuous file monitoring and prompt the user whether to delete greyed out tracks at close
Yes it is and it was not an issue till recently when NAS got affordable.
To easy understand this I'll give you example using terms of Removable Drive (Ext HDD) assuming that MM will behave same way as for UNC paths now. In which case this same behavior would be considered major bug.
1. Scan Ext HDD into MM library Create playlists, play tracks,....
2. Set File Monitor and Remove unavailable for Ext HDD
3. Close MM Undock Drive
4. Start MM And MM remove Whole Drive as Unavailable from MM library
5. Attach Ext HDD and MM do not recognize it due the 4. amd MM Library no playlists and specific track info is preserved
The solutions would be that File Monitoring UNC Paths are handled in same manner as Ext HDDs with additional Context option of manually Recheck Availability of Server to avoid unnecessary Resource usage of constant pinging of UNC Path
||I think that we can fix it in UpdateFilePath() by checking whether the given UNC path is available. I.e. before applying 'if autoRemoveDeadLinks then', we can use FindFirst() for the root path, which should give us enough info. E.g. for \\192.168.1.100\Music\Artist\Album\file.mp3 we would check \\192.168.1.100\Music for availability).|
||Fixed in build 1637|