Welcome to our community

Be a part of something great, join today!

  • 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 :)

Corrupt frames - please help

My rep says that they have had no reports of this on Firmware 3.2.21 - so the claim is that it has been solved. Has anyone experienced this on Build 3.2.21? If so - file a ticket so we can help them get to the bottom of it.

This is a lie! I was using 3.2.21 and lost a 25k production because of that! Red is joking with us!
 
Does anyone thought about the serials?

My Scarlet is #1607. What's yours that experienced the problem?
 
This situation is completely unacceptable, let's try to unite everyone that had the same issue and make one big email to Red.

We should start a list. My e-mail is clever@granadafilmes.com.br and I can organize it. Tell everyone with the issue to send me an e-mail. I'll put everyone in contact and we can fight with Red for an explanation.
 
Wondering if we can also describe the shooting conditions when the corrupt frames appeared (i.e power supply used, lights/ballast close to the camera, etc.) Wondering if there are external variables that might be causing it.



edited: for clarity
 
Last edited:
Good point Elan. I have lost probably around ten shoots over the years from a number of factors causing corrupted footage. Cameras from P2's, digibeta, XD 700, canon 5D and also my F3. There are so many possible reasons and sometimes not explainable except that it happened and hasn't happened since. In the end cameras are like anything else...sometimes things go wrong. But it's only when something becomes a pattern and an explanation to possible reasons that it's gets really concerning. But still sucks the big ones when it does!
 
I made a lot of tests the last days, and my belief is, that this issue is related to hardware. I think it is the connection between the SSD side module and the cam.
I had this corrupted frames on every (3....) firmware, and could see them right after shooting in camera playback. From day to day I had more of them, finally in every clip. Completely desperate I took finally the SSD side module away and gave a gentle blow to the contacts on both sides, camera and Side module. After that everything worked fine again. But how long? Is it really related to those contacts?
From experience I know Red support is great, so I´m looking forward to get this issue solved soon. We really need clarification about it! Every affected cam, Epic or Scarlet, can´t go out on a serious job, without at least knowing what can cause this problems.
Thanks,
Marc
 
I made a lot of tests the last days, and my belief is, that this issue is related to hardware. I think it is the connection between the SSD side module and the cam.
I had this corrupted frames on every (3....) firmware, and could see them right after shooting in camera playback. From day to day I had more of them, finally in every clip. Completely desperate I took finally the SSD side module away and gave a gentle blow to the contacts on both sides, camera and Side module. After that everything worked fine again. But how long? Is it really related to those contacts?
From experience I know Red support is great, so I´m looking forward to get this issue solved soon. We really need clarification about it! Every affected cam, Epic or Scarlet, can´t go out on a serious job, without at least knowing what can cause this problems.
Thanks,
Marc

The biggest problem is that the issue is randomly. Red should advise all Red community to don't go shooting in serious jobs otherwise you can get a surprise.
 
I made a lot of tests the last days, and my belief is, that this issue is related to hardware. I think it is the connection between the SSD side module and the cam.
I had this corrupted frames on every (3....) firmware, and could see them right after shooting in camera playback. From day to day I had more of them, finally in every clip. Completely desperate I took finally the SSD side module away and gave a gentle blow to the contacts on both sides, camera and Side module. After that everything worked fine again. But how long? Is it really related to those contacts?
From experience I know Red support is great, so I´m looking forward to get this issue solved soon. We really need clarification about it! Every affected cam, Epic or Scarlet, can´t go out on a serious job, without at least knowing what can cause this problems.
Thanks,
Marc

I did the same thing. The problem disappeared. It's definitely a hardware problem. Does anyone tried it also?
 
Wow, great news Cléver! We´ve got a bit nearer. Now we need somebody with this issue and a Atomos/ Hyperdeck recorder. If someone could record a clip with corrupted frames onto the SSD and at the same time a Prores/DNXHD to another recorder!? If it is the contact on the side module, then it should not appear in the Prores/DNXHD recording.
What do you think?
Thanks,
Marc
 
Wow, great news Cléver! We´ve got a bit nearer. Now we need somebody with this issue and a Atomos/ Hyperdeck recorder. If someone could record a clip with corrupted frames onto the SSD and at the same time a Prores/DNXHD to another recorder!? If it is the contact on the side module, then it should not appear in the Prores/DNXHD recording.
What do you think?
Thanks,
Marc

Yes, this would help us. Does anyone here have an Atomos?
 
No one has ever reported the issue on an Atmos or Sound Devices external recorder. Everyone is having issues with the files off the SSD's, which again is why I thought initially it was either the SSD's or possibly the side module.

I highly highly doubt anyone has gotten an issue with any of the external recording options...
 
how do all of you guys power the camera? vmountplate attached to the back?

I made several tests and had the issue powering the camera by redbricks, redvolts and ac adapter.

It's certainly something related to SSd's or SSD module.
 
I had this same problem with my Red One and CF cards and I learned a lot about it working through it. I think my problem was related to the laptop I was using, but it does appear to be the same problem. Never had it on the hard drive though, only the CF cards. And never had it after moving off of the laptop.

