Hi Todd,

Has anyone actually confirmed that SMB works?   If so are there 

configurations settings that needed to be set?

Jason

> 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:

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

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

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?

Thank you.

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.

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

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

November 2011, bug still exists, nothing has changed. Of course, Snow Leopard's Quicktime has been on 7.6.6 for a while so why would there be any chance.

1. Knowing Apple, I suppose this will never be fixed for 10.6.

2. Has anyone tried force-installing QT 7.7 to see if it makes any difference?  (Force since 7.7 is officially only for Leopard.)

3. Several people have mentioned NFS as a proven workaround. In this context, are there any downsides or pitfalls one should be aware of before enabling NFS?

4. I submitted this bug to Apple, for good measure:

Summary:

The 64-bit compression session API (AddMediaSample2) cannot write Quicktime files over 2.15GB (2GiB) to network volumes (AFP, SMB). Returns -1309 (fileBoundsErr).

Affects all of Adobe's Creative Suite products since CS5 as well as other products.

Steps to Reproduce:

1. Open an Adobe CS5 or CS5.5 Application on a 64bit kernel.

2. Generate / render / save a Quicktime MOV file expected to be over 2.15GB. For example 30 seconds of uncompressed 1920x1080 30p.

Expected Results:

Complete write of file.

Actual Results:

-1309  (fileBoundsErr). QT file is trimmed at 2.15GB (only frames up to a 2.15GB threshold are in the file.)

Notes:

Bug exists since April 2010.

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.

Hi Todd!

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

We're still waiting for the fix from Apple.

THANKS for the fast response!!!!

So we workaround this "..." and wait and wait and wait ..... for Apple 

Sure...

Most of us stopped last summer.
I was at last years NAB hunting down answers and didnt get any.

Itll be render to local drive for big QT docs for now.

Most of my renders go thru MainConcepts MPEG Encoder anyway and that works over AFP network.

I've asked for an update from my coworkers who are in communication with Apple about this issue.

I stopped to believe in anyone involved about this.

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...

"Stupid but simple..."

Key word being stupid.

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

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.

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

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

Yep this have been going on for years now.

Most have moved on.

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

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

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-network-using-afp.html

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?

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.

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.

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.

Hi Todd

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 jim@packetcolor.com

We are located in the LA Area.

Thank you.

Jim

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.

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.