Split + Delete (While Playing) Causing Huge Hangs

Comments

pierre-k wrote on 8/6/2020, 9:49 AM
 

2. Lockup seems to last 1min:45sec every time.

That time 1:45 is really magical.

why? 😸

Phil_P wrote on 8/6/2020, 10:23 AM
 

2. Lockup seems to last 1min:45sec every time.

That time 1:45 is really magical.

why? 😸

Yes, and it seems like longer. I originally estimated 5 minutes. I am sure the developers would have an idea, if they see this.

Marco. wrote on 8/6/2020, 10:36 AM

After another dozens of tests I can confirm what Phil_P experiences. The internal preview window has by far the most impact onto this issue.

In my most simple setup the freeze usually would appear within 2 to 4 minutes.

Within my 4-track setup the freeze usually would appear within 2 to 10 seconds.

Within my 20-track setup the freeze usually would appear immediately after the first delete process.

But if I (completely) remove the preview window from the GUI (not moving anywhere else, minimize or hiding it as tab in the docking area) I have no more repro, not even in my 20-track setup.
In this 20-track setup without internal preview there is a noticeable delay of all processes and the timeline cursor doesn't move anymore (while still in playback mode) but Vegas Pro would not freeze. And once I stop the deleting I immediately can go on working (maybe after a second or two).

Marco. wrote on 8/6/2020, 10:38 AM

"I installed all the old versions and tried them immediately. I didn't make any settings."

With each update we install there are hundreds of conditions changed by the developing process. It does not need us to change a setting.

pierre-k wrote on 8/6/2020, 11:00 AM

"I installed all the old versions and tried them immediately. I didn't make any settings."

With each update we install there are hundreds of conditions changed by the developing process. It does not need us to change a setting.

I will test if there is a difference between the first version of VP12 and its last update.

PS: comparison of internal settings VP11 / 12 without success.

pierre-k wrote on 8/6/2020, 11:30 AM

The error will already appear in version VP 12 build 367.

This is where my skills end. I'm not a programmer. Just a fan.

I ask the others to try VP 11 and tell the result.

Marco. wrote on 8/6/2020, 11:41 AM

Don't waste time in digging into older VP versions. It's way too complex.

Marco. wrote on 8/6/2020, 1:18 PM

After for me the internal preview is a proper save parameter to either trigger the issue or not, I do focus now on RAM preview and render threads.

