View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000863 | MMW v4 | DB/FileMonitor | public | 2003-11-03 21:23 | 2007-08-17 19:02 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0000863: Missing tracks should be deleted during a scan | ||||
| Description | One of the biggest areas of confusion with MM is that users are unclear why duplicates occur in their libraries. This problem stems from the fact that Scanning a directory doesn't also check for deleted tracks. This can easily be resolved by automatically checking whether tracks that are supposed to be within the directory being scanned, actually exist. This would occur for any manually initiated scan, but I wonder whether it would also make sense for this to occur for a startup scan by the File Monitor. After the scan occurs, the following would appear if tracks have been removed: ----------------------------------------------------------------- Remove Unavailable Tracks? ----------------------------------------------------------------- The following tracks could not be found in their expected locations. Do you want to remove them from the Library? --------------------------------------------------------------- [ ] Title Artist Path --------------------------------------------------------------- [ ] Title1 Artist1 Path1 ... ... --------------------------------------------------------------- ----------------------------------------------------------------- [Locate Moved/Missing Tracks] [Remove] [Cancel] ----------------------------------------------------------------- If the user: 1) Checks/unchecks a track then whatever action is selected is performed on that track 2) Checks unchecks the checkbox in the header, then all tracks are checked/unchecked 3) Clicks Locate Moved/Missing Tracks ---> The Locate Moved/Missing Tracks function is performed (if Gold) on the selected tracks. The Remove Unavailable tracks dialog is closed. 4) Clicks [Delete] --> Selected tracks are removed and the dialog is closed. Note: 5) We could make this behavior optional if we wanted (do not ask again) 6) It would also make sense to improve the Locate Moved/Missing Tracks dialog a bit by: --Adding checkboxes next to the tracks --Adding a 'Remove' button on the 'Unlocated Tracks' tab so that the user can remove such tracks from the library | ||||
| Additional Information | This bug was previously titled: Rationalize the Add Folders/File Monitor/Locate Missing Tracks functions. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1060 | ||||
| related to | 0003004 | closed | jiri | Locate Moved Missing Tracks: always fails when track timestamp doesn't match |
| related to | 0003404 | closed | petr | Locate Moved/Missing Tracks: Update & Remove buttons are a bit confusing |
| has duplicate | 0000280 | closed | rusty | New feature: ability to run the File Monitor manually |
| related to | 0003195 | feedback | rusty | Start File Monitor only sometimes on startup of MM |
| related to | 0003405 | new | Ludek | File Monitor: Start up scans should trigger 'Remove missing tracks' dialog |
| related to | 0008863 | closed | Ludek | FileMonitor: 'Remove missing items' deletes files if network tracks are inaccessible |
| child of | 0010489 | closed | Ludek | Clean-up / rationalize post-scan workflow |
|
|
Set as 'immediate' due to new strings. |
|
|
Assignign to Petr. I was thinking about an implementation that wouldn't cause performance or other problems. I'd suggest to keep track of IDs of tracks scanned in each folder and in the end of folder scan select from DB tracks that are in that folder (use new Folders DB table), but aren't in the set of IDs scanned in this batch. In the end of scanning, all tracks from all scanned folders would be shown according to the specification. |
|
|
Assignign to Petr. I was thinking about an implementation that wouldn't cause performance or other problems. I'd suggest to keep track of IDs of tracks scanned in each folder and in the end of folder scan select from DB tracks that are in that folder (use new Folders DB table), but aren't in the set of IDs scanned in this batch. In the end of scanning, all tracks from all scanned folders would be shown according to the specification. |
|
|
Done. Will be available in build 1060. |
|
|
Verified 1060. |
