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

Recovering Files after POST hang

D

Dave Cox

Well-known member
Joined
Sep 29, 2008
Messages
51
Reaction score
0
Points
0
Hey. I know that people have had this issue before and I have experienced it on repeatable shots in the past - however today we had this problem during a one-off stunt.

When the camera was to be cut, the POST text came up on the camera display and did not go away for some time. The power was hard-powered down in an attempt to review the shot.

The shot would not play back upon booting back up again, and so I took the drive and before doing anything else with it ran redundead to get the r3ds off that were corrupted.

The file will not play back in redcine-x 351 or STORM. I had a quick look with a hex editor and the unplayable file has a different header structure than the file recorded previous to it.

Is there any way to recover the body of this clip through some kind of magic from you guys at RED? I have the r3d and can send it along if that is useful.
 
File a support ticket at red.com/support.

Best of luck, hope you get your footage back.
 
This isn't much help... but I'm just wondering about SOP in that situation.

If you encounter a long POST, you should wait until POST stops displaying before any other actions.

Is that correct?

Is there some point where we can be "assured" POST has failed and rebooting the camera, as done here, is the correct course of action?

I guess I am wondering what the SOP is for various POST related situations?
 
Alexander Ibrahim said:
This isn't much help... but I'm just wondering about SOP in that situation.

If you encounter a long POST, you should wait until POST stops displaying before any other actions.

Is that correct?

Is there some point where we can be "assured" POST has failed and rebooting the camera, as done here, is the correct course of action?

I guess I am wondering what the SOP is for various POST related situations?
Click to expand...

Post can take a long time if you're recording very long clips. This is primarily to make the quicktime wrappers. I'd recommend turning off quicktime wrappers if you don't need them or can generate them later.
 
Having experienced this issue before, we have in fact turned off QT wrappers on all our cameras. When this issue has happened (more rarely on build 30 and also more rarely with QT wrappers off) it is pretty immediately obvious that it has occurred, since normally there is no POST delay when cutting.
 
Deanan said:
Post can take a long time if you're recording very long clips. This is primarily to make the quicktime wrappers. I'd recommend turning off quicktime wrappers if you don't need them or can generate them later.
Click to expand...

So, if you have a long POST, just wait. The camera is just doing its thing.

If waiting is not an option, then configure the camera so that it doesn't have to make the QT wrappers, and things will go faster- assuming you don't need the QT wrappers or can generate them in ingest/post.

If the camera actually malfunctions during POST are there other error messages that come up to alert you that its time to stop waiting?
 
Dave Cox said:
Having experienced this issue before, we have in fact turned off QT wrappers on all our cameras. When this issue has happened (more rarely on build 30 and also more rarely with QT wrappers off) it is pretty immediately obvious that it has occurred, since normally there is no POST delay when cutting.
Click to expand...

There is only a short POST delay if your takes are short.

I did an event recording which was two entire 320GB mags and the POST took a worryingly long time to finish! It was the first time I had ever done takes over a few minutes long.

I'm so glad I waited rather than panicking - although there wasn't any real choice as if it failed I would have lost 2.5 hours of one-off footage!!
 
Alexander Ibrahim said:
So, if you have a long POST, just wait. The camera is just doing its thing...
Click to expand...

I just did a shoot yesterday. Two consecutive short takes (less than 3 minutes), but POST just kept going and going. Eventually the POST message disappeared, but the clips were not there. Checking later, the clip folders were there, but no R3D files or proxies inside them.

On previous shoots, I've had partial R3D files but no proxies too.
 
Eric, what you are describing is closer to the issue we have had with our camera. I will say that we have experienced the long POST issue with QT proxies enabled, but it's been many months since we have had them turned on.

I don't think there are other error messages that indicate if POST has failed versus just taking a while to create the QT proxies. As a data manager I always recommend they are turned off at this point anyhow. We had a higher incidence of failed POST when they were turned on - though it may well be a moot point in later builds.

I have contacted RED support about this, and it's been an issue that I have wanted a clear resolution on for some time, and appears to have been present since at least build 17 - last season on this same series we had the same issue, however this year on build 30.5 with M-X cameras it is much less frequent.

If I do find out anything one way or the other, I will be sure to keep you guys updated.
 
Send the log files to support so they can check to see if there's a hardware issue.
 
