Track titles prefixed by Artist tag when displaying m3u playlist contents

[Andre Gosselin]

Following recent updates, I note that track titles are not reported identically when browsing through a playlist. The track titles are then prefixed with the value of the Artist tag.

Consider for ex. this track in flac format in a win7 directory:

Quote:C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

When browsing in folder view to this track with BubbleUPnP, metadata are reported as :

Quote:Track #=1
Title=Allegri: Miserere a 9, version avec ornamentations baroques
Artist=A Sei Voci
Album Artist=A Sei Voci, Fabre Garrus, Bernard

I create the following playlist in m3u format (using MediaMonkey):

Quote:#EXTM3U
#EXTINF:873,A Sei Voci; Fabre-Garrus, Bernard - Allegri: Miserere a 9, version avec ornamentations baroques
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

If I browse this playlist contents in folder view, the contents are now reported as follows in the BubbleUPnP playlist tab :

Quote:01. A Sei Voci; Fabre-Garrus, Bernard - Allegri: Miserere a 9, version avec ornementations baroques

If I browse to the track in folder view (or through the Album Artist index), the track title is reported as follows:

Quote:01. Allegri: Miserere a 9 , version avec ornementations baroques

Note how, when browsing the playlist, the value of the Artist tag is prepended to the track title.

I am pretty sure this behavior did not occur in previous minimserver versions (but I found no way of reinstalling a previous version to be 100% sure). Track metadata of m3u playlists were reported identically to the way they were when navigating through folder view or index tags. This indeed makes sense, since a playlist just points to files holding tracks, and the metadata should not be reported differently simply because the track is identified in a playlist.

Could you verify this please, and tell me if I am wrong ?

Regards

[simoncn]

(01-09-2014 06:25)Andre Gosselin Wrote:  Note how, when browsing the playlist, the value of the Artist tag is prepended to the track title.

I am pretty sure this behavior did not occur in previous minimserver versions (but I found no way of reinstalling a previous version to be 100% sure).

It is easy to revert to a previous update to verify changed behaviour by doing the following:

1) In the Packages tab of the Properties window, type the name of the previous update name in the 'Other package' field (for example, to revert to update 35, type minimserver-0.8-update-35)

2) Click Install and follow the prompts to install the update and relaunch MinimServer

Quote:Track metadata of m3u playlists were reported identically to the way they were when navigating through folder view or index tags. This indeed makes sense, since a playlist just points to files holding tracks, and the metadata should not be reported differently simply because the track is identified in a playlist.

This is an intended change to the previous behaviour. If you use the optional #EXTINF tag to specify a title, the #EXTINF title is used when you are viewing the playlist. If you want to see the original title in the playlist, you should omit the #EXTINF line or omit the #EXTINF title or change the #EXTINF title to the title you want to see displayed.

For example, you could use:

#EXTM3U
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

or

#EXTM3U
#EXTINF:873,
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

or

#EXTM3U
#EXTINF:873,Allegri: Miserere a 9, version avec ornamentations baroques
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

[Andre Gosselin]

(01-09-2014 09:30)simoncn Wrote:  

(01-09-2014 06:25)Andre Gosselin Wrote:  Note how, when browsing the playlist, the value of the Artist tag is prepended to the track title.

I am pretty sure this behavior did not occur in previous minimserver versions (but I found no way of reinstalling a previous version to be 100% sure).

It is easy to revert to a previous update to verify changed behaviour by doing the following:

1) In the Packages tab of the Properties window, type the name of the previous update name in the 'Other package' field (for example, to revert to update 35, type minimserver-0.8-update-35)

2) Click Install and follow the prompts to install the update and relaunch MinimServer

Quote:Track metadata of m3u playlists were reported identically to the way they were when navigating through folder view or index tags. This indeed makes sense, since a playlist just points to files holding tracks, and the metadata should not be reported differently simply because the track is identified in a playlist.

This is an intended change to the previous behaviour. If you use the optional #EXTINF tag to specify a title, the #EXTINF title is used when you are viewing the playlist. If you want to see the original title in the playlist, you should omit the #EXTINF line or omit the #EXTINF title or change the #EXTINF title to the title you want to see displayed.

