Memory usage issue - similar just like my test found.

What is the file size of your HDV footage that you want to import into VP14 ?
Ref: https://www.vegascreativesoftware.info/us/forum/vp14-bug-hdv-files-and-projects-hanging-or-crashing--103590/#ca638645

I am using Win7 Pro x64, but I'll investigate the Win10 solutions and see if they work with Win7.

Memory usage issue - similar just like my test found.

What is the file size of your HDV footage that you want to import into VP14 ?
Ref: https://www.vegascreativesoftware.info/us/forum/vp14-bug-hdv-files-and-projects-hanging-or-crashing--103590/#ca638645

The HDV file is 24gb.  I may just continue to use Vegas Pro 13 until this is remedied.

JR42, how was your HDV file created? Could you post a MediaInfo report for it (see #6 in this post: https://www.vegascreativesoftware.info/us/forum/why-does-my-rendered-video-look-bad-quality-troubleshooting-basics--103361/ )?

I have discovered that HDV files captured with VidCap cause problems, but HDV files rendered by Vegas don't, so I bet that if you re-rendered it (losslessly, with no recompression) in VP13, it would then open OK in VP14.

As I said on the other thread, if I open one of these large, problematic VidCap HDV files in VP14, the Resource Monitor does not show the "ramp" in memory usage that causes the "out of memory error" crash. So I think they are different issues, but possibly related.

This particular HDV file was copied from a Firestore drive.  The Firestore records in 2.5gb chunks, and then I joined them into a single file using MTS File Joiner.  This 24gb M2T file crashed Vegas 14 the moment I clicked on the file.  (Not even a double click, just a single click).  The file loads just fine into Vegas 13.

I had a similar issue where I was trying to load a m2v file that I had rendered using Vegas 13 into Vegas 14, where it did the same thing, it locked up when I single-clicked on the file.  But this time after about 7 or 8 minutes it finally let me load the file.  I would really rather not wait 8 minutes for the program to respond. 

Can you please post the MediaInfo, or tell us what the "Overall bit rate mode" is for the problem files. It seems "variable" might be the problem, but "constant" OK. See https://www.vegascreativesoftware.info/us/forum/vp14-bug-hdv-files-and-projects-hanging-or-crashing--103590/#ca642366

Video

ID :2064 (0x810)

Menu ID :100 (0x64)

Format :MPEG Video

Commercial name :HDV 1080i

Format version :Version 2

Format profile :Main@High 1440

Format settings, BVOP :Yes

Format settings, Matrix :Custom

Format settings, GOP :M=3, N=15

Format settings, picture structure :Frame

Codec ID :2

Maximum bit rate :25.0 Mb/s

Width :1 440 pixels

Height :1 080 pixels

Display aspect ratio :16:9

Frame rate :29.970 (30000/1001) FPS

Standard :Component

Color space :YUV

Chroma subsampling :4:2:0

Bit depth :8 bits

Scan type :Interlaced

Scan order :Top Field First

Compression mode :Lossy

Color primaries :BT.709

Transfer characteristics :BT.709

Matrix coefficients :BT.709

Audio

ID :2068 (0x814)

Menu ID :100 (0x64)

Format :MPEG Audio

Format version :Version 1

Format profile :Layer 2

Codec ID :3

Bit rate mode :Constant

Bit rate :384 kb/s

Channel(s) :2 channels

Sampling rate :48.0 kHz

Thanks but that misses the "General" and "Menu" sections of the MediaInfo report, which appear to be key in establishing a pattern of which HDV files cause problems and which don't.

Okay.

General

ID :255 (0xFF)

Complete name :D:\Crazy 8s\XHA1-Crazy\8spart1.m2t

Format :MPEG-TS

Commercial name :HDV 1080i

File size :6.70 GiB

Start time :UTC 2016-08-14 05:57:51

End time :UTC 2016-08-14 06:33:47

Overall bit rate mode :Constant

Maximum Overall bit rate :33.0 Mb/s

Encoded date :UTC 2016-08-14 05:57:51

And Menu:

Menu

ID :129 (0x81)

Menu ID :100 (0x64)

List :2064 (0x810) (MPEG Video) / 2068 (0x814) (MPEG Audio) / 2069 (0x815) () / 2065 (0x811) ()

Thanks. So that indicates that "Overall bit rate mode" is not the factor.

However your "List" in the "Menu" section perfectly matches my "bad" files, and doesn't match my "good" files. I don't know what that section means in the context of HDV files, but Magix or someone else might.

I try experiment with my 14.3GB HDV file, which originally captured using Sony HVR-MRC1K attached to HVR-Z5, copied (& automatically merged) to my PC using the provided application. Previously this file cannot be put to VP14. As told by Nick above, now I try RErender this media from HDV to HDV (no recompression required) in VP13:

(not remember what pic I upload here? - file broken?)

Then try put the RErendered media to VP14, now successfully can be put to timeline:

No waiting for unknown process... just like usual.

Set, I see that you are using Vegas 13 to "smart" render HDV. In this thread I looked at "no recompression required" rendering in Vegas:

https://www.vegascreativesoftware.info/us/forum/vegas-does-not-truly-smart-render-mpeg2--99510/?page=2

So far as HDV is concerned, I concuded:

"Conclusions

Smart rendering (no recompression of unchanged video) is sort after because it has the potential for fast rendering and no quality loss. Only Vegas 9 has a significant speed advantage, while Vegas 8 and 9 have the least unnecessary recompression, but they are not perfect. (Some unnecessary recompression may occur at the ends of a clip that has not been trimmed.) Vegas 12 and 13 are the next best at not recompressing unnecessarily. The worst effect of re-rendering is in the first two frames (in my samples).

If the first two frames are important and you intend to do multigenerational rendering, you might consider whether it would be better to force recompress. If not, then most of the video will look virtually unchanged with "no recompression necessary" rendering."

If you want true smart rendering of MPEG2 you could try VideoReDo, TMPGEnc MPEG Smart Renderer or Womble.

If you smart render HDV, up to the first and last half second or so will not get smart rendered, depending on where the cut is made, because it is outside of a full GOP (i.e. before/after the first and last I-frames in the original file).

You can improve the quality of those ends slightly by increasing the quality slider to 31 in the HDV render settings.

Interestingly, when I last tested this, HDV would also smart render to XDCAM-EX and Sony MXF, and in both cases the quality of the re-rendered ends was much better than re-rendered HDV. Also the XDCAM-EX render was much faster than HDV. That XDCAM-EX is somewhat confusing because it is actually MPEG-2 compression inside an MP4 container. Note there may still be issues with playability of XDCAM-EX and Sony MXF in some apps.

So, batch-transcoding HDV into one of those other formats in a previous version of Vegas might be an option for some, as well as just re-rendering out HDV (which "fixes" the files).

one of my great annoyances with vegas under sony was the introduction, then REMOVAL of ex1/3 xdcam mp4 smart rendering. 

has this been fixed in 14?

Just repeated that test in VP14. The HDV, MXF and XDCAM-EX renders now took all the same time, so I don't know what accounted for the huge speed difference last time round. But XDCAM-EX actually managed to losslessly render nearly all the ends of the files (i.e. no pixels moving on the video scopes) whereas the HDV and MXF didn't. All 3 play in VLC, WMP on Windows 10. I don't think there's a benefit to Sony MXF but XDCAM-EX is definitely an option. If I was still shooting HDV I think that's the format I would be archiving it to.

one of my great annoyances with vegas under sony was the introduction, then REMOVAL of ex1/3 xdcam mp4 smart rendering. 

has this been fixed in 14?

Got a sample file?

OK, found some here:http://www.dvinfo.net/forum/sony-xdcam-ex-pro-handhelds/465667-ex-1-ex-3-raw-footage.html

Ushere, if this was removed then it looks from my brief testing like it was restored in VP13 at the latest. The .mxf files in this zip from that page on dvinfo.net will smart render to the XDCAM EX "HQ 1920x1080-24p, 35 Mbps VBR" and Sony MXF "HD EX 1920x1080-24p" templates in both VP13 and VP14. It says "no recompression required" and it's fast. In reality I see very small movements in the pixels in some parts, but no visual difference. Not sure why that is.

Have you checked by differencing the rendered and original clips and looking at the vector scope? If there is no difference, you should just get a dot in the middle for all frames.

The differences I reported at the end(s) of a rendered clip were for UN-trimmed clips, so the GOPs should have been identical.

hi nick. i think this was the last point i left xdcam:

https://www.vegascreativesoftware.info/us/forum/smart-render-xdcam-ex--97284/

as it is i'm now simply rough cutting in vegas and using xavc-i as an intermediary and for archiving.

and this was another post from chris at scs:

ChrisDolan (SCS) wrote on 12/18/2013, 06:28 AM

Marco is right, disabling the EX smart render to fix the hang was my work.

It was a really tough call because it worked right ~90% of the time and hung the other ~10% of the time. What tipped my decision toward disabling was that the way it was built originally was just wrong -- we were using an AVC parser to find the MPEG-2 frames to copy over -- so that 90% success rate was mostly just due to the similarities of MPEG-2 and MPEG-4 bytestreams and a lot of luck. My fear was that the 90% success included a bunch of cases of silently corrupting the bytestream, which is even worse than a hang in my opinion.

I hope to fix it right in the future, but it's going to require tearing out all of the old code and starting over, so getting the new fix on the schedule has been tricky.

Please accept my apologies for removing a feature you relied on, but I felt it was necessary.

Have you checked by differencing the rendered and original clips and looking at the vector scope? If there is no difference, you should just get a dot in the middle for all frames.

I just eyeballed the scopes and looked for pixels moving around. I've forgotten how to do the difference-mask thing. Anyone care to remind me?

hi nick. i think this was the last point i left xdcam:

VP12 build 770 here says "no recompression required" for large parts of the render when I render XDCAM EX, and large parts of the render are indeed identical to the original footage, which goes against what it says in the thread you quoted from. Confused....

"I've forgotten how to do the difference-mask thing. Anyone care to remind me?"

Place the two clips on the timeline, one above the other. If you hover the mouse over the greenish icon to the right of the video level slider (to the left of the top clip) it will say Compositing Mode. The default mode is Source Alpha. Click on the icon and select Difference. View the scopes in Vegas 13 via View>Window>Video Scopes.