[REQ] backup and restore auto-playlists

Get help for different MediaMonkey 5 Addons.

Moderators: jiri, drakinite, Addon Administrators

Barry4679
Posts: 2399
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: [REQ] backup and restore auto-playlists

Post by Barry4679 »

ZvezdanD wrote: Fri Nov 25, 2022 11:04 amI am not sure that understand your mentioning of "break playlist criteria links when a user does some simple retagging" and "the JSON data in the source MM database would still be correct, but the ID has been broken". Could you please give a more detailed explanation or steps to reproduce?
I explained this before.

My general observation is that you are taking great care to migrate something where MM5 itself does a poor job to keep valid ... ie. you are somewhat impacted by Garbage In == Garbage Out, admittedly only in some corner cases. ... This is a comment about MM5, not what you are planning.

And, ironically, in at least one case you would have got a more accurate result if you had used the JSOn fields instead of the (potentially broken) IDs

Steps below.

But first, I am not trying to diss what you are planning to do (or ? have already done?). I am just making the general points
  • that a simple migration facility using JSON data would be a lot better than having no migration facility
  • and that a "simple migration facility would OK for my own personal Use Case
  • is OK to stop talking about this now? I get it that you don't agree
Here are some steps showing how MM5 fails to protect autoplaylists. ... these are just my observations ... maybe there is some corrective mechanism using the JSON data, but I Haven't been able to trigger it, so I doubt that it exists.
  1. create autoplaylist where criteria is Album - "The Dark Side of the Moon" ... select the album from the list provided by the MM5 autoplaylist wizard
  2. then (later) select all tracks in the album, and retag to change, or add, an albumartist tag ... eg. add Roger Waters ==> MM5 it creates a new row in the albums table, with a new IDAlbum
  3. MM5 does not alter the autoplaylist ... the playlist is now broken
  4. ironicaly the JSON field is still accurate, so in this case at least you would have got a function playlist if you migrated using the JSON field
  1. Or create autoplaylist where criteria is Album - "The Dark Side of the Moon" ... select the album from the list provided by the MM5 autoplaylist wizard
  2. then (later) select all tracks in the album, and retag to change the album name to 'Dark Side of the Moon'" ==> MM5 doesn't just alter the album name .. it creates a new row in the albums table, with a new IDAlbum
  3. MM5 does not alter the autoplaylist ... the playlist is now broken ... ie. is not protected by the fact that it used IDs
  4. in this case you would no better off if you used the JSON data
  5. nb. MM5 does reuse the AlbumID if the retagging is made from the Album detail panel, .. but not done from the main panels ... so this is "correct" way to do this retagging, but who knows that??
And the same thing happens when artist names are altered ==> new ID ID ==> autoplaylists are potentially broken.
My guess is that this is just a sub-set of situations where autoplaylists appear to become trashed.

And then there is the case of a DB REBUILD (ie. using the new MM5 DB Management option) ... that reassigns all album IDs, and probably other IDs also ... I haven't tested it, but I wonder if autoplaylists that are based on those Ids are protected?
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
ZvezdanD
Posts: 3257
Joined: Thu Jun 08, 2006 7:40 pm

Re: [REQ] backup and restore auto-playlists

Post by ZvezdanD »

A simple migration facility using JSON data wouldn't be better at all if it gives wrong data. You cannot get correct data without using IDs. Would you be OK if you get something that you don't expect?

The behavior that you are describing is intended, the program behaves like that since the beginning. You would think that if you select all tracks from an album and if you bulk retag these tracks that the operation is done in a single step, but in fact you will get executed a series of operations. For example, when you select all tracks from "The Dark Side of the Moon" and change its name to 'Dark Side of the Moon'" in the Properties dialog box, the program will first add a new album by that new name with the new ID, then:
- it will reassign the first track from that old album to the new one -> the old album will have one track less, but it will still contain the remaining tracks;
- then it will reassign the second track from the old album to the new one -> the old album will have two tracks less, but it will still contain the remaining tracks;
- and so on, until the last track is reassigned and the old album is left without any track. I don't know what happens in that case and cannot test it right now, but I expect that the program removes the old album record from the Albums table. The program cannot know what you did with it, and hence it will not alter the IDs in auto-playlists (and collections with the similar criteria). If you think that such behavior is wrong, you should report it as a bug to the MM developers.

