In both MC6.0.3/OSX10.7.4 and MC6.0.1/OSX 10.7.2 we cannot export reliably to H264 if Unity is involved at all. Any suggestions on how to make this work? Or is this a broken feature for Unity users?

We're desperate for an MC6-direct solution since the workaround (export sames-as-source and transcode) is sucking up time every day. We need to export every clip to satisfy client dailies requirements.

Project is 1080/23.98 with all captured DNxHD36 MXF media from HDCAM-SR captures from NitrisDX and MojoDX. MN Client 5.5.1 and Unity 5.1.3 using Atto Celerity FC-41ES on MacPro Harpertown Dual Quad Core 3GHz.

We're doing bin-level batch exports, not sequences that can be mixed down.

Export is H264 1280x720 QT with AAC audio.

There are several failure scenarios, but the most common posts an error during export: "Export Failure: errcode: 4294967247"  The other main failure we've seen are full MC hang or crash during export while "Making quick start movie..." is in the progress pane. Those mostly occur in fresh projects/fresh capture scenarios. Recovery from crash isn't possible and requires a hard machine restart.

We've tried many tests to isolate the problem's source, but in sum, using local media storage and exporting to local storage is 100% reliable. Reliability with our Unity storage for either media storage or export path is 20% at best.

I've seen several posts in the Media Composer for Mac forum highlighting H264 export trouble in general with MC6, and even some of the same error codes, but no solutions, and little mention of Unity.

What is the name of the Unity drives?

Try simplifying them to one word alpha-numeric.

If that does not work, you may need to do some workaround like exporting bunch a Same as Source and using Squeeze, MPEGStreamclip or similar software to do a batch conversion to H.264.

Name of Unity spaces varies in length, but is this format: FeaturenameOfflineMedia or FeaturenameExports. The Unity clients connect with names as Avid1, Avid2, Avid3, etc. Are those names illegal in any way? Or do I need numberless, single, unique names like Alpha, Beta, Gamma, etc? I recall a tip like that a while back on an earlier version, but can't recall whether it matters now.

We can export Same As Source and convert, and have been as a workaround, but the time required is significant. We need a direct export option.

Naught1:

Avid1, Avid2, Avid3, etc. Are those names illegal in any way? Or do I need numberless, single, unique names like Alpha, Beta, Gamma, etc?

Is it more safe to use alpha numeric names...? Yes! But in your case I don't think it has anything to do with the issue.

Have you checked error logs on the unity? How full workspaces are etc?

I've got a set-up so identical to yours it's like we're the same facility. And got a hard crash when trying to duplicate your problem.

I didn't get a chance to try, but what happens if you use Unity for the source footage and export to local storage?

We normally don't have the need to export to Unity and may have never tried, but some assistants like to export to an Appleshare server which very often fails. I make them export to the desktop and then copy to the server and it works.

This might not be ideal for you, but it's better than having to copy all your source media to local storage.

Robert

We have many issues when exporting to our Unity as well. I think it has to do with moving up to Lion as we never had this problem prior to our upgrades. It is hit or miss exporting to the Unity and almost all 3rd party programs lock up when writing to Unity that requires a hard restart. Our solution has been to write to desktop then move file to Unity.

Jeroen van Eekeres:

Is it more safe to use alpha numeric names...? Yes! But in your case I don't think it has anything to do with the issue.

Have you checked error logs on the unity? How full workspaces are etc?

Error logs show no signs of error, except for the forced disconnects when MC hangs the machine.

Workspaces are max about 59% full right now, and 67% of the overall space is used.

Robert Ferguson:

I've got a set-up so identical to yours it's like we're the same facility. And got a hard crash when trying to duplicate your problem.

Wow, thanks for trying that Robert. Good to know, I guess, that I'm not alone in this problem. 

Robert Ferguson:

I didn't get a chance to try, but what happens if you use Unity for the source footage and export to local storage?

We normally don't have the need to export to Unity and may have never tried, but some assistants like to export to an Appleshare server which very often fails. I make them export to the desktop and then copy to the server and it works.

This might not be ideal for you, but it's better than having to copy all your source media to local storage.

Robert

