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

R3D data manager???

well, can you? i'd love to hear your thoughts on that backup strategy


Anyway, r3d data manager has been saving my ass the past few days.

so far only one request:

when i view the copy results, it would be great if i could resize that window with the log in it so that each line of the log fills up one line and goes across my screen. its kind of annoying to figure out where each line ends and the next begins when im scrolling through the log.. its copying now so i cant test it, but i think when you resize the log window it just gets bigger but the square window of text that displays the log stays the same size! can you fix that?
 
well, can you? i'd love to hear your thoughts on that backup strategy

Honestly, I make a living figuring out data workflows and backup strategies for films, so Im not going to give away all the secrets. However, given that you need to change batteries about every 90 minutes, and music act rarely do sets longer than 40 minutes, its not hard to see where 4 drives would allow you to do a usable workflow where your data is protected and backed up and at the end of the day you have less than 150Gb on your last drive to download.

Since writing R3D Data Manager, Ive heard lots of stories about how they werent able to backup because of X, Y, and Z. The most often heard is that they had a 2.5 hour sitdown interview with a VIP - no time to change drives. How would they have done that same interview on a Panasonic or Sony offering? My opinion is that they overlook opportunities for downloading because there is still space on the drive - but then get mad when it takes a while to download. Whereas, if they had taken those opportunities to download during the shoot, they would have not only saved their valuable data from being lost due to drive failure BUT ALSO spread out the amount of time it takes to move the data over the course of the shoot.

I really believe that if you dont figure in a data backup strategy into your shoot, and make it a priority, dont bother pushing the red button. As the data sizes increase (6k, 9k, Epic & the lot) this will become MUCH more important.

when i view the copy results, it would be great if i could resize that window with the log in it so that each line of the log fills up one line and goes across my screen.

Already fixed in the next release.
 
Windows

Windows

Hi Photocon,

Is the windows version still on for this month?

Thanks
Stricko
 
Honestly, its one of those things - we keep adding features to the Mac side, mostly from user input, and realize those features change the way things on the windows side would be done significantly enough to just do it now rather than do the effort twice.

The upshot is that the mac and windows versions will be very close from the start. The down side is that it will be next month.

Thanks.
 
that's cool, I need it for a shoot coming up in about 4months, so it will be ready for me, cool.
 
I have the trial version, on a Mac Book pro
when I select the RDM Source Folder on the Red Drive, It shows up in the queue, but, below under Red Media, Shot Info, and Project Info it says "Not Valid Red Media"
Am I doing something wrong? or is this a function of the trial version?
The RDM Folder is the only Folder I can add to the queue,No other Sub Folders(RDC)? is this correct?
BTW Great program! I just want to make sure I'm using it correctly
 
Conrad -

Do you think you can add the full set of DNxHD formats to the renders since REDline now offers that?

Thanks!

Michael
 
Do you think you can add the full set of DNxHD formats to the renders since REDline now offers that?

The code is already in the next release. We are finishing up some testing and should have it out after the holidays.
 
hey there,
we bought the software only 3 weeks ago and tested it one week. great tool!
no problems within one week of shooting unless one:

Several Clips i copied resulted in copy & checksum error!
i was searching for the failures in the protocol... NOTHING to find. tried a few times again with the sam clips. a few worked out well a few did not.
still no error to find in the protocol only the queue window and the signalthing told me some red errors...

i copied the clip manually at last...

that was the on set bug i figured out. we the same problem back in the office but i am not sure if it concerns the same clips... (clips we're playalbe and fine to work with in RC and redrushes)

Our system:
latest macbook pro 17" 2.5ghz, 4gb ram, ....
wd 2tb raid1
lexar firewire cf cardreader
another backup hdd
and finally in the office a san.

any ideas why this happened?

best regards
jahno
 
The code is already in the next release. We are finishing up some testing and should have it out after the holidays.

Excellent, thanks! Will it also export an ALE file in addition to currently supported file exports?

Michael
 
hey there,
we bought the software only 3 weeks ago and tested it one week. great tool!
no problems within one week of shooting unless one:

Several Clips i copied resulted in copy & checksum error!
i was searching for the failures in the protocol... NOTHING to find. tried a few times again with the sam clips. a few worked out well a few did not.
still no error to find in the protocol only the queue window and the signalthing told me some red errors...

i copied the clip manually at last...

that was the on set bug i figured out. we the same problem back in the office but i am not sure if it concerns the same clips... (clips we're playalbe and fine to work with in RC and redrushes)

Our system:
latest macbook pro 17" 2.5ghz, 4gb ram, ....
wd 2tb raid1
lexar firewire cf cardreader
another backup hdd
and finally in the office a san.

any ideas why this happened?

best regards
jahno

If you get errors on the same clips over and over, and the clips play back fine, it may be a read error on the files when the checksums were first generated. You can look in the md5sums.txt file and compare those to the md5sums-****.txt files and see the difference. If all the md5sums-***.txt files have the same sum for the same file, but its different in the md5sums.txt file, then it was a read error on the initial checksum generation. You can use the "create new checksums" button to solve that issue.

This goes to show that errors can happen at any time - 1st read, 2nd read, transfer, 1st write, etc... By reading multiple times you can be sure that the data is correct.
 
If you get errors on the same clips over and over, and the clips play back fine, it may be a read error on the files when the checksums were first generated. You can look in the md5sums.txt file and compare those to the md5sums-****.txt files and see the difference. If all the md5sums-***.txt files have the same sum for the same file, but its different in the md5sums.txt file, then it was a read error on the initial checksum generation. You can use the "create new checksums" button to solve that issue.

This goes to show that errors can happen at any time - 1st read, 2nd read, transfer, 1st write, etc... By reading multiple times you can be sure that the data is correct.

hey! thanks for your answer. i compared the errors in the last few weeks of shooting...
the copy protocoll said "reference checksum not available" or something similar.

here's what i did:
i copied the files from CF cards to a RAID1 external HDD. then back in the office i copied to our SAN. of course both times via the manager...
i was wondering why only about 40 to 50% of the reference checksums were missing. my first idea was that the reference is on the CF card... but must be impossible because not every reference was missing.

any ideas?
thanks
jahno
 
hey! thanks for your answer. i compared the errors in the last few weeks of shooting...
the copy protocoll said "reference checksum not available" or something similar.

here's what i did:
i copied the files from CF cards to a RAID1 external HDD. then back in the office i copied to our SAN. of course both times via the manager...
i was wondering why only about 40 to 50% of the reference checksums were missing. my first idea was that the reference is on the CF card... but must be impossible because not every reference was missing.

Theres something you are doing that is not standard. Mounting the CF cards as read only or the reader is having an error. I would try different CF reader hardware or make sure you are allowing everything to complete properly.
 
Theres something you are doing that is not standard. Mounting the CF cards as read only or the reader is having an error. I would try different CF reader hardware or make sure you are allowing everything to complete properly.

Okay... hmm. what is not standard in our process?
We're using the lexar fw800 cf reader. i think that should be the best to get hm?
so i should mount it in read only? or i should not? i don't even know how to mount them in read only.

i am not sure if i explained the problem proper...
there's is no problem when we copy from CF to HDD_1. the problems appear when the CFs are already sleeping in their little peli case. the problems appear when we do a back up from hdd_1 to hdd_2
 
Then the issue may be with your first hard drive. Please send us an email with the log of the transfer and a screenshot of the folder contents for a RDC folder that does not copy correctly.

There still is something you are not doing correct, which we need to figure out.
 
Back
Top