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?

[Todd_Kopriva]

Jim,

Thanks for the offer, but we're making good progress here on fixing this on our side. We realized that we were never going to get a fix on the Apple side for this, so we're working on what we can do on our end.

Of course, I can't make any promises about when or whether any specific fixes may be available.

[colorkite]

Thanks for the update Todd - but I hope there is a lesson here for Adobe.

It's "probably" not good practice in product development to rely on other companies to fix features in your own product - even if it is thier tech. Sad to see that individuals are working to fix this becuase Adobe is 2 years late. Not to mention Adobe releases and sells 2 versions of a product that costs a premium while they wait on Apple to supply a fix. Quite underwhelming. Sad to say but - it's monopoly at it's finest.

[Guest]

Strange to me. I see it different. I do not see it as an Adobe Problem.

From everything I can see including what folks have done for a work

around it appears to be a networking issue or at least something in the

API that is affecting the network. Now at what level I do not know yet.

IT could even be deep in the Stack or at the higher level of the file or

files themselves. It could be just about anything. But I see it as an

Apple Problem that Affects Adobe. I do not see it as an adobe Problem.

When you develop for a OS you are Generally given an API and it is

usually the Same API used by the company or ORG that made the OS. And if

that has a bug there is not much Adobe can do but try and work it out

with Apple in this case. We have had Similar problems. But do to the

nature of our customer Base we have to assume that it may take some time

for the Factory to Fix the API. Thus we make a work around that is

rather invisible to the users. Instead of giving you an example of an

Apple Fix I will give you an example of a fix we made for one of the

More Popular DSP Chips that were used for Analog Modem and Faxes. After

the core dump we could see were the problem was. This was back in the

early 90s. I use this example as it helps one understand one of the ways

we fix problems. In those days we did not have Electrically programable

RAM. Also it was common Much like a Current CPU to have the code that

makes the chip work built into the Masking. So the Code or Program us

Part if the Die so to speak. But when you turned on the

Fax/Modem the code loads into RAM. What we usually do After we find the

problem and since we can NOT alter the Hard Coded into the Masking of

the DSP Chip We go to the Addresses in RAM were the Faulty code gets

loaded. That is where we make the fix. Thus when the system is turned on

The Faulty code loads but before the system is done booting we Make the

Changes in in the code that is loaded to the RAM using the Controller

Chip. Thus to the user they never know there was ever a problem. And as

the code is fixed eventually at the factory even if they leave our fix

in the system it will not hurt anything. A good analogy would be if

faulty code is loaded in RAM from the program we just add a Small small

Script that changes the values of the RAM or over right the RAM with the

fix.

Since Adobe does not feel they want to work with us would anyone else

like to do so?

Jim Faraday jim@packetcolor.com Direct cell 916-996-0956

[Guest]

I gave it some more thought.

I at this point do not really Care WHO is at Fault. One Thing I do know

for sure. We Answer the phones 24 x 7 x 365 because Our customers work

those kinds of hours. We feel it is irresponsible to sell into a Market

that works Long hours and then not Make ourselves available in Case

there is a problem. Even if the problem has nothing to do with our

solutions.

Personally I would never leave a customer in this condition or situation

for any amount of time. The More I read the more disgusted I am with

Apple and others that just talk and We have no indication for sure what

is going on. We would tell our customers the truth. IF we were ever to

run into a situation we could not fix and that has not happened since

1983 when we started this company. I am just Fed up with Companys that

decide not to deal with a problem because "It is too Hard " or it is not

our policy or what ever the deal is" The Lame promises are just words of

"We are working on it". For 3 Years now? Get Real.

I WILL Take Care of My customers. Always have and always will. And I

expect the same from whom ever I purchase from. Since I was made aware

of this issue Late Last week I have looked into it and decided to fix it

ourselves. With or without your help. Apple Should be ashamed of itself

and now I feel that other companys should as well. WE are not perfect

but we would never do this or allow this to go on for this long or any

longer that it takes to fix it and we would if it was our code have

fixed it. Sure there are lots of Bugs in a company of Apple And Adobe's

size. But you also have resources. It is not always ONLY about $. IT

should also be about helping a loyal customer because it is the right

thing to do.

Jim Davison

[sweety_1136]

Dear fellow sufferers!

One possible solution is using DAVE V 9.0! Somebody had posted this option already! I've now tested it and rendering to an CIFS share works also with >2GB!!! At least with the free trial version it worked well. But beware: this version no longer works with OS X 10.8! A corresponding new version (V 10) is only in beta. 

We have also tested with NFS. Here, unfortunately, a special mount option is required ("-o sync") which reduces the network performance extremly. Without this option After Effects crashes (+ Finder) complete shortly after starting to render.

Regards Michael

[Guest]

Hi

Using Thursby Dave did work for some. However it will effect speed. OSX

can work with SMB as Apple made it for compatibility but AFP is the way

OSX was intended to work. But even using SMB does not fix the issue, AFP

is Faster as it has larger Block sizes and it saves all Data in the

Resource fork as well as the Data fork.

NFS is so slow. It is a great tool and there are lots of uses for it.

But connecting to a Work Station that would put loads on both the Server

and the network to the extent that is found in the Publishing

and E.I..Fiber Channel is sometimes a way to go but it also has

Limitations. The Best way is 10 Gbps Ethernet with AFP. Apple uses AFP

as do at least one other solution besides us.

Anyway I would be happy to Give a server to anyone that wants to help us

with this issue. We are asking only for someone to cause the problem to

happen then we will get the Core Dump. Then after we make a fix you or

who ever can test it. No cost in $ and we are talking a very small

amount of time.

Let me know if you know of anyone.

Jim jim@packetcolor.com Cel 916-996-0956 or 310-770-0099

