Open a new project. Drop some previously unopened media on the T/L and while Vegas is building its waveform file(s) hit File>Save. That's it. Vegas is locked up and the OS has lost control. If you wait until Vegas finished building those files then you can get control back.Yup, I've seen that one ever since the first time I used Vegas. Also, both Vegas and DVDA can absolutely "take over" your computer, even if you lower the priority. Other applications just can't get a cycle to do anything at all. I wrote to development about this years and years ago, specifically about DVDA, and they did make a few modifications that kept it from totally locking up, but it is still way too easy to end up with the situation you describe.

I don't know a thing about how Vegas is designed, but I do know about Windows. The DOS box in the old Win95/98 code was preemptively multi-tasked which meant that anything going on in that DOS box could say "help" and would be immediately serviced. By contrast, in Windows, once a process gets hold of a thread, it is up to that process to be a good citizen and release the processor every now and then so other programs can get a chance to do something. If you don't write code according to the "rules," you get the kinds of things you describe.

I disagree, however, that what you are doing is in anyway like throwing the car in reverse. Quite the opposite: You are trying to do one of the main things that was the original selling point of Windows from its initial inception back in 1984 and its first commercially successful release (Windows 3.0) in May 1990, namely multi-tasking. The whole point of Windows -- and even the reason for the name itself -- is that you can have more than one thing going on at one time, and that you can switch ("window") between them.

i've had those soft lock-up's before. honestly, i find the last two pretty easy to avoid 99% of the time.

the first one I've never had in Vegas 4, 6 or 8. :) but the other two are 100% in my control. I just don't save while rendering waveforms (I hit "cancel", then save, or wait). I also just update my preview after I change the preview settings.

Not shutting down/aborting a process automatically? I'd say that's GREAT programming. A great program will do what it's told & handle anything that comes along. Vegas doesn't break, it gives priority to a certain function it's running vs another function (ie render waveforms vs save). A bad program would completely crash when it hit that roadblock instead of get through it.

vegas freezes & you can't cancel it? That's windows fault. that shows it doesn't actually have control over anything, it assumes the programs are smarter. Program goes nuts on linux tell the kernel to kill it & it's gone. it's just not vegas either: many programs AND processes refuse to due because (apparently) they have priority over the user & windows kernel.

Windows has never handled multiple programs well. Everything is expected to run by itself or have exclusive use of the CPU. The OS's job is to handle it, it's the highway police. Since Windows 3.0 (when I first used it) I've always found other OS's more stable & have more control. First it was OS/2. Then it was IRIX. Then it was linux. Each one handled things much better then windows did & never let anything have full control. OS/2 vs Windows 3.11/95 ran windows/DOS programs much better as well. go figure. :?

Ever since I went multi-core I've never even had issues with the soft-lockups. I give a process a core by itself & no issues, period. 3 instances of vegas work just fine with no lockups affecting any of the others.

I'm not saying that the two examples I gave are a problem in themselves. They've never caused me more than an annoyance nor am I saying they should shutdown automatically. They should handle the request from the OS to terminate though, it seems more like Vegas has lost control of itself.

But at times, not entirely. I've had Vegas takes many minutes to render a frame for preview, no not some hugely complex thing, just from a single m2t on one track. This as I think we're all aware doesn't happen with DV.

Bob.

There is a programme called end it all

I normally fire it up before I start anything that’s rendering intensive, it shuts all non essentials down
Also good for what you are talking about

Rory

Thanks,
I'll try that out. One problem today is it's harder to tell what should be running and what shouldn't, obviously not multiple Vegas70.exe processes but with some of the others it's hard to know.

Bob.

Windows really doesn't multitask. It does one thing, stops it, then does something else, stops it then does something else, stops it, then returns to one of the things it stopped before then stops it again and so on and so on until the four (or 10) things you clicked to happen are completed.
This process should be truthfully called "Psuedo Multitasking".
JJK

That'e because it's the male of the species.

