ID3 Tags in the Stream

[KD7TKJ]

OK, over the last week or so, I have REALLY been digging into this tag issue... And I finally figured out the difference between our headers and the headers from internet radio stations:

1. They use the audio/mpegurl MIME type, and we used the audio/mpeg audio type.
2. They used attachment content disposition, and we were using inline content disposition. Simply changing to attachment conent disposition suddenly forced all of my media players to read the ID3 tags from the stream as I expected.

Attached, please find a patch with those changes made. This is the first patch file I have ever created, so please let me know if it has any issues!
enable-streaming-id3.patch.txt

[KD7TKJ]

I'm once again less than convinced that I have fixed it afterall...
For one thing, I never see the Album name, which implies the client ISN'T reading the ID3 tags afterall...
For another, while the FIRST song in the playlist will now inexplicably "remember' the name of the song (Leading to my initial excitement and proclemation that I had fixed it), none of the other songs in the playlist will... Which isn't REALLY much of an improvement...

[KD7TKJ]

Ugh... My results have become wildly inconsistent...

I currently have an incarnation of the playlist loaded in Amarok that IS remembering the names of the songs and the artists... But still no albums... So I'm not at all sure if Amarok is simply reading those out of the M3U file, and inexplicably choosing to remember it this time, or if by some magic changing the MIME type actually changed behavior...

But the lack of consistancy is making this incredibly difficult to troubleshoot... LOL, can someone else test my patch and see if it changes any behavior in any clients, or if it's just my imagination?

[mario-tux]

Hi!
About the mime-type: as long I can see, we consistently use audio/mpegurl for playlists/stations and audio/mpeg for the get_song command that stream an MP3 and not a playlist. Your patch try to apply the playlist mime-type to the streaming command: it does make few sense.

I didn't think that the inline vs attachment specification could even make any difference for the audio clients and the logic suggested me that the former was the correct one.
Could you really say that Amarok change its behavior on playlists switching on the attachment one?

What to expect: if you pass to the client the URL of an M3U list, upon fetch, it can show you in the list only the details contained in the M3U file (so no Album: this the standard AFAIK). During the fetch of the current song the client COULD parse on-the-fly the ID3 tag in order to show all the metadata (included Album). In my tests, VLC doesn't parse the ID3 tag on streamed songs, but MPD does as long as Audacious (WOW!). The client COULD even decide to pre-fetch the URLS in the M3U list in order to get the missing metadata: VLC doesn't, Audicious does (WOW again). Note that the latter behavior is supported by GMusicProxy only in last release with the new multi-threading management of the requests (before no-parallel requests were managed).

So Audacious is so stupid to not recognize any M3U url without the proper extension... but it is smart enough to fetch (and pre-fetch) the ID3 tags. We are talking of single beast: nothing is standard here.

I did a small test switching on the attachment specification only for the get_song command: nothing has changed in VLC for ID3 on-the-fly parsing.

Closing: convince me that the attachment method change something (in positive) on other clients and I could switch all the headers on it.

[mario-tux]

any news?

[KD7TKJ]

First, I don't think I can prove anything interesting is happening as a result of the attachment method... And I think all of your reasoning is sound.

But yes, I do think I have come to a satisfactory solution in the attached patch... It extends the ShoutCast functionality to also include fields that VLC interprets in the "Now Playing" attribute. I will call it "Experimental," as I can't find any documentation to guide me, so I have no idea if I implemented this correctly... But it seems to work in VLC and Amarok (Amarok goes a step further, and interprets the Song and Artist from that string as well).
extended-shoutcast.patch.txt

[KD7TKJ]

It doesn't seem to affect functionality, but that patch did have an extra escaped single quote in front of StreamTitle... This one doesn't.
extended-shoutcast-b.patch.txt