On 26/11/11 09:50, Carl Fletcher wrote:
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
Andy,
Thanks for the explanation - I, too, have had problems under Windoze and
now I think back, it was often related to what else I was doing or what
else I had been doing and it was often cleared with a reboot. Now it
starts to make some sense.
Clive
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
