|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004640||MPD||Input Plugins - Streaming||public||2017-02-10 17:41||2017-02-11 02:07|
|Priority||low||Severity||tweak||Reproducibility||have not tried|
|Platform||Raspberry Pi - All||OS||All||OS Version||All|
|Target Version||Fixed in Version|
|Summary||0004640: Icy Metadata extractor treats all titles as new|
|Description||When playing a stream with Icy metadata, the extractor doesnt check if the title is a new one and sends it to the other sections of MPD no matter if it is the same as the old one. This causes some clients to miss behave, Only changing what MPD is aware of it if it is a new title could reduce resource usage and make clients behave better.|
Even though this seems like it should be a problem to fix in the clients, it'll be better for it to be fixed in MPD to allow Abandoned clients to have the benefits and simple scripts like MPD-notification could be less spammy
M.A.L.P.S Reaction: https://www.youtube.com/watch?v=-23-B7XxlVU
|Steps To Reproduce||MALP and MPD-notification seems to show the problem better so just play a stream and observe the behavour of one of thoes clients|
|I hope my Description has made it clear, But i have tried reproducing and it does seem to be reproducible|
But ... what is the problem?
The stream sends a new Title tag. Why does the stream send a new Title tag when it's the same as before? Why should MPD be responsible for comparing it with the old one? And what kind of problems does this cause for your client?
If a client misbehaves in any way just because it receives new tags too often, I consider that a client bug. I don't care if that client is abandoned - if it's broken, it must be fixed, and no workarounds will be applied to MPD. Don't even try to ask me to do that.
Sorry about the spelling, this is the second time i typed this as the last on didn't submit
Why does the stream send a new Title tag when it's the same as before?
Actually All icecast streams do this, its just that it was more notable in the stream I was using as it had a metaint of 8000.
Why should MPD be responsible for comparing it with the old one?
Most clients do this with icecast streams, I feel like it should as most clients only expect a song change, not a I received the same metadata stream. When I developed a radio streaming app I wouldent spam the user everytime I downloaded the now playing infomation I would compare it to the last one. Due to the way most clients behave for mpd as they assume the title change should be in the non-idle response should be for a new song, like users would expect.
And what kind of problems does this cause for your client?
Spammyness of notifications for ones that dont check, or graphical gliches for example in malp(Activly maintained) as you see in the video I shared.
> Most clients do this with icecast streams
Here I mean clients like MPV or VLC
NOT MPD clients
|I'm unconvinced. You're surrounded by bad streams and bad software, and you expect the only sane software (i.e. MPD) to compensate for everybody else's problems. No, that won't happend. MPD does exactly what it is supposed to do: when it receives a new tag, it forwards exactly that to its clients. All the others are misbehaving.|
|2017-02-10 17:41||ioangogo||New Issue|
|2017-02-10 17:41||ioangogo||Status||new => assigned|
|2017-02-10 17:41||ioangogo||Assigned To||=> cirrus|
|2017-02-10 17:41||ioangogo||Tag Attached: icy|
|2017-02-10 19:19||ioangogo||Note Added: 0010314|
|2017-02-10 20:42||cirrus||Note Added: 0010316|
|2017-02-10 23:45||ioangogo||Note Added: 0010320|
|2017-02-10 23:49||ioangogo||Note Added: 0010321|
|2017-02-10 23:52||cirrus||Status||assigned => closed|
|2017-02-10 23:52||cirrus||Resolution||open => won't fix|
|2017-02-10 23:52||cirrus||Note Added: 0010322|
|2017-02-11 01:47||ioangogo||Tag Attached: Big headed dev|
|2017-02-11 02:07||ioangogo||Tag Detached: Big headed dev|