Hi guys,

Just wanted to confirm whether anyone has tried rendering with the mov64 writer 
in Nuke 9.0v1?

In my local tests (well actually AFP network!) the 64-bit writer does not 
appear to suffer the same size limit as the 32-bit writer.

Would be good to hear your experiences with this..

Cheers,
Ant

> On 24 Nov 2014, at 18:54, adam jones <[email protected]> wrote:
> 
> Hey there john
> 
> we are running NS on mac os x 10.8.5 from my finding yes it is a little 
> random but hit about a 90% fail rate.
> 
> it not solely quicktime the issue that needs to be addressed is the afp 
> protocol, I am investigating using NFS and mount points but this brings it 
> own issue being that apple has not written it in there os to the own 
> specifications and standards, but for the least amount of issue it is 
> recommended to use Yosemite  over mavericks, works great with 10.8.5 but the 
> newer the mac the harder it is to get the box running with 10.8.5.
> 
> as howard mentioned maybe the way around is for the file to be written local 
> to a temp file the copied to network location on completion, would be awesome 
> if this all just happened under the hood, maybe a feature request for the NS 
> guys.
> 
> and yes I can defiantly say this is real.
> 
> regards
> -adam
>  
>> On 25/11/2014, at 3:25 AM, John Coldrick <[email protected]> wrote:
>> 
>> I don't know if you're running on Windows, but we've always had issues where 
>> we need to use UNC paths instead of mounted drives(or do it locally and then 
>> copy), it's completely random and is related to the quicktime dll.  It 
>> breaks without much in the way of diagnostics.  Tends to show up if you have 
>> more than a couple of mounted network drives.
>> 
>> For some reason this isn't widely acknowledged, but it's real.
>> 
>> J.C.
>> 
>>> On Mon, Nov 24, 2014 at 4:08 AM, Howard Jones <[email protected]> 
>>> wrote:
>>> Oh thats interesting. I've had lots of quicktimes fail in the past and 
>>> didn't know why. 
>>> I write a temp one and push to the network via python. Which has got around 
>>> this. 
>>> 
>>> 
>>> Howard
>>> 
>>>> On 24 Nov 2014, at 07:43, adam jones <[email protected]> wrote:
>>>> 
>>>> Hi all
>>>> 
>>>> So I thought we left this 2 gig file limit back with the passing of FAT 32 
>>>> however it seems to have reared it ugly head again in another form.
>>>> 
>>>> This is an article I found regarding AE and this issue
>>>> 
>>>> http://blogs.adobe.com/aftereffects/2011/05/cant-create-quicktime-movie-larger-than-2-15gb-across-network-using-afp.html
>>>> 
>>>> I post here as it seems to be with NS also over an aft network so of 
>>>> course it not a NS specific problem at all so I guess (aside from 
>>>> rendering to a local drive) does any one have a solution to this issue and 
>>>> if not what are peoples suggestions in term of another network protocol?
>>>> 
>>>> linux server with prodomantly mac osx connected to it with a few windows 7 
>>>> boxes for maya.
>>>> 
>>>> any thoughts or suggestions would really be appreciated.
>>>> 
>>>> cheers
>>>> -adam
>>>> 
>>>> _______________________________________________
>>>> Nuke-users mailing list
>>>> [email protected], http://forums.thefoundry.co.uk/
>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>> 
>>> _______________________________________________
>>> Nuke-users mailing list
>>> [email protected], http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>> 
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> 
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to