Drag/Drop import with different media types = unreadable clips

OK, I have another weird bug for you. When we drag and drop multiple folders containing different media types into a Cortex bin, the media gets imported but there’s tons of clips that are red. The Cortex log complains of “Error creating source extractor”.

The Cortex bin looks like this (notice some of the video AND audio files have been misread):

This only happens if you drag in a camera folder AND a sound roll folder at the same time. (For example, you drag in A001 which is a folder from a camera roll and another folder SR007 which is from a sound recorder.) If you drag each folder in individually, they import correctly. You can import multiple camera files at the same time, but the audio needs to be imported separately. And I think this is only if you drag/drop the folders into Cortex (I haven’t fully tested this with the Import button).

This only started showing up in Cortex version 1.5.3, starting with version b5126. Version 1.5.2 b5002 doesn’t seem to be affected. I’ve experienced this bug with these versions: 1.5.3 b5126, 1.5.3 b5260, 1.5.4 b5342. So whatever got changed with drag/drop import on version 1.5.3 is the culprit.

I have the log and will email it soon.

@amy can you reproduce this one?

@dave & @24pdailies I can’t repro this with any of 1.5.3 b5126, 1.5.3 b5172 (the following release) or the current beta

It may be specific to MXF footage somehow…

I gave that a whirl with no issue either, though I might just just not recreating some specific condition of the failing case

I did run a few more tests. Here’s what I’ve found:

  • if database is set to local, it doesn’t look like the bug is present. So far, I’ve only seen this on Enterprise with a shared MySQL database
  • clicking Import > Media Folder and importing the media also works. Both video and audio imported without problems. No bug there. So this is only showing up during the drag/drop.
  • I’ve tried with both F55 RAW and F55 XAVC files (both 4K). But because the audio is also not reading, I don’t think this is due to reading MXF files wrong. I think weird/bad data is being sent to the “source extractor creation thread” (my guess, based on the log)
  • The files were buried fairly deep in subfolders (ie SR007 > SHOW > ROLL2_2-43 > wav files). I reorganized the files so they were only one folder deep (ie SR007 > wav files) and tried drag/dropping into Cortex. This also triggered the bug and some media would not import.
  • I created an entirely new project/job from scratch (hoping to avoid the ‘corrupted database’ bug from before). Still getting the same results if using a shared database.
  • I made two folders. Each folder contained just one wav file, one a single camera clip (mxf, xml, bim). Video failed to import on this pair of folders also (just audio imported, not video)
  • any attempt to delete these red clips will crash the program
  • I checked permissions on the media folders - made sure they were set to Full Access for all users. Bug still present.
  • Media imported from two different locations: external RAID and SAN. Both tests caused issues on import.

So, I know this doesn’t really pinpoint the problem. For what it’s worth, here’s the steps I am performing to import the media into Cortex:

  1. Create/open job in Cortex
  2. Go to Windows Explorer
  3. Click first folder to select it
  4. Shift click additional folders to select them also
  5. Drag multiple folders to Cortex, drop them into the bin list area.

Thanks - I have a local DB, so that explains why I can’t reproduce it on my system!

Hmm… I can’t reproduce this in the latest with a MySQL database either…

@24pdailies - maybe it has something to do with the weird filename of this audio file?

"0","Cortex","Error","Cortex//GetSourceExtractorForClip(0): Error loading clip (TD6105==2    23At 4   ==PR.WAV): Unable to open source file   R:\SHOWNAME\101_102\Day04b\SR007\20140908.AAR\TD6105==2    23At 4   ==PR.WAV","","09-11-2014 09:39:37.576","6804","1","1175467937632","CORTEX05"

I thought the same thing, so I tried with a different show which uses a sane naming scheme (as seen in the screen shot above - ie 3T3.WAV, 3BT1.WAV, etc)

Then my suspicion is that its still something related to F55 footage and how those MXF files are parsed.

I don’t have a ton of F55 footage to play with here, though. If you find or make a few ProRes files can you reproduce the issue with those?

I was able to reproduce this with a shared DB in b5126 and b5325

To make it happen, I had to:

  • select more than two folders to drag and drop
  • one had to have an MXF file in it
  • one had to have a WAV file in it
2 Likes

EDIT: @peter has a fix for this. We’ll ship it tomorrow.

1 Like

this is now fixed in v1.5.3 b5387

1 Like

Awesome! Thank you!

I’m assuming this will be rolled into the 1.5.4 version before final release?

Yes, already rolled into v1.5.4 beta b5390 as well.

1 Like

Very cool!! Thanks!!

This topic was automatically closed after 4 days. New replies are no longer allowed.