This is becoming silly. Avid are you ever going to look into this?

Chris, Marianna, Ralph?

FYI, I am no longer able to reproduce this bug on Avid MC 2022.7!

Great news!

Definitely still an issue for me in 2022.7.   Using "show marked regions" makes big multigroups unusable.

Once again I want to beg Avid to look into this, not only because it is a serious bug but also because it seems to warrant investigation.  Why would a simple highlight be adding so much CPU load?   Ever since v2019+ groups came out, this has been a problem.

And yes, I tried brand new user settings to test out the continued existence of this bug.

Here are my findings on this subject.

When you create groups inside of Avid with the 'modern' way it will actually make one big group of your syncmap.
Even though you use a small portion of the group inside your master edit sequence it will still have to load all the underlying media-assets.

So if you have a mastersequence where there are allot of groups from several big syncmap it will load ALL the assests making it feel sluggish and slow bin opening and saving.

Solutions like groupitforme and acmetools.tv group the 'old fashioned' way with lots of add-edits in the syncmap. This is creating lots of smaller groups. The advantage of this is that when you use a smaller group inside your master edit sequece it doesnt have to load all the media assets that are in the syncmaps.

The 'modern' create group is only useable for small syncmaps with 1 or 2 blocks / ISO files. Not for complex syncmaps.

This is probably the reason why the OP says it works well for groupitforme.

Thank you for your repsonse Julian, I appreciate you clarifying the issue.  But the OP posted this years ago and they, like me, were pointing out to Avid that their groups are compromised.  The point of the OP's post isn't to promote groupitforme, it was to notify Avid that they have a huge bug in their groups.

A few points.

• Avid only struggles with it's own multigroups if your in/out selection is turned on.  I have ZERO PROBLEMS using their mutligroups as long as "show marked region" is turned off.   I have now been working for 2+ years without the marked regions and Avid is the fastest is has ever been.  I will never turn on my in/out highlight again until this is fixed.  It is night and day in terms of performance.

• Why should I settle for using outsourced grouping?  Avid groups are great, easy to make, very customizeable – and they work splendidly if you turn off "marked region".

• To be clear, I can turn on/off waveforms and they are their usual kinda-slow self –– but they work fine, just as they always have.   What I am talking about is the highlight – just the highlight between your in and out points.  That brings Avid to a grinding halt (when using multigroups at least).

So, my question is why isn't Avid looking into this?  It makes no sense that a simple highlight is pre-loading tons of clips and that turning off the highlight means the clips don't load.  ???  

Avid should be totally focused on this problem because there are doubtlessly legions of users who have tried out Media Composer and given up and gone back to Premiere or Davinci because when they tried out Avid it came to a grinding halt every time they tried to edit.

It's super frustrating to me that Avid doesn't seem to take such a ridiculous problem seriously.  I've been telling them about it for years.  For years!  I've sent two videos, one recently on this forum ,and I've had mulitple phone calls with them a couple years ago.  At no point has anyone from Avid even admitted it's a real problem.  They told me they "could not recreate it".  I suspect they cannot recreate it because they are not actually using real world projects with dozens of long interviews or mulitcam scenes.

I'm not a coder, but to me it feels like it could be a simple fix.  It's not like the Title Tool or something where there are a million options that have to work with keyframes and timelines etc.  It is JUST A HIGHLIGHT.  A graphical element of the interface – it shouldn't have anything to do with big CPU usage or preloading anything.

Sorry if I'm ranting, it is just mind boggling to me that this bug persists and is the default setup for Avid.  From both a design and a sales point of view it is a total travesty.

Hi all.

We have a client that is facing the same issue. 

On his case the woraround of deselect "show Mared Region" doesnt wor at all.

He is using several Z8 workstations with the RTX-A4000 graphical board. 64GB of RAM. XDCAM50 codec already imported to a NEXIS system, as AVID MEdiaFiles (no AMA). Multigroup of 7 CAMs. Media COmposer 18.12.15

The SAME, and I emphasize, THE SAME, sequence with the same multigroup, on a much lower spec Z4, on the same MC version, all is OK. They can even go up to 12 CAM Multigroup with no issues, on the same NEXIS system, with the same codec. So, the issue lives on the workstation/Wndows Config/drivers/boards world. 

Really difficult to explain. 

Worst than that, the previous project, on the same machine, same codec, 12 CAMs Multigroup, etc... was working fine. They say it started a month ago or so with these kind of issues but the operator only started to complain with the new project.  Opening the old project, we can see now, the problem as well. Windows version is the same on both Z4 and Z8, even they already have Z4 with WIN11 working fine (!!!). I noticed, on this thread, that MAC coomputers were havng the same issues... Its really puzzling.