For example, you could use:

#EXTM3U
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

or

#EXTM3U
#EXTINF:873,
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

or

#EXTM3U
#EXTINF:873,Allegri: Miserere a 9, version avec ornamentations baroques
C:\mu\flac\A Sei Voci\Allegri- Miserere; Messe Vidi Turbam Magnam; Motets\01 Allegri- Miserere a 9, version avec ornamentations baroques.flac

Simon,
Thanks for this fast answer. Thanks for informing me of this recent change in the handling of m3u playlists. This change however creates important problems for me.
1. I have a collection of more than 17,000 playlists, which have worked well for more than 2 years now with MinimServer. Editing those will be a time-consuming task. The music manager used to generate those playlists (MediaMonkey) automatically generates the #EXTINF lines shown in my post, and I have no control over that. Would it be possible to introduce a setting to tell MinimServer to ignore those lines inside m3u playlists, to keep the old MinimServer behavior and save big trouble for those like me who used to depend on it for a very long time ?
2. For the same track, the title metadata (as shown for ex. by BubbleUPnP with the "Show metadata" selection after a long press on the track) are reported differently, depending on whether the track is accessed through a playlist or by browsing the library indices. In the first case (playlist), the track "Title" value includes the "Artist", but not in the second case. This is inconsistent, and in my humble opinion, incorrect. Track metadata should be reported as they are stored in the music file.
3. All control points I know of allow the display of the Artist value alongside the title, on a separate line or distinct column of the screen. Including the Artist in the Title then becomes totally redundant, an clutters the display. When the Artist value is long (consider numerous singers in an opera for ex.), the title then may become way too long and exceed the display capacity of the control point. Worst, since the Artist value now comes first in the Title line, you face the situation where the important info (eg the title per se) is completely truncated, making the display practically useless.
4. I think it should be up to the control point to decide how to display the track metadata, and not to the music server.

Honestly, I have difficulty understanding why this (sudden) change in MinimServer behavior was needed, and who benefits from it. If you object to the idea of introducing the setting outlined above, would you have a suggestion to keep my huge playlist collection in a usable state ?

Thanks for your help

[simoncn]

(01-09-2014 15:12)Andre Gosselin Wrote:  Simon,
Thanks for this fast answer. Thanks for informing me of this recent change in the handling of m3u playlists. This change however creates important problems for me.
1. I have a collection of more than 17,000 playlists, which have worked well for more than 2 years now with MinimServer. Editing those will be a time-consuming task. The music manager used to generate those playlists (MediaMonkey) automatically generates the #EXTINF lines shown in my post, and I have no control over that. Would it be possible to introduce a setting to tell MinimServer to ignore those lines inside m3u playlists, to keep the old MinimServer behavior and save big trouble for those like me who used to depend on it for a very long time ?
2. For the same track, the title metadata (as shown for ex. by BubbleUPnP with the "Show metadata" selection after a long press on the track) are reported differently, depending on whether the track is accessed through a playlist or by browsing the library indices. In the first case (playlist), the track "Title" value includes the "Artist", but not in the second case. This is inconsistent, and in my humble opinion, incorrect. Track metadata should be reported as they are stored in the music file.
3. All control points I know of allow the display of the Artist value alongside the title, on a separate line or distinct column of the screen. Including the Artist in the Title then becomes totally redundant, an clutters the display. When the Artist value is long (consider numerous singers in an opera for ex.), the title then may become way too long and exceed the display capacity of the control point. Worst, since the Artist value now comes first in the Title line, you face the situation where the important info (eg the title per se) is completely truncated, making the display practically useless.
4. I think it should be up to the control point to decide how to display the track metadata, and not to the music server.

Honestly, I have difficulty understanding why this (sudden) change in MinimServer behavior was needed, and who benefits from it. If you object to the idea of introducing the setting outlined above, would you have a suggestion to keep my huge playlist collection in a usable state ?

Thanks for your help

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.

