To hopefully put this issue to rest (at least until the next Olympics):
On 13/02/2014 13:35, Sam P wrote:
Unfortunately the recording stops at 3.99GB. Please fix this issue
and allow us to download the full file or atleast split it to seperate 4gb
files.
The 4GB limit has absolutely nothing to do with get_iplayer. There is
no "fix" to be made.
On 13/02/2014 19:35, Peter S Kirk wrote:
As dinky has pointed out before, it appears to be an rtmpdump issue. See:
https://code.google.com/p/get-iplayer-automator/issues/detail?id=84
Some here will remember this identical issue coming up during the 2012
Olympics. Those who don't, let Google be your guide.
See the end of comment #13 in that thread for an example of using
--start and --stop to download a humongous programme in chunks and
trimming the files for combining together.
On 13/02/2014 18:57, batguano999 wrote:
I think the 4GB limit might be caused by RTMPDump.
The 4GB limit stems from the behaviour of the Flash media server. It
requires a re-connect once rtmpdump reports it has downloaded 4GB. This
appears to be a by-product of the RTMP protocol.
On 13/02/2014 19:09, J K.Eason wrote:
Dinkypumpkin mentioned in one of the earlier threads (copied below) that
RTMP had a 4GB recording limit, so I guess that could be something to do
with it if you're using a NTFS file system:
NTFS should be OK. It's possible the OP was trying to write to a FAT32
filesystem, but I suspect not.
On 13/02/2014 21:00, Paul Phillips wrote:
C:\Program Files (x86)\get_iplayer>--get 1231 --modes=best --stop
3:30:00 --attempts 1 --force
I'd suggest taking Paul's advice. It's worth noting that the 4GB limit
cuts less than 3 minutes from the end of this particular programme.
You may not want --attempts=1 in this case, since you probably want
get_iplayer to retry the stream in event of a connection timeout.
On 13/02/2014 22:17, Dave Lambley wrote:
It might be worth trying this recording on a machine running a 64 bit
build of rtmpdump. Probably on 64 bit Linux.
The 4GB limit is hit even with 64-bit rtmpdump and OS. However, when the
server stops the stream, 64-bit rtmpdump can recover by resuming the
download as usual, though there is no guarantee it will always resume
properly. 32-bit rtmpdump apparently fails to resume properly, possibly
due a 32-bit integer overflow, but I'm not sure about that. The
rtmpdump build used by Windows get_iplayer is 32-bit.
The only way I know to potentially complete the download in one go is to
use a small hack to rtmpdump so that it never reports receipt of more
than 4GB of data, which seems a bit naughty. Nevertheless, if your
machine and upstream network can sustain the connection, it is possible:
http://pastebin.com/raw.php?i=XgxcvEMM
This should work for 32-bit and 64-bit rtmpdump. If you want to try it
yourself, you can clone my rtmpdump repo and check out the "4GB" branch
to build rtmpdump with the necessary modification:
git clone https://github.com/dinkypumpkin/rtmpdump.git
See the README and Makefile for build info. I recommend building with
SHARED=no for static linking of librtmp.
Use --rtmpdump to instruct get_iplayer to use the alternate build of
rtmpdump. If your output directory is on a NAS, you also may wish use
--raw to avoid the wait for re-muxing and tagging.
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
