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

R3D Data Manager Quicktime Batch Renders Released (v4.0)

Photocon said:
Forgive me, but I dont understand where you are reading that it only works from Red Media? It will work from ANY source and write to ANY destination, as long as both are mounted volumes. R3D Data Manager is designed to be an end to end solution. In fact I know of lots of post houses that use R3D Data Manager to transfer clients footage - including a major one that posts on here quite frequently.
Click to expand...

Perfect, add to cart!

It's just that I got a feeling after reading that it can recognice a Red-media and do an Auto copy, and then when done, delete the card.
But if it can also do "normal" drives, then thats greate.
 
hmm, seems like the app only copys the R3D files on a drive.
And that the checksums needs to be created in the source folders.
So if I have a write protected drive, I can't do a checksum.
/carl
 
C_Skaff said:
hmm, seems like the app only copys the R3D files on a drive.
And that the checksums needs to be created in the source folders.
So if I have a write protected drive, I can't do a checksum.
/carl
Click to expand...

No, you have it backwards.

It does create checksums, but whats the use of creating checksums if it only stores it in memory? For data reliability you need to write those checksums down somewhere - preferably in the RDC folder that you just checked. Otherwise :
A) you would not be able to check the r3d files against those checksums in the future,
B) you would not be able to check those r3d files checksums using a different application,
C) you would not meet bond company or insurance requirements,
D) you would potentially lose checksums in a power loss or other outage.

By placing the checksums in the RDC folder you not only accomplish all the above, but ensure that the checksums end up in archives (tape, or otherwise) and ensure that its easy to check them again in the future.
 
here are some small bugs/things I noticed when trying it:

If I select a folder for Source, and then add a directory for a Destination, the app starts by showing me me Source folder.
If I then select a propper folder for Destination... and then put in a new CFcard and select Source again, It starts by showing me the last folder I was last in.
Would be good if I have seperate "memories" for source and destinations.

In QT Render Options:
On output Settings, It would be nice with a
"576 SD anamorphic (PAL 16/9)" & "486 SD anamorphic (NTSC 16/9)
I know its a bit tricky, cus I haven't found any apps that can do it.

How can I get more Codecs installed in R3D Data Manager? I would like to use DV 25p 420 MXF or somehing like that.

I had some issues when I did checksums. First: It didn't create them automaticly, I have to click "Create..." is that right?
If had created MD5-checksum's and changed to SHA-1 and did a "Check..." it shows Error.
I have to delete md5sums.txt in each folder...?

/carl
 
Photocon said:
No, you have it backwards.

It does create checksums, but whats the use of creating checksums if it only stores it in memory? For data reliability you need to write those checksums down somewhere - preferably in the RDC folder that you just checked. Otherwise :
A) you would not be able to check the r3d files against those checksums in the future,
B) you would not be able to check those r3d files checksums using a different application,
C) you would not meet bond company or insurance requirements,
D) you would potentially lose checksums in a power loss or other outage.

By placing the checksums in the RDC folder you not only accomplish all the above, but ensure that the checksums end up in archives (tape, or otherwise) and ensure that its easy to check them again in the future.
Click to expand...

I'd advise strongly against writing the checksum files to the original mag. We've had a few instances where we've had to recover footage from a drive that had a corrupt filesystem and the checksum files made the recover of some shots impossible.

Storing the checksum files in a master directory would be safer IMHO.
 
Deanan said:
I'd advise strongly against writing the checksum files to the original mag. We've had a few instances where we've had to recover footage from a drive that had a corrupt filesystem and the checksum files made the recover of some shots impossible.

Storing the checksum files in a master directory would be safer IMHO.
Click to expand...

Deanan- With all due respect, Id strongly advise against putting them by default into a master directory which you are implying is separate from the RDC folder. In many, if not most, workflows Ive encountered the whole RDC folder is archived, meaning that the checksum files with it. When de-archiving footage that checksum file is right there and easily checkable with R3D Data Manager or with an external application.

In addition, your assertion that the checksum files caused a file to be unreadable makes zero sense. When files are written to the drive they are written to the platters in order. Writing an additional 4kb file to the drive would not write into sectors already occupied by R3D files or other data. In fact, in most circumstances ALL the checksum files would be places AFTER all the R3D files. The ONLY instance where this would not be the case is when the user deleted the footage and did NOT re-format the media (in which case they are going against your previous directive). However in all cases, they would not occupy the same sectors as R3D files.

