Rendering - a bug

[Davidk]

This is more to report an issue - a bug - than to seek a fix.

Using X5 Ultimate, the OS is windows 7 Home premium SP1, and updating a project and rendering it to an mpg state. For example, after tweaking a volume level or some spelling.

Choosing Share/create video file, the save in panel presents and because its an update, select the same directory and filename as the previous one. The user is asked whether to overwrite the old file, choose yes. The progress bar appears and things proceed . . . until about 11-15% rendered, when it stalls. Stalls mean stuck at the same progress point for an inordinately long time - up to 10 or 15 minutes when the project should completely render in 5). Happens repeatedly, and on different project files. The point of stalling (the % rendered progress bar) while variable seems to be influenced by the project size and specifically appears to be when the program seeks the disk for the first time. I found this when using explorer to look at the directory results and found an incompleted %name% file that was about 6-12Mb, depending on the project. I surmised that somehow the operation dealing with an existing filename had not returned from whatever it was doing.

Fixing it - a workaround - is simple enough. Either remove the old version first, or at the save in panel choose a different directory or a different filename (eg, the old project name_new, or just add a numeric suffix - basically anything to make the name of the file being rendered unique). In effect, this is a first time render. Once it's finished - as these did when I applied this technique - the earlier versions can be removed or deleted.

However, while the workarounds work, the "replace the old one" should also work and it doesn't.

Davidk

[lata]

Hi

I ran a few tests and cannot replicate your particular problem, so if it is a bug then its associated with your operating system and not a direct Video Studio problem.

Maybe its Windows Explorer and the option to over-write the file that is causing the problem.

As for the fix, well yes, I tend to give the new file a different name, maybe adding a number as a prefix, then I have two files, but can delete when I am sure……..

[canuck]

Like Trevor I cannot duplicate your problem and I did several tests.

Does this happen with projects that you have modified or with only one?

What do you mean by "The point of stalling (the % rendered progress bar) while variable seems to be influenced by the project size and specifically appears to be when the program seeks the disk for the first time."

[Davidk]

For Canuck . . .
The point of stall is when the % rendered progress bar just stops moving for a lengthy time. Usually its busy incrementing away, another 1 or 2% every second or so. Occasionally waits a while and then moves 20 or 30%. I call it stalled when it just stops incrementing and remains at the same progress % for 10 minutes or even longer. Compounded by the flashing HDD access light that suggests something is going on. By comparison, using a unique filename for the rendered file just rips through the task - the progress bar barely stops changing.

This event happened with several projects. I have a holiday movie project spanning 2 disks and 8 project files; and Ken B gave me some feedback on it, backchannel. In essence, voice volumes and some location specific spelling needed adjustment. Correcting those elements (on the two project files for the first disk fix) meant minor modifications to 2 separate project files, and then re-creating the .mpg video files I would later use in an updated DVD burn. There were problems with that burn a DVD action also, posted, and Trevor has suggested fixes that work.

For both of you . . .
The first time it stalled on one project file, I assumed a minor glitch, aborted the process (basically because the OS gave me an error panel saying VS had stopped working), re started VS and tried again. Same result. Repeated this using the second project file (after the edits and save) and got the same results. So, whatever was going affected more than one file, and repeated. Then I went looking using explorer for evidence, and found those %name% leftovers I mentioned.

Now, generally when the OS or explorer replaces a file, it stores the new one until complete and then erases the old. But operations like this have time outs on them and if an operation takes too long - as in, a loop or data not available, or interrupted somehow - then either the calling program stalls forever waiting (which suggests a program issue that ought to be fixed), or it recovers or itself gets its nickers in a knot because the response to the call is not what was expected. Which seems to be what has happened in this case, because there is/was evidence of a new incomplete file of some size (megabytes - not just a filename with size of 0 bytes) after the event.

As to why, and where (OS, VS or both) - ? Into the land of WAG. The OS and any timeouts being applied are standard. I make it a practice to spread the OS, application code and any data required on separate physical drives (the motherboard supports 5 SATA3 connections and that large HDD total in my profile is made up of 4 internal drives varying from 160Gb to 2Tb in size) to minimise any disk head latency delays, and generally that results in quite good - speedy - performance. It is possible that any device response is too quick this way - years ago, a new model of IBM PC had a serious issue with printing to the serial port in this mode: the new processor and faster clock went too fast for the unchanged I/O chips in it. The fix was a patch that implemented a one-time jump to yourself delay after every write to that device, to slow the processor down and give the I/O chip time to respond. But the need for that sort of thing should be long gone and I have generally not had issues with file saves using the create video file option.

That said, this was the first time I had ever tried to save in the same directory and with the same filename (because of those updates I wanted a result with the same filename, to use in a later procedure with an existing project that used those filenames). It took experimentation to even find out what was going on. This sort of result would require some deep code analysis to identify let alone fix, which takes time even if the developer group is interested, and hence the post to advise 'be aware' and what a fix was.

Davidk

[canuck]

The problem though is that you are the only one having the problem. I do a lot of "overwrites" when creating video files and I have never had any problem.

Is that rather small 160GB drive used anywhere in your project.

BTW, listing your hard drive capacity is misleading

[Davidk]

I can accept that the problem I have seems to be mine, or at least not well reported. Issues like that are usually some unique combo of events.

The small drive is currently used as the OS repository (50Gb primary and active, about 40% used), and the rest is a logical drive used as a working scratchpad.

Davidk