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.
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.
We've been waiting for a fix from Apple. See this post for details:
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.
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?
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.
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
> 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.
I want to offer a possible fix for this problem. We have in the Past custom made work arounds for Mostly Apple but other company's issues.
We are not looking to charge for this. It is a free service. Based on Reading about this problem and how folks work around it I have good reason
to think we can make a work around. I can give a few examples of what we have done in the past to anyone that wants to know.
So I am looking for anyone that is having the Apple QuickTime bug. We need someone to work with on this but there is not very much that who ever works on this with us needs to do. We will give the exact instructions on what we need to try and make a fix. In Short we will need
to cause the problem then get a Core Dump and Stack Dump. We may need a little more than that depending on what we see in the Core dump but from this info we may be able to make a work around.
I wanted to talk to you in person but do not have your number.
ANYONE that wants to work with us we would like to fix this issue for all of you and for us.
I am not sure if it is within the rules to post my info and sorry if we are not supposed to do so but I can not fix it if I can not comunicate with whom ever wants to work with us on this. Again not too much to do for whome ever wants to work with us on this. And yes it could help our company if this problem is fixed.
Call me anyone that is interesed,
Jim Tel 916-996-0956 e-mail email@example.com
We are located in the LA Area.
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.
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.
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
Since Adobe does not feel they want to work with us would anyone else
like to do so?
Jim Faraday firstname.lastname@example.org Direct cell 916-996-0956
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
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.
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.
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 email@example.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
Apple has known of this problem since 09. Mid 09.
So has Adobe. Apple even has the problem listed in the bug report
database since 09. They call the database of Bugs "It's on our Radar".
And that is where it stayed. We have made fixes around Apple many times.
Apple and Adobe seem to be having some kind of issues. Not sure why.
I have some ideas but for the most part I think with Apple it is about
I-Pods etc.. Apple left Adobe Flash out of the new I-Pad. It really
sucks. So many sites use flash.
So if you have an I-PAD and folks that have been loyal to Apple for
years have asked Apple to support Flash. But Apple did not listen.
They are now the largest company in the world thus i guess they feel
they do not have to listen to anyone. Maybe that is the deal with Apple
ignoring such a large amount of customers. Who knows. All anyone can do
is speculate. Calling Apple is a waste of time for this issue.
for your problem. It has been tracked down to an issue with the
programing API Apple uses and so do developers such as HELIOS and Adobe.
So it is not exactly Adobe's fault. However I would have made a work
around long ago. We have done so in several of these Apple situations.
And there are several of them. ILM uses a very good work around. Also I
have heard that Adobe 6 no longer has the problem as they bypass the
Apple API. But I have not had confirmation on that.
I just know that we started to make a work around and discovered
there were several that are very sloppy work around such as using Dave
and there are very good work around s such as mentioned that ILM uses
one that is very good.
I would tell you but you stated to me 2.5 years ago. Apple is a company
that moves forward and does not look back.
Anyway we help out and get our customers fixed up so they do not have to
deal with the problem. We did so within Days of finding out about it. We
even suggested a way for Adobe to fix it. Not sure if they used our fix
or not but it looks as if they had a different route if it is fixed in
the latest version of Adobe.
I got responses over time. Always the same. We are working on it with
Apple. It has only been three years. Do you expect something faster from
Apple and or Adobe. I talked to some of the engineers about 2 years ago.
Very Arrogant. And did nothing but tell me how cool they were. They were
quite pleased with themselves.
We are working on it still. In fact, the issue is fixed in the recent Adobe Media Encoder and Premiere Pro CS6 (6.0.2) updates. We are still working on the After Effects piece, which has more complexity.
The speculations above about the relationship with Apple and Adobe miss the point. In fact, Apple has been cooperative in helping us to understand the issue. They tried to make a fix on their side, but it was too destabilizing in other areas. So, we needed to make some big changes on our side. We actually work rather well together.
This is fixed in the next version of After Effects. I listed it in the significant bug fixes here:
We're sorry that this took so long. The After Effects feature set regarding QuickTime is deeper than that for Premiere Pro and Adobe Media Encoder, so the fix that we used for those two didn't work for After Effects.
Thanks for the message but is it not the same message from about 10
I do not want to be rude but am I missing something here???
I never did blaime Adobe for the problem. It is clearly an Apple Problem
and SIRI is more important than the loyal customer base is what a lot of
folks are saying as they switch from Apple to Windows and quite a few to
Linux. There is some good ( Not as good as Adobe) tools for that OS that
do a good job.
Tell me what I am missing here Todd. I realy want to know and do care.
THANK YOU. Yes, it's been a long time but better late than never - this has been a huge PITA for quite some time now. Now - if we could only get some proper multicore based rendering without having to load the same scene up 16 times to make full use of my computer's cores (I don't care if it's tile based or frame based - but every 3D app on the market is about 1000% more effficient than AfterFX on this front). : )
Thank you TODD! Those of us who have been in this thread since the beginning are grateful for the work/communication you've shared the entire way. The news wasn't always good, but you shared it nonetheless. Software is always going to have bugs. But every day there are giant companies NOT giving a $@%& about it for their customers. You have proven different. So I wanted to say Thanks for that. I do have one question. You said "next version". Does this mean that it will be packaged in an update to existing CS6 or waiting until CS7?
Thanks again for everything.
> Does this mean that it will be packaged in an update to existing CS6 or waiting until CS7?
This refers to the next version, not an update to CS6. More details on exact release dates soon. You can subscribe to our blog to be kept up to date: