Heya,
I found a potential way around this....but there's the next, probably to be expected issue due to unintended usage (on my part...).
For testing this, I export the MusicBee AutoPlaylists to static ones and feed them back into MB's own playlist folder to be picked up on restart.... (not quite the standard use case I admit...
).
These then, once MB is restarted, appear updated & correctly sorted back in MB as static playlists.
Now I have them as a static playlist where I would need them to be write-able to iTunes xml so it preserves the rating based sorting I am after...
But, since there's now non-unique playlist names (i.e. the autoPlaylist and the static copy of it with the same name- living in different folders) these seem to cause problems for the iTunes xml export... it's hard to tell what is failing as there's no error, but in all cases I tested this, MB stopped writing out the iTunes xml altogether.
So I assume, since the iTunes xml export from MB does not respect the folder structure the playlists live in, non-unique names are probably causing the issues for the iTunes xml export here...
To visualize, this is what the folder/playlist structure looks like, ish:
Playlist Explorer:
_| FolderA
Playlist123
Playlist456
_| FolderB (= folder with only Folders / AutoPlaylists)
_| OrganizationalFolderC
Auto-Playlist123
Auto-Playlist456
_| FolderC-staticAutoPlaylists (= re-routed root folder where MB Preferences is pointing to for static playlist export...)
_| FolderB
_| OrganizationalFolderC
Auto-Playlist123 (=static copy)
Auto-Playlist456 (=static copy)
Is there maybe other ways/locations to store Auto-Playlists for MB or exclude them from the iTunes export altogether to avoid the conflict with static copies of them ?
If anyone has an idea/suggestion how one could achieve this, sing out.
Churs.
c.