Corrupt HQ Files From Multi-tasking?

[Mike Truly]

I have had this happen a couple of times now and I'm wondering if there's anything that can be done about it.

Imagine systemA. It is where Edius lives and is the edit system. It has numerous U320 SCSI drives some configured as RAID0 and others just as plain drives. There are many other systems that render 3D animation, primarily.

SystemA has Combustion working to assembly an HQ AVI file. The frames are coming from drive-i and the HQ AVI is being deposited on one of the RAID0 stripes.

At the same time, other systems are rendering TGA frames from across the network and depositing them on systemA's drive-i or other drives.

This is happening simultaneously and all seems well and all jobs finish without errors.

Until I go to open an Edius edit that already contains references to the HQ AVIs that Combustion generated. (Combustion was overwriting HQ AVIs that are needed/used in the edit). The restoration dialog pops up like it can't find the files. When I navigate to the folders, the files are right there and the proper names but the little preview window shows black and Edius won't open the files.

If I try and open the files in Media Player, etc. they open fine and play fine and appear fine. But something about them Edius doesn't like and it won't accept them.

It seems this is related to the fact that multiple things were happening on systemA at the same time. In the past when doing this, I had a couple of HQ AVIs that did play, but had some colored garbage blocks in the file in spots and had to be redone. When I re-assembled in Combustion with no other renders happening, the files were clean.

Today when doing this, the resulting files simply will not be recognized by Edius.

Since the files play fine in all other respects, it would be nice if there was an Edius app that would make the headers kosher so Edius would see them.

Has anyone else seen this type of behaviour?

Thanks!

[GrassValley_BH]

Could be a couple of different things...

Combustion is rendering to a format not matching the original clip. Perhaps non-drop timecode when the original was drop, or the clip duration, resolution, aspect ratio, or other clip property has changed. That would keep EDIUS from letting you replace the new clip with the old clip.

In the past (thankfully not recently), in the Windows 2000 and NT days, there was a weird behavior with respect to network sharing. You could get into a situation where somehow a shared file was cached, but the cached data was bad. The physical file on the disk would be OK, just access to it from other machines would come up with incorrect data. Eventually the cache would expire and the next access may or may not get correct data. More often than not, data was correct, but every now and then, something would get into this "bad cache" scenario.

It was discussed a lot about OpLocks and other things. Byte Brothers Network Tune-Up Utility seemed to have fixed it for me, but it's hard to find this utility nowadays and I'm not sure if it even applies anymore.

So far, it seems this problem doesn't affect Windows 2003 Server...

[Mike Truly]

Brandon,

Thanks for the info. It turns out this is the problem of the clips being a different length (which I've had before but didn't remember this issue).

To me, it's seems logical that the restore dialog might refuse to restore based on a corrupt clip or different resolution but illogical that a different length clip (but all other parameters the same) should refuse to be restored. At least Velocity and other editors don't seem to impose this particular limitation.

I have this situation all the time where where I already have a complete edit, yet one of the clips has to be re-rendered to a different length. I know the clip will not be fitting in the edit as before (and my next step upon opening the edit will be to adjust the edit to use the new length clip) and ideally, when opening the edit with the new length clip, the beginning of the new length clip will be placed exactly where the old clip beginning was... the end will fall where it may. (Or the user is provided a dialog as to how to place the new length clip).

For now, I will continue to use the Replace function.

Thanks again.

[GrassValley_BH]

Hi Mike,

Glad you figured it out.

Yes, I agree that the clip restore should allow for clips of different duration - especially now that there's the concept of a "virtual space" (not official lingo) in a clip. Right now the "virtual space" is just for sequences nested in another sequence, but I think the same concept should/could be used for clips as well, allowing a clip restore to not change any timeline positions (therefore not "messing up the timeline") and just let the clips have virtual space.

Anybody want to put in a feature-request? My fingers are a bit tired today.

[Mike Truly]

Brandon,

I'm glad you agree! I have posted the feature request.

Thanks!