Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 669800 Shoutcast streams on non-standard port would no longer play
Starred by 59 users Reported by viktor.g...@gmail.com, Nov 30 Back to list
Status: Fixed
Owner:
Closed: Jan 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

Blocked on:
issue 624462



Sign in to add a comment
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.3 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open a shoutcast stream broadcasting from a non-standard port, i.e. http://www.memoryradio.de:4000/;7094720172667444stream.nsv - the only thing you get is ERR_INVALID_HTTP_RESPONSE
2. Open the attached html file with several shoutcast streams embedded as HTML5 audio - none would play

What is the expected behavior?
1. In Chrome 54, the stream would start a download (it would play in Firefox)
2. In Chrome 54, all radios embedded in the attached HTML would play fine

What went wrong?
This seems to be related to changes mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=624462 and the same issue reported for WebKit here: https://bugs.webkit.org/show_bug.cgi?id=164530. 

Internet Exploder and Firefox would still play old shoutcast streams on non-standard ports fine.

Did this work before? Yes Chrome 54

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? No
 WebKit Nightly/ Safari 10.0.1 on Sierra

Chrome version: 56.0.2924.3  Channel: n/a
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 24.0 r0

This is not a bug and the problem seems to be on the broadcasting side,  but the recent changes regarding limited/canceled support for HTTP/0.9 will make thousands of internet radio stations unplayable in Chromium based browsers.
 
Added missing attachment with embedded radios.
radiotest.html
797 bytes View Download
I can also confirm the issue happening on Windows 7 as well as Windows 10 on Chrome 55.0.2883.59 beta (64-bit).

According to our records on radio.net a majority of Shoutcast Radio Broadcasters will be affected by this issue.

It would be good if this issue is resolved before the final release of Chrome 55.

Anton Tandiono
Product Manager Website
radio.net by radio.de GmbH
Cc: pbomm...@chromium.org gov...@chromium.org
Labels: -Pri-2 M-55 Pri-1
As per the description, this looks a regression in M55. Lopping to folks involved.
Cc: mmenke@chromium.org
cc'ing mmenke@ for more insights on the issue.
Components: -Internals>Media Internals>Network
Status: ExternalDependency
Viktor:  As you say, we're removing support for HTTP/0.9 over non-default ports, due to a security issue (See  issue 600352  for a description of the actual security issue).  Safari has done this as well, as you say, and I expect Edge and FireFox will do the same as well.

To fix this, the servers just need to send valid HTTP/1.x headers before the response body, or they can use port 80, though we'd really like to work towards removing HTTP/0.9 support entirely.

It is unfortunate that this change break existing Shoutcast servers, but our metrics indicate that HTTP/0.9 usage remains fairly low, and I don't think this is a widespread enough problem to warrant bringing back HTTP/0.9 support, potentially indefinitely.
Labels: -Pri-1 Pri-2
This shouldn't block M55, and given that Safari's already shipped this, I don't think we're going to want to rush out a revert (Or revert at all).
Comment 7 Deleted
In version 55 you removed the flash player, and support for http0.9. It is impossible to listen to all radio stations using shoutcast server v1! Please fix it!
As a website developer for our radio station, this indeed affects as badly. 
Our Shoutcast live stream no longer works in Chrome. Please fix.
@mmenke

Firefox appears to treat all streams beginning with "ICY " as if they were HTTP/1.0, would that be an acceptable workaround? https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpResponseHead.cpp#1091

