Jump to content


  • Posts

  • Joined

  • Last visited

iStrain's Achievements


Novice (1/7)



  1. Did some checking and here's what happens during my CTD: 1. usually occurs during thumbnail loading on the timeline; most often while doing things with clips, other times doing nothing in VP at all 2. the file cache.cmdt is wrecked (usually only 1k remains) Obviously, with no valid cache.cmdt, the project itself is no longer intact. A restoration of cache.cmdt from a backed up file restores the project and allows work to continue. In case anyone is wondering, cache.cmdt is found here: %appdata%\NCH Software\VideoPad Using Process Monitor, I see that VP makes extensive use of the file system. The cache (and cache.cmdt) are altered when anything is done on the timeline, and there is a massive number of write operations in a very short time span. This differs from Movie Maker, for example, which uses the registry almost exclusively, and the vast majority of those ops are read with very few writes. Which brings me to a problem with using an SSD with VP: it compromises the life of a NAND (i.e., tons of write cycles). Even with wear leveling, this is not good. It would be nice to have an option for putting cache.cmdt on a different drive (as with the option to use a different drive for the cache files themselves). There's the Macronix self-annealing tech boasting 100 million write cycles, but we aren't there yet. My Vertex-4 (MLC NAND), for example, is rated at a measly 6-10k). One short session of VP saw cache.cmdt written to thousands of times -- I probably put hundreds of P/E's on the same blocks just in experimenting with VP. Sure sure, wear leveling.. but why do this to a SSD when you don't have to? Eliminating the massive amount of file work also reduces latency and resource hogging, assuming the user has a sufficient amount of RAM which is reasonably fast. Anyway, that's how and where my CTD's are happening: mostly during thumbnail loads and the CTD occurs while cache.cmdt is being modified (so it ends up toast). As to the cause of the CTD's, most likely it's video or file system. I may look at it with Process Monitor again to try to pinpoint the exact cause.. if I decide to put my SSD through that.
  2. My BSOD's are probably driver (and/or Windows) related. If it's a hardware problem, then it's existed from day one of my build in Dec. 2012 using all new components. While certainly possible, evidence against the theory is in the 8.1 upgrade having significantly reduced the BSOD's with the same hardware (and same drivers right after the upgrade, btw). It seems MS did something to make 8.1 more agreeable to my system. Of course, it's also possible my W8 install got corrupted, which could have caused any number of issues, and a rewrite over that with 8.1 could have cleaned up some nastiness that I didn't find via the usual means (sfc, dism, etc.). You're barking up the wrong tree. I have 164GB free on the SSD and 1.79TB free on the Seagate HDD (which I later tried using for the cache; still got CTDs). There's an even bigger problem with using an SSD with VP (see next post). Other editors don't crash on me while working with the same lengthy video (i.e., same 147 clips). Most video editors are resource-hungry -- as can be seen in Task Manager's performance tab or Resource Monitor. The fact that other editors don't crash suggests VP is the culprit, and I may have discovered one reason why (see next post).
  3. Hi. Rarely do I experience BSOD with other graphics apps, including modern games (e.g., DCS sim, Battlefield), viewers (VLC, et al) and other editors. The upgrade from W8 Pro to W8.1 Pro has reduced the overall number/frequency of BSOD's, but I still get them once in a while. The BSOD reasons given by 8.1 Pro -- during VP and other app use -- vary; examples are kernel security check failure, NTFS file system, and my personal fav IRQL not less or equal. It was driving me nuts in W8 Pro. MS obviously fixed a few things in 8.1 Pro, thankfully. I'll have to play around with VP some more to see if there's a specific BSOD I tend to get more often than others while using the editor -- IIRC, CTD occured more often than BSOD. I would suspect only the cache.cmdt file is being corrupted on CTD, but that seems to be only a part of the problem. As a quick test, I changed a single character on a line in the cache.cmdt file -- the letter t was changed to r in the word "effect" in a thumbFrames.cache line. For a second test, I changed a number from 8 to 7 in one of the soundPeaks.cache lines. The result both times was exactly the same as deleting the cache folder itself: complete loss of all region (green) bars atop all clips on the timeline, the thumbnails and the waveforms, requiring a waiting period for the clips to be made fully ready for use. I'll tinker some more until I get a CTD, after which I'll run a comparison on the backup cache.cmdt vs. current cache.cmdt in Notepad++ and see if the current one got corrupted. During the tests, the bin was filled with clips quickly and my edits (splits and deletions) were not lost, whereas after CTD the bin gets filled slowly as each clip is loaded into VP and I lose all edits. I don't believe the .vpj can be the problem, because when I purposely corrupt the.vpj (by changing a char somewhere), thereby affecting its checksum, I get a prompt upon opening VP alerting me to the corruption; with CTD I get no such prompt, it just starts loading clips from scratch. Also, if I use the backed up (known good) .vpj, all edits are still lost and it loads clips from scratch. Does VP stick files somewhere else that I'm not looking for -- such as in system32 folder? Maybe the problem is a reg key corruption instead? It's Catalyst suite 13.12 (I don't generally mess around with beta drivers). I don't get CTD's with other apps. I find the VP CTD is more likely to occur after a good deal of time spent editing a huge sequence (as opposed to say 5 minutes after I open a project file with only a few clips). I presume this is due to the additional cache files and RAM burden. The same lengthy video/sequence doesn't cause CTD or BSOD in other editors. The other day I experimented with a small VP project. I loaded in 5 short clips (varying from about 30 secs to 1.5 mins) to the bin, put 'em all on the timeline and made tons of random splits, deletions, moves, undos/redos, previews (clip and sequence windows), wild cursor movement in timeline/clip/seq sections, just about everything I could throw at it (except using multiple tracks) at rapid fire pace. I engaged in this frenetic activity for about 5 minutes straight and could not force a CTD or BSOD. When I get the random CTD while working with a long sequence and then open my project again, I find it got borked and I have to start again from scratch. During all tests and normal VP use, VP was the only graphics or resource-hungry app in use. The difference is time lost, since VP has to rebuild missing cache files to make clips fully ready on the timeline (region bars). This can take a long time in large projects. If I restore the entire cache folder with the backup cache (and backed up cache.cmdt), my project gets loaded up and ready very quickly.
  4. I compared build and render times of VideoPad to Movie Maker (just as an example and because I happen to still have it installed). Project stats: video resolution: 1280x720 video length: 5 hrs 38 mins .mov clips: 147 edits: none other programs running: none VideoPad: build time (all clip progress bars on timeline green): ≈ 1 hour CPU load during output render: average 99% .mov out (H264, rate factor at default (23.0), 30fps): 1:1 movie/render ratio (every second of video takes 1 second to render) = 5 hrs 38 mins render time (or close to it) .mov out (H264, rate factor 1.0, 30fps): 1:5 render ratio (every second of video takes 5 seconds to render) = over 25hrs render .mp4 out (H264, rate factor 10.5, 30fps): 1:4 ratio (every second of video takes 4 seconds to render) = over 20hrs render Movie Maker: build time (all clips loaded and ready): ≈ 8 minutes CPU load during output render: average 85% .mp4 out (H264, bitrate 10.13Mbs, 72.44MB/min, 30fps): render time under 2hrs Verdict: VP offers extremely poor performance, even compared to the arguably cheesy Movie Maker. CPU loads combined with slow render times show how ridiculously inefficient it is. And that's too bad, because I do like the interface -- it needs a little polishing, but only a little. Were it not for the random crashes and lousy processing rates, I'd be using VP exclusively. But, there's just no way I'm going to wait a day for a render that a different program can produce in 2 hours. I'll watch the forums and version notes to see if this gets fixed.
  5. Unfortunately, even Save as to a secondary backup file under a different name and on a different drive doesn't prevent loss. VP is wiping out its own cache during the crashes, despite cache clearing options being unchecked. I'll add a heads-up to those who may overlook it: ensure any cleanup utilities (Wise Disk Cleaner, et al) are not configured to delete the VP cache files. This isn't the problem in my case, just thought I'd mention it. Unfortunately, I'm getting no prompt upon reopening VP that offers to report the crashes. edit: I'm periodically backing up the cache (local>temp folder) and will see whether restoring that folder after the next crash prevents loss of work. I'm also backing up the vpj file, but that didn't seem to have been affected by the crashes (i.e., it retained the list of clips for the bin). Backing up thousands of files (it's a lengthy video) is quite the pain -- and it may not even work -- so I hope the crashing can be resolved.
  6. I grabbed this program the other day to try it out and, although I like the interface and the fact that it lets me directly edit my camera's .mov files, it's at present ultimately worthless for me because of the random crashes that trash my project files. I worked for hours recently on a sequence of videos and VP worked well until suddenly and for no apparent reason, it crashed to desktop. When I reopened VP and loaded in the auto-saved project, it was toast and VP proceeded to import all the clips again (s-l-o-w) and I lost my previously saved edits; it was as if I had begun an entirely new project. It did this several times, crashing randomly. A few times, it reloaded the auto-saved project file, the clips loaded up jiffy quick and the sequence/timeline was quickly filled with processed clips (all green progress bars full) and my edits right where they should be. However, several times I had to start over from scratch because the project file was apparently corrupted during the crash. This suggests the crashes are occurring during auto-save. My drivers and W8.1 are up to date. I have no other relevant/graphic resources running, only VP when this occurs. Sometimes it only crashes to desktop. Other times, I get a BSOD (reason given varies) and a reboot. I don't get crashes with other editors I've tried -- problem is that they either don't allow me to edit .mov's properly or I don't care for the interface (e.g., Movie Maker). I did a forum search and didn't see where this is a commonly-reported bug. Does VP just not like my particular machine? System specs: AMD A10-5800K (no secondary GPU) ASRock FM2A85X Extreme6 mobo (on-board audio only) 8GB Crucial Ballistix Elite DDR3 C:\ drive: OCZ Vertex-4 256GB Seagate 3TB Seagate 320GB non-RAID Windows 8.1 Pro
  • Create New...