I did testing of deleting split media/ rippling media a few months ago and found it harder to trigger in 19 and when I got freezes they resolved themselves rather than just crashing it outright. So maybe in that respect it has been partially addressed.

I could trigger crashes in Vegas by replaying media until the computer overheated and power throttled.

Hi Roger, good to hear and thanks for following up.

Just to point out this was never a crash it was always a freeze for a certain (long) length of time.

You may be right that it is partially resolved in 19. I have started working in a slightly different way to avoid it potentially happening, so haven't tested in detail for a while.

However the last brief test I did on the newly built water-cooled i912900 still displayed the issue after a few attempts. (So it has absolutely nothing to do with CPU power or heat, which we knew already of course).

btw. I only came back to this thread as someone else commented.

Anyway thanks again Roger, for the useful info. :-)

If this is not happening for you great. How long your PC has been "on" is irrelevant. Trying it 10 times is also irrelevant. Sometimes it takes 50 tries, sometimes it happens on the first try.

I was able to replicate it within all of 2 minutes. Also worth noting it did recover from the white screen of death when I came back to it 10mins later

I'm sorry, but I'll liven up this discussion as long as this bug exists.

This bug has existed since version 12. The views that there is an error in the power supply or in the poor performance of the PC are really misguided.

I asked if the problem also manifested itself with the events stored on the SSD. Can you verify that?

This bug has existed since version 12. The views that there is an error in the power supply or in the poor performance of the PC are really misguided.

Yes absolutely :-)

I asked if the problem also manifested itself with the events stored on the SSD. Can you verify that?

Yes I can verify that here, All 6 of my drives are SSD of various sizes and brands. I haven't had a normal HDD for years, (apart from for backups).

Just acknowledging that it still exists in my latest daily build of VEGAS Pro 19. It happened to me on my very first attempt on a freshly booted machine (so overheating was not an issue, as already suggested). In fact, I don't even have to do the splits to make it happen. Simply deleting an event with Ripple on while playing causes it for me, and so far I have a 100% rerpo.

We are aware of it and it's related to a larger architectual issue which makes it difficult to fix. I'm not saying we don't find it important. We simply don't have a fix at the moment and do consider other things to be higher priortity. One brute-force possibility is to not allow delete while the timeline is playing. We've hesitated to implement that because the workflow is valuable to those of you who don't run into the problem.

I realize it's frustrating for those of us who do see it. I'll bring it up with the team again to see if there are any new thoughts on the topic.

Just acknowledging that it still exists in my latest daily build of VEGAS Pro 19. It happened to me on my very first attempt on a freshly booted machine (so overheating was not an issue, as already suggested). We are aware of it and it's related to a larger architectual issue which makes it difficult to fix. I'm not saying we don't find it important. We simply don't have a fix at the moment and do consider other things to be higher priortity.

I realize that doesn't help you, and I'm sorry. I'll bring it up with the team again to see if there are any new thoughts on the topic.

Gary thank you, it helps a lot and for me, (speaking personally), your acknowledgment is worth it's weight in gold. And as mentioned before, I totally understand that there are priorities above this. :-)

Thanks, Gary.

You have acknowledged that the problem does exist.

Hi Gary, Just quick note to say thanks to you and the team for your hard work on tracking this one down and sorting it out for the current update. I am running some tests today but so far, no lockups or freezes. Will post back if anything significant to report. My best, P.

@Phil_P, thanks...sorry it took us so long to find/fix this one. Feels good to have it in the past though. Let us know if you see problems.

@Phil_P, thanks...sorry it took us so long to find/fix this one. Feels good to have it in the past though. Let us know if you see problems.

Thanks. The problem seems to be solved.

It's just that the speed at which you solved the error is interesting. You asked your colleagues and in the next update the bug is fixed. We have been waiting for repairs for 15 years. Do you have more information, why so long? Just because she wasn't a priority?

Thanks for the info.

@pierre-k

Do you have more information, why so long? Just because she wasn't a priority?

I guess it's a complicated answer. Prioritization definitely has something to do with it, as does the people who have done the prioritization historically. I haven't always been in a position to influence the priortity of the team's work, as I am now.

And developer workload is not to be underappreciated. They have a lot to think about and do.

The fix was somewhat elusive (to say the least) and different developers had gone down different paths with no luck. This time, a developer happened to see it in a different way and proposed something no one had thought of previously. Honestly, if he'd have told me that it would take him six weeks to investigate and fix it, I wouldn't have prioritized so highly it either. So much other work to do...But, he felt his fix wouldn't take long, so we agreed to try it. It worked.

He made the fix look easy. And so it was. But identifying the fix...well, his alternate thinking on the problem finally saw it differently. He is your hero, not I.

Even if it took six weeks worth of time spent fixing this, is definitely worth the 15 or so years of lost time and work due to crashes I've experienced because of this bug since the early Sony days. I couldn't even try to count all the hours, and hours, and hours (probably multiple days by now) of lost time due to this. I can edit SO much faster now knowing I don't have to worry about this anymore. It had gotten a lot better in recent years, especially after Magix came into the picture, to the point where it rarely affected me, but to know it is gone completely is awesome.

Even if it took six weeks worth of time spent fixing this, is definitely worth the 15 or so years of lost time and work due to crashes I've experienced because of this bug since the early

Vegas and Premiere became a Meme due to how often they crashed, and when I've watched videos on YouTube showing the problem, it was mostly because of highly accomplished editors editing so fast they triggered this bug. It created a self selection bias, the better the editor potentially the bigger the YT channel due to the quality of work, the more eyes on the bug, the more Vegas became synonymous with crashing.

It's great that it is fixed now, but I wonder about how many people no longer use Vegas because of the time it took to fix. 6 weeks spent on other problem bugs relating to performance and reliability would also of course be appreciated but I have a suspicion the business model doesn't reward them for these resource intensive and expensive fixes. The people that left probably aren't coming back and will never know of the fixes

Exactly fr0sty! I full agree you!

Now finally i think about the upgrade from Vegas11, lol!

Well, that's all easy to say now that everything that has been accomplished in the meantime is in place. Ha. I hear you guys. Again, I'm sorry it took so long. Prioritizing can be a real @#$! sometimes.

I have vegas 18.0 build 527 had this issue and it shows up every time I split while I am playing a video or hit delete while a video is playing. don't know if someone posted this before.

what worked for me to make this go away was to go in to Options/preferences/file I/O and put a check mark on Enable Legacy AVC decoding. now I can split while playing or hit del without lock up.