On Mon, 04 Dec 2023 16:05:15 +0300 Aleksas Tunikas <m...@aleksas.ru> wrote:
> I was in the correspondence with amazing emms-mpv package to find out > why wouldn't the metadata (while it is parsed alright outside of emms > systems e.g. by playing directly in mpv) couldn't be updated in a > playlist file and here's what I found: > > 1. by testing on emms-streaming package it was obvious that metadata did > indeed work as expected, and by the song change the title is changing > indeed > 2. which lead me to try my liquidsoap instance to encode in non lossless > format and both normal what one can call 'native' ogg and as well as > mpeg3 is displaying metadata changes just fine > 3. the problem i still scratch my head is what is that emms system and > particularly emms-mpv not able to parse, as the metadata changes for a > lossless container still displays in other apps that take data directly > from mpv instance (e.g. pavucontrol) I've tried running mpv with the link you sent to me earlier, and emms-player-mpv-debug enabled as I've suggested, and see that mpv only emits initial "property-change" event for "metadata" at the start of the stream, and never after that. If I connect with a different mpv instance, that one seem to get updated metadata initially, but then doesn't update it either. mpv terminal output also does not show any metadata updates after playback start. So, I think there are two likely options: - Whatever sends data on these streams / connections simply does not encode metadata when changing tracks, and only sends it on initial connection, never after that. Since data is not there, mpv or emms can't do anything about it, this needs to be fixed on the encoding server side. - Metadata updates are encoded, but mpv fails to parse those, likely for whatever format or standard related differences. This needs to be raised with mpv, almost certainly with some kind of format examples, showing what exactly it fails to parse. (as obviously it's impossible to fix/implement something undefined) I don't know which of these two is the case in reality, didn't look at the binary stream data dump to tell if any metadata is there, and not really familiar with codec details to tell (as presumably it's not "icy" metadata tags, but should be something else?). But either way, can't be fixed on emms side, and if you want to debug this further, I'd recommend the following steps, in that order: - Making absolutely sure that metadata is in the stream. I.e. dump the stream into a file, grep it, see that tags from multiple track/name/metadata changes are all there. If not, either fix or raise issue with whatever generates that stream. - Learn how metadata should be encoded, i.e. which specific RFC or standard it follows, and check whether mpv (or ffmpeg that it uses) are known/expected to support it. - Depending on the above, either raise an issue about support being broken or feature request about it missing with mpv or ffmpeg project (probably mpv, but maybe ffmpeg parses these tags too, not sure). Either way, make sure to include information on which tagging standard is broken or missing there, with link to the actual document, and a dump/sample of bytes which should be decoded according to it (as produced/confirmed in previous steps). (this is important, because obviously asking to implement something that you don't even know exists might be silly on multiple levels) > This leads me to the following conclusion that it might be the headers > that encoded in the ogg container while it is streaming flac that > emms-mpv is not understand, and being a DJ and not a professional Dev > (no disrespect to that) I was unable during quick browsing of the code > figure out where the problem might lie. Therefore I am writing the > message here so maybe Yoni or the package author who I hope don't mind > me tagging him along as he wanted me to tell him the results of enquiry, > will be able to decode. Of the two options above, I'd suspect that software you're using simply does not encode metadata changes at all. I'm not aware of any standard other than "icy" tags for that, they are not there, and mpv doesn't see/parse anything else there, does not log any relevant anomalies, and you haven't mentioned anything detecting such metadata in the stream, so it simply not being there seem to be most simple explaination. Maybe this stream format isn't expected to support it mid-stream, and so streaming server silently ignores whatever options you set to ask it to include it. But as mentioned, I didn't dump the stream to check, and either way, mpv would need to support this, not emms, so issue should probably be raised there, as also outlined above. Cheers! -- Mike Kazantsev // fraggod.net
