Can't render files over 2Gigs in size...

[Phil Bates]

I'm using AE CS5, trying to render Quicktime movies in PhotoJpeg and ProRes at both 4K and HD. The source is .R3D and .MOV. The platform is Mac and the problem is consistent across multiple machines. We get an unreadable file ("this is not a movie file") if it renders over 2 Gigs.

Any idea what's up?

Thanks,
Phil

 

[John Oczkowski]

This sometimes happens when trying to render over a network. Have you tried a local destination?

 

[Greg M]

What is the file system of the drives? are they locally attached?

 

[Jeremy Neish]

I've been begging for an update on this feature for a couple of years now. Nothing from RED can write files larger than 2GB to any network volume AFP, SMB, etc. The response from RED is that the API they are using doesn't support it. This is a leftover from the OS 9 days that should have been dead long long ago. They claim they've tried the newer API but it has other compatibility problems. The strange thing is, I can't find a single other modern app that has this limitation, even freeware apps have overcome this limitation long ago.

I really, really wish RED could get this fixed as soon as possible. It's incredibly inconvenient for us, as we have to do all of our Rocket encoding to a local drive then sort and copy everything back to their server volumes. We do a high volume of Rocket encodes from various source locations, and for every one we have to document where it all came from and then sort the encodes and copy back, this easily double's the technician time, not to mention the added I/O.

I know they are very aware of the problem, I just don't think it's been a very high priority fix. Since most folks are using local drives or SANs. However, times are changing, and AFP/SMB file servers are finally getting fast enough for most of what users need.

 

[Phil Bates]

A little more info, the drives are not Fat 32, they're HFS+. Also, we've tried both across the network and local, same results.

Thanks,
Phil

 

[JoshBertrand]

I've had this annoying problem too writing to a networked MaxxRaid server. Writing to a local drive has always worked though so I'm not sure where that leaves you Phil, but I'll echo Jeremey's request to Red to find a solution to this issue, as it does cause a lot of extra work.

 

[Phil Bates]

Hold on... now I'm really confused.

I've never had a problem rendering .R3D files over 2 GB with CS4, but that ability went away with CS5. It doesn't seem to be a problem with the RED files or am I missing something?

In this discussion on the Adobe Forum it talks about why you can't render over 2GB to a network drive:

http://forums.adobe.com/thread/680432?tstart=0

However, in our case the source is on the network drive and we are rendering to a local drive. Could that be the same issue (just in reverse), because a network is involved?

This is a huge problem for us. All of a sudden because of the necessity for workarounds, it is taking twice as long to process footage.

I would gladly switch back to CS4, but that program can't accept RED footage shot with the new MX upgrade.

It's sure frustrating when upgrading takes away functionality rather than give it!

Phil

 

[Brandon Kraemer]

The strange thing is, I can't find a single other modern app that has this limitation, even freeware apps have overcome this limitation long ago.

...and AFP/SMB file servers are finally getting fast enough for most of what users need.

I have seen this issue with using an SMB share with metaSAN software... you get a file i/o error when reading anything is over 2 GB. This is a known issue...

http://discussions.apple.com/message.jspa?messageID=7128529
http://arstechnica.com/civis/viewtopic.php?f=16&t=699306
http://www.readynas.com/forum/viewtopic.php?f=23&t=15361

...but I am not sure if this is the same root issue that is causing your pain.