Does anyone know of software compatible with broadcasting an rr.com feed through a proxy server on port 8080?
Broadcast through port 8080
- Thread starter crayon
- Start date
- Status
PeterGV
K1PGV
No, but ScannerCast tried port 80 and if that doesn't work automatically then tries port 8000, if that's of any help.
That *was* requested for compatibility when ScannerCast was first being built... I honestly don't know if RR still accepts connections on that port.
Peter
K1PGV
That *was* requested for compatibility when ScannerCast was first being built... I honestly don't know if RR still accepts connections on that port.
Peter
K1PGV
It wouldn't matter much anyway because the broadcasting software talks to the proxy server on port 8080 and then the proxy server talks to rr.com on port 80. All http traffic has to go through port 8080 to get to the outside world.
I suppose if I was to rephrase the question, I would ask if any broadcasting software allows for configuration of the port instead of it being hard coded in to either port 80 or 8000.
PeterGV
K1PGV
What was I thinking?
You should be able to do it with ScannerCast Std Edition (not the RR Edition, the version you download free from my web site). The only downside is that you'll need to manually configure your feed (not use the auto config feature). Just specify 8080 as the server port, and you should be all set.
I've been using Auto Config for my RR feed for so long that I entirely forgot that my own program had this option!?
Hope that helps,
Peter
K1PGV
You should be able to do it with ScannerCast Std Edition (not the RR Edition, the version you download free from my web site). The only downside is that you'll need to manually configure your feed (not use the auto config feature). Just specify 8080 as the server port, and you should be all set.
I've been using Auto Config for my RR feed for so long that I entirely forgot that my own program had this option!?
Hope that helps,
Peter
K1PGV
Thanks for the reply Peter, I really appreciate it.
Based upon the screenshots posted here: ScannerCast Configuration and Usage Guide , I don't think your software has the needed feature.
What is needed is an option for ScannerCast to be proxy aware (ie: proxy.tld.com:8080) in addition to the option to configure it to know what it's Target Server Information is.
The conversation would go something like this:
As it stands now, if I were to configure the Target Server Information to talk to radioreference.com the first thing that ScannerCast does is a DNS lookup to get an IP address of radioreference.com. Since radioreference.com's IP address is not on the local subnet that means that it has to traverse the WAN. And because all of the address space in use at corp.com is RFC1918 addresses, the very first router that gets this traffic is basically going to tell ScannerCast to go fly a kite because it not going to route any traffic except for RFC1918's.
Without trivializing the huge amount of work that you have already poured into ScannerCast to make it is what is today, proxy server support is nothing new so there shouldn't be a need to reinvent the wheel. Surely there is a library somewhere that you can call, especially if you are programming in VB, that would let ScannerCast talk to a proxy first.
PeterGV
K1PGV
@crayon: Dude, that is about the funniest freakin post I've ever had about a ScannerCast feature. We should, like, frame it or something.
So, what you're asking is for ScannerCast to be proxy aware, as opposed to merely work through a transparent proxy. I guess that should have been obvious... Duh! Sorry.
Even more sorry to say, as much as I appreciate your request... and the way cool 3-way dialog that you wrote between ScannerCast, Proxy, and RadioReference... I've gotta tell you there's really no way, realistically, that I'll be implementing this feature anytime soon.
Yes, ScannerCast is a .NET application and it's written in C#. But, the problem is that ScannerCast talks the ICY protocol to the RR Icecast server, not http (note that Port 80 is used on RR's Icecast servers simply because it's more common for firewalls to allow requests on that port through). So, it's not like I can modify an http GET request to include the eventual end system the way, for example, a web browser does to talk through a proxy. And I can't use the mystic magic http classes built into .NET for the connection, either. Instead, ScannerCast would actually have to get into that dialog you described with your proxy server, exchanging credentials and the like, before it could put up the connection.
I'm not saying the code would be impossible... I'm just saying it would be a lot of real work (I *did* Google around for pre-existing class libraries to do this, and they're not too common)... you're the first one to request this feature, and -- heck -- I haven't even finished implementing the darn VU meter yet, which Gordon asked for, like, a zillion months ago.
So, ANYhow... thanks for the request. I'll remember it, and if I get lots of similar requests, I'll certainly reconsider adding the feature. But, given it's not a simple addition, I don't see it happening anytime soon.
Thanks again for the suggestion/request, and especially for taking the time to write the funny dialog. I've been working awfully hard lately (at my day job) and I really appreciated the chuckle.
Peter
K1PGV
So, what you're asking is for ScannerCast to be proxy aware, as opposed to merely work through a transparent proxy. I guess that should have been obvious... Duh! Sorry.
Even more sorry to say, as much as I appreciate your request... and the way cool 3-way dialog that you wrote between ScannerCast, Proxy, and RadioReference... I've gotta tell you there's really no way, realistically, that I'll be implementing this feature anytime soon.
Yes, ScannerCast is a .NET application and it's written in C#. But, the problem is that ScannerCast talks the ICY protocol to the RR Icecast server, not http (note that Port 80 is used on RR's Icecast servers simply because it's more common for firewalls to allow requests on that port through). So, it's not like I can modify an http GET request to include the eventual end system the way, for example, a web browser does to talk through a proxy. And I can't use the mystic magic http classes built into .NET for the connection, either. Instead, ScannerCast would actually have to get into that dialog you described with your proxy server, exchanging credentials and the like, before it could put up the connection.
I'm not saying the code would be impossible... I'm just saying it would be a lot of real work (I *did* Google around for pre-existing class libraries to do this, and they're not too common)... you're the first one to request this feature, and -- heck -- I haven't even finished implementing the darn VU meter yet, which Gordon asked for, like, a zillion months ago.
So, ANYhow... thanks for the request. I'll remember it, and if I get lots of similar requests, I'll certainly reconsider adding the feature. But, given it's not a simple addition, I don't see it happening anytime soon.
Thanks again for the suggestion/request, and especially for taking the time to write the funny dialog. I've been working awfully hard lately (at my day job) and I really appreciated the chuckle.
Peter
K1PGV
- Status
