Thanks for the response. I hope you can understand why there would be such incredulous frustration at the amount of time it's taking to fix an essential pipeline aspect of this software. I posted something on an Apple QT thread ages ago and never heard anything back at all, so its good to at least get an update.
> I was at NAB and had a few goals in mind.
One was to talk to someone from Adobe about this.
Next time, ask for me by name. I was there every afternoon waiting to answer just such questions. In fact, one other person did ask about it then.
Thanks Todd lets hope I wont have to ask this next NAB
Todd, you at least have to undestand where we're all coming from here. It's obvious this is an Apple QT API issue. No-one is debating you on that. It's also obvious, though, that Adobe used this brand new API without enough testing and charged people a **** load of money for the software that had a glaring workflow bug.
What really peeves me is that the thread was first responded to with a "submit a feature request" and that's just pure lazy - and downright insulting. After the initial responses here from Adobe it's difficult to have patience in this situation.
I would personally be embarrassed to sell a professional grade software suite without testing something as common as this. I hope it get's fixed "soon" as I (and assume many many others) have had to modify our workflows / buy extra gear to work around this "feature" or lack there-of.
>>> I was at NAB and had a few goals in mind.
>> One was to talk to someone from Adobe about this.
Next time, ask for me by name. I was there every afternoon waiting to answer
just such questions. In fact, one other person did ask about it then.
That person would be me. Here is some advice. Apple's ability (or inability)
to prioritize is very broken. In my 26 years of experience dealing with
Apple, especially during the Steve Jobs years, the best way to get a bug
fixed is by public embarrassment. Once Apple is embarrassed, then and only
then will a lingering issue get put to the top of the pile.
Thus, my specific suggestion would include having everyone here do all of
post this issue on Apple's discussion board under the QuickTime section.
Everyone should post to the same issue to make it get traction.
submit this issue to macfixit.com
submit this issue to macintouch.com
pick a writer at cnet, let's say
In your submissions, make it clear that this is a QuickTime bug and Apple
has known about it since at least September 2009 and is not running to fix
it. Apparently, they are too busy answering government privacy inquiries.
And look how quick that got fixed.
Todd, on your end, you still have dirt on your hands. Here is what Adobe can
and should do...
Where is the darn tech note so that other people don't have to chase their
tail or waste time combing through the forums?
Why isn't this issue listed in the release notes or in this document?
Let's assume Apple is not going to fix this since QuickTime is essentially
deprecated. In Lion, is there a new API under AV Foundation that fills the
void? If not, the AE team might want to create a way to buffer the file to a
local drive and then copy it to the network path. Relying on Apple to fix
this bug in a timely manner isn't working out.
+9000 points to Digital Desktop for extremely logical points. Specially the public tech note by adobe so more people aren't pulling thier hair out wondering why thier files are corrupt every time the render says "complete"
Good points, Digital Desktop (Jeff?).
I'll get such a document created. You're right that that would make it easier for people to find the information. I'll confess that my thought has been along the lines of "Oh, this is going to be fixed really soon, so it's not a high-priority tech note", and clearly I've been wrong about that.
It's a busy day today, so I'll get something up by EOD Monday. Deal?
Well I'm one of those people who's been pulling my hair out and I JUST found this thread. I'm happy to have found the cause but CANNOT believe that this bug has existed for over half a year with no end in sight. How could this not have been seen in Beta testing? Creating quicktimes over 2.15 GB's that get saved to an OS X network drive must happen thousands of times a day with all the companies out there using After FX in a OS X collaborative environment. At least there's a work-around but man... what a disappointment.
I've pretty much had it with Apple too... serious WTF with them. Second biggest company in the world and their Pro users are treated like crap. Sure cancel the Xserve.. then make the ones we still have useless with your stupid Quicktime bugs... why not just be honest with us and drop your Pro machines, software and support completely so we can all just move on. This half-assed effort on their part sucks. My next machine will be a PC (with a graphics card that isn't 3 years old!)
I feel really sorry for you, Greg. I was in your exact same postion a few months ago on a HUGE deadline for Levi's and I worried myself sick all night trying to figure out why I couldn't render a lossless file
Thanks for recognizing this as worthy of a technote (or "feature request" or "hey this thing doesnt work right" or whatever). In my opinion, taking the high-road on these things from the beginning will help reduce the angry mob that tends to build when situations like this aren't taken very seriously during initial discovery.
I saddens me that there are people out there, like Greg, who are likley on deadlines wondering why they can't deliver. There are probably thousands of these people out there - and liekly have no idea that there is a real problem here.
I'll pour one out to all those who have yet to find this thread...
And when you do find it - just...go render your project to local disk. Todd has heard enough complaining here.
> In my opinion, taking the high-road on these things from the beginning
will help reduce the angry mob that tends to build when situations like
this aren't taken very seriously during initial discovery.
Sorry if it wasn't clear from the beginning that we were taking this seriously. When I ask people to submit a feature request or a bug report, it isn't a brush-off. That's actually the best way to officially register your wishes and feedback. That's the point of this post.
The feature requests all get read by the guy across the hall from me, and I am the one who reads all of the bug reports. When we get one of these, it's very common for us to walk next door (to the engineering manger's office) and make sure that he understands how many of a certain report we're seeing.
In this specific case, the bug reports and feature requests that we got around this issue are what we were able to use in our conversation with Apple to show how large a problem this bug is. They don't want to know about how many forum posts we're seeing; they want to know how many bug reports we're getting.
Sorry for the rambling answer, but I just wanted to give some idea that we take bug reports and feature requests very seriously, and a response on this forum pointing you toward submitting these is in fact a sign that we care---not the opposite.
Haha Im not sure if Adobe actually takes down my crash reports
During the CS4 debacle (early days), I had an average of 20 crashes per day.
Each crash was met with the "report to Adobe" window.
I put email in there and sent out each time.
After a few months of this, I started sending nasty emails to see if I would at least get a message from Adobe whether its legal or not
Nope no one got back to me.
Eventually CS4 got better and things were fine again.
But that took almost a year
Now with CS5 a whole new crop of messes to deal with.
Anyhoo the only fix I see is converting is to not use Apples AFP file system.
Im good here since most of my files are rendered straight to MainConcepts MPEG Encoder.
For Uncompressed, render to frames then use CS4 to convert to big QT files.
I cant imagine the folks that have to render to large formats
I wasted all that time
Thanks for the transparency you have been able to communicate about this issue to date.
You wrote that Adobe can't go back and use the older API because it will not work in 64-bit and also doesn't provide some crutial features. Would it be possible to run with a patch that allows users to boot up in 32-bit mode and work with out a few features to circumvent this bug? What features specifically use the newer QT API?
Also, I think the only question the end users haven't seen a direct answer to on this forum is at what point did Adobe and Apple realize this API had a big workflow bug in it; was this discovered pre-release of CS5 or after?
Hi Todd - I've read the entire thread and I think you've done a good job communicating here (and keeping it professional). I beta test myself and know it's a grind. I think posting a notice about the bug publicaly is a good idea (perhaps in a readme faq or something as well when you install). Feel free to thrust blame on Apple - maybe that will shame them into action. It's a pretty big deal though - my editors have been asking me what the deal is...that movies weren't saving correctly. People have wasted a lot of time (when I posted last night it was 2:00 in the morning because I had just babysat a giant render only to see that it wrote out a file ending in 2.15 GB to my Xserve project server). I just finally noticed last night that they all stopped at 2.15 GB and of course figured 'oh great - now I have to delve into Snow Leopard server to figure out what's wrong here'... it never would have occured to me it was a QT bug.
Thanks for clearign things up, Todd.
I don't doubt that you take your job very seriously - and your transparency is valuable. I realise you care.
I think I worded my response to you poorly. When I say take the high-road in this situation, what I mean is that even if the bug is thought to be fixed within weeks of CS5's launch, and Adobe is aware of such flaw, it should immediately be made public knowledge. If even to save a handful of users extreme frustration (more than a handful in this case). My biggest problem here is that Adobe was aware of this far before I was dealing with the issue and yet it was still very difficult for me (and others spoken here) to find this specific thread on the forums.
Not to mention that since this bug is seeming to be entirely out of Adobe's control (apples API) - that you would specially want to make a big fuss about it in a tech doc or otherwise - so the mob knows we have to wait on a third party for a fix.
Perhaps a rapidly updating (like, real time) known issues system that users can easily discover when they are having problems could be extremely helpful for everyone (even you and the guy across the hall from you). (edit: maybe something like this exists and I just can't find it?)
In any right, I appreciate your responses and transparency.
It's extra sad that Adobe is already touting, and selling mind you, a new release (.5) before getting this bug fixed.
And as far as I can tell - this flaw is not listed in the release notes for the .5 update either. Shame, shame...
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.
Biggest reason why were not upgrading our Enterprise license.
I almost wasted resource on redoing our xserves to NFS.
Nope were staying with AFP and avoid the render bug going the long route
> It's a busy day today, so I'll get something up by EOD Monday.
Let me revise that to "I'll have something written by EOD Monday, but I need to wait until Tuesday for the relevant engineer to double-check for accuracy."
Don't forget the blessing of The Pope on Wednesday. 8-)
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
> 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.
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.
Apparently, Apple has a real good handle on this and they are running as
fast as they can to fix this... NOT!
Thanks, theoutfitvfx. SMB was the recommended solution, and I didn't test it myself. I just modified my post based on your feedback.
Thank You. I would love to know if anyone has had success with SMB.
Here's a public and easy-to-find statement of the issue:
Thanks, Todd, for listening to user feedback and acting quickly to get the info out.
And since your post - I can already feel the anit-adobe-ism withering away.
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.
Has anyone actually confirmed that SMB works? If so are there
configurations settings that needed to be set?
> Has anyone actually confirmed that SMB works?
It was suggested by Apple, but I haven't seen a case of it working yet.
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:
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.
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,
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.
we gave up on this and focused on things that to do work.
we still upgraded to CS 5.5 knowing nothing would help.
Aha! This happened to me on a couple overnight renders! And magically this topic appears.
Running AE CS5 10.6.8 connected via AFP to a HFS+ drive mounted on a 10.6.8 Mac. I vaguely remember this issue with Cinema 4D a couple versions back. My startup drive is an SSD, so local rendering huge Quicktimes isn't really an option. Here's hoping to CS5.5 + Lion fixes this.
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.
Im for REDCODE but not sure (technically) how that matches with OpenEXR.
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?