I am located in Beverly Hills so we are close to a lot of folks that

have this problem and have had to even resort to using PCs.

Hardly anyone that is any kind of Graphics Arts like to use PCs. They

learned on and like Apple for many reasons.

We have a location in Sacramento and one in Reno. So anyone anywhere

within a few hundred Miles of the CA Locations we will be happy to work

with.

Thank you.

[Brandon Kraemer]

Wondering if anyone on this thread has tried using webDAV as a workaround, since NFS seems to have a naming bug?

[Andrew Yoole]

I've created a new discussion in Apple's Support Forums about this issue.  Any existing discussions I found were archived, hence the new one.

I strongly suggest you post your own thoughts to the thread if you wish to get Apple to address the issue. 

https://discussions.apple.com/thread/3042027

[theoutfitvfx]

Hi Todd,

Your post says that SMB works.  Can you confirm this?  I have found that both SMB and AFP Experience this issue.  Only NFS works for me

[Todd_Kopriva]

> Your post says that SMB works.  Can you confirm this?  I have found that both SMB and AFP Experience this issue.

According to the engineering manager, SMB is the workaround that Apple recommended. But, if it's not working for you, we need to know that. Can you try again and confirm?

I'll get someone to look at this post and confirm from our side that SMB works.

[theoutfitvfx]

I have done a whole lot of testing on this issue. I have this problem

across both Shake and Nuke in our facility. Both AFP and SMB have

this problem. Did you test SMB and confirm that it works? The only

protocol that works for me is NFS. I have tried this both on our

XServe Server and Isilon Cluster. Mounting either Server over SMB I

can not render a quicktime over the 2.15GB Limit with either After

Effects CS5, Shake, or Nuke.

[Guest]

Apparently, Apple has a real good handle on this and they are running as

fast as they can to fix this... NOT!

[colorkite]

Digital Desktop wrote:

Apparently, Apple has a real good handle on this and they are running as

fast as they can to fix this...  NOT!

This is all still quite an abomination for Apple. I can hardly imagine the issues they'll have when they release FCPX with this new api and people wont be able to render movies with it...oh dear.

EDIT: Oh, but when it affects thier own product I imagine they might move "a little" faster to fix it.

Suppose we can look forward to a fix shortly after FCP X is released.

[Todd_Kopriva]

Thanks, theoutfitvfx. SMB was the recommended solution, and I didn't test it myself. I just modified my post based on your feedback.

[theoutfitvfx]

Thank You. I would love to know if anyone has had success with SMB.

Jason

[Lang_Walker]

Just a note to everyone who is being driven crazy by this bug ... it's been suggested that the best way to get Apple to pay attention to this problem is to post complaints on their discussion threads instead of just bugging Todd & the Adobe team about this. A thread has been opened here:

https://discussions.apple.com/thread/3042027

If everyone could please take a few minutes to register their frustration with this flawed Quicktime API with Apple, maybe we all stand a better chance of eventually seeing this fixed.

thanks,

Lang

[Brandon Kraemer]

We were discussing this ongoing and painfull issue again today at work and wondering if Lion offered up any solutions to this issue.  Can Adobe or anyone comment with tested knowledge about this?

Also, I formally submitted a bug report via the Apple developers site and got confirmation that this was a known bug and that Apple was working on it.  They also confirmed that the bug exists with SMB and AFP, neither protocol works with files of 2.15 GB.

I can only speculate that the 'fix' involves Adobe moving to AV Foundation and away from QT API.  Can we get an update from Adobe about the status of the progress on this bug and if Apple and Adobe are still jointly pursuing the issue?

Thanks in advance,

bk

[Todd_Kopriva]

I know that Apple was investigating a fix in Lion, but I don't think that the fix got into the current version of Lion. I've asked one of our quality engineers to verify that, though.

[Byron Nash]

I think this issue underscores the need for a platform agnostic movie  format. Quicktime has been troublesome for years. Many people have the  need for video files though so still frames aren’t the only option. I hope  that someone will develop something on par with OpenEXR for video.

[Guest]

Im for REDCODE but not sure (technically) how that matches with OpenEXR.

[Brandon Kraemer]

REDCODE is a pretty amazing format, but it's far from "agnostic", ARRI and Panasonic (or Pannavision) are hardly likely to adopt it.  Also it's read only, only the RED cameras can write it.  Something platform and program independant like it that is it's own file format and not just a codec would be welcome, but there will never be a single standard.

Todd: Did the Adobe engineers ever confirm Lion and CS 5.5 do/do not resolve any of our pain?

Thank you.

[Navarro_Parker]

Good luck, Chuck.

OpenEXR wouldn't have gained traction if it didn't offer benefits head and shoulders above other existing formats. So Quicktime's replacement would have to do everything Quicktime can do, but better. Quicktime is more than just a container. Despite its limitations, it's pretty remarkable. It's a whole frameworks for gluing together all types of media.

I mean, the NLE industry's support of open source MKV or OGG are pretty much nonexistant — and those are just container formats. I can't imagine a new cross platform AV framework getting any sort of application support.

There's only a handful of companies that could get market attention: Microsoft, Adobe, Sony, Grass Valley, Avid, Quantel, NewTek... But then ask yourself *why* would they?

In this economic climate, what's in it for them to dump the R&D money into such a project? For something that might work a little better than what works now? OpenEXR was developed because ILM needed it. I would only expect another Quicktime to be developed from the same internal motivations.

[Todd_Kopriva]

The fix did not appear to get into the current version of Lion.

[Andrew Yoole]

I can confirm that the bug still exists in Lion.  No fix.

[sweety_1136]

Hi Todd!

Are there any new Informations for the "2GB QT Limit" via Networkshare case????