Recent download issues

[Andy Bircumshaw]

On 24 November 2011, at 09:51, Carl Fletcher wrote:

> On 24/11/11 08:53, Jon Davies wrote:
>> On 24 November 2011 05:10, Carl Fletcher<kernelbasher at gmail.com>  wrote:
>>> I'm getting errors like this:
>>> 
>>> INFO:   sampletype            mp4a
>>> 467726.949 kB / 2546.96 sec (73.2%)
>>> ERROR: RTMP_ReadPacket, failed to read RTMP packet body. len: 70382
>>> 467775.627 kB / 2546.96 sec (73.2%)
>>> INFO: Connection timed out, trying to resume.
> ...
> using the same network, was having the same result.
> 
> Couple of things I have to look at:
> 
> 1. My router
> I have a feeling it's on it's last legs. But it's not causing problems for me with the BT sync, which usually happens with flaky routers.
> 
> 2. My ISP
> Entanet have been really good for me for years. But I'm going to contact them.
> Partly because on another subject. I have noticed Linux .iso's via bittorrent will scream down then suddenly it drops off to Zero for a few seconds, then comes right back.
> 
> flvstreamer just seems to deal better with the hang and picks up again (assuming it is a hang we are getting) But I see what you mean Jon.

Running BitTorrent at the same time will contribute to problems like this.

Older routers have slow CPUs and relatively little RAM. Their NATting tables tend to fill up when you run BitTorrent, because you have many other seeds constantly connecting to you to make a new connection (then often disappearing, leaving idle but open connections). New routers can handle heavy BitTorrent traffic better. E.G. The original WRT54G runs at 125Mhz and has 16MB RAM; modern routers have perhaps 600Mhz CPUs and 128MB RAM.

When running BitTorrent adjust the settings in the client to a lower number of permitted connections (and other related options proportionately). With only 15 connections permitted in deluge, I still often manage to max out the 150kb/sec download limit I set (my ADSL runs only about 2 - 3meg).

I have also experienced the "failed to read RTMP packet body", and this seems to fix it.

TCP provides reliable data transmission, in that the o/s / networking stack will keep retrying if there are any lost packets, and ensure that the application receives all the data. UDP is "unreliable", and packets may be dropped; the application must account for any losses and retransmission itself. I suspect that RTMP is like the latter - if we're streaming a video conference it doesn't matter if a few frames are dropped, so much as that the received video should catch up to the current state of the transmission; it doesn't matter what the speaker said 2 minutes ago, we need the conference to resume as quickly as possible with the minimum interruption.

When I see errors like this, I just identify the PID of the rtmpdump process (`lsof /path/to/downloads/*partial*`), then `kill $PID && rm /path/to/downloads/*partial*` - get_iplayer (running in a separate terminal window or via crontab) will take a couple of seconds to recognise the death of the rtmpdump process, and will try again; the new download will be initiated from scratch.

aB.