New in CS5, why can't I render a file larger than 2.15 GB to a network drive?

[Guest]

This started just as soon as I installed AE CS5. If I try to render to a shared network drive, once the file reaches 2.15 GB in size, either AE render crashes or the render completes but the file size is 2.15GB and it will not open or import back into AE. Rendering to a local drive works.

Why is this happening?

[JonChappell]

There's a bug in QT 7.7 causing all sorts of issues including crashes and being unable to open movie files. These issues are also affecting people who installed the latest Snow Leopard security updates and OS X 10.7.2 so it would appear that Apple is still updating QuickTime on newer operating systems but for some reason not bumping the version number.

[DLpres2]

I looked into enabling NFS on our systems (like theoutfitvfx), quite possible but not worth the hassle. The render-to-local-drive-and-copy workaround is fairly simple. Stupid but simple...

[colorkite]

"Stupid but simple..."

Key word being stupid.

[Greg Leuenberger]

It's pretty shocking that this is still being delt with....but I guess with FCP X working out of the local 'movies' directly they probably don't even know the problem exits.....lol..

-G

[colorkite]

Really true.. haha. But at least compressor 4 likes network volumes - and that's really a big clue for the compressor team to bug the quicktime folks about. But I feel like more and more there really are no quicktime folks these days. They are too busy optimizing codecs for iPads and iPhones perhaps.

[colorkite]

I've basically been queing an image sequence and an Audio export from AE as a workaround so I can have both my scratch audio and my image sequence on the AFP.

Who wants to render local and then transfer when you have overnight renders that you want ready for colleagues in the morning?

Sh*t workflow is sh*t.

[Rook888]

And now with CS6 we still have the same problem...

It is unbelievable that this issue is not solved since 07.2010!!!

[ianim8]

Yep this have been going on for years now.

Most have moved on.

I know that ProRes works over AFP and SAMBA over 2GB.

[Greg Leuenberger]

It does?  I don't think so - I always render in ProRes 4444 and I can't do +2GB files from my  Mac Pro to my Xserve file server over AFP.  I thought this was a 'Apple - Quicktime' problem and not an Adobe problem.

-G

[Todd_Kopriva]

We've been waiting for a fix from Apple. See this post for details:

http://blogs.adobe.com/toddkopriva/2011/05/cant-create-quicktime-movie-larger-than-2-15gb-across-net...

Since we haven't gottent the fix from Apple, we are for now recommending that people use NFS instead of AFP or use one of the workarounds described in the above article. We are also looking into how we can use a different set of QuickTime functions to get around this QuickTime bug.

[fwstudio]

Could you guys not have implemented one of the workarounds behind the scenes in the renderer, so my designers don't have to deal with it all the time? Surely you know having a facility erase and reformat it's entire server RAID over to NFS isn't a feasible solution.

At least once or twice a month, I have a designer forget, render out a bad file, and then have to rerender an image sequence, and reinsert any audio after the fact. Usually when a deadline is right around the corner.

Serious question, don't mean to sound snarky, really, but how hard would it be to build in something to the software that when it sees that something is going to be rendered that might even come close to invoking this bug, to have it render an image sequence and then compile and convert it to QT in the background when it's done, all while showing to the user that it's a QT render as usual?

I can imagine it would take longer to do the two steps behind the scenes, but at least it would work, and you'd have a ton of professionals singing your praises for finding a way to work with it. As it stands, the company line of "we're waiting for Apple to fix it," just sounds lazy. We all hate Apple for creating/not fixing this bug for so long, so why not engender some good will with your users instead of just sitting it out?

[Todd_Kopriva]

We honestly thought that the fix was coming in some recent Apple releases. Not lazy. Just mistaken. At this point, we realize that that is not likely... hence the last sentence of my previous post.

[fwstudio]

I know you guys aren't being lazy about it... it's just the appearance of it that gets frustrating for us. Thanks for your reply. I'm sure having to reply to the same people for the same issue for years now but be awful frustrating for you.

[DLpres2]

> Surely you know having a facility erase and reformat it's entire server RAID over to NFS isn't a feasible solution.

fwstudio, NFS (despite its name) is a network protocol, not a block-level file system. There's no need to reformat your drive, you just enable it on your server, like SMB etc.

Still, the newly-found bugs in NFS make this situation all the more delighting.

1. Has anyone tested >2GB files over AFP in Lion or Mountain Lion? Is this the same as Snow Leopard?

2. Another avenue to explore... a 3rd-party network protocol that's better implemented than what's built in into OSX. For example, Thursby's DAVE is an enterprise-grade SMB/CIFS Mac protocol. It has a fully functional 2-week trial, could be worth trying.

[MMCT-Matt]

Everyone should also be aware that since 10.6.4, into Lion and seemingly into Mountain Lion, there is an additional bug with OS X where files with long filenames (>=32 characters) saved to an NFS export will not show up for a random (but usually substantial) number of additional OS X machines mounting that same NFS export. The reason for the error is that OS X's file system manager (which is downstream of Adobe) saves the long file name with a truncation (using only 31 characters). Then, after the write is complete, it requests the filename be changed to the original. Most NFS servers comply. A check at the POSIX level (in the Terminal) will reflect the change, but at the OS X Application level (Finder, Adobe and above) many clients will still see the old file name.  So, if you have automations (or other creatives) expecting a certain filename, it won't be there. For those who have access to Apple's dev site, there are two open tickets since the middle of last year on this issue.

[Lang_Walker]

Hey MMCT-Matt - that's incredibly interesting and relevant news. Is this NFS bug in Apple's Server-OS implementation of NFS, or the client OS view of the NFS file system?

We're planning to migrate away from our old AFP/SMB X-serve-mounted SAN storage to Hitachi's super-SAN  setup using NFS as the core protocol (and we wanted to just leave the client connections through NFS largely because of this persistent and apparently unsolvable AFX/QT incompatibility). We mostly work in frame sequences anyway, but need to write out large quicktime files often enough to make it worth the while coming up with a permanent workaround to solve this problem that our old uncooperative overlords don't seem interested in ever actually fixing. However, if this is going to open up a large-names-freak-out-on-some-clients-and-break-scripts-nightmare then the cure is worse than the disease.

Anymore information on this NFS bug would be much appreciated (if its Apple server based only we're ok as we're abandoing that slowly sinking ship before Apple abandons us anyway).

thanks so much, Lang