A common advice for setting best value for the number of render threads in the Vegas Pro preferences is to use twice as much as CPU cores are avaible. This differs from the default setting in many or even most cases.
I will use that recommended value (4 cores, so I'll set it to 8 render threads) and check several RAM preview settings again.

pierre-k wrote on 8/6/2020, 1:38 PM

I must have the threads set to 1. At a different value, I have occasional errors in the image during playback and rendering.

The number of threads is not the solution for a auto ripple.

Marco. wrote on 8/6/2020, 2:16 PM

I'm pretty sure we will not find a solution. I'm looking for details of the cause which would help the developers to find a solution.

Finding out how much the number of render threads and the value of the RAM Preview affects the issue could be valuable information for the developers.

pierre-k wrote on 8/6/2020, 2:33 PM

I know. I'm afraid they won't get more information from us. We can reproduce the error. We know how to reproduce it. I recommend publishing your project here with empty events with more clues for developers.

Now it's up to them.

Marco. wrote on 8/6/2020, 2:39 PM

I'll gather as much valuable information as possible to uncover the blackbox as much as possible. It's not enough yet.

pierre-k wrote on 8/6/2020, 3:20 PM

The team should look for the cause in what are the editing changes being in VP12 and VP11? It is definitely easier than finding the differences between VP11 and VP18

What are the essential features added?

Take the next lines as speculation by a layman .......
The team definitely has the code for the old versions and they definitely know what has changed in VP12 b367. Gradual removal of changes from VP12 and testing reveals the error.

It is clear to me that this is not an ideal time for developers to spend a day at work, but it is necessary. Due to this bug, some users remain in VP11. And another problem with opening folders is the proof that VP11 is the fastest of many Vegas. (please, I'm not talking about GPU support now).

I think I'm also speaking for Phil_P, that we will be happy to join the tests.
The team will change something and we will test it. Until we figure it out.

Halo Gary? You are here?
It's time to fix it! 😺

Marco. wrote on 8/6/2020, 4:10 PM

Vegas Pro 8.1 and Vegas Pro 11 were - by far - the most unstable versions ever. And from 11 to 12 there's been the most feature changes ever. There's been thousands of code changes in between done by dozens of coders, separated in different teams. Not a good base to start from 10 years later.

I prefer focus the tangible aspects.

Phil_P wrote on 8/7/2020, 1:47 AM

Hi guys,

 

Just an update. I received another email from Vegas support and they are now (finally) escalating the case to QA. They wanted another System Info file.

Anyway I sent them back this email as an update. Let us hope they are taking it seriously at last:

Hi,

If you are communicating with developers or QA please also pass on the following info.

As mentioned, I do QA testing for various audio companies, (Cannot post the names on this forum due to NDA but let's just say very prominent software DAW host companies and plugin / instrument makers in the digital audio field - in the email I named the companies).

So there are some beta versions on my machine. I would be happy to join any remote QA or beta testing for Vegas. I have been doing this for 20+ years. using JIRA and CenterPoint etc.

My machine is maintained meticulously and none of the beta software is interacting with Vegas.

A number of us are able to reproduce this issue and are chasing it down but some interaction from developers would help.

The latest repro can be made with just a blank video created within a Vegas itself (by right clicking).

Repro:

  • Create a blank video file
  • Make lots of splits
  • PLAY
  • Delete some of the split sections while cursor is moving
  • Eventually Vegas will lock up

NOTES:

  • Cursor should be on or to the right of the sections you are deleting 
  • Preview must be ON (even if you are previewing nothing)
  • Auto Ripple must be ON
  • The lock up seems to last for close to 1min:45 seconds every time.

More info:

  • We have tried changing various settings.
  • The main thing that influences this is having preview ON, if preview is closed the issue does not seem to happen.
  • Changing Video ram preview sizes etc. makes little difference but not significant.

 

I also added again a link to my video & this forum post so that hopefully they can see all the wonderful detective work you guys have done so far.

Cheers, will keep you updated.

Phil.

Phil_P wrote on 8/9/2020, 8:28 AM

Breaking News: It still happens with Preview Hidden. It just takes longer. :-( I am going to continue working with the Preview Closed altogether. What a nightmare, trying to edit quickly.

Marco. wrote on 8/9/2020, 9:02 AM

That's why I made a macro. I pre-define the frequency, then hit one button, sit back and wait what happens.

But with a delete-frequency of 1 event per second even within a 20-track project (30 minutes, 360 events) I don't have a freeze if preview is removed. I will try again, though from a certain frequency it starts being an unrealistic test case.

Btw, I also reported my findings ( which matched yours) two days ago.

Edit:
I just doubled the frequency but still no freeze if the preview is removed.

Edit:
Now even set it to delete 4 events each second (in that 20-track project) but still no freeze if preview removed.

pierre-k wrote on 8/9/2020, 6:16 PM

the silence of the team leaves me restless. I'm very happy that in this case, users are pulling on one rope and not giving up.

Phil_P wrote on 8/9/2020, 11:54 PM

the silence of the team leaves me restless. I'm very happy that in this case, users are pulling on one rope and not giving up.

Don't worry buddy. I have (as listed above), sent a full report to support. Not planning to let this rest but waiting to hear back from them. I have had a case going on for a more than a couple of weeks with support. And have been patiently going through all the usual stuff (even paid out for a new graphics card), until finally it has been escalated.

I think we have done pretty much all we can do to prove the issue exists and we must hope that the developers listen.

Even though I was careful, I got hit with it twice again yesterday while editing my latest. It is a real creativity killer.

P.

fr0sty wrote on 8/10/2020, 12:31 AM

The developers are aware of the issue and are working on it.

Systems:

Desktop

AMD Ryzen 7 1800x 8 core 16 thread at stock speed

64GB 3000mhz DDR4

Geforce RTX 3090

Windows 10

Laptop:

ASUS Zenbook Pro Duo 32GB (9980HK CPU, RTX 2060 GPU, dual 4K touch screens, main one OLED HDR)

LongIslander wrote on 8/10/2020, 4:26 AM

Ive had this issue for years to.(and was just able to reproduce it).

Subconsciously ive always just worked around it; knowing not to delete timeline media when Vegas is playing or else the program hangs! 😆

Would be great to finally have the team work on this and get it fixed!

pierre-k wrote on 8/10/2020, 5:14 AM

If they manage to fix it, don't you know what kind of champagne is best for this event? Because this will be the biggest event of the year for some users!

Phil_P wrote on 8/10/2020, 5:52 AM

If they manage to fix it, don't you know what kind of champagne is best for this event? Because this will be the biggest event of the year for some users!

:-)

Phil_P wrote on 8/15/2020, 1:10 AM

All quiet on the Western Front. I have not heard back from support now for a week.

Very disappointing after all this effort and confirmation too.

Obviously I was not expecting a fix in a week but at least a little official communication would be appreciated. :-)