2017-02-25 23:36 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004651MPDMetadatapublic2017-02-17 19:07
ReporterunK 
Assigned Tocirrus 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
Product Version0.20 
Target VersionFixed in Version 
Summary0004651: MPD strips track and disc tags of valuable information
Descriptionbea5973e0cffe983584484ad29f900044b003093 breaks the behaviour that has been there since always i.e. now MPD, instead of storing tags verbatim as they are defined in the song file, arbitrarily chooses to strip track and disc tags by assuming they are a number.

Sure, it might be "100% correct" as you mentioned in 0004648, but:

1) It is extremely confusing to users as why these tags are tampered with whereas all the other ones are not.

2) Format x/x for these tags is often used and provides valuable information for how many tracks (or discs) are in the album, if you don't have all of them in the queue at the moment.

3) Current behaviour doesn't have any benefits from the point of view of MPD - it even adds complexity because these are special cases.

4) It doesn't add any coherence wrt. the definition of the tags. E.g. DATE tag can be either a year, a date or a timestamp. It's quite obvious that if MPD tried committing to having unified representation of this tag, it wouldn't work because there are so many choices (and there is no clear winner).

5) Simulating old behaviour with "readcomments" is infeasible because a client would need to issue that each time you request songs from MPD, for each song.

I presume the author of this commit had a mess in his tags and instead of fixing them he made a patch for MPD. I'm baffled though why you chose to merge it instead of telling him to fix his tags, as you usually do in similar cases.

To summarize, this change brings confusion, adds unnecessary complexity and reduces the amount of information about songs one gets. Because of that, I kindly urge you to reconsider and revert it.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0010364

cirrus (administrator)

This is not a bug. You agreed that it is 100% correct.

1) it may confuse those users who do not know the definition, but that's ok

2) valuable information is stripped because it doesn't belong here, no matter how valuable it is

3) it has benefits, because it adds correctness

4) now you argue that because other tags are inconsistent, this one should be inconsistent as well - stupid argument.

5) maybe it's infeasible, but that has nothing to do with your request

All of your arguments are wrong.

~0010367

unK (viewer)

You don't get to decide which information is valuable to me (or anyone else for that matter) or not.

Now, I should've known better that to try reason with you, although at least I tried.

I'll personally run patched version of MPD since now, it's just sad that others will have to endure your stupid decision.

~0010368

Rasi (reporter)

Just to add my 2 cents:

The only correct way to handle total tracks/discs is by using totaldisc/totaltrack tags, which are widely used (e.g. musicbrainz and all services relying on it)
+Notes

-Issue History
Date Modified Username Field Change
2017-02-17 13:24 unK New Issue
2017-02-17 13:24 unK Status new => assigned
2017-02-17 13:24 unK Assigned To => cirrus
2017-02-17 13:30 cirrus Status assigned => closed
2017-02-17 13:30 cirrus Resolution open => won't fix
2017-02-17 13:30 cirrus Note Added: 0010364
2017-02-17 14:21 unK Status closed => feedback
2017-02-17 14:21 unK Resolution won't fix => reopened
2017-02-17 14:21 unK Note Added: 0010367
2017-02-17 14:57 Rasi Note Added: 0010368
2017-02-17 19:07 cirrus Status feedback => closed
2017-02-17 19:07 cirrus Resolution reopened => won't fix
+Issue History