#627 closed request (fixed)
Fwd: Nagasaki's icecast server is serving the wrong content-type
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | tbd | Milestone: | ietf-087 |
| Component: | meetecho-streaming | Keywords: | |
| Cc: | My Current Location: | ||
| My MAC Address: | My OS: |
Description
It seems like the mime type of the remote audio stream is wrong again. It is serving audio/mpegurl instead of audio/mpeg. This was fixed last IETF. Note from Bill Fenner detecting it below.
This is causing the iPhone/iPad clients not to work.
Thanks,
Tom
Begin forwarded message:
> From: Bill Fenner <fenner@fenron.com>
> Subject: Re: Nagasaki's icecast server is serving the wrong content-type
> Date: March 12, 2013 11:47:51 AM EDT
> To: joel jaeggli <joelja@bogus.com>
> Cc: Tom Pusateri <pusateri@bangj.com>, Nick Kukich <nkukich@verilan.com>
>
> On Tue, Mar 12, 2013 at 9:49 AM, joel jaeggli <joelja@bogus.com> wrote:
> running icecast 2.3 looking at the config I'm not sure I see an knob for this...
>
> I can upgrade but I'll have to kick all the users off.
>
> I also created a .pls file with the appropriate format which is more expressive but doesn't appear to help.
>
> http://nagasaki.bogus.com/ietf/
>
> So it turns out that the streamer itself is supplying the "audio/mpegurl" content type. I talked to Nick and he is reconfiguring them all to use "audio/mpeg", so starting with the 1:00 sessions streaming to iOS should work right. The server was just reporting to the client what the streamer was reporting to icecast.
>
> Bill
>
>
>
>
> joel
>
>
> On 3/12/13 9:17 AM, Bill Fenner wrote:
> So I tried an IOS "icecast player". It came with some presets, like http://pub4.sky.fm/sky_classical, which it successfully streams and uses "Content-Type: audio/mpeg". nagasaki uses "Content-Type: audio/mpegurl" (which I thought was the content-type for m3u, not for the stream itself).
>
>
> Sample curl output:
>
> forbin:tmp fenner$ curl -v http://nagasaki.bogus.com:8000/stream01 > /dev/null
> * About to connect() to nagasaki.bogus.com <http://nagasaki.bogus.com> port 8000 (#0)
>
> * Trying 147.28.0.81... % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected
> * Connected to nagasaki.bogus.com <http://nagasaki.bogus.com> (147.28.0.81) port 8000 (#0)
>
> > GET /stream01 HTTP/1.1
> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> > Host: nagasaki.bogus.com:8000 <http://nagasaki.bogus.com:8000>
>
> > Accept: */*
> >
> * HTTP 1.0, assume close after body
> < HTTP/1.0 200 OK
> < Content-Type: audio/mpegurl
> < icy-br:64
> < ice-audio-info: bitrate=64;samplerate=22050;channels=2
> < icy-description:ietf86 - Boca1 - am1Orlando
> < icy-genre:misc
> < icy-name:ietf86 - Orlando - Boca1 - am1 - 64Kbps
> < icy-pub:0
> < icy-url:http://nagasaki.bogus.com:8000/stream01
> < Server: Icecast 2.3.2
> < Cache-Control: no-cache
> <
> { [data not shown]
>
> For the one that works:
>
> forbin:tmp fenner$ curl -v http://pub4.sky.fm/sky_classical > /dev/null
> * About to connect() to pub4.sky.fm <http://pub4.sky.fm> port 80 (#0)
>
> * Trying 72.26.204.77... % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected
> * Connected to pub4.sky.fm <http://pub4.sky.fm> (72.26.204.77) port 80 (#0)
>
> > GET /sky_classical HTTP/1.1
> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> > Host: pub4.sky.fm <http://pub4.sky.fm>
>
> > Accept: */*
> >
> * HTTP 1.0, assume close after body
> < HTTP/1.0 200 OK
> < Content-Type: audio/mpeg
> < icy-br:96
> < icy-genre:classical easy symphonic
> < icy-name:Mostly Classical - SKY.FM <http://SKY.FM> - Listen and Relax, it's good for you! www.sky.fm <http://www.sky.fm>
>
> < icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
> < icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>
> < icy-pub:0
> < icy-url:http://www.sky.fm/classical/
> < Server: Icecast 2.3.3-kh5
> < Cache-Control: no-cache
> < Pragma: no-cache
> < Expires: Mon, 26 Jul 1997 05:00:00 GMT
>
> There's a fair bit of evidence that "audio/mpegurl" is actually the content-type for the m3u file, not for the stream itself.
>
> Joel, is there a configuration you can tweak for this, or is this a bug in the server version you're running?
>
> Thanks,
> Bill
>
>
>
Change history (9)
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
On 7/29/13 11:49 AM, Nick Kukich wrote:
> Working on updating this now. I think some old code snuck into the
> latest version of the streaming stuff.
yeah the encoder sets the mime type looks like we got a regression.
> *Nick Kukich*
> *Senior Network Engineer*
> Verilan, Inc.
> 503.710.5115
>
>
>
> On Jul 29, 2013, at 11:37 AM, Tom Pusateri <pusateri@bangj.com
> <mailto:pusateri@bangj.com>> wrote:
>
>> It seems like the mime type of the remote audio stream is wrong again.
>> It is serving audio/mpegurl instead of audio/mpeg. This was fixed last
>> IETF. Note from Bill Fenner detecting it below.
>>
>> This is causing the iPhone/iPad clients not to work.
>>
>> Thanks,
>> Tom
>>
>>
>> Begin forwarded message:
>>
>>> *From: *Bill Fenner <fenner@fenron.com <mailto:fenner@fenron.com>>
>>> *Subject: **Re: Nagasaki's icecast server is serving the wrong
>>> content-type*
>>> *Date: *March 12, 2013 11:47:51 AM EDT
>>> *To: *joel jaeggli <joelja@bogus.com <mailto:joelja@bogus.com>>
>>> *Cc: *Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>>,
>>> Nick Kukich <nkukich@verilan.com <mailto:nkukich@verilan.com>>
>>>
>>> On Tue, Mar 12, 2013 at 9:49 AM, joel jaeggli <joelja@bogus.com
>>> <mailto:joelja@bogus.com>> wrote:
>>>
>>> running icecast 2.3 looking at the config I'm not sure I see an
>>> knob for this...
>>>
>>> I can upgrade but I'll have to kick all the users off.
>>>
>>> I also created a .pls file with the appropriate format which is
>>> more expressive but doesn't appear to help.
>>>
>>> http://nagasaki.bogus.com/__ietf/ <http://nagasaki.bogus.com/ietf/>
>>>
>>>
>>> So it turns out that the streamer itself is supplying the
>>> "audio/mpegurl" content type. I talked to Nick and he is
>>> reconfiguring them all to use "audio/mpeg", so starting with the 1:00
>>> sessions streaming to iOS should work right. The server was just
>>> reporting to the client what the streamer was reporting to icecast.
>>>
>>> Bill
>>>
>>>
>>>
>>>
>>>
>>> joel
>>>
>>>
>>> On 3/12/13 9:17 AM, Bill Fenner wrote:
>>>
>>> So I tried an IOS "icecast player". It came with some
>>> presets, like http://pub4.sky.fm/sky___classical
>>> <http://pub4.sky.fm/sky_classical>, which it successfully
>>> streams and uses "Content-Type: audio/mpeg". nagasaki uses
>>> "Content-Type: audio/mpegurl" (which I thought was the
>>> content-type for m3u, not for the stream itself).
>>>
>>>
>>> Sample curl output:
>>>
>>> forbin:tmp fenner$ curl -v
>>> http://nagasaki.bogus.com:__8000/stream01
>>> <http://nagasaki.bogus.com:8000/stream01> > /dev/null
>>> * About to connect() to nagasaki.bogus.com
>>> <http://nagasaki.bogus.com/> <http://nagasaki.bogus.com
>>> <http://nagasaki.bogus.com/>> port 8000 (#0)
>>>
>>> * Trying 147.28.0.81... % Total % Received % Xferd
>>> Average Speed Time Time Time Current
>>> Dload Upload Total
>>> Spent Left Speed
>>> 0 0 0 0 0 0 0 0 --:--:--
>>> --:--:-- --:--:-- 0connected
>>> * Connected to nagasaki.bogus.com
>>> <http://nagasaki.bogus.com/> <http://nagasaki.bogus.com
>>> <http://nagasaki.bogus.com/>> (147.28.0.81) port 8000 (#0)
>>>
>>> > GET /stream01 HTTP/1.1
>>> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0)
>>> libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
>>> > Host: nagasaki.bogus.com:8000
>>> <http://nagasaki.bogus.com:8000/>
>>> <http://nagasaki.bogus.com:__8000
>>> <http://nagasaki.bogus.com:8000/>>
>>>
>>> > Accept: */*
>>> >
>>> * HTTP 1.0, assume close after body
>>> < HTTP/1.0 200 OK
>>> < Content-Type: audio/mpegurl
>>> < icy-br:64
>>> < ice-audio-info: bitrate=64;samplerate=22050;__channels=2
>>> < icy-description:ietf86 - Boca1 - am1Orlando
>>> < icy-genre:misc
>>> < icy-name:ietf86 - Orlando - Boca1 - am1 - 64Kbps
>>> < icy-pub:0
>>> < icy-url:http://nagasaki.bogus.__com:8000/stream01
>>> <http://nagasaki.bogus.com:8000/stream01>
>>> < Server: Icecast 2.3.2
>>> < Cache-Control: no-cache
>>> <
>>> { [data not shown]
>>>
>>> For the one that works:
>>>
>>> forbin:tmp fenner$ curl -v http://pub4.sky.fm/sky___classical
>>> <http://pub4.sky.fm/sky_classical> > /dev/null
>>> * About to connect() to pub4.sky.fm <http://pub4.sky.fm/>
>>> <http://pub4.sky.fm <http://pub4.sky.fm/>> port 80 (#0)
>>>
>>> * Trying 72.26.204.77... % Total % Received % Xferd
>>> Average Speed Time Time Time Current
>>> Dload Upload Total Spent
>>> Left Speed
>>> 0 0 0 0 0 0 0 0 --:--:--
>>> --:--:-- --:--:-- 0connected
>>> * Connected to pub4.sky.fm <http://pub4.sky.fm/>
>>> <http://pub4.sky.fm <http://pub4.sky.fm/>> (72.26.204.77)
>>> port 80 (#0)
>>>
>>> > GET /sky_classical HTTP/1.1
>>> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0)
>>> libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
>>> > Host: pub4.sky.fm <http://pub4.sky.fm/> <http://pub4.sky.fm
>>> <http://pub4.sky.fm/>>
>>>
>>> > Accept: */*
>>> >
>>> * HTTP 1.0, assume close after body
>>> < HTTP/1.0 200 OK
>>> < Content-Type: audio/mpeg
>>> < icy-br:96
>>> < icy-genre:classical easy symphonic
>>> < icy-name:Mostly Classical - SKY.FM <http://sky.fm/>
>>> <http://SKY.FM <http://sky.fm/>> - Listen and Relax, it's
>>> good for you! www.sky.fm <http://www.sky.fm/>
>>> <http://www.sky.fm <http://www.sky.fm/>>
>>>
>>> < icy-notice1:<BR>This stream requires <a
>>> href="http://www.winamp.com/">__Winamp</a><BR>
>>> < icy-notice2:SHOUTcast Distributed Network Audio
>>> Server/Linux v1.9.8<BR>
>>> < icy-pub:0
>>> < icy-url:http://www.sky.fm/__classical/
>>> <http://www.sky.fm/classical/>
>>> < Server: Icecast 2.3.3-kh5
>>> < Cache-Control: no-cache
>>> < Pragma: no-cache
>>> < Expires: Mon, 26 Jul 1997 05:00:00 GMT
>>>
>>> There's a fair bit of evidence that "audio/mpegurl" is
>>> actually the content-type for the m3u file, not for the
>>> stream itself.
>>>
>>> Joel, is there a configuration you can tweak for this, or is
>>> this a bug in the server version you're running?
>>>
>>> Thanks,
>>> Bill
>>>
>>>
>>>
>>
>
comment:3 Changed 5 years ago by
| Component: | incoming → ietf-streaming |
|---|---|
| Owner: | changed from llynch@… to joelja@… |
| Status: | new → assigned |
comment:4 Changed 5 years ago by
The only place I'm aware of this being defined is in the streamer. I changed the content type during lunch. Is it still showing up incorrectly?
comment:6 Changed 5 years ago by
On 7/29/13 1:21 PM, IETF Meeting/NOC wrote: > #627: Fwd: Nagasaki's icecast server is serving the wrong content-type > ---------------------------------+-------------------------------- > Reporter: pusateri@… | Owner: joelja@… > Type: request | Status: assigned > Priority: tbd | Milestone: ietf-87 > Component: ietf-streaming | Resolution: > Keywords: | My Current Location: > My MAC Address: | My OS: > ---------------------------------+-------------------------------- > > Comment (by nkukich@…): > > The only place I'm aware of this being defined is in the streamer. I > changed the content type during lunch. Is it still showing up > incorrectly? this appears to be working as intended on iphone right now. > > -- > Ticket URL: <https://tickets.meeting.ietf.org/ticket/627#comment:4> > IETF Meeting/NOC <https://tickets.meeting.ietf.org> > IETF Meeting - NOC pages >
comment:8 Changed 5 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Note: See TracTickets for help on using tickets.
Working on updating this now. I think some old code snuck into the latest version of the streaming stuff. Nick Kukich Senior Network Engineer Verilan, Inc. 503.710.5115 On Jul 29, 2013, at 11:37 AM, Tom Pusateri <pusateri@bangj.com> wrote: > It seems like the mime type of the remote audio stream is wrong again. It is serving audio/mpegurl instead of audio/mpeg. This was fixed last IETF. Note from Bill Fenner detecting it below. > > This is causing the iPhone/iPad clients not to work. > > Thanks, > Tom > > > Begin forwarded message: > >> From: Bill Fenner <fenner@fenron.com> >> Subject: Re: Nagasaki's icecast server is serving the wrong content-type >> Date: March 12, 2013 11:47:51 AM EDT >> To: joel jaeggli <joelja@bogus.com> >> Cc: Tom Pusateri <pusateri@bangj.com>, Nick Kukich <nkukich@verilan.com> >> >> On Tue, Mar 12, 2013 at 9:49 AM, joel jaeggli <joelja@bogus.com> wrote: >> running icecast 2.3 looking at the config I'm not sure I see an knob for this... >> >> I can upgrade but I'll have to kick all the users off. >> >> I also created a .pls file with the appropriate format which is more expressive but doesn't appear to help. >> >> http://nagasaki.bogus.com/ietf/ >> >> So it turns out that the streamer itself is supplying the "audio/mpegurl" content type. I talked to Nick and he is reconfiguring them all to use "audio/mpeg", so starting with the 1:00 sessions streaming to iOS should work right. The server was just reporting to the client what the streamer was reporting to icecast. >> >> Bill >> >> >> >> >> joel >> >> >> On 3/12/13 9:17 AM, Bill Fenner wrote: >> So I tried an IOS "icecast player". It came with some presets, like http://pub4.sky.fm/sky_classical, which it successfully streams and uses "Content-Type: audio/mpeg". nagasaki uses "Content-Type: audio/mpegurl" (which I thought was the content-type for m3u, not for the stream itself). >> >> >> Sample curl output: >> >> forbin:tmp fenner$ curl -v http://nagasaki.bogus.com:8000/stream01 > /dev/null >> * About to connect() to nagasaki.bogus.com <http://nagasaki.bogus.com> port 8000 (#0) >> >> * Trying 147.28.0.81... % Total % Received % Xferd Average Speed Time Time Time Current >> Dload Upload Total Spent Left Speed >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected >> * Connected to nagasaki.bogus.com <http://nagasaki.bogus.com> (147.28.0.81) port 8000 (#0) >> >> > GET /stream01 HTTP/1.1 >> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 >> > Host: nagasaki.bogus.com:8000 <http://nagasaki.bogus.com:8000> >> >> > Accept: */* >> > >> * HTTP 1.0, assume close after body >> < HTTP/1.0 200 OK >> < Content-Type: audio/mpegurl >> < icy-br:64 >> < ice-audio-info: bitrate=64;samplerate=22050;channels=2 >> < icy-description:ietf86 - Boca1 - am1Orlando >> < icy-genre:misc >> < icy-name:ietf86 - Orlando - Boca1 - am1 - 64Kbps >> < icy-pub:0 >> < icy-url:http://nagasaki.bogus.com:8000/stream01 >> < Server: Icecast 2.3.2 >> < Cache-Control: no-cache >> < >> { [data not shown] >> >> For the one that works: >> >> forbin:tmp fenner$ curl -v http://pub4.sky.fm/sky_classical > /dev/null >> * About to connect() to pub4.sky.fm <http://pub4.sky.fm> port 80 (#0) >> >> * Trying 72.26.204.77... % Total % Received % Xferd Average Speed Time Time Time Current >> Dload Upload Total Spent Left Speed >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected >> * Connected to pub4.sky.fm <http://pub4.sky.fm> (72.26.204.77) port 80 (#0) >> >> > GET /sky_classical HTTP/1.1 >> > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 >> > Host: pub4.sky.fm <http://pub4.sky.fm> >> >> > Accept: */* >> > >> * HTTP 1.0, assume close after body >> < HTTP/1.0 200 OK >> < Content-Type: audio/mpeg >> < icy-br:96 >> < icy-genre:classical easy symphonic >> < icy-name:Mostly Classical - SKY.FM <http://SKY.FM> - Listen and Relax, it's good for you! www.sky.fm <http://www.sky.fm> >> >> < icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> >> < icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR> >> < icy-pub:0 >> < icy-url:http://www.sky.fm/classical/ >> < Server: Icecast 2.3.3-kh5 >> < Cache-Control: no-cache >> < Pragma: no-cache >> < Expires: Mon, 26 Jul 1997 05:00:00 GMT >> >> There's a fair bit of evidence that "audio/mpegurl" is actually the content-type for the m3u file, not for the stream itself. >> >> Joel, is there a configuration you can tweak for this, or is this a bug in the server version you're running? >> >> Thanks, >> Bill >> >> >> >