New issue
Advanced search Search tips
Starred by 61 users

Issue metadata

Status: Fixed
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

Blocked on:
issue 624462

Sign in to add a comment

Issue 669800: Shoutcast streams on non-standard port would no longer play

Reported by, Nov 30 2016

Issue description

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.;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 and the same issue reported for WebKit here: 

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.
Showing comments 40 - 139 of 139 Older

Comment 40 by, Dec 15 2016

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.

Comment 41 by, Dec 15 2016

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.

Comment 42 by, Dec 15 2016

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 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.

Comment 43 by, Dec 16 2016

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?

Comment 44 by, Dec 16 2016

 Issue 674779  has been merged into this issue.

Comment 45 by, Dec 16 2016

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!

Comment 46 by, Dec 16 2016

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

Comment 48 by, Dec 16 2016


Comment 49 by, Dec 17 2016

You broke more than 187 radio stations at our company. I hate you rigth now.

Comment 50 Deleted

Comment 51 by, Dec 17 2016

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?

Comment 52 by, Dec 17 2016

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)

Comment 53 by, Dec 17 2016

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

Comment 55 by, Dec 17 2016

Thanks @mmenke, this solved my issue!

Comment 56 by, Dec 17 2016

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

Comment 57 by, Dec 17 2016

Patch by @jordanmilnes reuploaded. Allegedly this BREAKS listing on, but fixes Chrome 55 and fresh versions of Safari.

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

Comment 58 by, Dec 17 2016

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

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

Comment 59 by, Dec 17 2016

@ 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.

Comment 60 by, Dec 17 2016


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 ...

Comment 61 by, Dec 18 2016


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

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

That is the only element missing from metadata send to

Comment 62 by, Dec 18 2016


i found this: , 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.


Comment 63 by, Dec 18 2016

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 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!

Comment 64 by, Dec 18 2016

This seriously affects 1000s of stations like myself
I hope someone can create a workaround until Chrome gets its finger out

Comment 65 by, Dec 18 2016

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.

Comment 66 by, Dec 19 2016

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.

Comment 67 by, Dec 19 2016

Upgrade Shoutcast to version 2.x. It worked for us

Comment 68 by, Dec 19 2016

Status: WontFix (was: ExternalDependency)
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, 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.

Comment 69 by, Dec 19 2016

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.

Comment 70 by, Dec 19 2016

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

Comment 71 by, Dec 19 2016

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.

Comment 72 by, Dec 19 2016

Oh Apple #bureaucrats.

Comment 73 by, Dec 19 2016

Status WontFix? Rly? Are you kidding?

Google, YOU, and ONLY YOU breaked this! What Safari does is interesting 0% (in words: ZERO!)

Comment 74 by, Dec 19 2016

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.

Comment 75 by, Dec 19 2016

I am pretty sure that, Chrome will have the Internet Explorer faith, useless.

Comment 76 by, Dec 19 2016

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!

Comment 77 by, Dec 19 2016

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.

Comment 78 by, Dec 20 2016

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.

Comment 79 by, Dec 20 2016

Blockedon: 624462

Comment 80 by, Dec 21 2016

FYI I've updated the patched Linux binary to be able to publish to the SHOUTcast directory: . 

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.

Comment 81 by, Dec 21 2016


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

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

29.8 KB View Download

Comment 82 by, Dec 21 2016

Not very good probably ditching chrome

Comment 83 by, Dec 22 2016

Status: Assigned (was: WontFix)
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:
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  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:
503 KB Download

Comment 84 by, Dec 22 2016

Google, please fix!!!

* shoutcast v2 is not upgrade for v1, Shoutcast v2 is a new commercial product

Comment 85 by, Dec 22 2016

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).

Comment 86 by, Dec 22 2016

"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?

Comment 87 by, Dec 25 2016

How to upgrade ShoutCast from version 1.9.8 to version 2.x

1) Download the latest version of SHOUTcast  from
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

Comment 89 by, Dec 25 2016

"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.

Comment 90 by, Dec 25 2016

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.

Comment 91 by, Dec 25 2016

Please fix :(

Comment 92 by, Dec 27 2016

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'

Comment 93 by, Dec 27 2016

"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... :(

Comment 94 by, Dec 27 2016

I'm agree with all comments.Please fix

Comment 95 by, Dec 28 2016

welcome to global control of internet. time to encourage all visitors on my sites to use Internet Explorer and Safari.

Comment 96 by, Dec 28 2016

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.

Comment 97 by, Dec 28 2016

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.

Comment 98 by, Jan 2 2017

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.

Comment 99 by, Jan 9 2017

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)

Comment 100 by, Jan 9 2017

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. 


Comment 101 by, Jan 18 2017

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.

