Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
if you are on windows, have you tried mapping the network drive to a drive letter and then rendering to that drive letter?
Copy link to clipboard
Copied
I'm on MacOSX 10.6.4 rendering to Xserve OSX10.6.4. All drives have correct permissions and are formatted the same HFS+.
Copy link to clipboard
Copied
You are probably connected to the server via SMB instead of AFP, if the server is also a Mac. If it is, in the Finder, hit Command-K, type afp://<server address or dns name>. If you are connecting to a Windows Server or NAS, it may be using older versions of SAMBA or an old version Windows Server.
Copy link to clipboard
Copied
We are definitely connecting via afp. The server shows me which machines are connected via which protocol. You actually have to go out of your way
to connect via smb when both your host and clients are macs. Again, this only started happening with CS5. This problem was not present in CS3 or CS4.
Copy link to clipboard
Copied
This is probably not the case since it renders locally fine, but, in the "output" section of the prefs (or at least, it's in that section in CS4), are you segmenting movie file sizes after a certain limit has been reached? If you render to an image sequence instead, does the same problem occur at the same accumulative file size?
Copy link to clipboard
Copied
I don't segment files and yes, it does render images sequences fine. The problem is only with a QT movie.
Copy link to clipboard
Copied
I asked the engineers to take a look at this thread, and they said that it's a limitation in the new QuickTime Compression Session API that Apple asked us to use. You can work around the problem by using a non-QuickTime format or sending the file to a local disk.
If that isn't workable, please file a feature request.
Copy link to clipboard
Copied
Todd, can you have the engineers define local disk? Will we have issues with SAN disks under XSAN, MetaSAN or SANmp or is this limited to just afp or all network protocols?
Copy link to clipboard
Copied
Thanks for the info. At least I can stop trying to fix it now.
I do however hope it is something that will be addressed in a much needed update for numerous CS5 bugs.
thanks again.
Copy link to clipboard
Copied
Hi Todd:
I can understand that's it's difficult to work with Apple if they're giving you bad information, but didn't you guys bother to test this software across a network at all? It's not like generating quicktime movies > 2.15 GB on a network drive is an obscure workflow. And suggesting we submit a "feature request" to restore a major feature lost in this "upgrade" is a bit cheeky.
Sorry to whinge, but seriously - shifting everything to image sequences is a major workflow nightmare, and rendering locally in a collaborative environment is a version-control nightmare. Please sort something out with Apple to get AFX CS5 working properly with Quicktime asap. Until then it's really just a beta release.
I sure wouldn't have suggested purchasing it if I'd known about this first. And I definitely won't suggest anyone else gets it until this is fixed.
Copy link to clipboard
Copied
I would like to second this.
Blaming this on Apple is not solving the issue. This is very standard workflow and we rely on sharing renders over AFP and SAN. It worked in CS3 and CS4.
It's not a feature request, it's a bug.
Copy link to clipboard
Copied
Blaming this on Apple is not solving the issue. This is very standard workflow and we rely on sharing renders over AFP and SAN. It worked in CS3 and CS4.
It's not a feature request, it's a bug.
There was no blame; only explanation.
The same form for feature requests can be used for bug reports. Call it whatever you wish, but you can register your need for this change using the link that I provided.
Copy link to clipboard
Copied
Thanks for clarifying that bug reports and feature requests are available on the same link. "Blaming" was a poor choice of words on my part... but it's not like most of us know what "QuickTime Compression Session API" is... we just know our workflow is broken, hopefully temporarily. That is the end user perspective I guess. Glad to know the engineers are aware of this. I did follow up and submit a bug report on this issue.
thanks
Copy link to clipboard
Copied
We are having exactly the same problem here! It ruins our whole Workflow...
Copy link to clipboard
Copied
I downloaded the 10.0.1 update this morning with great hope that it would address this problem, but After Effects CS5 is still incapable of creating QT files >2.15 GB on network drives. WHY WOULD YOU BOTHER TO RELEASE AN UPDATE THAT DIDN'T FIX A HUGE BUG THAT MAKES YOUR SOFTWARE SO DIFFICULT TO USE IN A COLLABORATIVE ENVIRONMENT?!? It's like releasing a version of Photoshop that doesn't work with TIF's > 5MB and acting like it's ok and up to the end users to change all their workflows.
I'm writing to our supplier this morning to let them know about this problem with After Effects, and the cavalier reaction by the Adobe staff on these forums. I'm suggesting they advise any other enterprise clients of the problem before selling more licenses, as at this point I feel our serious expenditure in upgrading licenses and plugins was a colossal waste of money.
Our artists are reporting that when AFXCS5 works correctly, it is much faster - but that it is also much more fragile and temperamental now. This might seem like a reasonable trade-off to the Adobe Marketing team, but it puts the utility of your software as a real production tool in jeopardy. All will be forgiven if you fix this ASAP in 10.0.2, but if this drags on much longer we'll be forced to re-think the core position of After Effects in our production pipeline.
Adobe, please don't turn into Quark.
Copy link to clipboard
Copied
Here's a message from the engineering manager responsible for this area:
"To support the new compression APIs that give us access to the two-pass encoding and good stuff in H.264 encoders etc., we need to use the Apple API AddMediaSample2. It is critical for frame reordering to work and gives us access to 64-bit time samples, which means we can export longer movies.
HOWEVER, AddMediaSample2 has a bug that AddMediaSample1 doesn't. That is when you hit 2.15 gigs on an AFP volume, the function returns -1309 (fileBoundsErr) and we are stuck and can't do anything else.
We are not the only people reporting this. As posted on the Apple QT list:
http://lists.apple.com/archives/quicktime-api/2006/Aug/msg00235.html
We are tracking this bug with Apple."
Copy link to clipboard
Copied
Thanks for that update ... Sorry to be so shrill with my complaints, but it is a pretty big issue for us (and others I'd assume). It helps to know that you're onto it and trying to sort something out with the Cupertino crowd.
Copy link to clipboard
Copied
Some of the video files I work with are for large res video walls and thereby terabytes in size. We always work uncompressed until we have to compress. We do have a RAID setup on the main machine, however, I'm not sure THAT'S enough room for some of these files "Locally".(Not to mention the time it takes to copy them back over to the network afterwards so they can be backed up.)
I hope this doesn't spin off into another wrestling match between Apple and Adobe. The two (QT and AE) have worked hand in hand for most of us for so long.
Consider this not a complaint, but a plea... please remedy this ASAP. I've got another HUGE project coming LOL. I'm sure that would make us all very happy people.
Copy link to clipboard
Copied
Vision3Jason,
We're working on it.
In the meantime, I'll suggest again that looking at a workflow that doesn't involve directly rendering and exporting to a self-contained .mov file has advantages beyond just working around this issue: Rendering and exporting to image sequences and then assembling those in QuickTime Pro (or whatever else) after the fact can be a lot easier to deal with in some cases, especially when dealing with network rendering.
Copy link to clipboard
Copied
Hello Todd,
I just need to join to this discussion because of its importance.
Like others here we are working with very large files over the Network which need to be, and to stay, -quicktimes.
This because all the files carry sound.
If we had known this issue before would have never made this upgrade.
I just want to encourage to give top priority to this topic.
Thank you very much for your understanding.
Copy link to clipboard
Copied
Another caveat to image sequences is they don't always play so well in a SAN environment. Bring on the QT fix, the sooner the better.
Copy link to clipboard
Copied
I don't have a lot of new information on this, but I wanted to at least update this thread to tell you that we're still on this, and we're talking with Apple about what can be done.
If anyone has any questions about workarounds in the meantime, we're here to help.
Copy link to clipboard
Copied
Thank you very much for your effort and keeping us informed.
In the meantime here is another funny one:
Due to this situation we decided to render out in a Tiff sequence -and then to convert this back to a animation quicktime.
We encountered a problem with a certain tiff-seqence where we are unable to create a animation quicktime from it.
We can make uncompressed quicktime or compressed formats from it,-but nothing
with animation codec.
we would like to give you a link to this special file.
Thank you very much,
Copy link to clipboard
Copied
> we would like to give you a link to this special file.
Please attach the problematic file to a detailed bug report and send it to aebugs -at- adobe -dot- com. Thanks.