Shoutcast -> iTunes (only!) causes rebuffering errors

Talk about Audio On Demand or Streaming
Post Reply
Jay Levitt
Posts: 7
Joined: Mon Mar 07, 2005 10:15 pm
Contact:

Shoutcast -> iTunes (only!) causes rebuffering errors

Post by Jay Levitt »

We're running Shoutcast Server 1.9.4 on a reasonably-powered Red Hat machine (2.4.21-4 kernel) with little else running on it. We're currently just broadcasting from iTunes to Shoutcast via Nicecast; the iTunes files are 320k MP3s. (A bit overkill, but that's what we have for now).

For some reason, something iTunes is doing at the TCP level is confusing Shoutcast; listening in iTunes causes "Rebuffering stream..." errors, and the TCP stream does in fact seem to stop even though the TCP window isn't full. This *only* happens with iTunes clients (both Windows and Mac). I can run iTunes and RealPlayer back-to-back, and Real will work, iTunes will fail. QuickTime, which you'd think uses the same engine as iTunes, works fine too.

I can see the stream halting with Ethereal, but I'm at an utter loss as to why; again, the window isn't full, so the host should keep transmitting. I'm happy to send libpcap dumps to anyone who's capable of troubleshooting this. Anyone have any ideas?

Interestingly, if I relay the shoutcast server in question with a server on my own home network, (which presumably reassembles and then resplits the stream), iTunes can connect to *that* with no problem.
User avatar
Jay
Will work for food (Administrator)
Posts: 3020
Joined: Mon Jan 14, 2002 12:48 am
Location: Next Door
Contact:

Post by Jay »

does it happen if you source shoutcast with something other the nicecast? Like sc_trans_macosx?

If so then the problem is likely itunes, if not then I would say nicecast is embedding something into the stream that itunes can't deal with or you are using some sort of vbr setting.
- Jay
Jay Levitt
Posts: 7
Joined: Mon Mar 07, 2005 10:15 pm
Contact:

Post by Jay Levitt »

Haven't tried another source for iTunes, but that's a good idea. I have limited access to the Shoutcast server itself (I can't even read the config file) but I can certainly run something else on the Mac.

If there were general compatibility problems with Shoutcast and iTunes - as a source, client or both - I'd think we'd have heard of it by now, no? I figure there must be something configured wrong, most likely at the network layer.. this feels kind of like all those old problems with MTUs and packet reassembly in the good old days.

I don't think it's anything in the stream data itself, because that would persist through the Shoutcast relay server I set up.

Also, I forgot to mention: we *think* that the problems exist only when listening to the Shoutcast server from outside our firewall. It's hard to say; we have one report of rebufferring inside the firewall, but that of course could be simple network congestion or something else. Most users are outside the firewall, so it could also just be natural that the reports come from there too.

So, to sum up:

iTunes -> NiceCast -> Shoutcast -> ||FW|| iTunes: stream stops.
iTunes -> NiceCast -> Shoutcast -> ||FW|| WinAmp/Real/QuickTime: Fine.
iTunes -> NiceCast -> Shoutcast -> ||FW|| Shoutcast relay -> iTunes: Fine.
iTunes -> NiceCast -> Shoutcast -> iTunes: Fine, mostly.

I spent another hour looking at the packet trace, and I'm still baffled. There is absolutely no reason for the stream from the host to stop! And yet it just does, and only with iTunes.

I wonder if there's something in iTunes's headers that is confusing Shoutcast, or triggering a bug? iTunes sends:

GET / HTTP/1.1
Accept: */*
Cache-Control: no-cache
User-Agent: iTunes/4.7 (Macintosh; N; PPC)
X-Audiocast-Udpport: 49238
Icy-Metadata: 1
Connection: close
Host: xxx:8000


While RealPlayer sends:

GET /listen.pls HTTP/1.1
Accept: */*
User-Agent: RMA/1.0 (compatible; RealMedia)
Icy-MetaData: 1
Bandwidth: 1544000
Language: en-US
RegionData: 0
ClientID: MacOT_10.3_10.0.0.0_play32_RN01_EN_PPC_No-FPU
GUID: 00000000-0000-0000-0000-000000000000
SupportsMaximumASMBandwidth: 1
Connection: Keep-Alive
Host: xxx:8000
Accept-Language: en-us
Accept-Encoding: gzip

WinAmp sends:

GET / HTTP/1.0
Host: xx.xx.xx.xx
User-Agent: WinampMPEG/5.0
Accept: */*
Icy-MetaData:1
Connection: close

And Quicktime simply:

GET / HTTP/1.0
User-Agent: QuickTime/6.0
User avatar
Jay
Will work for food (Administrator)
Posts: 3020
Joined: Mon Jan 14, 2002 12:48 am
Location: Next Door
Contact:

Post by Jay »

no, the problem is likely in the decode process of itunes. Windows media player has this sort of affliction with vbr streams (which is why I mentioned it) The stream stops only because iTunes stops actively recieving data. Players stop recieving data when they get stuck on a decode.

I have listened to SHOUTcast streams in iTunes and never experienced any problems so i doubt that iTunes is triggering anything in the server.
- Jay
Jay Levitt
Posts: 7
Joined: Mon Mar 07, 2005 10:15 pm
Contact:

Post by Jay Levitt »

Jay wrote:no, the problem is likely in the decode process of itunes. Windows media player has this sort of affliction with vbr streams (which is why I mentioned it)
Nope, it's 320k, not VBR - and the headers from Shoutcast confirm it.
The stream stops only because iTunes stops actively recieving data. Players stop recieving data when they get stuck on a decode.
Well, but looking at the packet traces, I can see that it's actually the server that stops sending. That's what's so odd! I'd love to see the traces from the server side, and I'll hopefully get a chance to soon.

I'm not sure how familiar you are with TCP/IP, but the "flow control" there is pretty straightforward. The sender has a limit of how many bytes it can send without acknowledgement from the recipient - in this case, 65535 bytes. The server was sending down 1460 bytes at a time, and the recipient was acknowledging them within milliseconds, so there was no reason for the server to stop transmitting - yet it did.
I have listened to SHOUTcast streams in iTunes and never experienced any problems so i doubt that iTunes is triggering anything in the server.
Right.. and again, listening to the same stream locally, or rebuffered through another Shoutcast server outside the firewall, works fine. That's what is so puzzling.

Other Jay
Jay Levitt
Posts: 7
Joined: Mon Mar 07, 2005 10:15 pm
Contact:

Post by Jay Levitt »

Looks like this is a firewall config problem. Using a command-line streamripper tool connecting with "User-Agent: iTunes" gives the same problems, but connecting with "User-Agent: jTunes" works fine.

So never mind. Argh.
Post Reply