For ref this was added in https://bugzilla.mozilla.org/show_bug.cgi?id=869725
That looks like a hack around an issue with mime sniffing.  I don't think we want to add a permanent hack to the web platform for this case - it just doesn't seem a widespread enough issue, and given that there's apparently only one software package with the problem, it seems more reasonable to update that, rather than impose a feature on all web browsers in perpetuity.
I understand. The issue is widespread. Most internet radios use the shoutcast v1.
Shoutcast uses HTTP 0.9. I have a company Internet radio. Thousands of customers have lost the ability to listen to music through the fault of chrome.
I can not force my customers to upgrade shoutcast server. Internet radio stations is too much.
Your actions are too aggressive.
Please restore support http 0.9 :(
The change was made due to a security issue with HTTP/0.9.  The fact of the matter is we (And other browsers) are basically stuck either supporting HTTP/0.9 over arbitrary ports forever, or we have to have some path to removal.  Given the security issue, and the low usage of HTTP/0.9, removal seems the way to go.

Fact of the matter is that if we keep HTTP/0.9, the situation is unlikely yo changed in one year, and quite likely it won't have changed in 10 years, given that shouldcast v1 hasn't been updated in 10 (?) years.  And even if that does change, new servers will sprout up relying on HTTP/0.9 support.  We have a responsibility to our users to close the security issue.
Can't you really make such hack as Firefox and treat ICY header as HTTP 1.0? I know that you want Chrome to be as small and fast as possible, do it on mobile version but not on desktops. It is only 4 lines of code, remove support for other services, but not for Shoutcast v1, that won't be updated by Shoutcast.com and is crucial for thousands of radio stations that also can't easily update to v2 (you must upgrade your links to stream on any site, directory or app). It can be compared to force stop using DOS in Windows.
My website has this code:
<audio src="http://mp3stream7.apasf.apa.at:8000/;" controls preload="none"></audio>

The audio server sends a valid status line (ICY 200 OK) and valid key-value pairs:
icy-notice1: <BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
icy-notice2: SHOUTcast Distributed Network Audio Server/win32 v1.9.8<BR>
icy-name: Hitradio OE3
icy-genre: Pop
icy-url: http://oe3.orf.at
content-type: audio/mpeg
icy-pub: 1
icy-br: 128

but because of some bug Chrome ignores these headers and assumes that the entire response is an HTTP/0.9 body, with no headers.

"ICY 200 OK" isn't a valid HTTP/1.x response to an HTTP/1.x request.  Previous versions of Chrome treated it at HTTP/0.9 response (And new versions still will, but only on port 80 for HTTP, and port 443 for HTTPS).
Just to give an idea of the magnitude of the issue: 
At radio.net we know of around 4000 broadcasters affected. 
The number of broadcasters affected worldwide is very likely much higher.

Shoutcast only gave information that official builds of Shoutcasts DNAS v2.4 and newer should not be affected. It doesn't look like they will provide a patch for v1.9.x
http://forums.shoutcast.com/showthread.php?t=398988

We at radio.net are very concerned about this issue and are forced to inform our users to use Firefox, Internet Explorer, Edge or our mobile app, if they wish to continue listening to their (affected) stations.

Anton Tandiono
Product Manager Website
radio.net by radio.de GmbH
PLEASE FIXED ...

:(
This is a serious issue affecting thousands of our streaming servers.
Please consider a Shoutcast specific hack, looking for the "ICY" result code and assume it's http/1.0.

This is a VERY serious issue that could effectively put us out of business. I am needing more time to create a work around/fix for this. However, we need Chome to revert back for a few months longer to give us a chance to fix.  This update came with no warning to us. We need time to create a work around.
Google, please fix!!!
all my shoutcast_V1 stream are DOWN with google chrome 55.
FIX
Comment 22 Deleted
Comment 23 Deleted
Google, it is mandatory that you revert this. Just look @shoutcast.com, over an half of the top listeners streams aren't working anymore.

YOU have broken it :(
No promises, but we're talking about rolling the change back for a couple months.  The concern is we'd just break a bunch of shoutcast streams then, instead of breaking them now, with no significant improvement in the situation.
How about include:  Shoutcast specific hack, looking for the "ICY" result code and assume it's http/1.0. - Hence, you would never have to break them at ANY date!
For folks running shoutcast servers on non-port-80: Are there specific issues which prevent moving to newer versions of the server (like DNAS 2.4)?
> Are there specific issues..
The main issues I know about are:
- The sheer number of installed v1 servers. Can be hundreds on a single node. Need time to migrate
- Many servers are managed and monitored by automation systems that assume shoutcast v1. This can also be fixed given enough time (months)

> The sheer number of installed v1 servers. Can be hundreds on a single node. Need time to migrate

I patched DNAS version 1.9.8 to send radio streams back with an "HTTP/1.0" response line instead of "ICY": http://saynotolinux.com/shoutcast/ . 

I'm not familiar enough with SHOUTCast clients to know if that's kosher or not, but it seems to unbreak playing in Chrome 55 and might be an OK stopgap between DNAS 1.9.8 and 2.x. The protocols seem to have the exact same semantics.
I have checked @jordanmilnes patched linux binary. Thank you!!
It's safe to use: it changes only 2 bytes, a HTTP string and the version string. Displayed version is "v1.9.9 (Dec 10 2016)"
I did not test run it.

For chromium, a temporary rollback may still be the best option.

Could anyone verify to me if only the Shoutcast daemon is the only affected or IceCast is too?
IceCast does not appear to be affected. It uses either HTTP/1.0 or HTTP/1.1 chunked for streams.
@jordanmilnes
can you do a linux version?
thanks
YES!!!the jordanmilne's patch WORK GREAT!!!!!!! Thanks 
@jordanmilne

The Patches Version has a Problem:

<12/15/16@14:39:13> [yp_add] yp.shoutcast.com gave error (nak)
<12/15/16@14:39:13> [yp_add] yp.shoutcast.com gave extended error (Using an unsupported DNAS server, use the SHOUTcast DNAS server instead to be listed.)
Hello to everyone. The Jordanmilne's patch works for chrome 55 issue but with this patch the server stop to publish the stream in the shoutcast directory.
That really a seriously problem, I believe that could ultil generate processes to Google, beucause that update and action is affecting many stream companyes and radios around the world, and who will pay the bill of that problems? You seems amateurs and not studies previously the result of your actions! I see suggestions above to solve that and stop to block that streams, so please make some thinhg to help! I 
I found a workaround: The problem is that chrome blocks HTTP/0.9 on non-standard ports per default; but this behaviour can be disabled using group policies.
Just follow these guidelines: https://support.google.com/chrome/a/answer/187202?hl=en

The policy "Http09OnNonDefaultPortsEnabled" has to be set to "enabled"/"active" (I don't know the english label, in german it's called "Aktiviert").
Restart Chrome and it works!

That's true.  That group policy will be removed sometime next year - it's to allow people time to migrate their servers (Really targeted at enterprises, but end users can take advantage of it, too).  The real solution is for server to migrate to HTTP/1.x or later.
We do need to remove support for HTTP/0.9 on non-standard ports in Chrome, for the aforementioned security reason, and we are not going to hack in support for Shoutcast streams.  The question is whether if we delayed the non-standard-port HTTP/0.9 removal, is is likely that a significant majority of Shoutcast servers could be migrated in the meantime, so we don't just run into this problem again, when we re-remove it.

Given the distributed nature of Shoutcast servers, I'm not really seeing a potential delay getting us much.
This is unfortunate but understandable given the security reasons. We're getting plenty of email complaints about this and more to come as the 55 update rolls out to more people.

Our DB of 91,218 radio servers show that 60,384 are still running Shoutcast v1. This is the vast majority of radio servers that will have any HTML5 players stop working from now on.

As this change is going to persist then more time is needed to upgrade users to Icecast or Shoutcast v2. We are going to work on an upgrade path for our users ASAP. A roll back and time frame for reimplementation would be very much appreciated in the meantime.
A roll back for at least 6 months, or maybe 12, would be great.

But Google should clearly declare this via writing it down in the changelog as significant change due security reasons.

Most newssites also publish the changelog, so there is a chance that (hopefully) many or the most server providers can upgrade to shoutcast v2.

Maybe this could be (clearly only a temporary) solution.

Quote from shoutcast.com:

"SHOUTcast versions prior to 2.0 are over 10 years old and will not be supported and will be delisted from the Website, YellowPages and API soon. Version 2.0 or better is required to retain your SHOUTcast listing. Make sure you’re on a SHOUTcast 2.0 (or newer) server to take advantage of the latest in streaming technology."

I don't think that many serverproviders are aware of this.
Hello! Not quite understand what happened and what to do!
But with online radio stations refused to broadcast 40%.
Notice that the problem only in chrome.
Are users to write, that would use alternative browsers?
Cc: kkaluri@chromium.org
 Issue 674779  has been merged into this issue.
It worked and after the update it stopped. Many stations cannot stream in chrome. I have lost most my listeners. how can Google think screwing those who stream is a good idea? Why not just make youtube obsolete....oh wait, you own them!
It seems that google owns the internet and thinks it can decide what will or will not exist, and does not seem to care if there are people who still use something or not. Keep it up and soon another browser will gain space.
Comment 47 Deleted
Cc: -mmenke@chromium.org
Owner: mmenke@chromium.org
You broke more than 187 radio stations at our company. I hate you rigth now.
Comment 50 Deleted
Could someone explain how this issue can be resolved?

@mmenke mentioned that some valid HTTP headers needs to be set on server side connection before response, could anyone point out which one?
It just needs to send a valid HTTP/1.x status line, optionally followed by valid headers.  i.e:

HTTP/1.x 200 OK
...

(Where "..." is either just a blank line, or HTTP/1.x headers, eventually followed by two CRLFs)
WHMSonic people have fixed this issue already. Yesterday I have received a new update from WHMSonic and my shoutcast v1 HTML5 players are working fine with chrome 55 and opera too. So, if you are using WHMSonic update your software to latest.
Comment 54 Deleted
Thanks @mmenke, this solved my issue!
Anyone got the 1.9.8 patched version? please share the download link because the one shared by @jordanmilnes is no more available on his site at http://saynotolinux.com/shoutcast/


Patch by @jordanmilnes reuploaded. Allegedly this BREAKS listing on shoutcast.com, but fixes Chrome 55 and fresh versions of Safari.
http://s000.tinyupload.com/index.php?file_id=83336842146235185536

Note to mods: This issue affects all platforms, and even affects Flash on Chrome.

This will be the error after using the patched version by @jordanmilnes : 

The server wont be listed on shoutcast.com because this hex edited/patched version does not have ICY 200 OK, it has : HTTP/1.0 200 OK, shoutcast directory will verify your server for this response : ICY 200 OK, so you have to choose either "work with Google Chrome Browser" or "Listed on SHOUTCAST Directory" you cannot have them both.


<12/17/16@13:39:13> [dest: 37.59.27.98] starting stream (UID: 3)[L: 2]{A: SHOUTcast Directory Tester}(P: 1)
<12/17/16@13:39:14> [dest: 37.59.27.98] connection closed (0 seconds) (UID: 3)[L: 1]{Bytes: 39487}(P: 1)
<12/17/16@13:39:14> [yp_add] yp.shoutcast.com gave error (nak)
<12/17/16@13:39:14> [yp_add] yp.shoutcast.com gave extended error (Using an unsupported DNAS server, use the SHOUTcast DNAS server instead to be listed.)

@ p...@icode.se thanks! i just needed to make sure it works on google browser for my site users and listing in shoutcast directory isn't important for me.
Hello

The patch does not work! I downloaded it, stopped it, start it and it did not work, did you upload the correct patch?

I'm very worried about this, please help ...
@jordanmilnes

The patched version of SHOUTcast error (publish on YP, nak error) is because this patched version do not send the Server version,

Example:
Server: SHOUTcast Distributed Network Audio Server/Linux v1.9.8

That is the only element missing from metadata send to yp.shoutcast.com



Guys,

i found this: http://onair18.xdevel.com:8042/ , seems to be another patched version of SHOUTcast DNAS v.1.9.8, know somebody where we can find that version, have included a html5 player on status page.

Thanks
Hello all, 

This is so annoying. Every time Google decides to update, we, developers always suffer. This update broke hell of a lot of things in my company too. We've decided to go back to the IE11 (not joking). I had to re-code all my applications in the past 3 days. Surprisingly my collages said that its (the new apps) looks better, feels better in IE. (again, not joking). 

My major problem is, that our radio streaming website suffering of this. #knockoneffect
At eRadioNow.com we trying to find some solutions with no success. We hoped we could support the 1000's of stations, but we are nowhere compared to Google's mess. Now, we have to wait all of you guys to upgrade your patches. 

Obviously the major browser is Chrome. I really hope some other company will come along and beat them down. 

google! You are so frustrating! 

To all streamers! I feel sorry for you all!
This seriously affects 1000s of stations like myself
I hope someone can create a workaround until Chrome gets its finger out
Another frustrated radio owner here, it was bad enough killing our flash players not long ago, having to re program new players, now even those do not work it's all well and good telling listeners to use Firefox, Edge or Internet Explorer, but Google have promoted Chrome on a big scale, removing services only harms the end user, it may be a small issue to Google, with a fraction of people affected BUT that fraction is hundreds of thousands of internet users who regularly use Chrome to access web radio via Shoutcast, I know of no other (even huge company) who can happily irk so many people, these people will still access web radio they just will not use Chrome, this update has harmed the user, the companies who run radio outlets and yes Google itself.
Updating Shoutcast V1, means changing all the sockets of my IRC bots. Too many hours of missed programming!
On another occasion, I had to change the flash players, now I have to change the version of my Shoutcast?
The only solution I have found until fix it, is to recommend to my listeners that they use another browser.
If anyone knows a patch for Linux Centos 7 64 bits, thank you for sharing it.
Upgrade Shoutcast to version 2.x. It worked for us
Status: WontFix
Thanks for all the feedback on this bug. Ultimately we have decided to keep the behavior introduced in Chrome 55, where HTTP/0.9 (or HTTP/0.9-like) responses are no longer accepted on non-standard ports. 

The reasons behind this decision have been stated earlier in this bug, but to summarize:

- This change in behavior was originally introduced to address a security issue. Safari has also changed behavior for this reason.

- HTTP/0.9 usage across all servers exhibited low usage across Chrome. This included not only Shoutcast servers on non-standard ports, but also any HTTP/0.9 servers on any port.

- An upgrade path exists to Shoutcast v2 which will work with Chrome 55. It looks like this does not cost money to upgrade. According to https://www.shoutcast.com/BroadcastNow, SHOUTcast versions prior to 2.0 are also not supported and will be delisted from their site.

For security-initiated deprecations like this we have to make a tradeoff between the majority of users who are not using HTTP/0.9 (or interpreted response), and the impact removing the feature will have on those who are using it.

The recommendation is that folks who have deployed an earlier version of SHOUTcast upgrade to a newer version of the server.

cbentzel@ we really don't care what Safari does or does not, we asked you/in here about Chrome, we don't need reasons like Safari did that, Mozilla will do that, etc.

I tell you all, forget about Chrome. Use your favorite which works.
I mean seriously cbentzel@? I guess you speak on behalf of google... Google didn't come up with an original idea. It was enough for them to read this thread through and see what the individuals come up with. 

How dare you! I already using FFox.

Looks like in USA everyone lost their mind... No we can #blameTrump and #blameGoogle
Outside of America and the UK, almost nobody uses the desktop version of Safari and most iPhone/iPad users don't care about Safari's compatibility with Shoutcast because they listen to radio stations using native iOS applications in the background.

Oh Apple #bureaucrats.
Status WontFix? Rly? Are you kidding?

Google, YOU, and ONLY YOU breaked this! What Safari does is interesting 0% (in words: ZERO!)
You are abusing your dominant position in the market. You have been completely wrong, you have left thousands of radio stations without service in your browser. Instead of thinking of a solution, your answers are superb and abusing your position. You are simply pathetic.
I am pretty sure that, Chrome will have the Internet Explorer faith, useless.
Your argument of low usage across Chrome is pathetic. Of course have low usage, because the the listener does not remain clicking all the time in the player link to listen, it is normal for the person to access the player and continue navigating the radio website by listening to the radio. The listener will access one time the shoutcast but can access hundreds of other files / pages of the radio station. Dictators!
Time to move to Opera folks. Fast and clean. with built in VPN.
To me this is a predatory move to squash open source streaming to line their own pockets with more money.
Don't be evil my ass.
I agree with what most participants think, but the solution is to use the Patch by @jordanmilnes
Some have reported that that patch removes the radio from the Shoutcast lists, but anyway versions prior to 2, will be removed from those lists soon, according to Shoutcast.
I worked this solution perfectly and my Radio is not interested in being in the Shoutcast Lists.
Blockedon: 624462
FYI I've updated the patched Linux binary to be able to publish to the SHOUTcast directory: http://saynotolinux.com/shoutcast/ . 

Please email me directly using the email on that page if you have any issues with the patches rather than commenting here, as to keep this thread clutter-free for the Chromium folks.

I agree with mmenke, though. It's a wonder that DNAS 1.9.8 streams ever worked correctly in Chrome, and these binaries are 10~ years old. People should upgrade to DNAS 2.x servers as soon as they're able.
Hello,

Shoutcast Relay: It may be temp solution for Shoutcast V1. Most of SC V1 server use ICY 200 header ... where we need HTTP

http://www.radioforge.com/

Use Shoutcast Radio proxy or Shoutcast Re-streaming for Shoutcast old version

http://www.steamcast.com/?req=dir

Thanks

   
sc-relay.png
29.8 KB View Download
Not very good probably ditching chrome
Status: Assigned
In case people missed it in the debate above, there is a (probably temporary) work-around for these issues.  On Windows (tested on Windows 10 but earlier versions should work too):

1) Download the attached policy template (which comes from the ZIP file described here: https://www.chromium.org/administrators/policy-templates)
2) Go to Start->Run (or Windows-R) and type "gpedit.msc"
3) Select User Configuration -> Administrative Templates
4) Right Click and choose "Add/Remove Templates..."
5) Click the "Add..." button
6) Select the chrome.adm file you downloaded above
7) Close the add/remove templates window
8) Still under "Administrative Templates" open "Classic Administrative Templates (ADM)"
9) Open "Google" then click on "Google Chrome"
10) In the list of settings on the right find "Enables HTTP/0.9 support on non-default ports" (just over half way down)
11) Double click that to edit and set the policy to "Enabled"
12) Click OK and then close the group policy editor window
13) From Chrome go to the URL chrome://policy
14) Click the "Reload policies button"

