On 26/11/11 08:13, Andy Bircumshaw wrote:
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<[email protected]> 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.
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
Funny Andy
I really know better than to use BT when using get_iplayer.
Thanks for the tips though. I made a note of them.
For now, I'm still using flvstreamer. Strange eh.
My Netgear DG834GT is one of the better old routers out there.
But I'd be interested in any one else make replacement recommendations :-)
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