We also have an open case 04483726 for this and, until now we were upgrading all drivers, NEXIS client Version, reinstalling Media COmposer software, collecting logs and nothing more. For the RTX boards we need to download a specific driver for it but AVID MC Matrix only mentions the version for the Quadro graphic boards that are not compatible with the RTX. The NVIDIA site has no working lin for the old RTX driver versions so the latest is a 5. somenthing whereas the original Z8 is using a 4.7.2.39... They didn't comment much about the fact it's running well on the Z4s but requested the configuration of those machines as well...

Dont now if this can help anyone to figure out another solution for this problem, other than replace the Z8's by Z4s :-)

Best regards.

Gonçalo.

Gonçalo, my initial problem is the same in that it's Avid made groups that cause an issue. Have you tried using a service like Groupitforme to make groups? I do not have the same issues with them and that's my current workaround.

Seperately, I had an issue with stuttering groups recently where removing 32GB of the 64GB of RAM fixed the issue. This was on an old MacPro trashcan. Either the RAM was bad (hard to believe four sticks were all faulty, especially as the rest of the OS seemed unaffected) or there was something about having 64GB of memory that MC didn't like. Could this be related to your issue of having a lower spec machine be able to play the groups but not the higher spec Z8? Just spitballing.

Andi

Gonçalo,

In Greece we have been seeing multicam performance issues on Z4's running MC 2018.x.x at multiple sites but as we only recently installed some Z8's, I have never tested/compared them. Our performance issues on Z4's were compared to MC 8.4.x - 8.6.x on z420/z440.

Just something to check on the Z8's. Is NUMA disabled in the bios?

Julian Willemsen:

When you create groups inside of Avid with the 'modern' way it will actually make one big group of your syncmap.
Even though you use a small portion of the group inside your master edit sequence it will still have to load all the underlying media-assets.

So if you have a mastersequence where there are allot of groups from several big syncmap it will load ALL the assests making it feel sluggish and slow bin opening and saving.

The 'modern' create group is only useable for small syncmaps with 1 or 2 blocks / ISO files. Not for complex syncmaps.

 

I would second this complelety.  I've been on the technical side of digitizing/sorting productions for the last 16 years, and this is exactly the problem I found with the 'modern' avid groups in all the large scale reality shows.

We don't use this new feature in any of the shows I work at.

As long as I have "show marked regions" off, I have had zero sluggishness issues with large multigroups made in Avid.  Over the past 4 years or so, across versions 2018, 2020, and 2002, at various facilities on various Macintosh systems I have experienced this problem.

Every time, turning off show marked regions has solved it.   I turn on the "feature" every time I upgrade and it always bring my system to a crawl.    I believe there is a deep seated bug, or something, that Avid is ignoring for some reason.   It still shocks me that they won't address this.

I'd like to chime in with my thoughts.  I did not experience this at all on Avid 2018 on my Windows 10 machine but my colleagues working on the same content said they were having sluggishness with large multicam groups (on a mix of Mac and Windows machines).  We updated everyone across the board to 2020.12.7 and now I am experiencing the sluggishness as well.  Turning off "show marked regions" unfortunately does not resolve the issue.  The problem is crippling because we almost always edit with A and B cams grouped and on many occasions are using large gruop clips with 10+ angles.

The big thing that I've noticed is a complete lack of utilizing CPU power when playing back multicam clips in quad or 9 split mode.  In prior versions of Avid, I could swear (I don't have any actual datalogging to back it up) that Avid would utilize all available cores and push CPU usage to a fairly high percentage when playing back 9 streams simultaneously.  As it is now, while playing back a large multicam clip (13 angles) with 9 split enabled, I'm barely getting any more than 15% CPU usage with my 16 core 32 thread AMD 3950x.  Only a handful of cores are being pushed while the rest look idle.  Granted, this is with 1080p DNxHR LB footage which by itself requires very little CPU power to play back smoothly, but playing back that many streams should push the CPU and not be sluggish, correct?  The footage is on a fast NVME drive, so there's no bottlenecking happening from drive throughput to hold back the CPU.

In contrast, Avid is properly utilizing the CPU with HR footage in normal (non-grouped) clips for me.  I just dropped a 4K 60 fps ProRes 422 clip in a timeline, stacked it up 4 times, added a 3D warp to all layers, and *bam*, CPU immediately shoots up to 90%+ usage (all 32 threads just about pegged) and the 60 fps playback is flawless and there's zero delay in scrubbing/navigating or setting in/out points.

Is this a matter of Avid not utilizing resources as it should?  Should quat/9 split multicam playback even with low-res DNxHR LB footage be using more CPU to playback, scrub, and navigate more smoothly, or am I barking up the wrong tree?

Hey, 

Let me forward this thread on.

Philip Kapadia:

Let me forward this thread on.

That has been done many times. But maybe Avid will listen to you. 

I posted this 3 years ago now. The pattern of half-implementing a feature continues.

Andi