You should now see an entry for Http09OnNonDefaultPortsEnabled saying the policy value is "true".  Chrome 55 will now be restored to the behavior it had in Chrome 54.

Note this was advertised here https://developers.google.com/web/updates/2016/09/chrome-54-deprecations#http09_deprecated.  Unfortunately we didn't hear about Shoutcast being broken from any Chrome dev/beta channel users, so by the time this issue was filed it was too late to change things for Chrome 55.

Re-opening this issue to track (in the new year) taking a closer look at the metrics and following up with the details on the original intent thread for this breaking change: https://groups.google.com/a/chromium.org/d/msg/blink-dev/OdKnpLlvVUo/1EpFGVUjAwAJ

chrome.adm
503 KB Download
Google, please fix!!!

* shoutcast v2 is not upgrade for v1, Shoutcast v2 is a new commercial product
If you'd like to register your interest in seeing this changed, please click the "star" button at the top left.  That's the signal we use to tell how many users care about the issue (and right now it's relatively small - 22).  If you have specific information to add, please feel free.  Eg. the fact that users can't simply upgrade from Shoutcast v1 to v2 is, IMHO, relevant - thank you.

But otherwise "please fix this" comments are unhelpful (just clutter the discussion and can lead to public comments being disabled).
@comment84
"shoutcast v2 is not upgrade for v1, Shoutcast v2 is a new commercial product"
Where is this coming from? When I go to their website it states that SHOUTcast v2 is "Completely Free".
I just installed SHOUTcast v2.5.0.715 to check and it never asked for any payments, am I missing something here?
How to upgrade ShoutCast from version 1.9.8 to version 2.x

1) Download the latest version of SHOUTcast  from http://shoutcast.com/broadcastnow
2) Make a copy of the folder containing your existing SHOUTcast DNAS server.
3) Extract the contents of the file you downloaded which includes the latest version of version ShoutCast.
4) Temporarily stop your existing ShoutCast server.
5) Look in the folder that was just created and locate three files.
The sc_serv[.exe] file.
The cacert.pem file.
The docs folder.
Take the files and move them to the folder containing your old ShoutCast server software, overwriting the existing files (don’t worry you’ve made a copy of the original folder should anything go wrong).
Set aside the software documentation contained in #3 the docs folder so you have a local copy to refer to.
6) Start your newly upgraded  ShoutCast server.
And there you have it, you are now running the latest version of ShoutCast streaming software!
Note: The SHOUTcast D.N.A.S version 2.x includes the same functionality as version 1.98 but has many new features including increased platform stability and resource efficiency. The official word from Radionomy, the owners of the software, is that all stations are very strongly encouraged to upgrade as soon as possible. The update process as detailed above is quite straight forward and very easy, it has been achieved successfully many times and should only take about 5 minutes to complete.
Comment 88 Deleted
"Note: The SHOUTcast D.N.A.S version 2.x includes the same functionality as version 1.98 but has many new features including increased platform stability and resource efficiency"

