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

Epic File Glitches - Anyone run into this?

Adam White

Active member
Joined
Mar 5, 2011
Messages
30
Reaction score
0
Points
0
Location
Cleveland, Ohio
Hello,
My last job (shot on my Epic at 4K) seems to have had a problem after I gave it to the client. As we shot, I transferred each Red Mag to the client's HD via my laptop. Each 128GB mag was only shot to around 60% capacity, just to improve the download workflow. I spot checked a couple of files there at the job with RCX-Pro, just to make sure all was good, which it was. A few days later the client said they were getting glitches on each file, while RCX-Pro 16 was crashing during transcoding more than one clip at a time. I have attached the client's glitch example.

So, anyone ever here or see such a thing before? I have not had any other problem like this, nor was I able to replicate the problem at home with a mag still containing the client's footage.

Thanks,
Adam
A003_C007_1221N7_003.jpg
 
I believe this is just one frame from a clip. And I do not believe they have a rocket.
 
It also appears that the client used CS6 Media encoder to do the transcoding, stating that RCX-Pro 16 crashed too much.
 
Hello,
My last job (shot on my Epic at 4K) seems to have had a problem after I gave it to the client. As we shot, I transferred each Red Mag to the client's HD via my laptop. Each 128GB mag was only shot to around 60% capacity, just to improve the download workflow. I spot checked a couple of files there at the job with RCX-Pro, just to make sure all was good, which it was. A few days later the client said they were getting glitches on each file, while RCX-Pro 16 was crashing during transcoding more than one clip at a time. I have attached the client's glitch example.

So, anyone ever here or see such a thing before? I have not had any other problem like this, nor was I able to replicate the problem at home with a mag still containing the client's footage.

Thanks,
Adam
View attachment 33302

I feel the pain as this has happened to me on two different jobs. Very worrying if it wasn't for the good service and advice provided by the team here at Red Europe.

Open a ticket with Red as soon as poss. This is a familiar glitch for me anyway, as I had it on a couple of occasions and my camera is being shipped to them as we speak. As initial thoughts, after I sent them the camera's redlog and some screen grabs, they rulled out my initial suggestions that it could be the Redmag not having been inserted properly, or dislodged. They said if this would happen, the camera wouldn't record at all. So they think it might be a problem with the SSD block and how it connects to the main camera block. Again, they cannot be certain until they see the camera.

I'll keep you posted on how things go...
 
As we shot, I transferred each Red Mag to the client's HD via my laptop... I spot checked a couple of files there at the job with RCX-Pro, just to make sure all was good...


That description does make it sound like only a single copy was made, with no checksum. If that is the case, you can't tell if there was corruption in the original recording or if it happened during the copy. This is why that is a very risky backup strategy, and not recommended.


If I have misunderstood then I apologise.
 
Sorry but my experience is different and this has been happening in-camera to me. I can see it both in playback using Redcine X and in the same place when I play it using Premiere. THere may be all sorts of things that happen in terms of possible date corruption. But this sort of banding is just like the sort of stuff I have in-camera.
 
Sorry but my experience is different and this has been happening in-camera to me. I can see it both in playback using Redcine X and in the same place when I play it using Premiere. THere may be all sorts of things that happen in terms of possible date corruption. But this sort of banding is just like the sort of stuff I have in-camera.