One bad frame will screw up your ability to see footage downstream as it corrupts the computer's memory. THE REST OF THE CLIP MAY NOT BE BAD!!!, just the working memory gets fouled. I had some that were bad enough to crash my Mac (back when I was on one).

My salvage steps:

1. Open RedCine-X. Goto Edit -> Preferences -> Playback and lower memory usage to 1%
2. Turn OFF the Red Rocket as it takes this problem to an unworkable level. If a bad frame hits the RedRocket you have to reboot the computer to be sure of it's state.
3. You need to identify all the bad frames. Open the clip, jump to the end, and slowly scroll backwards to find a bad frame. When you find one write down it's frame number and close RedCine-X to clear out the memory. Open it back up and repeat the step jumping back a little bit to leap over the bad frame, then continue working backwards to find all the corrupted frames in that clip. Every time you touch a bad frame, stop RedCine-X and restart it (It's a major PITA, but for me at least some of my bad frames would show other to be bad when they weren't so it was the only way to know) Once you have all the bad frames in your clip identified you can move on to your workflow...
4. Workflow dependent: At this point you can use RedLine or RedCine-X to transcode the clip, skipping the bad frames. I have also had luck with opening the clips directly in After Effects, adding the clip as a small stub then slowly drawing it out right up to, but not including the bad frame. I then dupe the last good frame, and composite it with the next good frame (however makes sense) to fill in the missing bad frame. On some clips I have been able to export a single bad frame tiff that gets me the good half of the bad frame. You just kind of have to work the problem, usually in a compositor of some type.

R3D Data Manager has a technical limitation that people should understand... The way it works is that it copies out the file to disk, creates a checksum, then copies a second time to memory creating a 2nd checksum, then it compares those two checksums. If there is a repeatable flaw in the copy process it will not be caught by this method. The only way for this to truly work 100% of the time would be to have the CAMERA's brain create the initial checksum that followed the clip as it is copied out (which would be up to Red, but I doubt the current hardware has thad kind of bandwidth to spare). Don't get me wrong, I use this utility and recommend it to others. The checksum process is worth the overhead beacuse it will catch most types of errors, just not all of them on the initial copy off of the RED media. Downstream of this it should be able to catch EVERYTHING as this initial checksum follows the clip unaltered as long as you continue to use the utility to make the copies.



Bob
 
I had this same problem with my Red One and CF cards and I learned a lot about it working through it. I think my problem was related to the laptop I was using, but it does appear to be the same problem. Never had it on the hard drive though, only the CF cards. And never had it after moving off of the laptop.

One bad frame will screw up your ability to see footage downstream as it corrupts the computer's memory. THE REST OF THE CLIP MAY NOT BE BAD!!!, just the working memory gets fouled. I had some that were bad enough to crash my Mac (back when I was on one).

My salvage steps:

1. Open RedCine-X. Goto Edit -> Preferences -> Playback and lower memory usage to 1%
2. Turn OFF the Red Rocket as it takes this problem to an unworkable level. If a bad frame hits the RedRocket you have to reboot the computer to be sure of it's state.
3. You need to identify all the bad frames. Open the clip, jump to the end, and slowly scroll backwards to find a bad frame. When you find one write down it's frame number and close RedCine-X to clear out the memory. Open it back up and repeat the step jumping back a little bit to leap over the bad frame, then continue working backwards to find all the corrupted frames in that clip. Every time you touch a bad frame, stop RedCine-X and restart it (It's a major PITA, but for me at least some of my bad frames would show other to be bad when they weren't so it was the only way to know) Once you have all the bad frames in your clip identified you can move on to your workflow...
4. Workflow dependent: At this point you can use RedLine or RedCine-X to transcode the clip, skipping the bad frames. I have also had luck with opening the clips directly in After Effects, adding the clip as a small stub then slowly drawing it out right up to, but not including the bad frame. I then dupe the last good frame, and composite it with the next good frame (however makes sense) to fill in the missing bad frame. On some clips I have been able to export a single bad frame tiff that gets me the good half of the bad frame. You just kind of have to work the problem, usually in a compositor of some type.

R3D Data Manager has a technical limitation that people should understand... The way it works is that it copies out the file to disk, creates a checksum, then copies a second time to memory creating a 2nd checksum, then it compares those two checksums. If there is a repeatable flaw in the copy process it will not be caught by this method. The only way for this to truly work 100% of the time would be to have the CAMERA's brain create the initial checksum that followed the clip as it is copied out (which would be up to Red, but I doubt the current hardware has thad kind of bandwidth to spare). Don't get me wrong, I use this utility and recommend it to others. The checksum process is worth the overhead beacuse it will catch most types of errors, just not all of them on the initial copy off of the RED media. Downstream of this it should be able to catch EVERYTHING as this initial checksum follows the clip unaltered as long as you continue to use the utility to make the copies.



Bob

Bob, our problem is very different from yours. We have the corrupted files on SSd's and we can see them on playback on camera.
 
Back
Top