View Issue Details

IDProjectCategoryView StatusLast Update
0012392MMAAction barpublic2019-11-11 12:17
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status assignedResolutionreopened 
Target Version2.1.0 
Summary0012392: Deleted track is synced back to the device
DescriptionIf the user deletes a track from a playlist in MMA, then upon syncing the playlist the track will be copied back to MMA!

This is probably due to the fact that the Playlist is synced _after_ the content rather than before the content.

Note: I'm pretty sure that we had previously resolved this bug, but I can't seem to find it. Similar one is at 0011009
Steps To Reproduce1 Wi-Fi Sync Playlist A
2 In MMA, delete Track C from Playlist A & the device
3 Initiate Wi-Fi sync
--> Track C is copied back to the device!!
--> Playlist A is updated in MMW so that it no longer includes Track C
4 Initiate 2nd Wi-Fi sync
--> Track C is deleted from the device.
Additional Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=21&t=78497
TagsNo tags attached.
Fixed in build1723

Relationships

related to 0011009 closedmarek Auto-sync: playlists fail to update with added tracks (regression) 

Activities

marek

2014-11-30 19:49

developer   ~0041221

I am able to reproduce:
1. MMA sends new playlist content to MMW
2. MMA requests synclist and it still contains the deleted track

MMW probably doesn't refresh it's synclist

Ludek

2014-12-02 11:49

developer   ~0041273

Last edited: 2014-12-02 11:53

I don't think that this particular case is a regression, but probably never noticed, because user mostly deletes tracks just from playlist and not from the the device at the same time.

The refresh on MMW side will be more complicated because of the random auto-playlists, its content is dynamic and therfore is cached during WiFi sync, MMW will need to refresh just the affected playlist and keep the cached auto-playlist content unchanged.

Ludek

2014-12-02 12:03

developer   ~0041274

Last edited: 2014-12-02 12:03

Thinking about it again it really might be a regression, i thing that previously MMA did not ask for playlist content during the confirmation phase so the sync-list was builded after the confirmations.
Solving with Marek...

Ludek

2014-12-02 13:37

developer   ~0041275

Last edited: 2014-12-02 14:24

The whole situation is getting more complicated with the random auto-playlists, there can happen that deleting TrackA from PlaylistA in MMA can cause that also AutoPlaylistA content needs to be refreshed in case the AutoPlaylistA criteria looks like this:
Playlist is: 'PlaylistA'
Limit: 5 tracks
Order: Random

So I will need to refresh content for all playlists during sync (including APs), but the negative impact will be that there can be more tracks in the device after sync than actually should be, because MMA deletes tracks on the sync start (after confirmation dialog is shown). The tracks will be deleted on next sync start.

Fixed in build 4.1.6.1723.


Note that the main problem here is that (at the time of showing confirmations) MMA/MMW cannot know what _exactly_ should be shown in confirmations, because the actions are dependent.
e.g. uploading a 5 star track can cause that '5 stars tracks' auto-playlist needs to be rebuilded and thus cause that some others tracks should be deleted from the device as consequence of the upload action. The only solution would be to split the confirmation dialog into more dialogs (depending on the action, as we used to have in the past), but this would be less user friendly.

rusty

2014-12-04 01:23

administrator   ~0041301

Last edited: 2014-12-04 05:40

I happened to delete several playlists from my Android device and then resynced and _all_ of the content from all of the playlists that were deleted (1600 tracks) are being resynced, even though only 25 tracks should!

In addition, when I tested MMA 1.0.7 against the new build, if I deleted one playlist from MMA and resynced, then all of the other playlists were duplicated following the sync operation. I'll test this with 1.1.0 as soon as tracks get recopied (see the bug above).

peke

2014-12-04 01:48

developer   ~0041302

Reopening, As talked with Russell on IM Deleting Playlist on device Resync whole playlist in next sync.

Question is how to handle if user wanted to delete whole playlist and shouldn't MMW detect that tracks are already on device.

Note: that it doesn't sync tracks that are we not in playlists.

peke

2014-12-04 02:21

developer   ~0041304

Additionally wouldn't be better to avoud not needed refreshes which can take too much time on some complex auto playlist.

rusty

2014-12-04 06:39

administrator   ~0041310

Last edited: 2014-12-09 00:17

Further testing reveals that the issue reported at 0012392:0041301 (all content syncing when playlists were deleted), is not an issue, but a test error (when testing another device, a playlist was actually added to this devices auto-sync list).

As to the issue with MMA 1.0.7 of duplicate playlists when re-syncing following deletion of a playlist, it doesn't occur with MMA 1.1.0.

I'm not quite sure I understand what issue Peke is raising--he indicated some other problems that he'd experienced--but I'm not clear on the problem. Re-resolving and leaving for Peke to either verify or re-open.

peke

2014-12-04 10:30

developer   ~0041311

Verified Issues I was experiencing are related to 0012411 but triggered on track deletion due the sync back.

rusty

2014-12-08 20:22

administrator   ~0041371

This issue should not have been 'closed'.

Users have reported that the originally reported issue hasn't been fixed. I'm able to reproduce it as well using MMA 352 vs MMW 1723.

Ludek

2014-12-09 13:05

developer   ~0041379

Rusty, are you sure it is not again the test error you mentioned in 0012392:0041310 ?

i.e. that a playlist including the same track was not auto added to sync list?

The best would be to test just with very small group of tracks and a single playlist. If you are sure that you are still observing the issue with 1723 then please generate log and indicate which track is not supposed to be copied according to you.

rusty

2014-12-09 15:08

administrator   ~0041384

Last edited: 2014-12-09 15:17

Tested as follows:

1 Sync playlist called 'Sync Test', consisting of:
Stranger in my house
Uncle Dysfunktional
White Skin Black Heart

2 In MMA open playlist 'Sync Test', select 'White Skin Black Heart', press DELETE and use the 'Remove from Playlist and Delete from Device' option.
--> Track is removed from the playlist and Deleted from the device (verified by examining the playlist and searching for the track)

3 Initiate Wi-Fi Sync
--> MMA shows no confirmation dialog prompting for deletion of the track and the track 'White Skin Black Heart' is synced back to MMA (as viewed in the sync status).
--> Examination of MMA shows that the track 'White Skin Black Heart' is back in the sync list

I performed steps 2 and 3 twice in the following logs:
MMA Debug log: GTQLSFSPCA
MMW log: Posted to ftp

Note: If I just 'Remove from Playlist' (instead of Remove from Playlist and Delete from device' then synchronization works as expected (i.e. MMA prompts whether the playlist should be updated on the server and the playlist is then updated).

Ludek

2014-12-09 16:41

developer   ~0041387

Last edited: 2014-12-09 16:49

I haven't found the MMW log on FTP, but based on Rusty's description it looks that MMA doesn't update playlist timestamp or doesn't consider the playlist as changed when the "Remove from Playlist and Delete from device" choice is selected? Thus it also doesn't propagate the playlist change to MMW and thus the track still remains on the sync list.

I just tested the "Remove from Playlist and Delete from device" choice and I see the same. If I use the "Remove from Playlist" choice and then I delete the track from another view in MMA the issue does not happen (this is the reason why I couldn't reproduce the issue - due to different steps in MMA)

peke

2014-12-09 21:17

developer   ~0041393

Last edited: 2014-12-12 19:05

I can replicate like described as 1. in 0012411:0041322 and can confirm once Time is in Sync it doesnt happen. Exactly like Ludek found and described at 0012411:0041323 and concluded in 0012392:0041387