I'm not saying that this didn't happen in camera. I'm just saying that with only a single copy with no checksum you can't really tell if it did or not (I'm assuming the original REDMAGs have been wiped by now).
 
Sorry but my experience is different and this has been happening in-camera to me. I can see it both in playback using Redcine X and in the same place when I play it using Premiere. THere may be all sorts of things that happen in terms of possible date corruption. But this sort of banding is just like the sort of stuff I have in-camera.

You have it when you playback in-camera directly from the ssd, too. Right?

This used to be a copy issue on the r1.
Never managed to make a repeatable instance of this that was not copy related.

I see now that some manage to get this issue on Epic/scarlet when it is not. I still would controll my copyprocess first.

Which means...
Use r3d data manager with checksum to do the copy.
Copy to at least two separate disks/arrays
Preferably transcode the files before any cards are erased.

When/if I am to take any responsibility for red files, these are my minimum requirements.
Things can slip throughthe md5 controll, be bad on the copy without things being bad on the cards themselves.
Seen this a couple of times.
Never ever erase the cards until the copy is fully veryfied.

Now. This is not in denial of situations where there is a hardware fault on the camera, but still I have NEVER had unresolveable issues with Epic or R1, when following the above pracsise.

And that is for several hundred 1 and 2 camera shooting days on both platforms...
So I feel pretty confident the advice is not directly bad...

Then again, I may just have been lucky with the selection of cameras and media I have had the chance to work with.

Last piece of advice:
NEVER go into production with an untested build (beta or not). Without accepting that new stuff can happen.
If you can tell the producer that, and get acceptance for that: fine
If not: you're on your own
 
I'm not saying that this didn't happen in camera. I'm just saying that with only a single copy with no checksum you can't really tell if it did or not (I'm assuming the original REDMAGs have been wiped by now).

Sure, but if you browse the forum you will find others with similar experiences which point to the camera itself. My advise, my personal opinion of course, is to open a ticket with RED as I imagine you don't want this happening on another job.

Good luck with it. Meanwhile I'll keep you guys posted on how things go with my Scarlet and RED Europe.

Antonio
 
Not denying your experience, Antonio.
Just noting that in the cases I have been able to verify, bad transfering routines has caused 100% of the issues.

I have no problem seeing how a bad esata cable to the ssd recorder, can give the same issues.
 
Not denying your experience, Antonio.
Just noting that in the cases I have been able to verify, bad transfering routines has caused 100% of the issues.

I have no problem seeing how a bad esata cable to the ssd recorder, can give the same issues.

Sure, if you ask me I really hope it's not the camera, although I only use original cables and back things up twice. In interview/documentary situations and minimal crew, you back up before erasing but you don't have the time to watch the whole reel before moving on. It's just not realistic. You trust the integrity of the camera you paid for and you move on swiftly onto the next part of your schedule.
 
Sure, if you ask me I really hope it's not the camera, although I only use original cables and back things up twice. In interview/documentary situations and minimal crew, you back up before erasing but you don't have the time to watch the whole reel before moving on. It's just not realistic. You trust the integrity of the camera you paid for and you move on swiftly onto the next part of your schedule.

NOT if you accept liability for data integrity. THEN you rent more cards. Just sayin'
 
NOT if you accept liability for data integrity. THEN you rent more cards. Just sayin'

Well said Gunleik and point taken. But we're driftin' a bit here. The main point is, you want a camera you can trust. I shot countless times with a number of cameras and I have had issues with dropped frames here and there before. But it was one within quite a few cards. The issue talked about here has happened countless times in the one card and sometimes over several consecutive frames at a time. Two to four frames max in my case. Also in documentary environments, if you shot something you probably won't get a chance to shoot it twice. So you can hire as many cards as you want, the issue will still be there. btw I have had this issue in the mag themselves.
 
Well, goes for the same really... From the sound of it, you have nailed it to a specific card. Then you cannot trust that card.

Don't really think I am drifting.
Huge part of my job used to be to see to and take responsibility for glitches not happening for multiple drama and docus in a broadcast environment. Hickups were simply not accepted.
And we found some simple routines that prevented them from happen.
Skipping those routines, led to hickups. Fortunately solveable, because the cards were intact. But breaking the routines allways caused an issue of sorts down the line. When the routines were in place, they seemed unneccesary, as they picked up any problem we got.

Now.
When I work on my own, I accept that risk to some degree, to be able to get through things on my own and with no budget.
But if there are others involved... I bite my ass into the routines.
And they work.

Part of it is allways test before you shoot, if you use equipment not used by you the last time it was used.
 
Actually, being a bit categoric here, but...

You should ask yourself:
Am I prepared to guarantee the technical integrity of this production?

If answer is: yes
You're either a hothead, or have done a thorugh checkout and prep.

If answer is: no
You should continue testing until it is yes, and if the conditions are in a way that makes it impossible to say yes, you need to inform of that, and make those in charge make the choice of either fixing the situation or accept the risk.

My advice would be to give up the gig, if you cannot guarantee it, even if you have told those in charge that you are unhappy. Eventually it comes back to you if something happens.



I have still to seen the equipment being the actual cause of any problems.
That is NOT to say that I haven't seen bad drives or cables or computers or card readers (so far I haven't seen bad cameras), just that we have been prepared for those events, and that after a proper checkout, it has been an extremely rare event that those issues rises.

As to data integrity, routines seems to be the main concern.
Use checklists. It is very easy to skip a step in the heat of a production when data from multiple cameras enter the workflow in asyncronus paces.

OTOH I have seen productions with tech issues keep on shooting for days and getting days worth of bad footage home because they thought the issue "shouldn't be there".

If you are responsible, one of your most effective tools, is to stop a production if you are not sure about integrity. And you should have the integrity and tech knowledge to do that, if neccesary, and not let the cameras roll until it is solved.
And of course the remedies to solve issues... :-)
 
Back
Top