Sure, but if you ask the radio makers, you get the same statement!
- It's unripe
- It's anything but stable
- Not every broadcast program supports v2
- Missing metatags

To claim an update to v2 would be the better solution - no!

A tip for v1 users:
You can also use v2 as a relay for v1. Chrome users will then able to tune in.  
And regarding, Radionomy does not support v1 any more.

No one knows what Radionomy is planning for the future, but many fear since the acquisition that Radionomy will develop a business model. 
Please fix :(
You have rolled out changes that have affected millions of Internet radio users across the world. You did not think of the consequences of your actions. You hide behind the potential security risk and that Safari has already removed support to justify your unprofessional handling of this upgrade. You have done nothing more than try and pretend this issue has affected a few people. YOU ARE WRONG!!! You have rolled out an upgrade to Chrome with no due diligence in an amateur way. All I have in this forum are arrogant, weak and pathetic answers to our questions, it is plain that the 'WE ARE THE GIANT GOOGLE, WE DO WHAT WE WANT' attitude is prevalent without any commitment to fix what you have broken. I for one think it is an abuse of your dominate position in the market place and would not be surprised if a class legal action is not imminent. I would advise that you bring this issue to the attention of the management, someone that has the understanding of the word 'consequences'
"Sorry, but your Browser doesn't support our radio. We recommend to use Firefox or Opera."

Maybe we'll see this message on some websites... :(
 I'm agree with all comments.Please fix

welcome to global control of internet. time to encourage all visitors on my sites to use Internet Explorer and Safari.
Per comment #85, unless you have new information to add about the issue that has not yet been discussed (Why updating servers is hard, etc), please refrain from commenting.  Not only do "me too" comments make it harder to find the more relevant posts, they're also sent to all the other users who have starred this bug.
To all complainers: @jordanmilne has a really good fix above for this: a patched shoutcast v1 server. It appears to work very well, and is a drop-in replacement.  Also a v2.5 upgrade is not hard, and quite a good option for many.

As per commend 96 I'll add some more info why we can't easy just update our shoutcast v1.

Shoutcast v2 (the latest build) is still buggy, with our setup (I suspect meta data but haven't had time over the holiday to investigate) the v2 server doesn't work well with many client (including Chrome) it sends a small amount of data, then buffers out and drops the client after 30s.  Using a v1 server or an earlier beta v2 both work, but suffer from the header problem here.  When I get chance I'll try and diagnose the new server and post in their forums to try and get the new shoutcast v2 fixed, however that it going to take time (they don't produce new builds often).  Although v2 is the only official version my feeling (and of many others) is its still only at a beta status compared with the old v1 servers.
So for now there isn't an official version of shoutcast that works reliably with Chrome.

I've tried the patched binary above, and it does let Chrome connect, but isn't compatible with the sc_trans source we are using, it connects then drops, I've tried both the compatible and simple versions with the same result.  Again if I have time I could try and snoop the connection and see why, but I suspect sc_trans is not liking the new header, it maybe possible for compatible version patch to have a second exception to send the old header too, but as it is it doesn't work in our setup.

As a work around I've got sc_trans sending to the old beta v2 server which is then relayed to the patched v1 and it has it temporarily working, but it isn't a nice solution. Having Chrome reverted to "just work" would be a much better solution, and address the security issue (which I haven't read up on) in a more compatible way.
Google is kidding its self if it thinks only a few only a few people are affected, hundreds of thousands of stations and millions of listeners is the correct consequence of this change.

I am a station owner and my inbox is full of complaints and listener stats are down.

Using version 2 is not a short term option for us as our station uses many scripts to run tasks which don't work with Verion 2, and the station is listed on dozens of sites which all have to be updated.

Simple answer Google, 'fix it' (please)
There is at least one more oddball Shoutcast-inspired protocol affected by this - wanted to provide some details. 

The Networked Transport of RTCM via Internet Protocol (NTRIP) protocol [1] is used to transfer streaming GNSS (think: GPS) data over the internet. An example server implementation is Trimble Ntrip Caster. 

Similar to the `ICY 200 OK` header, NTRIP returns a "SOURCETABLE 200 OK" response to an HTTP/1.1 request. 

The original design doc acknowledges the deviation from the HTTP standard: "The RTCM SC-104 Committee is aware that the use of HTTP for Ntrip as described in this document differs from the HTTP standard... While the protocol described here works with many proxy servers, their use should be avoided whenever possible." Whoops. 

Apparently NTRIP v2 aims to restore full HTTP 1.1 compatibility. 

[1] http://www.wsrn3.org/CONTENT/Reference/Reference_NTRIP-V1-Tech-paper.pdf

deseo escuchar la estacion de radio 106.1 el LOBO,ya que me gusta mucho la musica en Ingles que pasan en esa estacion de radio, asi como la informacion de los artistas y canciones mas actuales.
Any interest for a cloned (not patched) shoutcast v1 app that avoids this issue, and lists on both xiph.org and shoutcast yp?

Let me know. Its somewhat of a personal project I've been working on for ages; this is the butt-kick I needed to get it working properly. It can read sc_serv.ini files (well the important bits anyway) so its pretty much a drop-in replacement.

I don't use sc_trans, so I've no idea how it plays with that, but I do have Windows 64 & 32-bit binaries, and can build Ubuntu 64-bit binary.

If there's enough interest, I need somewhere to **__anonymously__** host it (offers?!!) and I'll give you guys the link. I don't want to end up like the poor Edcast guy...

Key notes: Drop in replacement for sc_serv in v1 mode. Possibly v2 later, though the authhash shite is a pain in the arse for most. Runs on 'doze and Linux. Its statically linked, so has no dependencies and the exe is just over a meg on 'doze.

Labels: -OS-Mac OS-All
After much discussion and looking at how many users this impacts, we plan on re-enabling HTTP/0.9 over ports other than 80 for Chrome 56.  We'll remove it again in Chrome 57, but we'll also add a hack to allow it just for responses that look to be from Shoutcast servers (Ones that start with "ICY").  So behavior should be just like it was in Chrome 54 and earlier going forward, for Shoutcast servers (Worth noting this does not quite match FireFox's current behavior).
AWESOME !!!!, thank you mmenke@.
Comment 105 Deleted
Thank you MMenke and the Chromium Stuff
Comment 107 Deleted
That was awesome thank u mmenke

SHOUTcast v2 is not a viable option. Thanks as you will enable back on next Chrome build. SHOUTcast v2 is still beta (in my opinion) and will be always till they don't hire a proffesional team to develop that server and to fix all old and actual bugs, 32bits linux version of last SHOUTcast v2 release have a huge bug and they don't care to fix: 

BUG: SHOUTcast DNAS/posix(linux x86) v2.5.1.723 (Sep 30 2016)

Issue: 
ERROR	[YP] Request [https://yp.shoutcast.com/yp2] failed, code: 1 [Protocol "https" not supported or disabled in libcurl]
ERROR	[YP] Internal error. Unknown cmd value in response (8)

Anyway, thank's to enable back @mmenke
no quiero recibir mas notificaciones

2017-01-21 19:28 GMT+00:00 florin.i… via monorail <
monorail+v2.3216032244@chromium.org>:
aldoguineauneca:  If you don't want emails about updates to this bug, you need to unstar it yourself.  Click the yellow star at the top right left.  Sorry for my bad spanish, but...erm...

Use la estrella al máximo izquierdo.
feliz domingo,solo espero que arreglen el sistema para oir las emisora radiales,que no puedo conectar aqui en venezuela,siendo locales,ante lo hacia,,,parece que la competencia de los servidores las bloquean,,,gracias
Saludos para escuchar radio web ko pueden hacer por fire fox o versiones anteriores a la Chrome 55, pueden probar con livetrackradio.com
confirming this new version of chrome is less helpful. would be happy to have these sites accessible again so we can enjoy them as usual
Labels: Restrict-AddIssueComment-EditIssue
Going to go ahead and restrict comments on this, just to avoid comments inserted in the administrivia of merging.
Project Member Comment 116 by bugdroid1@chromium.org, Jan 24
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2617c4a136497244376e1bcf11aa356afb2a1e06

commit 2617c4a136497244376e1bcf11aa356afb2a1e06
Author: mmenke <mmenke@chromium.org>
Date: Tue Jan 24 16:53:52 2017

Enable HTTP/0.9 on non-standard ports by default

This is a temporary patch to enable HTTP/0.9 on non-standard ports by
default.  After merging it with Chrome 56, it will be reverted, in favor
of specifically adding detection of Shoutcast servers on HTTP ports
other than port 80.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2651753002
Cr-Commit-Position: refs/heads/master@{#445743}

[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/chrome/browser/io_thread.cc
[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/net/http/http_network_session.cc

Labels: Merge-Request-56
Requesting merge of https://codereview.chromium.org/2651753002 to M56.  See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qS63pYso4P0 for details.  Change is low risk - setting a bool previously controlled by group policy to be true by default instead of false.

Once merged, I'll revert from trunk and land the long term solution instead (Which will need to be merged to M57 as well).
Project Member Comment 118 by sheriffbot@chromium.org, Jan 24
Labels: -Merge-Request-56 Merge-Review-56 Hotlist-Merge-Review
This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Note that https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qS63pYso4P0 also briefly mentions impact - about 0.4% of users are potentially running into an affected page each week (Some of these are undoubtedly running into things other than shoutcast, unclear what portion of them are).
Labels: -Merge-Review-56 Merge-Approved-56
Approved for merge into M56 based on comments in the thread and low risk of the CL.
Please merge your change ASAP, M56 Stable RC cut is at 4.00 PM today 1/24.
I'm having trouble applying it, unfortunately.  I'll try to make the deadline, but not promises, as I haven't had to work through this sort of thing in quite a while.
Project Member Comment 123 by bugdroid1@chromium.org, Jan 24
Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22

commit 431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22
Author: mmenke <mmenke@chromium.org>
Date: Tue Jan 24 21:06:25 2017

Merge 2617c4a136497244376e1bcf11aa356afb2a1e06
Enable HTTP/0.9 on non-standard ports by default

This is a temporary patch to enable HTTP/0.9 on non-standard ports by
default.  After merging it with Chrome 56, it will be reverted, in favor
of specifically adding detection of Shoutcast servers on HTTP ports
other than port 80.

TBR=eroman@chromium.org
NOTRY=TRUE
NOPRESUBMIT=TRUE
BUG= 669800 

Review-Url: https://codereview.chromium.org/2651753002
Cr-Original-Commit-Position: refs/heads/master@{#445743}
Review-Url: https://codereview.chromium.org/2656693003
Cr-Commit-Position: refs/branch-heads/2924@{#856}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/chrome/browser/io_thread.cc
[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/net/http/http_network_session.cc

Project Member Comment 124 by bugdroid1@chromium.org, Jan 27
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82d19a580c72707597f9e3e60d9f55f271c51317

commit 82d19a580c72707597f9e3e60d9f55f271c51317
Author: mmenke <mmenke@chromium.org>
Date: Fri Jan 27 23:26:32 2017

Revert of Enable HTTP/0.9 on non-standard ports by default (patchset #2 id:20001 of https://codereview.chromium.org/2651753002/ )

Reason for revert:
Removing to apply the CL with Shoutcast detection in its place

Original issue's description:
> Enable HTTP/0.9 on non-standard ports by default
>
> This is a temporary patch to enable HTTP/0.9 on non-standard ports by
> default.  After merging it with Chrome 56, it will be reverted, in favor
> of specifically adding detection of Shoutcast servers on HTTP ports
> other than port 80.
>
> BUG= 669800 
>
> Review-Url: https://codereview.chromium.org/2651753002
> Cr-Commit-Position: refs/heads/master@{#445743}
> Committed: https://chromium.googlesource.com/chromium/src/+/2617c4a136497244376e1bcf11aa356afb2a1e06

TBR=eroman@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 669800 

Review-Url: https://codereview.chromium.org/2656373002
Cr-Commit-Position: refs/heads/master@{#446825}

[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/chrome/browser/io_thread.cc
[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/net/http/http_network_session.cc

Project Member Comment 125 by bugdroid1@chromium.org, Jan 28
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d78f5290a5585d318081007097b9b2ba3b1cf311

commit d78f5290a5585d318081007097b9b2ba3b1cf311
Author: mmenke <mmenke@chromium.org>
Date: Sat Jan 28 01:20:59 2017

Add detection of Shoutcast responses and accept them as valid HTTP/0.9
responses over HTTP ports other than port 80, unlike other HTTP/0.9
responses.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2648253004
Cr-Commit-Position: refs/heads/master@{#446867}

[modify] https://crrev.com/d78f5290a5585d318081007097b9b2ba3b1cf311/net/http/http_stream_parser.cc
[modify] https://crrev.com/d78f5290a5585d318081007097b9b2ba3b1cf311/net/http/http_stream_parser_unittest.cc

Labels: Merge-Request-57
Requesting permission to merge https://codereview.chromium.org/2648253004 to M-57.
Project Member Comment 127 by sheriffbot@chromium.org, Jan 30
Labels: -Merge-Request-57 Merge-Review-57
This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before we approve merge to M57, could you please confirm whether change listed at #126 is well baked/verified in Canary and safe to merge to M57?
It's been in Canary for a couple days without issue, and seems to fix the problem in my limited testing.  It's also a low risk CL (Basically code that was gated on a group policy is now gated on group policy and an extra check).
Labels: -Merge-Review-57 Merge-Approved-57
Approving merge to M57 branch 2987 based on comment #129. Please merge ASAP. If merge happens today before 5:00 PM PT, then we can take it for tomorrow's last M57 Dev release. Thank you.
Project Member Comment 131 by bugdroid1@chromium.org, Jan 30
Labels: -merge-approved-57 merge-merged-2987
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129

commit 9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129
Author: mmenke <mmenke@chromium.org>
Date: Mon Jan 30 19:58:38 2017

Add detection of Shoutcast responses and accept them as valid HTTP/0.9
responses over HTTP ports other than port 80, unlike other HTTP/0.9
responses.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2648253004
Cr-Commit-Position: refs/heads/master@{#446867}
(cherry picked from commit d78f5290a5585d318081007097b9b2ba3b1cf311)

TBR=mmenke@chormium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2665603003
Cr-Commit-Position: refs/branch-heads/2987@{#176}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129/net/http/http_stream_parser.cc
[modify] https://crrev.com/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129/net/http/http_stream_parser_unittest.cc

Labels: -Restrict-AddIssueComment-EditIssue
Status: Fixed
Unrestricting this issue to comments, in case people run into further trouble.  Note that only Chrome 56 and 57 (And later) have fixes, and Chrome 56 isn't on stable channel yet.  Once people are using 56 or later, please post if you're having trouble with Shoutcast servers (If they're working fine, no need to comment).
Labels: Needs-Feedback
Tested the issue on Mac 10.12.2,Win 10 and Ubuntu 14.04 using Dev # 57.0.2987.19 and Beta # 56.0.2924.84, below are the observations.

Steps followed:
1) Followed the steps from Comment #0.
2) Opened http://www.memoryradio.de:4000/;7094720172667444stream.nsv
It starts downloading where as Firefox plays it.
3) When opened radiotest.html the first stream is not playing and rest 3 are playing(same behaviour in FireFox too).

mmenke@: Attached the screen cast of Mac here with, please confirm on the same.
669800_Jan_31.mp4
714 KB View Download
This matches behavior prior to the regression - Chrome doesn't mime sniff nsv files (Per mime sniffing spec).  It needs to be in a media element to play, I believe.
(Note that with chrome 55, you just get an error page)
Had an offline chat with  mmenke@ and performed another testcase with media with Chrome  57.0.2987.19 on Windows 7,10, Mac and Linux.

Steps followed:
1. Try to open "data:text/html,<audio controls> <source src="http://hazzardstream.de:7777/stream/1/" type="audio/mpeg">" in omnibox amd make sure audio is playing.
Labels: -M-55 -Needs-Feedback M-56
Sign in to add a comment