In addition, it should HELP to determine where files are and what the checksums should be. If the drive dies, the truly only way to make sure the recovery worked is to compare against those checksums. In addition, when doing a sector by sector recovery the checksum files if in between R3D files would help to determine the boundary of said R3D files.

In short - the recovery of those files failed for other reasons, but NOT because of the checksum files, and to use coincidental evidence to state that as fact is wrong.
 
C_Skaff said:
here are some small bugs/things I noticed when trying it:

If I select a folder for Source, and then add a directory for a Destination, the app starts by showing me me Source folder.
If I then select a propper folder for Destination... and then put in a new CFcard and select Source again, It starts by showing me the last folder I was last in.
Would be good if I have seperate "memories" for source and destinations.
Click to expand...

Thats a standard mac application function there to show you the last directory you were at. There should also be a drop down box of the last 4 directories you were at.

C_Skaff said:
In QT Render Options:
On output Settings, It would be nice with a
"576 SD anamorphic (PAL 16/9)" & "486 SD anamorphic (NTSC 16/9)
I know its a bit tricky, cus I haven't found any apps that can do it.
Click to expand...

Anamorphic modes with all red apps are still evolving, mostly because the Red side of things is still evolving too.

C_Skaff said:
How can I get more Codecs installed in R3D Data Manager? I would like to use DV 25p 420 MXF or somehing like that.
Click to expand...

At this time we only support the codecs that Red officially supports. We are looking into adding other codecs.

C_Skaff said:
I had some issues when I did checksums. First: It didn't create them automaticly, I have to click "Create..." is that right?
If had created MD5-checksum's and changed to SHA-1 and did a "Check..." it shows Error.
I have to delete md5sums.txt in each folder...?

/carl
Click to expand...

You should never delete anything.

R3D Data Manager will only create checksums automatically when it detects the source is a Red Media. Otherwise it will not create checksums automatically, and you should click on the create checksums button then.

As for the error - it may be because it didnt find the R3D files or for some other reason. Its hard to know without seeing the error message. However, in our testing you can switch between any of the three without issue. Please note however that sha1 sums are not kept in the md5sums.txt files but rather in the sha1sums.txt file.
 
Photocon said:
You should never delete anything.

R3D Data Manager will only create checksums automatically when it detects the source is a Red Media. Otherwise it will not create checksums automatically, and you should click on the create checksums button then.

As for the error - it may be because it didnt find the R3D files or for some other reason. Its hard to know without seeing the error message. However, in our testing you can switch between any of the three without issue. Please note however that sha1 sums are not kept in the md5sums.txt files but rather in the sha1sums.txt file.
Click to expand...

Here's what I do:
I don't have axces to a red-media. I have a copy of everything that was on one card. I put that on a FW-drive in a folder called CF1. in that folder I have all my original RDC-subfolders.

I select the CF1 as my source

Since it's not a Red-media, I have to create the checksums myself by clicking create. That works fine

But if I change my mind and wants to use SHA-1 instead of MD5. I uncheck the MD5 and check the SHA-1 box.

When that is done, I have to create new checksums, since I donät have any sha1sums.txt-files, only md5sums.txt.
The "create" button is grayed out and only the "check" is avalible. If I click that one, it shown "error" in th eSource folder area under Checksums, next to copies.


I agree that nothing should be deleted, but the only way I found to enable me to "change checksum type" were to delete the md5sums.txt and remove the source folder, add it back into R3D data manager, and click Create again.

maybe it's just the way it is, and doesn't caus a problem for anyone, cus maybe people aren't "changing checksum types" that offten, maybe everyone uses MD5(?) cus its good enough.
But how about adding a fuction that when ckecking for checksums, and the app sees that the checksum that excists isn't the same as the user selected, is keeps the old one and asks the user wether it should use the excisting typ as a check or to create new checksums.
That way I could, when doing archiving to LTO, do all three checksum types (probably take forever) and when I recover from archive, I can simply select witch one I want to use. That way the archive could be on a read-only media and still be able to do all three checksums years from now in either one of these three.

By the way... how do I setup a auto-workflow? I think its possible to set it up in a way that when a red-CF is inserted, it starts the whole prosses.

(what do people actualy use for checksums, MD5?)


Otherwise, nice to get some quick feedback. Hope you don't see these as complaints rather then "helpful comments" :)
/carl
 
You must log in or register to reply here.
Back
Top