Option to allow MM not to store playlist permanently in DB.

[monkeyfan1970]

Hello.

In reference to this thread :

Automatically export playlist to user specific folder

Thank your for showing me the add-on.

I would like to mention this from the addon's tread - Export M3Us/Playlists for Child Nodes 3.5

These are being imported by MM because you have this folder being monitored by MM. First why are you exporting the playlists out of MM and then using MM to watch and import them back into the db?? If they are already in the db why do you want them as a part of your monitored folders??

Thanks for your reply.

Why would I want to do that? Simple. I always want to have the latest physical [not really physical ] .m3u version of my playlist in the folder E:/Music/Playlist exported automatically. And I also want MM to watch that playlist folder to load from.

I understand that MM keeps the playlist in it's DB and I also realise how MM treats it's playlists. I don't really like the way it treats music files and playlist files differently in the watch folder. Example : I configure MM to watch E:/Music and E:/Music/Playlist. If there are 10 songs in E:/Music/ MM loads them and if I delete them, the songs also are removed from MM. But for Playlist it is different. I placed 10 playlist in E:/Music/Playlist and MM lists them in "Imported Playlists" sub-node [I am fine with that] but when I delete the playlist from E:/Music/Playlist , the playlist are still listed in the "Imported Playlists" sub-node. I believe that there should be an option for this for users who want playlist not stored in DB permanently. MM also ignores the unique filename/playlist name of .m3u files. It should technically overwrite the playlist with the same name. I will request this in the wish list section. I think if this behavior is implemented, there will not be any duplicates.

Please share your thoughts.

Thanks.

Will it be possible to add an option for MM to handle playlist storing in DB differently. At the moment, MM stores them in DB regardless of them being in the folder or not. The option would be for MM not to store the "imported playlist" permanently. It is treated almost like the way it treats music files. Every time it scans the playlist folder, Ii will load them under the playlist, if it is not there, they will not be loaded. In this way, if the playlist are renamed/modified/deleted they will be listed relative to the E:/Music/Playlist.

If if set "Export M3Us/Playlists for Child Nodes 3.5" to export the playlist automatically to E:/Music/Playlist at shutdown, at launch of MM I will always have the latest version of my playlist without any multiple of multiple duplicates.

There are number of advantages for this behavior. 1. If I clear my DB, I will always have the latest version of playlist to load. 2. If I am on a network, other user of MM will always have the latest version of the playlist loaded. 3. Any who ever creates/modifies are always exported automatically to E:/Music/Playlist and everyone has the same playlist to watch from MM.

Thanks.

[nohitter151]

I really don't see any advantage to this, other than that it will confuse users.

In reference to your listed advantages:
1. Why would you need to clear the DB at all?
2. With uPnP in version 4.0, DB playlists can be shared over the network to other instances of MM and any other uPnP client. Plus it has the advantage of auto-conversion, volume leveling, etc. on the fly
3. Even if you just need to export playlists for use in another program, you can use the export playlists option to export your MM playlists every X minutes, or on startup/shutdown, to a non-monitored folder in MM. Then the playlists are all accessible. Why isn't that sufficient?

[monkeyfan1970]

I really don't see any advantage to this, other than that it will confuse users.

In reference to your listed advantages:
1. Why would you need to clear the DB at all?
2. With uPnP in version 4.0, DB playlists can be shared over the network to other instances of MM and any other uPnP client. Plus it has the advantage of auto-conversion, volume leveling, etc. on the fly
3. Even if you just need to export playlists for use in another program, you can use the export playlists option to export your MM playlists every X minutes, or on startup/shutdown, to a non-monitored folder in MM. Then the playlists are all accessible. Why isn't that sufficient?

Hello,

Thanks for your reply.

I don't think this option will confuse users. There are tons of advance options in MM and I believe both casual and advance users will find them useful. I believe this option will be no different from the other advance options.

1. Of course, I don't clear my DB daily. But I do format my PC every 6 months or so to keep things neat. But you can tell me, why not just export them before you format and re-import them after that. But that is not the main point. But that also leads to my answer in no.3, why not have the option?
2. I am not fully aware of the new uPnp features in 4.0. Will try them out!
3. My question is why not a monitored folder? Why not have the option? Is it too difficult to implement? It will be great if MM had the option to treat playlist physical and as a relative link to the DB.

I really hope that you would add this option. Of course this option will be off by default. I believe MM is one of the most sophisticated players out there. And what make it sophisticated, are the options and customisation given to users. I also believe this option will add the same level of sophistication and customisation to MM.

Thanks.

[nohitter151]

1. Clearing your DB and starting over should not be a regular part of MM maintenance. Sure, some people like to reformat their PC from time to time, but you could just back up your database file and restore it. That has several advantages over saving just playlists. For example, you then retain all non-tag stored information in addition to playlists like play count, skip count, added date, last played date, etc. Plus in backing up the DB file you must only save and restore 1 file, instead of several playlist files.

3. Because there doesn't seem to be any good reasons for that option. Playlists can already be exported, and even at regular intervals. Why should you have to worry about keeping several files safe from tampering instead of just the one database file? Not to mention it would cause issues with autoplaylists since they are database specific. This means if you exported an autoplaylist criteria from one DB and imported into a new DB, that it would no longer work.

[monkeyfan1970]

Hello,

Even the developer of "Export M3Us/Playlists for Child Nodes 3.5" thinks the duplication of Playlist is a bug.

Reference post :

viewtopic.php?f=2&t=34512&p=313142#p313094

You are right. It seems to me as the program bug. I don't understand why MM creates the new playlist with the same name as the manually created playlist in the "Imported Playlists" folder.

Thanks.

[nynaevelan]

Personally:

I do not understand why it is considered a bug. If I am importing playlists than I would expect that it imports it under the same name and I would rather have it import in a specific location rather than in the main branch of the playlists, especially for those users who use playlists to sort hierarchies. If they were imported in the main branch it could become very difficult for users to distinguish between the ones which are freshly imported and those that were already there. Though if this was a configurable option, each user would be able to select the option that best meets his/her needs.

The only part of the import process which I find to be not user-friendly is the fact that if the playlist already exists within the imported playlists branch, MM will not give the user the option to either append to it or overwrite it, instead it just ignores that playlist. I've said it before and I'll say it again, I would like more playlist management functionality, and this request would be a feature that some would find very useful.

Nyn