View Full Version : "cannot request non-http url" and other shenanigans

2012-01-20, 12:20
I have a SBT and there have been a couple of issues that pop up on my device when I try to use it at work. First of all I'm forced to use wifi instead of ethernet because (I think) our administrator is blocking outgoing high ports. Second, our wifi interface is very busy and over utilized. So maybe I can short circuit this whole discussion by asking if there is an option for low port (80) access instead of 3483/9000 I see under diagnostics?

If not then why does my SBT need to contact mysqueezebox.com? And why does my device stop working when it cannot contact the server? Either my plugins all disappear or I get a message that says something like "cannot contact mysqueezebox.com". It would be nice if it cached my settings or something.

That problem I might be able to live with because if I can't contact the website then I probably cannot stream. But what is really killing me is the "cannot request non-http url" that I constantly get while I use the device. If I am streaming a station and decide I want to try a different one I click back and either a) choose a new station and nothing happens or b) try a different folder and I get the url error. The way to fix this is so back out all the way to the main menu and then navigate my way back in. Happens on shoutcast and live365. This is extremely annoying! My guess is that this has to do with the flaky wifi I'm attached to, but what can I do to improve robustness of the device?


2012-01-20, 13:40
I have seen the "cannot request non-http url" error using the SKY.fm app since it was recently rewritten. However, it seems to occur only when I try to resume a stream that I was playing in the past. For example, yesterday I was playing one of the channels, then turned the Touch off. Today, I get that error. Once I correct the problem by returning to the SKY.fm entry under My Apps and then select a channel, the problem does not occur. Until later, that is.

There is a bug (http://bugs.slimdevices.com/show_bug.cgi?id=16345) regarding this message. The comment in the bug tracker says this:

"Many services only provide media URLs with an expiry time of a few hours or a
day. After that delay the URL will be invalid. If you're on a playlist you've
assembled the day before, you might very well be trying to get information for
an invalid (outdated) URL."

That seems to be the cause of the problem I am seeing. This was not happening before the app rewrite, which in turn was done because the API changed.


2012-01-20, 13:47
I use ShoutCast all the time, never seen that error. Do you only use it at work? Can you try it on your home network for comparison?
If it is some work related IP restricting or monitoring it may not be solvable on your player.

2012-01-20, 16:30
If my network were restricting access it would never work, but I do think it is related to the flakiness of my work wifi.

2012-01-20, 16:34
If my network were restricting access it would never work, but I do think it is related to the flakiness of my work wifi.

Let me clarify: If my network administrators were restricting access by IP it would never work, and I don't think they do not do any monitoring because the web apps (pandora, live365, shoutcast) all work fine, but I do think it is related to the flakiness of the wifi.