Imported Playlists Do Not Import Changes For Existing Playlists

[Dryst]

Version 5.0.4.2690.

I just reproduced this minutes ago.

The issue is that I have external m3u8 playlist files that refer to content on a file server within my network. This file was previously imported and exists within MMW5 under Imported Playlist. I changed this external m3u8 file by added a new song to it. I then selected File|Add rescan files to the library and checked off my folder containing my changed m3u8 playlist file. I then clicked the Scan now button, and MMW5 started scanning content. It completed but showed no playlist changes in the status window after it finished. The newly added song was still missing from imported playlists. The scanning appeared to do nothing at all.

I then deleted the previously imported playlist file from Imported Playlists and repeated the steps above. After it completed the m3u8 file was again shown under Imported Playlists. This time the new file I added was present within MMW5. For import to work it seems I must delete all existing playlists prior to scanning. If it already exists it will not import changes. Note that I did not close and restart MMW5 at all. I am not sure if closing and restarting would have shown different behavior.

[Lowlander]

Correct, once a Playlist is imported it now is a MediaMonkey Playlist and no longer associated with the original Playlist. Changes in either MediaMonkey or the Playlist don't affect the other. This means that you need to change the Playlist in MediaMonkey and then you can export the Playlist.

[Dryst]

This is expected behavior?

This is a usability issue and should not be difficult to properly fix.

[Lowlander]

Yes, it's by design.

[Barry4679]

Yes, it's by design.

Are you sure? That sounds unlikely
Ie. is unlikely that they would have designed a ReScan facility, which reads playlist files meeting the altered date or sized based criteria, But which ignores any changes.
Why else would the User be rescanning them?
The reScan facility is specifically to "Update the properties of any scanned media files that have changed "
Maybe they didn't specifically consider the case of playlist changes during the Design process, but it seems unlikely that they would have consciously excluded them.

One would think that this puts this into the "To Be Fixed" category .. doesn't it?

BTW the MM5 documentation doesn't appear to cover this exclusion; an exclusion which you would have to say would be unexpected by any reader... The fact that it is undocumented further suggests that this exclusion wasn't part on the Design intent doesn't it?

[Barry4679]

The issue is that I have external m3u8 playlist files that refer to content on a file server within my network. This file was previously imported and exists within MMW5 under Imported Playlist. I changed this external m3u8 file by added a new song to it. I then selected File|Add rescan files to the library and checked off my folder containing my changed m3u8 playlist file. I then clicked the Scan now button, and MMW5 started scanning content. It completed but showed no playlist changes in the status window after it finished. The newly added song was still missing from imported playlists. The scanning appeared to do nothing at all.

Hi Dryst,
I have been thinking more about your issue.
In your Use Case you have an external playlist, which is live, ie. receiving updates from somewhere other the MM5.
You want a MM5 rescan to import changes into this external playlist.

This seems reasonable, but there may be alternate Use Case.
What if your Use Case was you imported a static playlist from outside of MM?
Then you made changes to the MM version of that playlist ... ie. the MM version was the "live" playlist.
If you then rescanned the folder which contained the original playlist, you probably wouldn't expect to lose your MM5 playlist changes?

Maybe the rule for this 2nd Use Case would be that you had to move the playlist out of the Import Playlists node?

The issue is not quite as simple as it first appeared.

[Dryst]

Thanks for following up on this.

I actually posted the reason I am doing this in the past. It is to handle unique songs from my music library that exist for the same songs existing accross different albums. MMW5 has zero support for this out of the box. See this thread here: viewtopic.php?p=493284#p493284

This could at least be made an option within the software. When a user imports an external playlist that exists in the Imported tree node, delete the existing playlist prior to import. That is a quick fix that requires the least amount of work. The alternative to this would be to update existing entries if they point to the same target. All the new entries would then be captured.

This is very much do-able, so I am surprised by the initial response.

[Peke]

Hi,

This is very much do-able, so I am surprised by the initial response.

Like Barry said, thing is very complicated and not so easy to solve. Each developer choice have its pros and cons. For someone pros are better than cons.

MM is designed to Auto Manage playlists according to changes to library tracks and not pay attencion to external third party apps playlist because you use MM as designed and manage your library in MM. Especially if feature from other apps can be done in MM the same or even easier way than in those apps. I stand corrected if so things can't be done in MM or it is harder to be done in MM, then if reported and proven valid we tend to either find the way to make things easier (addons, workarounds, tutorials, ...) or add that as feature in MM dev To-Do list for implementation or in case of bugs fixing. Again not that some things stay unfixed/added (I personally have feature I made addon in 2004. which still work in MM4 [not ported to MM5 unfortunately] and specified in details is not yet added), but at least we try to consider and read user propositions.

There is also design decision where we need to calculate pros/cons and multiply with number of users use that feature against number of users that would negatively affected by that feature and decide. It is no win situation for developers.

Instead of writing fairy tails, I tried your suggestion