Export to local storage was better for a while, but now gives similar errors to Unity exports. Exports to Unity have all worked for us in the past, but that was on MC4.05/OSX 10.5.8. 

Unfortunately it seems we've found the thing that doesn't work on this combination of platforms. [:'(]

outpostbc:

We have many issues when exporting to our Unity as well. I think it has to do with moving up to Lion as we never had this problem prior to our upgrades. It is hit or miss exporting to the Unity and almost all 3rd party programs lock up when writing to Unity that requires a hard restart. Our solution has been to write to desktop then move file to Unity.

Wow, I had no idea that Unity was so problematic on Lion. Are you on MC6 as well? And is it just H264 or are all exports from MC failing to write to Unity?

Are there threads I haven't found where others have similar issues? Exporting to Unity is essential for us.

Naught1:

Are you on MC6 as well?

I am currently on 6.5 but the problem has been around since 6.0/Lion upgrade.

I have replied to a couple of threads in the past where others have had issues with Lion/Unity.

Naught1:

And is it just H264 or are all exports from MC failing to write to Unity?

I have luck exporting to Avid Codecs "most" of the time and get lockups when trying to export to some other flavor of Quicktime.

I have found it Key not to be multitasking when exporting. I can't be exporting the same time as compressing a file in squeeze or compressor.

I use Squeeze/Compressor to do most of my format flipping.

outpostbc:

Naught1:

Are you on MC6 as well?

I am currently on 6.5 but the problem has been around since 6.0/Lion upgrade.

I have replied to a couple of threads in the past where others have had issues with Lion/Unity.

Naught1:

And is it just H264 or are all exports from MC failing to write to Unity?

I have luck exporting to Avid Codecs "most" of the time and get lockups when trying to export to some other flavor of Quicktime.

I have found it Key not to be multitasking when exporting. I can't be exporting the same time as compressing a file in squeeze or compressor.

I use Squeeze/Compressor to do most of my format flipping.

Since we're in DNxHD36 mxf media, our exports as Same As Source match your experience. Works most of the time, but not 100%. Since we're locked into H264 exports by the dailies requirement, we haven't tried too many other codecs yet. Sounds like those won't work either, though.

I'll have to try killing everything but MC6 and FibreManager, see if that helps.

I'm also going to install the X264 encoder to see if that gets around the problem.

And Luckily, our Avid Vantage case has been escalated to a very capable and persistent support individual, so I have good feelings that we're headed to a solution!

We have simillar unreliability on MC 5.5 on Unity.

So before any big export we do a restart of MC and this seems to improve reliability.

After a number of (kind of basic, but easy-to-miss) steps, we've had some improvement - exports to are about 75% reliable vs. not, and in the process ID'd some other possible root causes.

1. On Unity. we had exceeded the maximum number of directories by about 800. After deleting a bunch of Avid DS archive folders (hundreds of empty folders each), we're down to about 7000 directories. That seemed to make the biggest difference.

2. The time settings weren't working so client and server times were different by as much as 20 minutes.

3. The MN5.5.1 readme calls for a different slot config for the FC card in our Harpertown 3,1 Mac Pro's vs. the older MN client version we were on, so we moved all cards to the indicated slot.

The other likely cause of the export failure include some corrupt media. Now this problem is a nut unto itself, but seems deeply related to an occaisonal batch capture error "Exception: TC_Unexpected_MOB" The files created when this pops lurk and are not always getting caught during database scans, and are probably in part responsible for the export failures. I'm surmising that batch exports of corrupt media would fail in some way.

In turn, the corrupt media invalidates the databases, so media goes offline, partly because the scanning gets hung up on the bad MXF's, and partly because the media that was there isn't, as far as MC can tell.

Some of the clips in MC6 eventually lose or do not have an end time code right after capture. Eventualy these cause indexing errors and the inability to relink to media. 

I've had my fill of divide and conquer on the affected media files- hours of moving files and scanning to isolate 1 or 2 clips at a time.

Avid's escalated this issue up the chain to determine the actual cause othe Unexpected MOB error. In the meantime, we've set our Batch Capture settings to "Optimize for Disk Space" from the previous setting of "Optimize for Speed" which we've used for years on the same hardware without trouble. 

They're also trying to hunt down an application built a few years ago to ID files with this particular corruption.