2017-02-25 23:37 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004640MPDInput Plugins - Streamingpublic2017-02-11 02:07
Reporterioangogo 
Assigned Tocirrus 
PrioritylowSeveritytweakReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformRaspberry Pi - AllOSAllOS VersionAll
Product Version0.20 
Target VersionFixed in Version 
Summary0004640: Icy Metadata extractor treats all titles as new
DescriptionWhen 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 ReproduceMALP and MPD-notification seems to show the problem better so just play a stream and observe the behavour of one of thoes clients
Tagsicy
Attached Files

-Relationships
+Relationships

-Notes

~0010314

ioangogo (viewer)

I hope my Description has made it clear, But i have tried reproducing and it does seem to be reproducible

~0010316

cirrus (administrator)

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.

~0010320

ioangogo (viewer)

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.

~0010321

ioangogo (viewer)

> Most clients do this with icecast streams

Here I mean clients like MPV or VLC

NOT MPD clients

~0010322

cirrus (administrator)

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.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History