However, I would do the next test. What happens if you change an album name in the Albums node of the Media Tree, instead of selecting all tracks from it and using the Properties dialog to retag the tracks? Maybe I will test it latter.
Magic Nodes 4.3.3 / 5.2 RegExp Find & Replace 4.4.9 / 5.2  Invert Selection/Select None 1.5.1  Export/Create Playlists for Child Nodes 4.1.1 / 5.4.1  Expand Child Nodes/Expand All 1.1.2  Event Logger 2.7  Filtered Statistics Report 1.6  Track Redirection & Synchronization 3.4.2  Restore/Synchronize Database 3.1.8 / 4.0.1  Find Currently Playing Track 1.3.2  Queue List 1.2.1  Add to Library on Play 1.0.1  Tree Report for Child Nodes 1.1.1  Update Location of Files in Database 1.4.5 / 2.3  Inherit Child Playlists 1.0.3  Add Currently Playing/Selected Track(s) to Playlist 1.2
Barry4679
Posts: 2399
Joined: Fri Sep 11, 2009 8:07 am
Location: Australia
Contact:

Re: [REQ] backup and restore auto-playlists

Post by Barry4679 »

ZvezdanD wrote: Sat Nov 26, 2022 6:41 am The behavior that you are describing is intended, the program behaves like that since the beginning.
You say that like it is a benefit, or should be expected, from a User perspective.
I doubt that it is "intended". At best it is something that they didn't think through, but maybe it was an intentional shortcut, because they didn't place too much importance upon protecting the contents of auto playlists.
ZvezdanD wrote: Sat Nov 26, 2022 6:41 amYou would think that if you select all tracks from an album and if you bulk retag these tracks that the operation is done in a single step. ----- [snip] ---- The program cannot know what you did with it, and hence it will not alter the IDs in auto-playlists (and collections with the similar criteria).
Yes I understand what happens at the database level.

But the user did just one transaction, ie select all tracks from an album, and retag them all as a group.

If the MM Devs cared as much about the sanctity of a playlist as you do, they could have detected that all tracks for the album were about to be modified .. they could have done an album rename in these situations, so that a the album was not a assigned a new album ID. ...

Same thing when an albumartist tag is bulk changed, or a new albumartist tag added. The fact that this operation reassigns a new album ID, and breaks auto playlists, seems even less excusable to me .... And I am convinced that neither of these things would be expected or understood by the majority of Users.

BTW this may be what the new json data is for.. ?. ... Maybe they are planning a SQL Delete trigger to repair auto playlists that become broken like this??
ZvezdanD wrote: Sat Nov 26, 2022 6:41 am If you think that such behavior is wrong, you should report it as a bug to the MM developers.
They can see this thread.
I am not going to report it, because as already discussed I don't hold auto playlists as being too important, and there is a lot of other things that I would rank ahead of this.

ZvezdanD wrote: Sat Nov 26, 2022 6:41 am However, I would do the next test. What happens if you change an album name in the Albums node of the Media Tree, instead of selecting all tracks from it and using the Properties dialog to retag the tracks? Maybe I will test it latter.
There is no need to do that test. As I have said twice already in this thread, a rename from the Album or Artist Detail panel doesn't cause a problem.
Want a dark skin for MM5? This is the one that works best for me .. elegant, compact & clear.
ZvezdanD
Posts: 3257
Joined: Thu Jun 08, 2006 7:40 pm

Re: [REQ] backup and restore auto-playlists

Post by ZvezdanD »

If you apply the Properties dialog box to retag group of tracks, it is not one transaction. Each affected track is updated in a separate transaction. It is one transaction only if you explicitly rename an album name using the Albums node in the Media Tree or, as you mentioned, using the Album panel.

Your example is assuming that all selected tracks are from a single album, and that only the album tag is affected. But, what if you have selected multiple tracks from several albums? Or, what if you have selected all tracks from the same artist and you change its name? Did you test an auto-playlist with "Artist" "is" "something" criterion and what happens with its ID when you change its name? Or, album artist, or composer, or genre or any other multi-item field that has its relational table? What if you retag not only album, but other tags as well at the same time using the same Properties dialog?

I suppose it would consume too much CPU time if the program needs to check what you have changed using the Properties dialog and how these modifications are affecting the database, just to be able to update IDs in the auto-playlists and collection rules.

However, all of our guessing are pointless. As I said, I am not the right person for this conversation and you should report it to those who are responsible.
Magic Nodes 4.3.3 / 5.2 RegExp Find & Replace 4.4.9 / 5.2  Invert Selection/Select None 1.5.1  Export/Create Playlists for Child Nodes 4.1.1 / 5.4.1  Expand Child Nodes/Expand All 1.1.2  Event Logger 2.7  Filtered Statistics Report 1.6  Track Redirection & Synchronization 3.4.2  Restore/Synchronize Database 3.1.8 / 4.0.1  Find Currently Playing Track 1.3.2  Queue List 1.2.1  Add to Library on Play 1.0.1  Tree Report for Child Nodes 1.1.1  Update Location of Files in Database 1.4.5 / 2.3  Inherit Child Playlists 1.0.3  Add Currently Playing/Selected Track(s) to Playlist 1.2
Post Reply