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

resolve and rendering corrupted frames

resolve and rendering corrupted frames

I had this problem a few months back when a cf card had a few clips with corrupted frames. I think was the hit that day or I don't really know what...
RED cine would crash every time . I managed to render some of those clips with Resolve, it rendered the corrupt frames as black and I cut them out to get parts of a usable clip. Some of the clips rendered all black but 80% of them rendered just fine. With RED cine was impossible, the whole system would crash all the time. I only tried prores as I was editing offline in 1080 did not try DPX and other res. Resolve seems to go over the corrupted frames and render the clip.
 
I was shooting today with 3.2.21 and got a lot of corrupt frames again.

I'm totally scared, don't know what to do. I'll send my camera back.
 
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.

Can you validate that? The developer says specifically that checksums are created "right off the card".
 
If anyone wants to see what's happening:

2l8uv4m.png
 
I have just had an issue with this and I'm wondering why it's becoming so pronounced. I don't like that there is no official response from Red. From the post, it seems too frequent to be a corruption in data transfer. Obviously, people repeating the issue in in-camera playback negates that as well.
 
I think the ssd module were build wrongly and it does not hold the ssd card properly.....sometimes when you use the camera making harsh movements it does cause those corrupted frames...I am having the same issue and I am sending my brain and ssd module back to red tomorrow morning. I had this problem 5 times now and it is unacceptable thinking that you are responsible for the work that you delivery to the clients. This is getting frustrating especially because there is not way to protect it from happening...I tried to use tape to hold the ssd straight into the module but after while I think the connection inside get loose. BAAAAAAAAAAAAAAaaaaaaa
 
I can make my scarlet produce corrupt frames whenever I like. It's not the cables, SSD module or firmware. Just hit record and let it go for more than 3 minutes (sometimes less) and bang....corrupt. The fan hits 100% much quicker than any Epic I've used.....

I'm sending it back to RED this wednesday, they have been very good about the whole thing. I can't wait to have my camera back and begin rebuilding my reputation with clients. I'm both totally pissed and gutted that my 20k investment doesn't work, but, I'm also pleased that RED are treating the issue seriously and making me feel like my investment with THEM is a good one.
 
Okay, just speculation here based on past experience with similar things. I have seen this issue exactly twice, both times repeatable, and both times it happened very frequently over a period of time. However, each had its own cause. The one which produced the part or half frame nasty noise errors, were due to an over heated card reader data on the card was fine, but no matter how often it was re copied, it was at the same point that it corrupted. Switched card readers ( to the red station) and that solved it on that camera. On the other camera and instance, which produced more of the noise pattern shown in a few posts up, where the noise pattern is less defined and seemingly localized to certain areas, it was due to a camera hardware failure. Its the only time i have ever seen it quite like what is above, and it was on a camera that had been struck by lightning, though it didn't begin to reveal itself until nearly a year later. It had to be sent in to Red for repairs. Just stating this as I know that although these look like similar problems, do your due diligence on your own equipment, as just because one is having an issue in camera playback, another may be having a transfer issue due to an over worked reader. Good luck all, I remember the heart failure I had both times i found it. Was glad that it was someone else's that had the major issues, and mine that had the melting card reader. Hope this helps
 
If I can make a suggestion: it would be helpful when reporting an issue on this thread if you can specify firmware, SSD type, RCX version, OS version, and any peripheral hardware or software used to copy the footage. From there it should be pretty easy to start narrowing down common factors.

I assume this is what Red's bomb squad is doing behind the scenes as well.
 
Okay, just speculation here based on past experience with similar things. I have seen this issue exactly twice, both times repeatable, and both times it happened very frequently over a period of time. However, each had its own cause. The one which produced the part or half frame nasty noise errors, were due to an over heated card reader data on the card was fine, but no matter how often it was re copied, it was at the same point that it corrupted. Switched card readers ( to the red station) and that solved it on that camera.

Hi Ian, I'm confused with your post....I got:

> You had a card reader that was not the red station (what card reader exists?) and with that, it was over heating the cards which produced corrupt frames
> You then changed card readers to another one, in this case, the Red Station, and that fixed your camera??

Man I'm so lost with that one....

As for the lightening strike, that sounds like a pretty extreme case....how the heck did that happen? Forget the camera...was the operator okay?
 
If I can make a suggestion: it would be helpful when reporting an issue on this thread if you can specify firmware, SSD type, RCX version, OS version, and any peripheral hardware or software used to copy the footage. From there it should be pretty easy to start narrowing down common factors.

I assume this is what Red's bomb squad is doing behind the scenes as well.

Good plan :)
I ordered my Scarlet November 3rd, and until lately had never recorded anything longer than under 1 minute per take. So, I never saw the problem. Recently I shot a film with 3 minute takes and that's when I saw the problem. It only occurs when recording more than 1 minute, and it seems to be a factor of heat. Even out in the cold of night, with fans auto, the camera seems to get very hot with long (3 minutes) takes. If I record for a few minutes, it's there. Once the noise pattern becomes fixed on screen, camera needs to be shut down to cool down and then a black shade to get rid of it.

> Firmware: 3.0.0 and all in-between firmwares up to 3.2.21
> SSD 64GB, tried 6 different cards
> RCX from 11 to now, problem also occurs in Premiere Pro 5.5, EDIUS 6.5, Davinci Resolve 8 and Davinci Resolve 9 and the Red Player - Corrupt frames are also visable in camera playback, on all firmwares from 3.0.0 to 3.2.21
> OS version (I hate Macs) i7, 8gb RAM, Windows 7
> Copied using E-Sata and USB (tried both) with the REDStation (not mini)

Matt

p.s. Like I said in a previous post, I will be sending my camera off next week and RED are taking a look at it, they have been very supportive and helpful.
 
I got this problem too all of a sudden on my Scarlet. It's on the SSD's and is not a transfer thing...
What now?

Will send in a support ticket and hope for the best :)

EDIT: I have not been able to reproduce the errors I got yesterday... That`s kind of great but also kind of scary as I would rather figure out what I did wrong, if anything.
Will keep testing and report back here if I figure it out :)
 
Did this issue ever get resolved for you guys?

My brand-new BT Scarlet is doing the same exact thing.

Fuck...

P

When my camera started making corrupt frames, I was told by Red that it was a Firmware issue. I am now running the latest release build FW and have not had the issue again.

Keep us posted on your situation.
 
Did this issue ever get resolved for you guys?

My brand-new BT Scarlet is doing the same exact thing.

Fuck...

P

Yeah, it sucks man I know! Mine was brand NEW and doing this....anyway, the ONLY solution is to send it back to RED. It's a hardware fault. Nothing to do with firmware or SSD or heat or anything like that. There's a component in there that isn't working properly and needs to be replaced/fixed. Send it in ASAP! RED will sort you out :) Try not to get too mad....I know I was to begin with, but it doesn't help the situation. Now my camera is back and for the last three solid shoot days in super hot conditions, I've had no such corrupt frames and no problems what-so-ever :) Confidence restored :)
 
Thanks, guys. Yeah, I KNOW RED'll treat me right, they always do. Just... this is a brand-new, "battle tested" Scarlet that's gone through extensive QC after their shoot. So weird this is happening.

I agree it's most likely a hardware fault of some kind, esp. since it hasn't let me do a black shade, either (kicked failure both times).
 
Back
Top