help, rtmp livestream connection get disconnected after 4 hours

[trebla]

Hi,
I am having issue with recording a livestream. The connection gets disconnected around 4 hours. I tried setting the duration parameter in the "play" message to no avail. Are there any other parameters that need to be set or server message that a client needs to reply in order to prevent the issue. In a wireshark trace, it is the server sending a tcp "FIN" to initiate the disconnection. In rtmpdump trace prior to the tcp disconnect there are no unusual message being dumped out. I am just running out of idea now, any help or pointer would be greatly appreciated. Thanks.

[Stream Ripper]

Giving us the URL for the live stream might be a good start...

[trebla]

Here are the rtmpdump command parameters:

rtmpdump -r rtmp://cp87869.live.edgefcs.net
-s file:///mac.flv
-t rtmp://cp87869.live.edgefcs.net/live
-a live
-y us_100@21007
-p file:///mac.html
-f "LNX 9,0,48,0"
--live
-o test.flv

Thank you very much.

[trebla]

I think that the server stops transmitting media data when the server-to-client bytes approaching 4G. Are there any parameters on the server side that may have an impact on this? Any idea? Thanks.

[compn]

4gb is the filesize limit on FAT32 formatted harddisks.

is your drive formatted in fat32 ?

[trebla]

I have disabled the msgQueue and FLVCache on the server side, presumably, I think the server should just pass the published live stream to client without buffering or caching it in a temporary file. But, who knows. I am still trying to find out which parameter is responsible for it... Thanks for the response...

[compn]

i mean, is the harddrive you run rtmpdump on formatted as fat32?

are you recording your stream using rtmpdump on windows ? if so, there was a bug in mingw that breaks reading files over 4gb.

[trebla]

I have tried sending the output to /dev/null to no avail. I tried to run two separate instances with one hour apart. The first instance failed when the server-to-client bytes reached ~4G while the second instance was still receiving data, then the second instance failed only when the same condition occurred. I tend to think the issue is per session on the server side. Thanks.