Hi Simon, Generally, for error states the MediaProcessor library in AMT3 provide exceptions that you should be able to catch but specifically notifications such as the Web Services check-in are currently implemented as 'fire and forget' operations. The expectation is that this mechanism is used only during the EWC phase, and that your application

Hi Rich, please submit a self contained and executable demo project that makes your issue reproducible for our engineering teams. The AMT3 SDK includes an issue reporting template project as part of the demo software source code.

Hi Rich, Current latest version is 4.4.18.

Hi strangecapella, one possibility is that the error is what it states - the AAF describing your Avid Atoms may not have physical source mobs. You can use an AAF dumper for example from the AAF Toolkit to validate this. If the AAF is Avid generated, it will normally have physical source mobs. A second and much more simple possibility is that you're

Hi Tom, some version numbers for AMT and NEXIS backend and server would be helpful but there was an issue in some older NEXIS client that resulted in long track creation times with AMT 2.x. This is dependent on the number of audio tracks but seems to be in line with the numbers you are showing above. As a first step, you should retest with a version

Hi Rich, AMA methods are currently not exposed through any API because they depend on very specific interactions between the AMA plugins and Interplay. We are currentyl investigating how read access and some other safe functionality like deletion could be enabled through one of our public APIs, and will let you know once we can offer this functionality

itochu-cable, the sample AAF "2-45-2 error.aaf" provided shows a pan effect on the sequence, see below. You can check out the AAF edit protocol documentation on the AMWA web site for a description of the AAF effect model:

itochu-cable, case 2899004 has been created for you. The sample sequence provided contains unrendred effects such as audio pan. Is it possible that you might be sending the original sequence and not the downmix result to the downstream process? This could be a possible explanation why the process still continues to fail after the mixdown being applied

pluginPCI, as I explained in my posting above AvGenericFTP_Receiver dll and AvGenericFTP_Receiver dll are absolutely different things. AvGenericFTP_Receiver dll is the 'setup' DLL that creates a 'media placeholder' (proxy mob) for you; AvGenericFTP_Receiver dll is the receiver DLL that moves media. They are by no means interchangable

itochu-cable, I looked at the AAFs you provided and the cause is quite obvious: The sequence AAF you are trying to send, '2-45-2 error.aaf', contains a composition (sequence) with audio pan effects and pulldown applied. The CheckSequenceIsReadyForXfer() call should fail on this; the result you're seeing is absolutely consistent with what