View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019326 | MMW 5 | FileMonitor / Find Missing | public | 2022-08-24 14:39 | 2023-06-30 09:50 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| Product Version | 5.0 | ||||
| Target Version | 5.1 | ||||
| Summary | 0019326: File monitor doesn't correctly deal with moved files | ||||
| Description | Based on ticket 4639, it appears that if MM is monitoring Parent folder X, it won't _properly_ detect movement of files from subfolder x-a to subfolder x-b. I haven't tested any of this, but based on Peke's analysis, if TrackX is part of PlaylistY, and Windows Explorer is used to move TrackX from subfolder x-a to subfolder x-b, then MM will: Case I: 'Remove unavailable items' is enabled - Remove the track from subfolder x-a - Add the track to subfolder x-b - Delete the track from PlaylistY Case II: 'Remove unavailable items' is disabled - Add the track to subfolder x-b - Leave the inaccessible track in subfolder x-a and in PlaylistY For most users, this isn't the desired behavior. Most users would expect that MM would just 'move' the track and adjust Playlists automatically (and that the 'Remove unavailable tracks' option only applies for cases where the track has been completely removed from the library). Could this be implemented using 'matching' logic similar to MMA's sync logic? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I checked the code and testing this and it actually already works the suggested way. 1) Scanned file C:\Temp\Testing\sf1\test1.mp3 into fresh database and added to a playlist 2) Enabled continuous file monioring for C:\Temp\Testing\ 3) Moved C:\Temp\Testing\sf1\test1.mp3 to C:\Temp\Testing\sf2\test1.mp3 => path has been correctly updated for the file in the database and the playlist preserved with link to the new path In the debug log I saw: [8080] MM5 [17652](R) Auto-scan: Found candidate for source of move - C:\Temp\Testing\sf1\test1.mp3 So resolving, please re-test and in case it fails for you generate debug log. |
