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

Help - Offloading Red Drives - Speed vs. Safety

Dustin Cross said:
I am interested to hear what problems people have had with Drag N Drop? I can't even imagine the ones that would make my skin crawl.


Dusty
Click to expand...

Hi Dustin,

I generally do a finder copy to a separate raid prior to using R3D data manager to do the "official" copy to the authoritative source directory. (I generally push pretty hard to be working of CF cards instead of Drives so the finder copy is about five to seven minutes) It's pretty fast, and it's a get out of jail free card in the very unlikely event that the raid six array that I offload to has an issue.

I won't go into exhaustive detail here, but I've seen the file size in byte count be different on occasion when doing a Finder copy. I'm not talking about the first size number listed in the get info window which is effected by block allocation size, but the actual byte count for the file.

I saw this three times last week. A second copy to the same location resulted in the expected identical file size.

I've also had a couple of experiences where the finder completed the copy, and terminated the copy dialog normally, but it skipped sub directories more than one level below the root level of the directory being copied.

That's super rare, but I've personally experienced it.

This is one of those things like a multiple hard drive failure. Chances are it's never going to bite you (so to speak) :-), but do if it does, you're completely hosed.

One of the reasons the guy comes around and hands me a check at the end of the shoot is that he doesn't have to worry about such things, it's my job to make sure it all just works.

Having said that I've had a couple of DP's insist that R3D data manager is too slow and insist that I do only finder copies.

After the obligatory "sin upon your head dread sovereign" conversation, if the director / producer agrees... I shut up and row.

Steve
 
Plenty of people are going to have vastly different and and staunch opinions here. All I will say is that no matter what process you are using, you should be doing manual verification past it.

I have had a "copy, check versus check sum" program report a perfect transfer, only to find on manual verification that the clip had corrupt frames. Now these were not the fault of the program, they were in fact the fault of a dieing cf reader. However, the check sum program saw the data it it's corrupted state and copied it thusly. With out the manual verification I would have left the "during transfer induced" corruption in the clip.

So I say, no matter your transfer process, you should be doing manual verification. As Conrad puts it, how important is your footage. Take the time to make sure its right.
 
J. Eric Camp said:
Plenty of people are going to have vastly different and and staunch opinions here. All I will say is that no matter what process you are using, you should be doing manual verification past it.

I have had a "copy, check versus check sum" program report a perfect transfer, only to find on manual verification that the clip had corrupt frames. Now these were not the fault of the program, they were in fact the fault of a dieing cf reader. However, the check sum program saw the data it it's corrupted state and copied it thusly. With out the manual verification I would have left the "during transfer induced" corruption in the clip.

So I say, no matter your transfer process, you should be doing manual verification. As Conrad puts it, how important is your footage. Take the time to make sure its right.
Click to expand...
Agree 100%. At the very least scrub through, and best case scenario watch the clips all the way through. Not only will you possibly catch a corruption in the file, but there are those times when you might catch a visual problem that you will bring to the camera team's attention (using the correct chain of command of course). This is why having multiple systems that can handle various tasks is often times a necessity on set. You can be backing up on one machine, while visually inspecting clips on another.
 
Watch the footage in real time, there is no substitute.
Check sums are great, but they won't flag dropped frames or any other nastiness in your clips.
 
J. Eric Camp said:
I have had a "copy, check versus check sum" program report a perfect transfer, only to find on manual verification that the clip had corrupt frames.
Click to expand...

I have had the same thing happen consistently with one application. It was also a hardware issue, but a particular [and popular] application out there lets a scary amount of corrupt footage slip by even its most thorough check.

Thankfully the errors were all caught before the original media was scrapped in all cases. I've since moved on to R3D Data Manager with great success.
 
Brook Willard said:
It was also a hardware issue, but a particular [and popular] application out there lets a scary amount of corrupt footage slip by even its most thorough check.
Click to expand...

Ok Brook, now that you said that much, you know you have to name names here buddy. Who is it? or give us the clue. ;)

Prost,
Rich
 
I code on OSX and I am going to reiterate that I wouldn't trust Finder either. I've copied thousands of large files during some application development I was doing and I have noticed a variety of issues:

(1) Copies stalling and locking up
(2) Incomplete copies, especially if other applications are touching the files (a backup started when something was copying)
(3) Lost Files
(4) Inconsistent file lists

The 4th one amazes me and I can recreate it easily. If I have a directory with > 1000 entries, I've had it not sort the contents properly based on name and sometimes those items not show up. It's ALWAYS on drives with thousands of items in the root directory.

For my own critical stuff, I use 'cp' as well from the command line. It has never failed me. Finder scares the CRAP out of me!
 
Brook Willard said:
I have had the same thing happen consistently with one application. It was also a hardware issue, but a particular [and popular] application out there lets a scary amount of corrupt footage slip by even its most thorough check.

Thankfully the errors were all caught before the original media was scrapped in all cases. I've since moved on to R3D Data Manager with great success.
Click to expand...

Would that be Shotput pro?
 
You must log in or register to reply here.
Back
Top