4GB filesize limit

[dinkypumpkin]

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.