When a user imports an external playlist that exists in the Imported tree node, delete the existing playlist prior to import.

and as I have 7.8k+ playlists in library importing single M3U file named "Top 40.m3u" would delete exactly 237 carefully manually collected and managed playlists to replace it with one that I downloaded from internet for a review (often deleted afterwards) and would negate 16 years of work in a single click. NOTE: that in MM you can have two+ playlists with same name and even that playlist can have sub playlists (for me some goes 4 levels deep) and how to handle that?

I also scanned my HDDs (200k+ of tracks on 12TB of storage) and found out that external playlist exist only in temp folders that are scheduled to be deleted after review. So unfortunately at least for me if I assume that I export all of those 7.8k playlists to M3U MM would need to scan all of them each time any of them change modified time stamp and size (Note that M3U can also contain part of metadata) and as that they are part of my 200k collection then to compare to all rest of playlists it would put MM into almost infinite loop. I am not even talking about watching other apps changes.

Like Barry initially I thought "Dryst is right, we should check something and improve things!", but when testing/researching how to handle describe I came to ok, this also needs to be changed and that would affect that which woudl be in conflict with this that we added of bug there. So instead of single I needed document changes to 10 core features that affect 50 other in order to make 10 playlists work but it will potentially break many more things that I have not yet found. Ok I said, that will not work as suggested, so what Dryst needs to do in order to MM detect playlist updates and not create duplicates on each scan (more if folder in constantly monitored), so I added number and updated playlist imported again. Hmmm. interesting and what about adding Date/timestamp in playlist name which will give me easy way to fin them. Little hustle but no other part of MM will be affected.

As for:

I actually posted the reason I am doing this in the past. It is to handle unique songs from my music library that exist for the same songs existing accross different albums. MMW5 has zero support for this out of the box. See this thread here: viewtopic.php?p=493284#p493284

It was answered and explained, maybe you should try to use Analyze for duplicates on Scan that would compare audio data fingerprinting to allow you easily delete duplicates, but would not solve issue with multiple Albums of same track which I personally solve by adding something in title eg. "(2023 Album version)" or "(Remaster)" or "(12 inch.)" and I know that is not the same original track/file but different and they do not show in duplicates.

Please, please if I missed some case or I am wrong in testing let me know. You got me interested into investigating further and get to bottom of it.

[Barry4679]

Instead of writing fairy tails, I tried ...

Your New Years' Resolution?
Sounds like a good plan

There is also design decision where we need to calculate pros/cons and multiply with number of users use that feature against number of users that would negatively affected by that feature and decide. It is no win situation for developers.
[snip]

Please, please if I missed some case or I am wrong in testing let me know. You got me interested into investigating further and get to bottom of it.

Your post was a bit dense, and I didn't absorb all of it.
Yeah, I know I am one of the last people who should be able to say that, but ...

As I understand it:

• MM supports the Use Case where it can import an external playlist
• this will occur only if the external playlist file name does not match the name of a existing playlist in the Imported Playlists node
• +++> This exclusion is undocumented. This should be fixed
• the Summary at the end of the a Scan gives no confirmation when playlist(s) are successfully imported into MM5
• +++> This is a deficiency which should be fixed ... ie. the UI doesn't allow the User to see whether the playlists were imported or ignored
• that summary gives no warning, when a changed playlist is rescanned, and is ignored
• +++> There should be a count (and preferably a list) of re-scanned files which were ignored even though they met the normal re-scanning criteria (file was updated or size change)
• as it stands MM5 doesn't handle the Use Case where a User wants re-import (aka "replace") a set of changed external playlists
• That seems to me to be a reasonable request, which would be generally useful. It could be done without the death and destruction that you describe. eg. maybe create a Playlist subnode named "Imported Live Playlists" .. MM5 could allow re-importation if the User moved the playlist from "import Playlists" to "Imported Live Playlists"
• +++> It should be given more serious consideration. Please escalate.

... I am surprised by the initial response.

Yes. Me too.

[Dryst]

to allow you easily delete duplicates, but would not solve issue with multiple Albums of same track which I personally solve by adding something in title eg. "(2023 Album version)" or "(Remaster)" or "(12 inch.)" and I know that is not the same original track/file but different and they do not show in duplicates.

Deleting files from my audio library is not a solution. It's a work-around due to lack of ways to prevent the issue in the first place. It's not a very good work-around, because I lose content from my music archive.

Here are some options to prevent it in the first place:

1) Add support to ignore files within the library. This will require manual work to check off the files I never want selected. A one time action.
2) Add support to combine duplicates such that a single instance is chosen for autoplaylists, auto DJ and all other selections.

There's ways to resolve, but currently MMW5 offers me no good way to handle this.

My proposal to delete the Imported Playlist if it already exists prior to import should be a quick and easy code change. Yet I am getting push-back against it. Heck -- make it an option. If users don't like it, turn the option off.