I am using latest quicktime.
What exactly makes up your E: drive? Have you already checked the user privileges and file ownership settings? I tend to agree with you asessment, but that realyl is something you must fix in the operating system...
Yes I checked the user privileges, but I am not sure how to check the file ownership settings?
Thanks for the fast answer.
1 person found this helpful
Right click on the folder, then properties -> security
you should do this as the administrator, and make sure any users that will be needing access are listed.
Thanks for the answers.
Somehow I was able to solve the problems . I formatted the hdd drivers and re-made the partitions .
The problems was still there if I installed windows with the old partition information, I had to remove the partitions and re-install
Windows, - then it worked fine.
Yes, that may happen. Different Windows versions use slightly different sub-versions of NTFS plus allocate different hidden sectors on the disks. That may indeed cause weird side effects in the physical drivce mapping, if no reformat is done on install. Anyway, glad you resolved the issue.
Just wanted to add that I had this render occuring on a mapped network drive (on an isilon), and found the solution by remapping my drive through the server's IFS path.
"Weird side effects" is right!
Same problem here.
After Effects 10.0.1.19
Apple Quicktime 7.6.9 (1680.9) (tried with different versions of Quicktime, since 7.0)
Windows 7 Professional/Ultimate 64 bits (with and with Service Pack 1)
We're getting the same error when trying to render to Quicktime files using network shared folders as a destination:
Unable to open file. (-1610153459)
The funny thing: it only happens when there are at least two shared folders mapped on the workstation, and the destination folder used for the rendered movie is not the first one.
If we have only two mapped drives, F: and G: for example, and we try to render something to F:, everything works fine and no error is showed. But, when the destination is the G: drive, rendering never works, the error is showed, but a zero-byte file is created in F: (!!). ODD! If we remap F: drive with a different letter, but a letter BEFORE G:, the problem always happens. If we remap drive F: to any letter AFTER G:, making G: the first available network drive, rendering works. Also, simply unmapping F: and leaving G: as the only connected network folder makes render to work.
We do not have a D: drive in our Windows 7 workstations, they are all C: only.
It is a 100% reproducible problem. We tried with three different Active Directory networks and workstations. It has all of the features of a software bug. By software i mean After Effects.
We tried logging a support ticket with Adobe this morning, but had not heard anything from them yet regarding the situation. And to note: the Adobe guy who provided support asked me to re-format my network shared folders as a solution, which is clearly not the solution, since it happens with different file servers and different workstations. Also, it is not a NTFS security permissions problem, because rendering works fine with any mapped drive, as long as they use the first letter available after the local disks and DVD-ROM. BTW: who could be possibly that insane to ask a customer to reformat three production file servers?
Any help would be appreciated.
Hmm that's sounding pretty wierd. If you are running Linux on the file
server, try tweaking your SMB. If windows, disable your anit-virus on
the affected machines. On the shared folders, try seeing if the
problem occurs when access is set to everyone, then i'd try to turn
off UAC. I'm going to bet it's AntiVIrus. and you'll probably need a
fresh boot to check.
This does not sound like an adobe problem, it happens with other soft
too, I think there is something in the windows unmanaged code that FU
when folder redirects are used.
Weird, indeed, but not that much since it is 100% reproducible.
No linux on the fileserver. Happens with both Windows Server 2003 and 2008 versions running on the file server. They are fully patched. It also happens when a local workstation's shared folder, such as C:\Temp or any other, is (re)mapped on this same workstation.
Problem also happens when the Shared Folder has Everyone, Full Control permissions on its root. Also, i would like to emphasize that is not a filesystem issue with the fileserver, since render works fine when the destination folder uses the first available letter or when it is the only mapped drive on user's computer.
Tried with and without UAC disabled, same behaviour. Tried also with workstation users in the local Administrators group.
It's not Antivirus either. Tried with three different fileservers, two of them run Symantec Endpoint Protection, and one of them runs no antivirus at all. Tried also disabling antivirus software on both the workstation and the fileserver.
And, finally, it does not happen with other software, only with After Effects rendering Quicktime movies. Other codecs render perfectly, without any error.
After Effects is creating zero-byte files on the first available mapped drive, which is a clear indicator of a software bug to me, whether from After Effects or from Quicktime.
Have you tried downgrading the quicktime server on your machine? All
this stuff runs via a server listening to a port on your system. It
may be an issue with the environment, but it's not specific to just
adobe, yet occurs with quicktime on other apps that use the same
server.Maybe windows firewasll or defender has changed? Assuming this
was working earlier. Have you tired disktools on the disk? Take the
same filename 0 byte file, and name some large file the same. see if
when you write to another section of the disk if you don't see the
same problem. I've seen disk errors affect CS5, probably why I am on
As i posted previously, Quicktime was downgraded to several versions until 188.8.131.52. Even After Effects (given the conditions that it is using only one mapped drive or the first one as destination), can overwrite the zero-file and render Quicktime properly. It is not a disk or NTFS security settings problem and i would like to evaluate other options which could be causing this situation.
I just need to install a Windows 7 Professional, download all updates for it, install the latest version of After Effects CS5, download all updates for it, install Quicktime's latest version, join the computer to the domain, and reproduce the problem. So, it is not related to any changes being made to the workstation.
Would you have more information on how the communication between After Effects and Quicktime happens? Any ideas regarding overly-secured GPOs, maybe?
I have same problem while export to mov but it works fine with AVI, mpg, etc.
my machine have 2 harddisks with same name ,eg: "Harddisk D:\" and "Harddisk F:\"
I got the -43 error when I check export video in quicktime pro,
here's the solution:
try using different name for each harddisk and it will work fine.
That may work for local harddisks. As stated previously by RoFz_55, the error happens with SHARED FOLDERS.
I'm a little late to jump on this thread, but I have the same problem. Has anyone come up with a solution at this point? It happens with DNxHD exports/renders from AE or PR. But I can export a PSD or TIFF sequence to the exact same drive just fine.
I had this problem as well
I was writing to a mapped drive "F" where "F" was an alias to c:\dev
When I changed the output path to "C:\dev\PathToMovieRenderLocation\" from F:\PathToMovieRenderLocation\" my movie rendered fine. I'd call this a bug
If you are still out there did you ever find a solution to this issue? We have the exact same issue in our environment.
I am so glad I found this post before I started messing with permissions etc, it's so easy to reproduce, we had a H: Drive mapped and an X: Drive. rendering to X failed with Unable to open file. (-1610153459)
However after creating a new mapped drive G: pointing to the exact same path, rendering worked!
Interestingly, rending Quicktime from Nuke also has this issue, so now I am thinking the bug is Quicktime and maybe not AE?
Any help would be greatly appreciated!
That’s what I found.
I used the direct path rather than the virtual path and I was fine. I agree that this is probably a QT issue rather than anything endemic to AE.
I did not try re-mapping the drive, so I don’t know if creating another drive mapping would have solved my issue.
I thought i'd add my situation. I'm getting the same error trying to render to a network drive. I can render fine locally, and I can also render image sequences to the network drive, it's only video files (QT, WMV) that give me errors. I'd also like to add that I get the same issue when rendering from Cinema 4D. This makes me think the issue has something to do with the OS or network setup.
We're still getting this... ONLY exporting to network drives, and ONLY with .WMV files. We haven't tried QT.
Any files we export to our C:\ drive or anywhere locally, work fine... any network locations, the .WMV files don't play. There is no error on exporting, and it's the same from AfterEffects, and Premier.
The file isn't getting written correctly, or the header is broken or something. The file won't play in Media Player Classic, but works in Windows Media Player on Windows 7, but not XP.
Clearly needs to be sorted out Adobe!!
It took a huge amount of time a few years ago to figure this issue out, but we've been waiting for it to be fixed for a loooooooong time!
CS5 and CS6 on Windows 7 Enterprise 64-bit
Am having this problem too: Windows 7 x64 SP1, rendering quicktime files only, and only when we're trying to render to a network share which is the last alphabetically in Windows's list.
Symptoms are similar to RoFz_55: most of our files are stored on a Linux share mapped to Z:\, but we also have other shares mapped to Y:\, X:\ etc (depending on the user). I can render Quicktimes to any mapped share on the list except the last one (Z:\). This happens from C4D as well as AE, though, so it looks like a Quicktime or Windows issue :/
I am having this problem on Windows 7 64bit too. I was rendering to a sata drive that had a folder on it mapped to a network drive. I reformatted the drive and it rendered to it just fine. After that, I remapped the network drive back to the same folder location on the drive and immediately the render error came back. This time, I tried to render by picking the mapped network drive and it rendered just fine. I can't however render to the actual drive root. I'm going to move the folder that I map as a network drive to a different physical drive so my render drive will not have the network mapping associated with it. Really weird but at least I got it figured out on my machine. Good luck!
2 people found this helpful
I was having a similar problem where After Effects, Premiere, and Sony Vegas could not create QT files on certain drives. After a lot of forum searching I finally found a solution thanks to a tip from Rob Maybury on CreativeCow.net
It looks like QT will only write to drives with a unique name. My volumes were set up as follows (looking at Windows File Explorer)
- Local Disk (C:)
- New Volume (F:)
- New Volume (G:)
- New Volume (H:)
I could create files in C: and F: but not in G: and H:. After changing the Volume names so they all were unique:
- Local Disk (C:)
- SSD Volume (F:)
- Main Volume (G:)
- New Volume (H:)
I could now create files on any drive.
To change the Volume name, right click on the drive and select 'rename' or bring up the properties window and rename it there.
I just had this problem. pfm_nj's solution worked like a charm. Thanks for posting!!!!
After many years I found the solution and it so funny that quicktime care about volume drive.
I think it's because of different way to address files in mac and win.
Anyway thank you so much "pfm_nj's" . It work very well.
i had the same issue and this helped me so much thanl you!!!
For some reason the render would fail if I export audio as AAC but works with Uncompressed. Using After Effects CC (2015.3).
아..진짜 감사합니다.. 정말 어디에도 안나오던데 안되던게 바꾸니까 바로 되네요!
Thanks a lot...:)
The Best and probably the ONLY solution.
Thanks a million ton!!!!