URGENT: Can the RED CINE file locking be removed, please?

[Axel Mertes]

Hi RED SWAT,

we are currently encountering problems of decoding footage quickly enough using RED CINE. As we shot in 16:9 mode (not knowing that it doesn't open in RED ALERT and QT CODEC by now) we are now forced to decode everything with RED CINE.

So we wait dreamingly for the bug fix for QT and RED ALERT.

It appears to us that in RED CINE all opened .r3d files get locked, ie. no other system is allowed to open / read the files.

As RED CINE is review & transcoding only tool it makes really NO SENSE AT ALL to have the files locked (except to prevent their deleteing while they are opened for reading).

So could you do us a big favor and remove that lock (or at least give us an option to lock or not lock the opened footage).

We have enough machines to spread the decoding process (which otherwise will take calculated 5 days alone on a single system...).

Please drop us a line so we can better decide on how to proceed from here.

Is is urgent.

Thanks listening,
Axel

[Axel Mertes]

I need to add that we currently decode on PC's.

Axel

[Wes Printz]

It may be a better to file a report with RED Technical Support...

http://www.red.com/support

You get a direct response from the technical team..

When you hit the “Send” button, an Incident Ticket will be generated and a RED technical support representative will be notified. The representative will contact you within 4 hours via email or phone to discuss the incident.

[Mark L. Pederson]

Hi RED SWAT,

we are currently encountering problems of decoding footage quickly enough using RED CINE. As we shot in 16:9 mode (not knowing that it doesn't open in RED ALERT and QT CODEC by now) we are now forced to decode everything with RED CINE.

So we wait dreamingly for the bug fix for QT and RED ALERT.

It appears to us that in RED CINE all opened .r3d files get locked, ie. no other system is allowed to open / read the files.

As RED CINE is review & transcoding only tool it makes really NO SENSE AT ALL to have the files locked (except to prevent their deleteing while they are opened for reading).

So could you do us a big favor and remove that lock (or at least give us an option to lock or not lock the opened footage).

We have enough machines to spread the decoding process (which otherwise will take calculated 5 days alone on a single system...).

Please drop us a line so we can better decide on how to proceed from here.

Is is urgent.

Thanks listening,
Axel

Hey Axel - can you be more specific? I don't know what you mean "locked" - we process 16x9 4K in REDCINE all the time without issue. I assume you understand there is no distributed rendering - so, you need to manually split up the media over multiple machines. Obviously faster with a SAN. Also, make sure your destination has a fast WRITE speed. If you can explain your problem a bit more clearly maybe I can help -

[Axel Mertes]

Hi Mark,

we have the footage on a SAN and we have about 50 machines connected to it. The SAN is fast enough to do a near realtime decode in terms of uncompressed bandwidth, but surely fast enough from computing side.

We can manually open only a single file at a time, but typically someone will put in a bunch of files. As soon as another machine has the same .r3d files already opened, the file is "locked" and no one else can open it.

What I am pointing to is that it just don't make any sense to lock the files, as they are opened ONLY FOR READING them, so the software has no need to lock the file access for any other app.

Imagine one is editing with the files, while someone else tries to do bulk decoding to e.g. uncompressed TIFF or DPX files for post processing. In such a situation, editing must be stopped for as long as the decoding will take. Thats a useless performance bottle neck.

If one needs to lock the files for security reasons, RED SWAT can surely modify the software to have a switch to do this (or not do this).

That is what I want them to understand and build into the next release.

Axel

[Emery Wells]

Hi Mark,

we have the footage on a SAN and we have about 50 machines connected to it. The SAN is fast enough to do a near realtime decode in terms of uncompressed bandwidth, but surely fast enough from computing side.

We can manually open only a single file at a time, but typically someone will put in a bunch of files. As soon as another machine has the same .r3d files already opened, the file is "locked" and no one else can open it.

What I am pointing to is that it just don't make any sense to lock the files, as they are opened ONLY FOR READING them, so the software has no need to lock the file access for any other app.

Imagine one is editing with the files, while someone else tries to do bulk decoding to e.g. uncompressed TIFF or DPX files for post processing. In such a situation, editing must be stopped for as long as the decoding will take. Thats a useless performance bottle neck.

If one needs to lock the files for security reasons, RED SWAT can surely modify the software to have a switch to do this (or not do this).

That is what I want them to understand and build into the next release.

Axel

Are you referring to being able to use the Quicktime wrappers for editing while transcoding in RC at the same time? If you shot in 16x9 then the wrappers dont work anyway.

As Mark pointed out, there is no distributed rendering so If you want to split things up then just split things up manually. Everything can still live on the SAN but each RC project should pull different files.

[Mark L. Pederson]

Hmmmmm .... so, what you are saying is that TWO seats can not open the same .r3d files at the same time on your SAN?

That is a bit curious - Tony, Lucas want to chime in here?

[John Cordell]

Why not segregate your files into several folders, and then load only one folder-full of files into each of your machines that you'll be using to transcode? That should avoid any locking problems. You'll just need one folder for each machine you'll be pressing into service.

[Mark L. Pederson]

Still ... there is no reason I can think of off the top of my head why two separate workstations on a SAN could not access the same .r3d file at the same time ... if in fact, that is what is happening here.

[Axel Mertes]

Still ... there is no reason I can think of off the top of my head why two separate workstations on a SAN could not access the same .r3d file at the same time ... if in fact, that is what is happening here.

I am sure it is the way it is right now, locking the files - so any other app isn't able to open the files.

I am working on some scripts to run it on the render farm in future, beasty conversion... If going for 2K output we'll be surely several times faster than realtime.

Anyhow, not everybody has this much CPU performance nor system setup, so I'd like that RED is correcting this issue. Should be a minor thing. I suspect its a inheritage maybe of some of the Shake source in there. For whatever reason, I really don't need it to lock the files. And the SAN by itself is out of question, we have file level sharing in action over here...


Thanks,
Axel