Track titles prefixed by Artist tag when displaying m3u playlist contents

[Andre Gosselin]

(01-09-2014 15:50)simoncn Wrote:  I will revert this change in the next update. It was intended to provide consistency with how #EXTINF titles for other playlist items (audio streams and nested playlists) are handled. For these items, the #EXTINF title (if available) is used in the playlist display.

Simon,
I think I found a way to suppress the #EXTINF lines in my playlist collection, by patching some scripts inside the MediaMonkey distribution and recreating the playlists from the database. I think MediaMonkey generates those lines to allow the backwards regeneration of the playlists inside the database from the m3u files, in case the database ever gets corrupted. Patching the scripts will make this impossible, but I never faced such a situation, and I am better protected against this eventuality by simply regularly backing up the database files per se, as I do now.

I understand your point about using #EXTINF to attach a title to items which lack this info. But what about items which do already have explicit title metadata (which I think, for consistency reasons, should be reported faithfully when querying the metadata in the control point, irrespective of the way the item is reached) ? Could the #EXTINF value be ignored in that case ?

Since I am confident to solve my problem by patching the MediaMonkey software, you could keep the change introduced in the last Minimserver update.

By the way, this raises the issue of how metadata could be explicitly attached to playlists, and how they could be managed through UPnP. Currently, metadata are all attached to tracks, which is not ideal since quite often they shoud be attached to higher level objects instead of being redundantly replicated in the object components. Consider the album for example, which should really be the object holding attributes like "publisher", "catalog number", "release date", "album art", etc. If we could attach attributes (tags) to playlists, then playlists could serve to define those higher level objects, like albums and compositions. Playlists could then be seen as tables similar to those used inside a relational database, and serve to implement some sort of data model, a concept which is sorely lacking in the current track-tagging scheme.

Regards