Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Camera Freezes as it "Posts" the clip Recording to DRIVE

F

Federico Verardi

Member
Joined
Nov 20, 2008
Messages
7
Reaction score
0
Points
0
I shot a music video this weekend and had issues with my recently received Red Drive. In 2 instances after hitting the record button to stop the camera the red timecode on the LCD turned into the word "POST" like it usually does, except this time it froze on POST for several seconds. I ended up having to shut down the camera and when I went to play back the clip I got a green screen followed by a message that stated the clip was corrupted. Any ideas out there as to what may have happened? The two times it happened tha camera was being operated hand held but nothing rough, just "floating". Besides I think I would probably drop frames and the camera would tell me?
 
Are you running Build 17? I would suggest testing with Build 18 as it may resolve this issue for you. If not, please contact tech support at www.red.com/support .

Thanks, BC
 
Yes I am running build 17, but I am a little scared of upgrading, I have used another Red Drive and had no problems, so maybe it's the actual hard drive?
 
I am on a feature in Philly right now running three cameras all on build 17 3.4.1 release build and one of the cameras is having this exact same issue. We have had it happen at least half a dozen times in the last three weeks. RED support suggested that it might be the drive cable as we are using the same drive on multiple cameras without issues on all but one.
I would switch all cams to build 18 but I don't like the idea of upgrading in the middle of a show.
 
mikeburton said:
I am on a feature in Philly right now running three cameras all on build 17 3.4.1 release build and one of the cameras is having this exact same issue. We have had it happen at least half a dozen times in the last three weeks. RED support suggested that it might be the drive cable as we are using the same drive on multiple cameras without issues on all but one.
I would switch all cams to build 18 but I don't like the idea of upgrading in the middle of a show.
Click to expand...

Can you try turning off writing the QT wrappers on the camera?
 
This is drive specific.

I bet when you look in the folder for that shot all you have is a 64kb R3D file that doesn't open in RedCine/RedAlert right?

It can also be more prominent on one camera than another but it IS a drive malfunction. Having removed the drive from operation I haven't had this happen once again. The second I ever have it do it again I'll sideline that RedDrive for good too.

Hope this helps as no one had a stone wall reason for why this was happening. I ticketted Red about it and heard nothing. The chaps at Red Europe helped as much as they're allowed too but were also at a loss. I only discovered it was one specific Red Drive after a lot of testing. As you know it doesn't necessarily often happen and it can happen for no real reason so getting it too occur under test conditions when you have all the different variables to consider is a bitch!

Cheers
Paul

EDIT: Just wanted to add that very early builds occasionally had a similar issue but this was most definitely resolved around build 14/15.
 
This is almost certainly NOT drive specific, but probably is probably more correctly labeled "output specific". Indeed, it has nothing whatsoever to do with whether you are using a drive or not, as we have had it happen with our cameras using CF cards (but never with drives). Indeed, last summer, with Build 15 and using ONLY cards (we had two drives, but never once used them), we had it happen so often with camera 1256 that it was essentially rendered useless and put away in its case.

In our case, it turned out to be a bad CF reader/writer. RED sent us out a new reader/writer and it worked almost flawlessly from that point forward. I never once checked to see if the R3D file was good or not, as we only edited off the proxies, and since the proxies weren't there (the problem is that the camera is hanging up during the proxy generation), we never even looked at that footage. (But I wish I had!)

I'll tell you one thing, it cased me innumerable hassles on the set. My camera guys were "cursing" me (their producer/director) all the time!

Stephen
 
I did happen to me few times..
What exactly does Word "POST" Mean?
 
POST is when the camera is writing the QT wrappers, which is why Deenan suggested that you turn off the QT wrappers in camera and create them in post instead.
 
Thanks Birns
 
I had this problem with an early drive. It was replaced under warranty and have not had the problem since. (knock on wood) I'd be looking at the drive.
 
Turn the QT proxies off. Unless they're absolutely essential for your workflow, it's just one extra task you're asking the camera to complete every time you roll.
 
You must log in or register to reply here.
Back
Top