View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006647 | MMW v4 | Synchronization | public | 2010-11-05 16:41 | 2011-10-14 01:15 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0006647: Deletion of tracks that aren't on the sync list is broken (regression) | ||||
| Description | Build 1321 doesn't sync correctly with at least two iPod nano devices. 5G: popup window will appear that "Track J:\iPod _Control.... was modified in the device. Do you want to copy it over I:\Music\.... ?" Upon checking "No to all", then all tracks from iPod will be removed (even when they should be there, because they're in sync list). Then music is removed from the iPod library, though it's still on the device. 3g: Track deletion confirmation dialog appears. Click 'OK' --> Sync stops. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1442 | ||||
|
|
1. It's a regression caused by the recent changes to device handling. I found that the problem is in the fact that on: if SongsByPath.Find( fname, pointer( ss)) then fname don't have driveletter, while SongsByPath does have. In fact, it's seeded even earlier in ScanDeviceContent_Var() where d_iPod plug-in is handled in a non-standard way. This should be fixed, so that real device content is scanned (and this bug is fixed). 2. I also found out that there aren't any reasonable mechanisms for terminating long scanning of device. E.g. for WMDM devices it can take very long time. This should be fixed and tested. Note that it can free device sync on while Device.ContentIsScanning and (Device.DeviceContent = nil) do Sleep( 50); for a long time without any option for terminating it. |
|
|
Upon further testing, I can confirm that the bug also occurs with MTP devices (tracks that aren't on the sync list aren't deleted). In some cases, the sync operation proceeds but fails to delete tracks, and in others, the sync process just stalls at the 'Preparing list of tracks' stage. |
|
|
I've made some improvements re. internal path handling, but there are still more things to properly finish, mainly Device.DeviceContent handling, since it isn't updated at all. |
|
|
Fixed all the described issues + made huge device scanning speed improvements for devices with known drive letter. Fixed in build 1323. |
|
|
Verified 1323. |
|
|
Tested 1324 on an iPod Touch 3G and tracks are not being deleted from the synch list :( |
|
|
I could reproduce it only for tracks that wasn't in iPod DB, I suspect it was your case. Fixed in build 1325. |
|
|
Re-opened, issue re-appears in build 1344: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=55071 [^] http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=54578&hilit=iphone [^] http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=10906 [^] |
|
|
Fixed in build 1345 |
|
|
It is still deleting and resyncing playlist items each sync |
|
|
Fixed in 1346 |
|
|
verified 1375 |
|
|
Re-opened, there is one more issue: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=60862 If the Device->Options->Destination->Sync Music files to: \Music\<Album Artist>\<Album>\$If(<Disc#>,<Disc#>\,)<Track#:2> <Title> but the folder on the device is all capitals, i.e. 'L:\MUSIC\' then this functionality fails. If you rename the folder on the device to 'L:\Music\' then this functionality works. Fixed in build 1442. |
|
|
Verified 1444 |
