Here are some things that I have learned about iTunes and streaming. Or think that I have learned. I place them here to hopefully prevent others from banging their heads against this wall in the future.
In iTunes 8 and 9, and possibly earlier versions, streaming audio works like this:
- The Content-Length header is used to compute the "Time" column based on the MP3 bitrate. The x-audiocast-bitrate header may also be implicated in this but I'm not sure.
If there is no Content-Length, "Time" shows as "Continuous".
If headers contain both "Content-Length" and "Accept-Ranges: bytes" then the "seek" slider in the UI is active, and moving it re-loads the URL using "Range:bytes=N-M". The server must then respond with status 206, a "Content-Range" header, etc.
You can set the title of the stream (as displayed in both the track listing and at the top of the window) by sending either the "x-audiocast-name" or "icy-name" headers. Case-sensitive!
You can accomplish the same thing by sending an ID3v2 TIT2 tag at the front of the MP3 data.
If you send multiple ID3 tags, only the first is used (you can't just send multiple tags to update streaming metadata).
iTunes supports Icecast/Shoutcast-style inline metadata, but does not advertise this. It should be sending "icy-metadata:1" to indicate that it is capable, but it does not. However, if you send icy-metaint:NNNN and encode it properly, it works. This is the only way to update streaming metadata, e.g., to change the title when the song changes. This metadata will be displayed at the top of the window, but does not overwrite the track name.
Now here's where it gets fun. iTunes 10 changed things. As far as I can tell, inside the black box there is now a "mode" that distinguishes between two cases. Let's call these cases "streaming" and "playing a remote file". You might think that those two cases are exactly the same god damned thing, and you're right, but iTunes disagrees.
When iTunes 10 has decided to be in "streaming" mode:
- Regardless of Content-Length, "Time" always shows as "Continuous".
- Titles and metadata can be updated with x-audiocast-name, icy-name and/or inline icy-metaint metadata.
- The "seek" slider is inactive. No byte-range requests will be made, period.
When iTunes 10 has decided to be in "remote file" mode:
- "Time" is displayed properly.
- The "seek" slider is active, and byte-ranges work.
- The x-audiocast-name and icy-name headers are ignored. Sending an ID3v2 TIT2 tag works, though.
- Sending icy-metaint inline metadata will cause audio glitches. It's not interpreting it at all.
Now, how does it decide between these two modes, you might ask? Well I'll tell you:
- Whether the URL ends with the string .mp3.
No, I am not making this up.
So what this means in practice is that there is no way to have a stream that is seekable and also has dynamically-updated metadata. Either you have a single title for the whole thing that never changes, and you can enable seeking; or you can have continuously-updating metadata, but never seek. In iTunes 9, you could have it all; no longer.
So what's changed in iTunes 11?
I haven't tested it personally, because I still depend heavily on a couple of features they've deleted, but from talking to others who are running it, the situation appears to be:
- iTunes 11.0.1 will now send the icy-metadata header when it is in the mood to accept inline metadata. Unlike earlier versions where you had to guess, at least now they're being explicit about it. Not that that helps much, since you still have to guess for older versions of iTunes.
The "seek" bar never works, ever. If the bits came from a URL, then the "Size" field says "Stream" and you can't seek, even if the URL provided a Content-Length and Accept-Ranges. It now won't even tell you how long the stream is, though the information is there.
So, having only recently crippled the functionality of "stream" by dividing it into the "stream" and "remote file" false dichotomy, they appear to have gone farther and nuked the "remote file" capabilities entirely.
Seeking and metadata still work in VLC, for what it's worth, assuming that you can bring yourself to tolerate that program's catastrophically terrible UI.
If you work for Apple, please hassle somebody about bug reports 13004973, 13004985 and 10737146.