[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

[simoncn]

(01-09-2014 17:14)Andre Gosselin Wrote:  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 ?

This is somewhat difficult to implement because every audio item is required to have a title and MinimServer uses a default title of the filename if no title is specified as metadata. By the time the playlist processing is performed, this defaulting has already happened and there's no way to tell whether the title was original metadata or a default value.

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

Thanks for this. I have already written and tested the code to revert the change. If anyone particularly wants the other approach, we can consider it again after a more extensive discussion.

My reasons for reverting it are:

1) It is likely to cause trouble for users who are expecting the previous behaviour.

2) It is inconsistent to take the title from #EXTINF but take all other metadata such as Artist and Album from the track file.

3) MinimServer ignores the duration from #EXTINF and uses the duration in the file. It is inconsistent to do the opposite for the title.

4) There appears to be an established convention that the #EXTINF title should contain "artist name - track name" rather than just "track name". It is inconsistent with this convention for MinimServer to assume the #EXTINF title is just the track name.

5) No-one has complained about the previous behaviour.

Quote: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

I agree with all this, but today's reality is the current imperfect scheme and I don't want to take on the task of trying to create something better and establish it as an industry standard.

[Andre Gosselin]

(01-09-2014 17:38)simoncn Wrote:  

(01-09-2014 17:14)Andre Gosselin Wrote:  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 ?

This is somewhat difficult to implement because every audio item is required to have a title and MinimServer uses a default title of the filename if no title is specified as metadata. By the time the playlist processing is performed, this defaulting has already happened and there's no way to tell whether the title was original metadata or a default value.

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

Thanks for this. I have already written and tested the code to revert the change. If anyone particularly wants the other approach, we can consider it again after a more extensive discussion.

My reasons for reverting it are:

1) It is likely to cause trouble for users who are expecting the previous behaviour.

2) It is inconsistent to take the title from #EXTINF but take all other metadata such as Artist and Album from the track file.

3) MinimServer ignores the duration from #EXTINF and uses the duration in the file. It is inconsistent to do the opposite for the title.

4) There appears to be an established convention that the #EXTINF title should contain "artist name - track name" rather than just "track name". It is inconsistent with this convention for MinimServer to assume the #EXTINF title is just the track name.

5) No-one has complained about the previous behaviour.

Quote: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

I agree with all this, but today's reality is the current imperfect scheme and I don't want to take on the task of trying to create something better and establish it as an industry standard.

Thanks a lot for your attention.

[simoncn]

(01-09-2014 17:45)Andre Gosselin Wrote:  Thanks a lot for your attention.

This change has been reverted in update 41.

[scrutney2]

Hi Simon.

I was actually quite pleased with the way update 40 handled playlists...

The reason is that I have iTunes organise my music files, and in doing this it names them with the track number and title, e.g. 04 A Case Of You.

I also use iTunes to create playlists, which I export to .m3u format using a program called iTunesExport. The resulting .m3u files contain #EXTINF lines containing "artist name - track name".

Prior to update 40 Minimserver displayed playlist tracks with only the track number and title, from the file name. Update 40 showed the artist too, which clearly made it a lot easier to identify songs! Now with update 41 I'm back to the previous situation..

Would it be possible to have Minimserver use the #EXTINF per the convention you mentioned, and display "artist name - track name" in playlists?

Regards,
Simon

[simoncn]

(11-09-2014 22:19)scrutney2 Wrote:  Hi Simon.

I was actually quite pleased with the way update 40 handled playlists...

The reason is that I have iTunes organise my music files, and in doing this it names them with the track number and title, e.g. 04 A Case Of You.

I also use iTunes to create playlists, which I export to .m3u format using a program called iTunesExport. The resulting .m3u files contain #EXTINF lines containing "artist name - track name".

Prior to update 40 Minimserver displayed playlist tracks with only the track number and title, from the file name. Update 40 showed the artist too, which clearly made it a lot easier to identify songs! Now with update 41 I'm back to the previous situation..

Would it be possible to have Minimserver use the #EXTINF per the convention you mentioned, and display "artist name - track name" in playlists?

Regards,
Simon

Thanks for this input.

I would be interested to hear opinions from other users about which approach they prefer.