Author Topic: Playlists - non-persistent behaviour when removing files from library  (Read 2017 times)

alec.tron

  • Hero Member
  • *****
  • Posts: 706
Heya,
I just made a persistency test for playlists, and the outcome was a tad worrying...
See if anyone else can reproduce this - I'm using Musicbee 3.0.5918 (with latest MusicBee3_Patched.zip as of 2016/03/16 21:15 UTC+12:00):

- throw a temporary music file (this needs to be deleted later!) somewhere in a library / monitored folder
- add that file to your library (I did a MB restart, it added it to the inbox as expected [neat!], and I send-to library)
- with the file in the library, add it to a playlist (mine are m3u based, as I need to mass export edited playlists afterwards, so this seems to be the only way atm to do so)
- now, with the file added to a playlist, delete that file off disc (or move it, or rename, I assume would work as well)
- restart MB
- upon re-scan it will detect the file missing
- confirm here that you want to remove it from the library
- now look at the playlist where you added it to, in my case it was gone without a trace

I expected that it then would appear as a dead ( ! ) entry in the playlist, but it did not, it was removed without any notice or warning, effectively mutated the content without informing / warning the user.

Can anyone else reproduce this ?

Cheers.
c.
Last Edit: March 18, 2016, 09:36:53 AM by alec.tron


alec.tron

  • Hero Member
  • *****
  • Posts: 706
Hey Steven,
that has me a bit stumped...
I assumed, since you stick to persistent data presentation on imports (i.e. a m3u playlist that points to a file that does not exist still arrives in MusicBee's playlist, yet marked with a (!) sign - which is one of the things that drew me to Musicbee.... ), that this is also true (or configurable as an option) for internal edits (be it user action, or library action (automatic) based)...

If you feel like explaining why altering inter-dependent data without options or informing the user, I am very curious, as I only see negatives to this 'as intended' behaviour if there's no alternative route available...

Cheerio.
c.

redwing

  • Guest
There was a previous discussion on the issue: http://getmusicbee.com/forum/index.php?topic=14983.0
It would be better to continue from that thread to avoid repeating what's been already said.

alec.tron

  • Hero Member
  • *****
  • Posts: 706
Hey Redwing,
thanks for pointing that out & good to know I'm not alone in this.
But:
"Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic."
So I'll keep it here...?!

I can only say this is fully true for me as well:
Being able to have the option to keep dead links in the playlists as it happened in the past when re-scanning the library would really be a great addition.

And I would really hope for this to become available as an option for users who do not want their playlists/m3u altered automatically.

Also, another suggestion - since each track knows in which playlist it lives ( = the Playlist column for the main tracks view), would it be possible, if a track that is to be removed from the Library and exists in playlist(s), to warn the user here by showing the Playlist Column in the (Remove from Library) "Confirmation" Window as well ?

Thanks.
c.

psychoadept

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10413
Don't be intimidated by that 120 day warning, it's just an automatic message.

For what it's worth, I would find it helpful to have a setting for static playlists regarding whether to retain info on deleted files or not.
MusicBee Wiki
Use & improve MusicBee's documentation!

Latest beta patch (3.4)
(Unzip and overwrite existing program files)