There is a bug in RMC4 where downloading large streams will overflow the 32-bit signed integer that stores the amount of bytes that have been downloaded. This means the max that can be downloaded is around 2.1gb until you overflow the int. I have submitted a support ticket on it, I can also post a URL here, but it is an ESPN3 URL so it may not be accessible by the support team. This issue should be reproducible on any stream that downloads over 2.1gb.
Example of the progress log:
...
Downloading (RTMP) - 2097134 KB (02:09:01 / 06:00:08)
Downloading (RTMP) - 2097142 KB (02:09:01 / 06:00:08)
Downloading (RTMP) - 2097147 KB (02:09:01 / 06:00:08)
Downloading (RTMP) - -2147481013 B
Downloading (RTMP) - -2147474243 B
Downloading (RTMP) - -2147466051 B
...
Note the value goes from a positive value to a negative, a sure sign the int has overflowed and the sign bit has been flipped.
i can confirm that I am trying to download an espn3 stream that is fairly long, and at the 2gb file size mark the .flv stops recording. I just purchased the replay media catcher 4 and thought it was that it was being recognized as trial or something. I can provide access to espn3 to one of the admins if they were to email my personal account registered to this. I would also be hopeful that someone could give me a tutorial on how to properly get these espn3 streams. they seem to keep grabbing multiple streams, and the 2gb file i got ended up being great to start but then would really speed up to like 2x speed but the audio was fine for the second hour, so if you know how to get these streams correctly email me or let me know. I guess I should probably start a separate thread for that issue.
My files do the same speed up without audio, or out of sync audio, but I assume it is because they lose timestamps, or the timestamps are assigned negative file locations due to this bug.
Total conjecture, but I bet if the above bug is fixed the rest will be fine.
Edited to add:
Regarding the ESPN3 streams, there are 4 that download and fail initially. I believe these are the server testing to see what quality the stream should be. Then you will DL the main stream. If you double click on the downloading stream, at the end of the URL you will see a number, like 400k, 800k, 1200k. This is the quality of the stream. As the server tests again to see how your DL speeds are, it might stream you a better or worse feed. This will cause multiple downloads of different qualities. You can cancel all but the best qual in the RTMP download mode, or download all the client serves you and keep the feed you want.
This would work awesome if it weren't for the 2gb bug I describe above. The workaround is to use "recording mode" where you record the live stream instead of requesting a huge buffer to DL the thing as fast as possible. I think I capped a whole event with it, but it looks like the event is spread across 3 separate files with 3 separate resolutions, so I am going to have to splice them together in an editor and the result will be a single file with vastly changing quality in it. The end result may not be something I keep, will report back after I find the time to remux out of .flv and sort out what I got.
Last edited by smokee; 03-26-2011 at 08:18 PM. Reason: rambling!
I hope they get this sorted soon. The whole reason I bought this program was to cap the espn3 races. It would tie up too much computer time to cap 12 hours of races using recording mode, and then convert it with a single core cpu (that is going to hurt). Although having it split into seperate files would be a nice feature, as long as they were all uniform quality.
I suggest you to submit a support ticket and to include your login/password so that the developer can test this and make a fix.
I have submitted a support ticket and supplied an account they can use for testing.
submitted mine as well. Have you seen any activity on your ticket smokee? Nothing on my end.
Yes, the support team has responded and requested more info, which was sent on to the dev.
Bookmarks