[SOLVED] MPD database: forward slash in "track number" tag

chikinn · 2017-02-12 07:27:52

Hi all,

In my music tags, often I want to store a track number that shows the total number of tracks on an album. For example, "01/15" instead of just "01". Normally this is no problem.

Today, though, when I tried to write such a tag in ncmpcpp's tag editor, no error was raised, but nothing from the slash onward showed up in ncmpcpp. My "01/15" appeared as "01". With another tagging utility I verified that ncmpcpp wrote the correct tag ("01/15") to the MP3 file itself. However, in a text dump of the MPD database, the tag was simply "1". Apparently, ncmpcpp is writing the correct tag, then trying to update it in MPD. But MPD fails to store the right tag, and tells ncmpcpp the tag to display is "1" (to which ncmpcpp prepends a 0 for whatever reason).

I updated MPD recently from 0.20-1 to 0.20.4-1. Figured that was the issue, but rolling back, restarting MPD, and trying to write the tag again didn't help.

Haven't updated ncmpcpp in months so I doubt it's the problem.

Any ideas for how to troubleshoot this?

Same story with the "disc number" tag, by the way. All other tags I use are still working normally.

Last edited by chikinn (2017-02-18 07:14:40)

seth · 2017-02-12 08:32:54

Try to trigger an update using "mpc update" and also inspect the mpd log (eg. ~/.mpd/mpd.log, but that's configurable)

chikinn · 2017-02-12 10:46:15

Thanks. Unfortunately, triggering an update didn't show any errors and there's nothing new in the log.

seth · 2017-02-12 10:54:47

Does this find your tune?

mpc search track "01/15"

chikinn · 2017-02-12 17:43:44

Nope. But it is searching my database, I tried other queries.

Last edited by chikinn (2017-02-12 17:44:14)

seth · 2017-02-12 20:53:29

Touch the file (to ensure it's re-read), "mpc update" again, dump id3info on the file (maybe the track was stored in the "wrong" field) - then iÄm out of ideas. I've such tracks here and they're found by resp. mpc searches. *shrug*

chikinn · 2017-02-13 00:16:15

No dice. But thanks for your suggestions!

Here's another thing I noticed. Old entries in the database are still intact. It's only when I try to add a new song to the database, or update an old song, that the track info gets messed up.

seth · 2017-02-13 11:30:49

Yup, confirmed for even 20.1 - no problem with present tags, but new track IDs aren't updated.
Don't ask me when that borke, though (didn't find a bug on https://bugs.musicpd.org/view_all_bug_page.php at hand)

chikinn · 2017-02-14 20:28:47

Thanks for confirming. Bug report submitted: https://bugs.musicpd.org/view.php?id=4648

Last edited by chikinn (2017-02-16 07:03:34)

chikinn · 2017-02-16 17:28:16

Wellll, MPD dev acknowledges the behavior but says it's intended and won't offer a config option to preserve 0.19 behavior. He suggests using the "readcomments" function to bypass the database -- but if I submitted that as a feature request to the ncmpcpp dev, I doubt he'd go for it because it would be much slower than database access.

I guess I'll just roll back to 0.19 but this feels like a pretty dumb reason not to use the latest version. Hopefully enough other people will complain, eventually.

unK · 2017-02-17 12:25:19

Sigh. https://bugs.musicpd.org/view.php?id=4651

Aaand it got closed without any attempt of discussion. Great. Here's a patch that reverts this idiotic behaviour, if anyone is interested: http://rybczak.net/files/mpd-0.20-track-disc-fix.patch

Last edited by unK (2017-02-17 13:15:01)

seth · 2017-02-17 13:22:14

Well, he's got a habit ;-)

However, I looked at the patch and it's rather shitty.

The API reads a char pointer and passes a passes a char pointer to the clients, so any conversion will have no technical causes (also mpd clients have dealt w/ freeform track tags ever since, I've written one and it actually contains code to deal with the "a/b" scenario...

The conversion applied nevertheless converts the string to an unsigned long, but expects base-10 (so any track id "#5" will end up invalid) and uses a static 20 byte buffer (wherever that length came up from) as value, so instead of using 2 bytes for track "1\0" it now uses 21 bytes for track "1\0" (\0 is the end marker)

Notice that anytime the "number" in the (freeform) id3 tag does not match these pattern expectations "\s*[+-]*[0-9]+.*" you end up with a song w/o any track id.
IOW: it's inefficient and not very robust. Not sure why it was done, but it should be done "better". Seriously.

Unfortunately both bugs are closed instantly and that guy does not seem willing to take a discussion on the matter, so I'm not gonna open a 3rd one.

chikinn · 2017-02-18 07:14:16

Thanks for the patch, unK! It may be ugly but it gets the job done.

Marking solved.

Arch Linux

#1 2017-02-12 07:27:52

[SOLVED] MPD database: forward slash in "track number" tag

#2 2017-02-12 08:32:54

Re: [SOLVED] MPD database: forward slash in "track number" tag

#3 2017-02-12 10:46:15

Re: [SOLVED] MPD database: forward slash in "track number" tag

#4 2017-02-12 10:54:47

Re: [SOLVED] MPD database: forward slash in "track number" tag

#5 2017-02-12 17:43:44

Re: [SOLVED] MPD database: forward slash in "track number" tag

#6 2017-02-12 20:53:29

Re: [SOLVED] MPD database: forward slash in "track number" tag

#7 2017-02-13 00:16:15

Re: [SOLVED] MPD database: forward slash in "track number" tag

#8 2017-02-13 11:30:49

Re: [SOLVED] MPD database: forward slash in "track number" tag

#9 2017-02-14 20:28:47

Re: [SOLVED] MPD database: forward slash in "track number" tag

#10 2017-02-16 17:28:16

Re: [SOLVED] MPD database: forward slash in "track number" tag

#11 2017-02-17 12:25:19

Re: [SOLVED] MPD database: forward slash in "track number" tag

#12 2017-02-17 13:22:14

Re: [SOLVED] MPD database: forward slash in "track number" tag

#13 2017-02-18 07:14:16

Re: [SOLVED] MPD database: forward slash in "track number" tag

Board footer