Usb output folder disconnected during rendering

[lata]

Hi David

Reading between the lines and I think you have an issue with the content of your project.
Can you confirm that the problem exists with all other projects, that at least will rule out the projects content.

Optimiser
I am sure we have different ideas in what that actually does, for me not a lot except choosing render properties the same as the Mpeg2 files used in the project, then you can choose a “Size Under” option that modifies the data rate.
If the Mpeg was the first video then choosing “Same as First Video Clip” would use the same template.

If there are no suitable Mpeg2 files used then Optimization is not available.
The optimiser does not alter the way the encoder renders the project.

[erdna]

I would also run Malwarebytes. You never know that there is some malware jumping aroun..

[Davidk]

Update.

All the cards on test are formated to FAT32.

There are 3 brands, and 3 classes of card I have successfully used to record video (on a camcorder) or play video files (copied from the main PC for remote use with a laptop): total of six cards, to be run thru render testing with X7 and X6 both directly connected and thru a powered hub. 24 tests in total, now done but there were significantly longer (x8 or more) render times using the powered hub connection compared to the directly connected card reader. That really really slowed things down.

The project file used was originally created on X7, and saved from X7 as a <same name>x6.vsp file. So the project files are the same - at least no editing or variations done by me between them. Where the results show fail, that's when the usb disconnection occurred and I recorded the rendered file size at that point. In the following results, one of these cards was the one I was using to render straight to an SDHC card when this "event" first occurred and lead to the opening posts in this thread. I've shown that card in the tabulated results with a magenta background in the cells.

These are the tabulated results. Inserted into a spreadsheet and then screenshotted seemed to be the best way to present them.

Lessons I draw from this test activity:
1. avoid verbatim class 10 cards: these items had the highest render fail rates in the directly connected and hub connected parts of the test, and on both versions of VS. Of the 8 tests involving these cards, 50% failed the test when the card was disconnected (VS could not find the file was the Corel error message at the end, absolutely nothing from windows). In fact, there was only one other failure in the test group, using a powered hub and the slowest class card. I've wondered if that was incidental, but it happened.

2. if possible, avoid powered hubs when rendering to a card. Both X7 and X6 showed really dramatic increases in render times thru the hub. It took me several cycles to recognise this before I started recording the render times, so there is no stated/recorded data for card #4, but it was consistent with the others. For the directly connected card, render times of 5-6 minutes was consistent for every card that completed the render test, on both versions of VS. Connected via the hub, 35 to 65 minutes was the sort of result I recorded for those that rendered to the end meaning, the usb drive was not disconnected during the process.

Why the powered hub should create this sort of result is a mystery - the card presented to and was recognised by the computer (drive U:) in the same way whether if was viewed in explorer, or direct or via a hub when the render location was being defined in the share part of VS.

Davidk

[erdna]

In the past I used a little program https://www.dropbox.com/s/mrsn76tbs0l9b72/h2testw.exe
to test some exotic (very cheap and often fake) SDHC cards. Verbatim is a known brand, but some of my cards were "Sannisk"...

[Davidk]

Hi erdna,

The test results point to the hardware (both brand and class of card). Yes, verbatim is a recognised brand. But that hasn't stopped recognised brands from selling marginal products in the past (I still have memories of commentarieson forums mentioning brands of DVD that others suggested NOT be used . . . )

You've consistently suggested a power issue with these results/cards, and given the results I can't escape the thought that it is involved somehow. Quite possibly, as part of a "condition + condition" chain scenario, where all parts of the condition chain need to apply before it occurs. And it looks like those conditions might well include hardware and software elements. For example, card #7 is the worst performer by far on these tests, but it has been used regularly to copy (using MS exploder) mpg files, previously rendered OK and stored on a desktop HDD. Plugged into a notebook, the card played those files happily when I took the notebook elsewhere. The project file I used for this test was one of those, and that was a major reason I chose it for the test. Trevor suggested I might have a problem with that project file, but it's been rendered about 45 times now, including many times on internal HDD, with the only failures being those 5 noted in the table, so I think it is unlikely. Further, you will note that
- copying operates different to rendering even is the target folder is on the same media, and
- card #7 is the only one that failed rendering with both versions of VS when directly connected.

Apart from render times, one of the things that has jumped out at me as a result of this test is the consistency of successful render (file size) results between the VS X6 and X7 versions. 5Mb is not much, but it is consistently there, and the file created by X6 was always that much larger than the one created by X7 regardless of how the media was connected to the rendering processor. So X7 does seem to be doing something different in this process compared to X6 to give that result. Note also that most of the render failures occurred using X6. Several reasons for my observation that a software condition may be part of the chain of events. But I cannot think of any way to explore that further.

Retrospect . . .
It's occurred to me that everyone might be wondering why I got into this.
Normally, I render on a desktop to a HDD location, and then copy the result to a usable SDHC card I can take on the road with a notebook. I graduated to this approach this year because I was getting perplexing speed failures with USB memory sticks used to transfer mpg files for remote playing: they all copied Ok, but some would play (when response time of the removable media becomes time critical) fine, yet others clearly gave slow transfer results that caused VS, VLC and MS media player to pause during play while the data from the memory stick caught up. (there's other posts of mine on the forum on that topic. The only relevance here is that SDHC is faster then usb, and the HP notebook I use has a card port on it). I was getting the main desktop HDD storage filled up with versions of different projects created like that, and this time (1st time I had done it this way) I decided to render direct to the SDHC card I was going to use with the notebook 'on the road', to save some space on the desktop machine. As luck would have it, card #7 was fairly new and basically empty, so it was the one. And then this event . .

I'll check out the test tool link you supplied.

Davidk

[Davidk]

Update . . . memory test on the cards failing render test

The test tool recommended by erdna was downloaded and ran (write then verify) against the free space on each of the cards that failed (disconnected) during the render tests described previously. If that had shown errors, the whole card would have been re-tested. But none of them showed any errors.

card#4 (Lexar 8gb) - 401Mb free space, no errors on test
card#6 (Verbatim 8gb) - 3389Mb free space, no errors on test
card#7 (verbatim 8gb) - 2436Mb free space, no errors on test

Davidk