Well, if doing something, then stopping and doing something else is not called multitasking, then just what IS multitasking?

Multitasking is doing everything at the same time like a women driver steering a vehicle with her knees, talking on the cell phone, drinking coffee, applying makeup, etc.
Windows does pieces one at a time, therefore not multitasking but it does it fast enough so you think it's multitasking. A perfect example is:
start something in windows then insert a DVD into your player and wait for about 3 seconds while windows has everything locked up tighter than a drum, and then it unlocks everything like nothing ever happened.
JJK

Well, we're into a semantic argument.

Windows definitely does multi-tasking, but as I said before, it does not do preemptive multitasking. This means that Windows gives the foreground task complete control over the computer and it is up to that task to relinquish control periodically. Windows then goes to each of the other processes and queries them to find out if they need to use the CPU. If the application (such as Vegas and DVD Architect) is poorly designed and doesn't let other applications get their turn, or if it only does so every few seconds instead of every few milliseconds, you get the problems you describe.

But, if all applications yield every few milliseconds, you can have lots of programs appear to be progressing simultaneously and, indeed, this is how things usually work with other programs.

The preemptive approach is tougher for developers, but it is generally considered "more elegant." It certainly has the one main advantage in that if a program truly needs to be serviced, it can raise its hand and get attention right away, rather than waiting for some other program to wake up and yield the CPU.

Johnmeyer:
You explain things much better than I do.
JJK

By contrast, in Windows, once a process gets hold of a thread, it is up to that process to be a good citizen and release the processor every now and then so other programs can get a chance to do something.

This is 100% incorrect, all threads in Windows (assuming you are not using Windows 98) are multitasked preemptively. In fact, it is not possible, even for a badly written application, to hog all Windows resources. If you give Vegas below normal priority it will always be pre-empted by other tasks with higher priority in Windows XP and Vista. No exceptions. Kinda.

