How to use iView (ABC Australia) downloaders

[blood.eaglz]

Originally Posted by gxdata

Yes, some weird server beaviours which usually require waiting until things change again.
Incidentally, I have had a few downloads in the past 3 weeks that connected to Akamai instead of Hostworks (my ISP is iiNet, should be free on Hostworks).

Yep that's one of 3 different server issues I've had the past week or so (I'm with Adam fyi, so also meant to be through hostworks), though my downloads never went through when connecting to akami.

2nd was unable to connect at all via downloader or iview site for a few hours

3rd was a 0kb file (Good Game) that was fixed later.


If the past is any thing to go by this suggests either the hostworks server is being over loaded at certain times again, or they are messing with the server again (eg maintenance or optimisation hopefully nothing more).

Originally Posted by Anywho

They all do. It gets the cue from ABC's server. It's specified in the HOST field of this page.

yeah this is iviews fail safe, should one server provider fail (pretty much equals "hostworks") then all traffic is rerouted through the other as a stop gap, has happened a couple of times since iview started.

[sbt]

Originally Posted by Anywho

You sure something isn't broken on your end, like something blocking port 1935. For example:

• another video playing in a browser at the same time
• firewall permission or antimalware blocking port
• hung program
• more than one instance of RTMPdump or downloader running

Bingo! Thanks, Anywho, that was it! It turned out that a weird set of unrelated changes to my LAN configuration triggered a router firewall fail. RTMP traffic was relying on the side effects of another rule for outbound Skype traffic and I foolishly hadn't checked the firewall log thinking this couldn't be the issue as it hadn't changed; I was focused on the IDS side, which had given issues in the past.

Originally Posted by Anywho

Specifying "-c 80" means you are overriding the port that was specified in the RTMP URL to rtmpdump. I don't think any of the D/Ler's actually specify the port number for the reason mentioned in the following paragraph.

By default, rtmpdump will use port 1935 because that is the specification. I'm not too sure, but I think rtmpdump will fall back to port 80 or else port 443 if it cannot get access to 1935 (will that's what should happen IIRC).

However, I might just ask for confirmation on the RTMPdump mailing list that RTMPdump does actually fall back to other than port 1935 if it's not available.

Yes, I'd discovered this use of port 80 by sniffing traffic from the iView flash client which was still working fine. That's where I got the idea to change to "-c 80". However, to save you the trouble with the RTMPdump folks, I can say in my experience that RTMPdump doesn't fall back (at least in version 2.3). It would be a nice feature, though; if you have any chops with those folks, it'd be great if you'd ask them.

Originally Posted by Anywho

They all do. It gets the cue from ABC's server. It's specified in the HOST field of this page.

OK, sorry, this was a misunderstanding; I'd assumed since my ISP says it's unmetered and they can't unmeter Akamai sources (unlike iiNet) they'd always point me at Hostworks. I'd noticed people complaining on the ABC forums about a lack of fail-over from unmetered to metered sources when the ABC was having load issues with the unmetered side. However, it's probably due to gxdata being with iiNet; they'd have the fail-over option with unmetered Akamai.

I guess if that's true, none of the downloaders will fail-over for me, if they all refer only to the directions in the HOST field and don't second guess it.

Thanks again for the assist and detailed explanations!

[sbt]

Originally Posted by blood.eaglz

If the past is any thing to go by this suggests either the hostworks server is being over loaded at certain times again, or they are messing with the server again (eg maintenance or optimisation hopefully nothing more).

Sorry for the misleading report; this issue turned out to be totally my end!

Originally Posted by blood.eaglz

yeah this is iviews fail safe, should one server provider fail (pretty much equals "hostworks") then all traffic is rerouted through the other as a stop gap, has happened a couple of times since iview started.

As per previous post, I think this behaviour might be ISP specific; I haven't observed at all with Internode, although issues have been mostly with load rather than reachability, so not sure what scenarios would trigger failover in this case.

Thanks again...

[Anywho]

Originally Posted by sbt

It would be a nice feature, though; if you have any chops with those folks, it'd be great if you'd ask them.

OK, I asked on the mailing list (good to see the arrogants and arseholes are still there), and the answer is no, RTMPdump does NOT fallback to ports 443 or 80. And going by the replies so far, there is not going to be any intention to do so.

[sbt]

Originally Posted by Anywho

OK, I asked on the mailing list (good to see the arrogants and arseholes are still there), and the answer is no, RTMPdump does NOT fallback to ports 443 or 80. And going by the replies so far, there is not going to be any intention to do so.

Anywho, thanks very much for running the gauntlet over there ; I guess it'll be up to the downloader developers to handle this if they want, retrying the rtmpdump process using the "-c 80" option if the default doesn't connect. I guess another option would be to fork RTMPdump and add this feature ourselves.

I noticed the batch file downloader already tries "different places" if the default doesn't work. Maybe the port 80 approach could be added as another retry option. Or, maybe just make port 80 the default, if it works for Hostworks.

Cheers.

[Anywho]

Originally Posted by sbt

Anywho, thanks very much for running the gauntlet over there

Hahaha... No probs

We have a winner! Howard Chu, the current author and lead programmer, has added an extra exit-code so that the caller programs can react to a "no-connect" situation. This means that the caller can check for the code (3) and try another port using "-c".

So the codes returned by RTMPdump are/will be:
0 = Success
1 = Failed
2 = Incomplete
3 = No Connection

I just need to compile the latest revision so that everyone can try it

Many thanks to Howard!

[gxdata]

Originally Posted by Anywho

Hahaha... No probs

We have a winner! Howard Chu, the current author and lead programmer, has added an extra exit-code so that the caller programs can react to a "no-connect" situation. This means that the caller can check for the code (3) and try another port using "-c".

So the codes returned by RTMPdump are/will be:
0 = Success
1 = Failed
2 = Incomplete
3 = No Connection

I just need to compile the latest revision so that everyone can try it

Many thanks to Howard!

Well, that is totally unexpected by me (I follow the RTMPdump email list, and there is a lot of grumpiness).

Those extra error codes will be useful (I did ask a naive question on the list 6+ months ago - about getting better error feedback - but was discouraged & gave up).

AdamW is making some progress (same list) with some extra features for rtmpdump, so this is positive for the iView/SBS/Plus!7 downloaders.

[hyc]

Originally Posted by gxdata

Well, that is totally unexpected by me (I follow the rtmpdump email list, and there is a lot of grumpiness).

Nah, it's just low tolerance for stupid questions. Ask something intelligent and you'll get a useful response.

[sbt]

Originally Posted by Anywho

We have a winner! Howard Chu, the current author and lead programmer, has added an extra exit-code so that the caller programs can react to a "no-connect" situation. This means that the caller can check for the code (3) and try another port using "-c".

[snip]

I just need to compile the latest revision so that everyone can try it

Many thanks to Howard!

Yes, that's great news and mad props all round!

Originally Posted by gxdata

Those extra error codes will be useful (I did ask a naive question on the list 6+ months ago - about getting better error feedback - but was discouraged & gave up).

AdamW is making some progress (same list) with some extra features for rtmpdump, so this is positive for the iView/SBS/Plus!7 downloaders.

I always found it annoying to have to manually delete the zero-byte files if the connection barfs. Hopefully the extra error code from RTMPdump means this can be handled in a more user-friendly way.

By the way, you've all been so helpful, so please let me know if I can assist with testing updates, etc. At least I know how to trigger the port fail!

Cheers.

[Yansky]

Originally Posted by hyc

Nah, it's just low tolerance for stupid questions. Ask something intelligent and you'll get a useful response.

I accidentally a whole rtmp, is it dangerous?