Comment 102 by, Jan 19 2017

Any interest for a cloned (not patched) shoutcast v1 app that avoids this issue, and lists on both 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.

Comment 103 by, Jan 20 2017

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).

Comment 104 by, Jan 20 2017

AWESOME !!!!, thank you mmenke@.

Comment 105 Deleted

Comment 106 by, Jan 20 2017

Thank you MMenke and the Chromium Stuff

Comment 107 Deleted

Comment 108 by, Jan 21 2017

That was awesome thank u mmenke

Comment 109 by, Jan 21 2017

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)

ERROR	[YP] Request [] 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

Comment 110 by, Jan 21 2017

no quiero recibir mas notificaciones

2017-01-21 19:28 GMT+00:00 florin.i… via monorail <>:

Comment 111 by, Jan 22 2017

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.

Comment 112 by, Jan 22 2017

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

Comment 113 by, Jan 23 2017

Saludos para escuchar radio web ko pueden hacer por fire fox o versiones anteriores a la Chrome 55, pueden probar con

Comment 114 by, Jan 24 2017

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

Comment 115 by, Jan 24 2017

Labels: Restrict-AddIssueComment-EditIssue
Going to go ahead and restrict comments on this, just to avoid comments inserted in the administrivia of merging.

Comment 116 by, Jan 24 2017

Project Member
The following revision refers to this bug:

commit 2617c4a136497244376e1bcf11aa356afb2a1e06
Author: mmenke <>
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 

Cr-Commit-Position: refs/heads/master@{#445743}


Comment 117 by, Jan 24 2017

Labels: Merge-Request-56
Requesting merge of to M56.  See!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).

Comment 118 by, Jan 24 2017

Project Member
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 - Your friendly Sheriffbot

Comment 119 by, Jan 24 2017

Note that!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).

Comment 120 by, Jan 24 2017

Labels: -Merge-Review-56 Merge-Approved-56
Approved for merge into M56 based on comments in the thread and low risk of the CL.

Comment 121 by, Jan 24 2017

Please merge your change ASAP, M56 Stable RC cut is at 4.00 PM today 1/24.

Comment 122 by, Jan 24 2017

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.

Comment 123 by, Jan 24 2017

Project Member
Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:

commit 431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22
Author: mmenke <>
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.
BUG= 669800 

Cr-Original-Commit-Position: refs/heads/master@{#445743}
Cr-Commit-Position: refs/branch-heads/2924@{#856}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}


Comment 124 by, Jan 27 2017

Project Member
The following revision refers to this bug:

commit 82d19a580c72707597f9e3e60d9f55f271c51317
Author: mmenke <>
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 )

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:
> Cr-Commit-Position: refs/heads/master@{#445743}
> Committed:
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 669800 

Cr-Commit-Position: refs/heads/master@{#446825}


Comment 125 by, Jan 28 2017

Project Member
The following revision refers to this bug:

commit d78f5290a5585d318081007097b9b2ba3b1cf311
Author: mmenke <>
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

BUG= 669800 

Cr-Commit-Position: refs/heads/master@{#446867}


Comment 126 by, Jan 30 2017

Labels: Merge-Request-57
Requesting permission to merge to M-57.

Comment 127 by, Jan 30 2017

Project Member
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 - Your friendly Sheriffbot

Comment 128 by, Jan 30 2017

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?

Comment 129 by, Jan 30 2017

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).

Comment 130 by, Jan 30 2017

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.

Comment 131 by, Jan 30 2017

Project Member
Labels: -merge-approved-57 merge-merged-2987
The following revision refers to this bug:

commit 9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129
Author: mmenke <>
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

BUG= 669800 

Cr-Commit-Position: refs/heads/master@{#446867}
(cherry picked from commit d78f5290a5585d318081007097b9b2ba3b1cf311)

Cr-Commit-Position: refs/branch-heads/2987@{#176}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}


Comment 132 by, Jan 30 2017

Labels: -Restrict-AddIssueComment-EditIssue
Status: Fixed (was: Assigned)
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).

Comment 133 by, Jan 31 2017

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;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.
714 KB View Download

Comment 134 by, Jan 31 2017

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.

Comment 135 by, Jan 31 2017

(Note that with chrome 55, you just get an error page)

Comment 136 by, Jan 31 2017

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="" type="audio/mpeg">" in omnibox amd make sure audio is playing.

Comment 137 by, Mar 24 2017

Labels: -M-55 -Needs-Feedback M-56

Comment 138 by, Dec 21 2017

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!!!

Comment 139 by, Feb 1

I'm another user delighted with the station and frustrated with the cutoff. Whatever must be done, please do!
Showing comments 40 - 139 of 139 Older

Sign in to add a comment