Camera generated proxies are great - saves time later.

But what would be cool is some way to abort a POST that was generating the QT proxies but taking too long, but not aborting the part of POST that deals with properly updating the Table of Contents so that full (or even partial) R3D files are saved.

Maybe a two part POST message. I'm making a big assumption that the camera completes the R3D file writing first, and only then generates the proxies. If so, can we have a two stage POST message, ie POST R3D, followed by POST Proxies, with an option to abort the POST Proxies stage? For safety there should NOT be an abort option for the R3Ds for obvious reasons!

If that's not possible, maybe a progress bar with the two stages in different colours. So at least if we have to shut the camera down or pull the power to kill a POST hang, we have some idea when that is really necessary.

At the moment, there is no definitive way to know if a POST is just taking a longer than usual time or the camera has frozen.

On the mad run & gun music video I was doing, the POST hangs and then fail on the last setup of an overrunning day were agonisingly long to wait :(

To be fair the camera was perfectly fine until then!
 
I had this happen on a shoot last week. Half the take - GONE. On top of that - one of my other drives is dropping frames. Most of the drives out there are past their "best before" date. It would be great to get an update on SSD. I don't want to throw good money after bad filing support tickets and paying for repairs to a piece of gear that will be shadowed by SSD. But if SSD is months away - it may be worth the time and money...
 
Is there any reason to have the camera generate the Proxies? Does anyone actually use them anymore? On jobs I am generating ProRes files for offline editorial, I don't think anyone ever looks at the Proxies or uses them for anything. Just curious. They seem antiquated to me.
 
Deanan said:
Send the log files to support so they can check to see if there's a hardware issue.
Click to expand...

Deanan, this issue is coming up all over the place. I've witnessed this on one shoot (not my gear) and have received SOS calls from two other shoots I was not on in the past month. The second someone sends in a file for you to examine, please make this one top priority.
 
Curtis Abbott said:
Is there any reason to have the camera generate the Proxies? Does anyone actually use them anymore? On jobs I am generating ProRes files for offline editorial, I don't think anyone ever looks at the Proxies or uses them for anything. Just curious. They seem antiquated to me.
Click to expand...

A couple of jobs ago, a director wanted to do the offline edit on his laptop using the proxies. I did advise against, but he was technically proficient and wanted to do so anyway. In the end he was the boss and can do it whatever he likes within the realms of possibility.

I like to view the proxies with Quicktime player rather than Redcine-X. Faster to open and can have multiple instances open.
 
Alexis Hanawalt said:
Deanan, this issue is coming up all over the place. I've witnessed this on one shoot (not my gear) and have received SOS calls from two other shoots I was not on in the past month. The second someone sends in a file for you to examine, please make this one top priority.
Click to expand...

I'll try to send some logs in this evening.
 
Dylan Macleod said:
I had this happen on a shoot last week. Half the take - GONE. On top of that - one of my other drives is dropping frames. Most of the drives out there are past their "best before" date. ...
Click to expand...

Well, that might mean that the drives are wearing out!

You know, it would be really nice if we could just swap the drives on our RED Drives. They are generic 2.5" drives after all.

If only someone could have foreseen that these drives would wear out and made accommodations for such user level maintenance. Maybe if some users had asked for this feature.

</sarcasm>

I'm looking forward to the new SSD drives, but at the same time I'm hoping that as the technology advances RED will keep an eye towards user maintenance of the parts - including replacing the flash drive in the enclosures.

RED Users are very competent. I'm sure that, once a procedure was published, they could figure out for themselves if they wanted to try it.
 
Dylan Macleod said:
I am actually considering trying this on one of my drives...
Click to expand...

They are third party drives, but with Red custom firmware, and possibly custom proprietory raid hardware. So probably won't work unless you have the means of reading and flashing the firmware yourself. I haven't had any luck finding DIY software for this.

With Red no longer producing them, it would be great if Red enabled suitably qualified end users to fix their own Red drives at their own risk of course.

Sony et al, while obviously the competition, do allow end users to service and repair gear at their own risk, even providing service manuals. While I understand Red protecting their IP on new and current gear, this would be great to allow for Red gear that was no longer in warranty and/or end of line.

Same with the batteries and chargers - with suitably large safety warnings!!
 
You must log in or register to reply here.
Back
Top