View Issue Details

IDProjectCategoryView StatusLast Update
0008863MediaMonkey (current)DB/FileMonitorpublic2013-06-11 00:12
Reporterpeke 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformWindowsOS7OS Version-
Product Version4.0.1 
Target Version4.1Fixed in Version4.1 
Summary0008863: FileMonitor: 'Remove missing items' deletes files if network tracks are inaccessible
DescriptionWhen 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.
Additional InformationYAW-575064
http://www.mediamonkey.com/forum/viewtopic.php?f=4&t=71296
TagsNo tags attached.
Fixed in build1637

Relationships

related to 0000863 closedpetr Missing tracks should be deleted during a scan 
related to 0005548 feedbackpeke Abandon handling Mapped Drives and force UNC Naming 
related to 0003405 newLudek File Monitor: Start up scans should trigger 'Remove missing tracks' dialog 
child of 0010489 closedLudek Clean-up / rationalize post-scan workflow 

Activities

rusty

2011-12-15 03:03

administrator   ~0029475

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

peke

2011-12-15 04:07

developer   ~0029487

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.

Example:
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

jiri

2011-12-27 16:21

administrator   ~0029642

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).

Ludek

2013-05-13 11:49

developer   ~0036048

Fixed in build 1637

peke

2013-06-11 00:12

developer   ~0036410

Verified 1642