View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011552 | MMA | Synchronization | public | 2013-12-06 02:53 | 2013-12-30 23:53 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.4 | ||||
| Target Version | 1.0.4 | Fixed in Version | 1.0.4 | ||
| Summary | 0011552: Metadata doesn't update in MMA during the pairing process | ||||
| Description | If a device doesn't have an MMA database, but it does have many tracks that were synced via MMW or another application, then when MMW syncs with MMA for the first time, track metadata isn't updated. This results in any fields that aren't saved to tags (e.g. ratings, volume leveling, etc.) not being available to MMA, despite the fact that the tracks are paired. e.g. 1 Wi-Fi sync 5 playlists to MMA 2 Delete the MMA database and /MediaMonkey directory (e.g. due to corruption on the device) 3 Re-install new version of MMA and perform WiFi Sync --> The tracks are paired as expected BUT ratings information is missing, as is volume leveling, etc. This explains the cases in the forums where users indicate that: -volume leveling isn't working -ratings are missing Edit: Note that the tracks _are_ paired, as evidenced by the fact that an edit to the metadata in a track correctly syncs to the track's pair. I did notice, though, that upon syncing for the second time, the Dialog re. First-time synchronization appeared even though it shouldn't have. This did not re-appear on subsequent syncs. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 200 | ||||
|
|
Assigned to me, as discussed with Marek this is a regression caused by the faster WiFi sync workflow (when MMW serves only tracks with changed metadata or new tracks). The fix will be relatively easy and regressionless (on MMW side). EDIT: It is regression only partially, this has never worked for tracks that were not on MMW sync-list. |
|
|
Fixed in MMW build 1678. Neverthless note that this change has significant performance impact, MMA needs to update the metadata from MMW to MMA (which seems to take quite long according to my tests), also it re-downloads all tracks that needs auto-conversion or their size differs. That said the pairing process takes much longer than before. EDIT: Currently if there is 3000 tracks in MMA that have not been paired yet, then on the initial sync MMA pairs all 3000 tracks although sync-list is empty. That's probably unacceptable, MMA should pair the tracks once are added to sync-list, but that would require further workflow changes on both MMA/MMW sides. |
|
|
Based on IM discussion with Rusty: The workaround would be to communicate to the user that this is happening. e.g. "New media files have been detected on the device. Please wait while they're updated with metadata from your Library." Note: I assume that this would only be a one-time penalty whenever tracks that are unpaired are detected. Note that only tracks that are on sync-list should be re-downloaded if their size differs (as currently designed). |
|
|
I think that a performance penalty (within reason--e.g. .02s/track) is acceptable, provided that the user is given some feedback about what is happening. e.g. during the Analyzing phase "Matching new files on the device with the library." And provided that this is a one-time penalty that only occurs for tracks that are unpaired. The question was also raised as to whether this pairing process should replace newly paired files so that they match the tracks in the library based on size/auto-conversion settings. e.g. if TrackX is found in MMA @320kbps and it also exists in MMW @128kbps, what should occur? I would propose that matching tracks shouldn't be replaced during the pairing process--only the metadata should be updated to avoid such problems. Finally, my preference (although this may not be possible at this time) would be that _only metadata for items on the auto-sync list_ should be updated. It doesn't make sense--both from a performance perspective, and from the perspective of user expectations--that the pairing process should update metadata of tracks that aren't on the sync list. |
|
|
OK, I adjusted it on MMW side: In older builds (pre 1678) MMW posted only track identifiers in the pairing reply and thus MMA updated only the track identifier into MMA DB. Starting from build 1678 MMW posts also track metadata in the pairing reply and thus MMA can update also rating, volume levelling etc. in the same SQL update. So it shouldn't degrade performance much and in addition user will be informed about it: "New media files have been detected on the device. Please wait while they're updated with metadata from your Library." Assigned to Marek to implement it on MMA side. |
|
|
Note: the following string would probably fit better with the other Analyzing strings: "Matching new files on the device with the library." |
|
|
Fixed in build 198 |
|
|
Test note: needs to be tested with MMW build 1680+ |
|
|
Verified MMW 1680 and MMA 198 using smaller number of tracks approximately 600+ to test functionality. |
|
|
Tested MMW 1680 and MMA 198 and it does not work for me, MMA is saying "Matching new files on the device...", but after that the rating is not updated in MMA. What is worse, that MMA is trying to match the unmatched tracks on every sync now! This is a regression. In previous MMA builds if a track couldn't be matched (does not exists in MMW) then MMA was not trying to match it again on next sync. |
|
|
There's one more tweak needed as well: The message is shown on just one line and so it isn't shown completely. |
|
|
Hmm, it was caused by a bug on MMW side when MMW was not serving complete info (including rating) when device profile was not deleted beforehand. this was most probably the reason why it worked fine for Peke. Fixed in MMW 1681. |
|
|
Assigned to Marek to update the progress bar. As discussed over IM, MMA should indicate rather individiual Title/Artist, if there is thousands of tracks then the progress looks like frozen (because it e.g. downloads lyrics/artwork for each track). |
|
|
Test note: metadata pairing should be tested for all fields in MMA, including multiple attribute fields (Genre, Artist, Composer) |
|
|
I'm still trying to figure this out, but somehow MMA/MMW deleted the content of all playlists that are on the auto-sync list--despite the fact that I never explicitly approved synchronization of Playlists from MMA to MMW. At this point, my theory is that the device playlists were emptied somehow during the pairing process and copied to MMW--but I'm really not sure how this occurred. EDIT: I can't seem to replicate this. Pairing seems to be working correctly for all tracks. The only possibility I can think of is that an earlier sync with build 198/and MMW 1680 caused some sort of corruption. Can any devs think of a way in which playlist content could be deleted in MMA (e.g. by terminating a sync?), and then transferred to MMW _without confirmation_? EDIT2: when I did the initial sync it was as follows: 1 Deleted /MediaMonkey directory and App data, leaving tracks and .m3u files that had been synced by 198 2 Installed 199 and ran MMA 3 After scan, proceeded to sync --> pairings occurred --> prompt to Update playlists from MMA to the server!! (even though the content should have been identical to the server) 4 I _accidentally overlooked the prompt_ and accepted it --> playlist content was transferred from MMA to MMW (and presumably deleted) |
|
|
As we discussed over IM, the pairing process in 1680 was faulty (fixed in 1681), it explained issue 0011588, but I we can't see how playlists could be emptied in MMW without confirmation. Rusty also thought about the dummy PLA: 0011550 that are created for him, but it again doesn't explain how they could get to MMW without confirmation. In addition all the empied playlists has PC change: 2013-12-09 21:46:52 in the log, so it doesn't look like a consequence of build 1680, they were changed earlier on 2013-12-09 21:46:52 and all at once in one second. But Rusty indicated that they were not empty on 10th which contradicts, but maybe they were cleared after (the log was earlier). EDIT: Most probable cause is that MMA picked the M3U playlists and added them to its new database, therefore new playlist were created in MMA (with new timestamp) and thus were suggested to sync back to MMW, Rusty overlooked it in the 'Updates' or 'Uploads' tab. During the process on MMW (or MMA?) side, MMW (or MMA?) could not find/match corresponding tracks, therefore the playlists were added as empty (cleared). |
|
|
Unfortunately, playlists have newer file timestamp so they are synced to MMW. Timestamp cannot be changed on non-rooted devices...this is a known Android bug ( https://code.google.com/p/android/issues/detail?id=18624 ). This is problematic for MediaStore too. We store correct timestamp in DB. But when you delete it...it is insolvable. |
|
|
But isn't this issue (deletion of playlist content due to a combination of the fact that playlist timestamp on the device will always show up as more recent, and failed matching of tracks on the playlist) liable to occur for users who have synced to their Android devices using MMW without having MMA installed? If yes, would it make sense that during the initial WiFi sync the date of paired playlists is set to match the date of playlists that exist in the DB? (In fact, I'm not sure if any metadata should update to the library on an initial sync) |
|
|
Fixed in build 200 Timestamp of playlists synced newly from MediaStore is set to 0 (because it is not reliable). This way these playlists are not propagated to MMW. But it is slightly slower because this kind of playlist has to be compared item by item during MediaStore sync. |
|
|
Verified 213 |