In Windows NT based systems (2000, XP and Vista) there is only one way to write code in such a way that you can hog system resources in such a way that nothing else can run (if you run under normal or below normal priority), and that is to write a device driver (a tiny exception, and I'll get to that lastly). Vegas doesn't include, but heavily uses, device drivers.

What does this mean? Simple really, if Vegas completely hangs on your computer to the level where it will not even be killed, you probably have a bad device driver somewhere. If I was a betting man I would bet on NVIDIA, but that's just me.

Now, to the final area where Vegas can completely hang your computer. CD ROM/DVD Burner/etc. Most of these are connected to your PC on the EIDE bus. EIDE is a terrifyingly bad way of connecting anything, particularly hard drives and CD ROM/DVD ROM and other items to a computer. The reason is that in order for the OS to be able to write to such a device it needs to utilize the CPU, and since it is a disk drive, these operations take absolute highest priority. In other words, if you have a disk drive/controller with some issues, or a DVD burner that is getting long in the tooth, the first symptom will be that applications using these will hang. In fact these applications will tend to hang the entire Operating System since the disk operations have such high priority that the OS holds all tasks waiting for your task to complete.

Is there a solution? To a degree. Get a newer DVD burner with a SATA interface that supports command queueing. I am not sure such a thing exists, but take a look at newegg. Alternatively, if you can find it, you can get a SCSI DVD burner which will not exhibit these problems at all.

But again, cooperative multitaskin, as you describe, was killed with Windows 98/ME

Windows definitely does multi-tasking, but as I said before, it does not do preemptive multitasking.

BZZZT! WRONG.

This means that Windows gives the foreground task complete control over the computer and it is up to that task to relinquish control periodically. Windows

This is true for real-mode windows, and only partly. That is, it is partly true for Windows 98 and Windows ME. It is completely wrong for Windows NT/2000/XP/Vista.

The preemptive approach is tougher for developers

Absolutely not. Preemptive multitasking makes things a lot easier for the developer since he no longer has to worry about things like "relinquishing control periodically". Since Win32 is fully preemptively multitasking you can code straight ahead not worrying about anything because it is not possible for a normal application to take "full control" of Windows.

It certainly has the one main advantage in that if a program truly needs to be serviced, it can raise its hand and get attention right away

Wrong again. In a preemptive system the application can raise it's hand however much it wants, it will be serviced whenever the OS scheduler damned well pleases. That's the nature of preemptive multitasking. If you want to I can go into some detail in differences in scheduling models for various operating systems, and also for various versions of Windows. Windows 2000/XP/Vista desktop versions (Professional et al) for example uses a slightly different scheduling algorithm than does Windows 2000 server. The client versions and the server version can be configured to use matching scheduling, but out of the box they do not.

Again, what you are saying was (mostly) correct for real-mode versions of Windows, that is, those that are based on DOS. For protected mode windows versions, that is those that are based on Windows NT (2000, XP and Vista), it is way off.

Also, one minor thing, DOS was not preemptively multi-tasked in these versions of Windows, it was easy to write a DOS program that would monopolize the machine. In Windows 2000/XP/Vista there is no DOS, so the point is moot. There is a DOS emulator, and this is, as all other Windows software, fully preemptively multi-tasked.

Windows really doesn't multitask. It does one thing, stops it, then does something else, stops it then does something else, stops i

BZZZT! Wrong. Kinda. If your PC has one CPU it can, obviously, only perform one task at the time. This goes for any version of any operating system ever created. Obviously. Now, multitasking, per the usual definition, and preemptive multitasking, is exactly that, you run one piece of software for a sec, then the next, then the next, then the next. That is how all multitasking operating systems works, there is in fact no other possible way to work. If you have only one CPU.

Now, since Windows (the one you know now) was written to support multiple CPUs from the get-go, it actually also can, if there are multiple CPUs (or cores) run more than one task in true parallel. Again, same as all operating systems.

Multitasking is what Windows does, and it is what Unix does, and what Mac OSX (which is just Unix anyway) does, it is what VMS and z/OS does too. The latter in a slightly different manner however. But for that I'd have to recommend a course in OS design and implementation.

If there is only one CPU all of these can only do what is popularly called preemptive multitasking, but with multiple execution paths (more than one CPU or core) they will run tasks truly in parallel.

You explain things much better than I do.

I still wouldn't recommend listening to him though, since not a single thing he has stated so far is correct. :-)

what you are saying was (mostly) correct for real-mode versions of Windows, that is, those that are based on DOS.

Your last four posts are a bit overkill, but you are correct. Brainfreeze here. What I said applies to Win3.0/3.1/3.11 for sure. I am pretty sure it applies to Win95/98. It does NOT apply to WinNT/2000/XP and Vista.

Sorry. I screwed up.

That's okay. I allocate myself one screwup per hour, and I'm pretty consistent at meeting my quota.

This has become an interesting discussion however just to go back to the problem I (and I suspect others) are seeing, it is directly related to the contents of the file Vegas is reading. It certainly seems tied in to a driver in general and the disk one in particular as when this hangup occurs the disk light stays hard on.
What's even stranger is I've seen the problem clear itself from after a few minutes to quite a long time. I've noticed renders that should have taken a few hours blow out to days, they can get to 70% in an hour and then take a day to render the last 30%. But it's not that simple, if you watch regularly you'll see Vegas appear to stall at one point then eventually resolve the problem and move on at it's previous render speed. It may hit the same speed bump several times.

All of this agrees with the previous conclusion that the source of the problem is indeed a correctable error in a GOP. I've not seen this happen with mxf files from SxS cards or HDV from the DR60 HD recorder. Where it's now causing me trouble is from HDV from a 4 hour recording made from my EX1 to my M15 VCR. The first two hours have been just fine. All hell breaks loose at the point when the not too bright lighting guys tripped two breakers. The tape plays out just fine and was captured with no dramas, there's no unrecoverable errors and no frozen GOPs.

As I might have mentioned elsewhere though, much to my pleasant surprise Vegas 8.0b sails past the problem section without so much as a change in the fps. So I'm back to my previous workflow.
Capture in V8, render to 16:9 DV or Sony YUV, edit in V7.0d. It's a bit trickier on this project as I had a B cam for cutaways and sometimes I want to reframe the B camera shots. Also I've got an additional 3 tracks of audio from double heading the sound so doing it all at once in one project would be quicker. Can't have everything and at least the job will get done, eventually.


Bob.

Your last four posts are a bit overkill

That is why I put a small smiley at the end of it. It was intended as a humorous end of my tirade. I hope I did not offend.

Terje:
I like your explanations but my (real world) computers (4) do not do what you say. The SATA Sony Burner does not do what you say. The 4 core VS. 2 core VS single core does not do what you say. My Q6600 with 8 gig ram and Sata Burner (Vista 64 Ultimate) will freeze everything when a DVD disc is inserted. (Auto search shut off) All the other three computers (XP PRO) (1 SATA, 2 IDE burners) do the same thing. I believe in what really happens, not what is supposed to happen. And the USB mouse will also freeze in the Vista 64 system. Do you think I should replace all four computers? I wonder if "MACS" do this. But actually what bugs me the most is waiting for the operating system to turn on and off.
JJK

my (real world) computers (4) do not do what you say

Well, that depends, but read along and you'll see...

The 4 core VS. 2 core VS single core does not do what you say.

Well, they do. Each of them will run software independent of the other cores. There will still be things that can lock your computer completely though. SATA can be one of them. IDE/EIDE/ATA is definitely one of them.

will freeze everything when a DVD disc is inserted.

This is a legacy thing, and it is a combination of hardware and software. The main problem is that your SATA drive is connected via an evolution of the most terrible thing to ever hit the computer industry, the IDE/EIDE/ATA - whatever you want to call the evolution, interface. SATA tries to remedy some of this in newer versions with command queuing. This means that your drive and your interface must support command queuing though, and it also means that Vista must take queuing into consideration. I don't know that it does.

But, the main cause of lock-up delays on any PC (what you describe) is, and will forever be, the CD/DVD drive. It is horribly designed, and since PC makers and users have forever refused to adopt the much more sensible SCSI standard, it will be an issue.

believe in what really happens, not what is supposed to happen.

As I think I said above, this problem is one of the few areas where a computer will become unresponsive for a period of time. This is a hardware issue.

I wonder if "MACS" do this

Way back when, when Apple sensibly used SCSI for all of its computers, they wouldn't. Now that a Mac is just another PC, they will tend to unless Apple is very careful with the components it choses and it takes full advantage of some of the (tiny) improvements that has been made in the later versions of the SATA interface.

I am not sure I would endorse a move to SCSI. It is a fantastic technology, for sure, but the cost is horrendous. I invested heavily in SCSI eighteen years ago. I now have almost no SCSI devices, but unfortunately I have a huge collection of cables that cost $50 each !! That parallel design was (and is) incredibly expensive to implement, and having three different connectors multiplied that cost enormously.

I'm still not sure I know the answer as to why it takes 10-15 seconds for a CD/DVD device to communicate with the O/S. All my early CD drives were SCSI, and I seem to remember that they had the same problem.

Oh, and no offense taken to your comments. They were correct, and it was good that you corrected my mistake. I was involved heavily, back in 1992, with a product called the "WinPrinter" from LaserMaster (I was on their board). I did a stint as a consultant and helped them with their launch. That printer used the computer CPU rather than a CPU in the printer (which had been the norm up until them) to do the rasterization of each page. To get performance, they developed a DOS app that ran in a DOS session, and that was what rasterized the page. The fact that DOS could run preemptively (whereas Windows was "cooperative") was part of the whole "magic" of the approach, and I spent a lot of time with the engineers understanding how it worked.

So, that experience stuck in my head, and my brain freeze was not remembering that NT (which then became 2000 and eventually XP) was re-written completely and eliminated cooperative multitasking.