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

Build 20.1.3 CF card failure!

J

Jens Jakob Thorsen

Well-known member
Joined
Apr 22, 2007
Messages
804
Reaction score
0
Points
16
Age
60
Location
Denmark
Website
www.jensjakob.com
I had a serious issue with a 16GB CF card the other day. I formatted the card in camera succesfully(20.1.3). I recorded until the 2% media cutoff.
During the day I played back one take to check, no problems.
When I came home and looked at the footage there where only to full takes playable(the first and the last) and 4 partly playable takes. The rest(10 takes) where not palyable. I looked at tha media in Finder and could see old takes from before the formating, but could not play them.
I called Bombsquad and was told to use redundead and then format to fat32 to use the card again.
I tried redundead but it would not give me any files.
I then tried to use R3Dmanager and it created files with similar names as the new broken takes. But non was playable.
The card was upgraded by RED

Any suggestions?
 
This build (20.1.3) is burning. Red must fix this urgently. Too many situations happening like Sata errors and now this. Weird stuff man. I´m rolling a comercial in a week, got my drive and cable shipped to red to fix the Sata trans error but i´m felling that downgrading to build 17 is probally the best thing to do.
 
You used the "R3D Recovery Tool" from R3D Data Manager, which gave you the same files as listed in finder, or the correct footage just not playable?

Have you tried a different computer, to rule out that the copied files are indeed playable?
 
I know it is easy to point a finger at Build 20.1.3 and say it is causing all of these issues. Stuart and I have addressed the SATA error condition many times so I will not rehash our replies here.

Jens and Colin, the quickest way to determine if it is firmware or hardware is to rollback to another Build and see if the situation still arises. I have not heard other reports from other people with the two issues you are seeing. If you have card issues, the first places to look are to see if the cards are being unmounted properly each time, if they are being processed with a UDMA CF card reader, to check to see if the UDMA card reader is damaged, or see if someone bent a pin on the card reader/writer in the CF module. Firmware, AFAIK, won't inflict physical damage to a card - but those other scenarios could.

BC
 
Last edited:
Brent@RED said:
I know it is easy to point a finger at Build 20.1.3 and say it is causing all of these issues. Stuart and I have addressed the SATA error condition many times so I will not rehash our replies here.

Jens and Colin, the quickest way to determine if it is firmware or hardware is to rollback to another Build and see if the situation still arises. I have not heard other reports from other people with the two issues you are seeing. If you have card issues, the first places to look are to see if the cards are being unmounted properly each time, if they are being processed with a UDMA CF card reader, to check to see if the UDMA card reader is damaged, or see if someone bent a pin on the card reader/writer in the CF module. Firmware, AFAIK, won't inflict physical damage to a card - but those other scenarios could.

BC
Click to expand...


none of issues you mention above are the issue. Not to bash the firmware, but all signs point to the firmware.

Colin
 
I understand where you are coming from, Colin. But with thousands of cameras on B20.1.3 and us only having seen your particular issue with you, hopefully you can understand how I want to look at angles other than just firmware. If the firmware caused that issue, I am guessing tech support's inbox would be overflowing with hundreds of others with the same issue. It's not.

Regardless, I have passed along your post to the firmware engineering team to investigate and try to replicate.

BC
 
Build 20

Build 20

This build (20.1.3) is burning. Red must fix this urgently.
Too many situations happening like Sata errors and now this. Weird stuff man.
Click to expand...

No it isn't Luis.

We have explained that Build 20 v20.1.3 reports SATA errors several times on the other thread(s)

It's just not known what Jen's exact issue is - it could easily be a CF reader induced issue - so let's not speculate.

By all means stay on Build 17 if that is your preference, obviously the camera provides that option, but the Build 20 code base is solid.
 
Brent@RED said:
I understand where you are coming from, Colin. But with thousands of cameras on B20.1.3 and us only having seen your particular issue with you, hopefully you can understand how I want to look at angles other than just firmware. If the firmware caused that issue, I am guessing tech support's inbox would be overflowing with hundreds of others with the same issue. It's not.

Regardless, I have passed along your post to the firmware engineering team to investigate and try to replicate.

BC
Click to expand...

Sorry Brent, but we also just had a sata error.... on 20 v20.1.3 !!

Too quote Luis "This build (20.1.3) is burning. Red must fix this urgently."

The camera and drives has never made any errors....! and now on 20.1.3 SATA ERROR????
 
Correct me if I'm wrong, but if I understand Red correctly, build 20.x.x is more sensitive to the quality of the cabling, drives, cards etc. And in the event that the camera detects any anomaly, it reports this error. The fix in these circumstances is to replace the hardware?

Is this correct?
 
Colin has summed it up, pretty much. Build 20.1.3 gives you the SATA error if a hiccup along the eSATA path is detected by the camera. In previous builds, if there was a hiccup, it could lead to the camera rebooting. If you get the SATA error, nothing is "wrong" with the build - it is doing what it is supposed to - alerting you to a hardware issue that could lead to a reboot.

If you get SATA errors, contact tech support so they can get you taken care of.

BC
 
Stuart English said:
No it isn't Luis.

We have explained that Build 20 v20.1.3 reports SATA errors several times on the other thread(s)

It's just not known what Jen's exact issue is - it could easily be a CF reader induced issue - so let's not speculate.

By all means stay on Build 17 if that is your preference, obviously the camera provides that option, but the Build 20 code base is solid.
Click to expand...

Stuart

Just getting this felling by the constant error feedback by many red users me included and not speculate.
As you know getting your footage burned are our worst nightmare.
If the build 20 is solid, and i dont argue about that, seeing lots of guys shouting out for help, should be a good indicator that something need to be made to calm down the waters.
 
I can understand the frustration when the issue crops up for you directly, Luis. We are by no means minimizing that fact.

At the same time, please note that we have thousands of cameras in the field even more drives. This is not a chronic problem with the firmware. As I stated above, it is behaving as it was designed - to alert people of a potential hardware issue that could potentially cause a reboot. By the responses here on REDUSER and through tech support, the numbers of people affected by the SATA errors is very small relative to the number of drives out in the field.

Again, I understand the frustration when you are one of the few affected. We want to get your gear back here, check it out, fix as needed, and have you shooting with confidence.

BC
 
You must log in or register to reply here.
Back
Top