I've converted many large projects and never really had any problems. I've tried to convert each file individually and that works, but when I try to convert them all, in one large project, I get this error at the very end. Exception raised in conversion Thread with message "Access violation at address 00961949 in module 'ConvertXtoDvd.exe'. Read of address 15580208" Haven't had any problems before. Can post the log if that will help.
Actually I think I solved my own problem. It was still converting other projects, which led me to believe there was some problem with one of the files, but it turns out that ConvertXToDvD just doesn't like converting things to a different hard drive. I have 2 250gig hard drive, and the hard drive with the "problem" files was a little low on free space, so I was converting them and telling it to save that conversion to my other hard drive which it didn't' like. After clearing up some space and trying to convert it to the same hard drive, the error message disappeared, and everything worked out.
Nope. I tried making the project smaller AND tried making it a DVD-9 conversion but none of those worked. But it worked the first try after changing the settings to convert it to the drive which actually had the files.
easy one.. both running instances tried to write to ram at the same time and to the same location.. probably buffering which will use a pre-allocated block of ram.. say 5 or 10mb's before shuttling the write queue either to the pagefile or the save location. It wouldn't be the hdd actually causing the stall because the OP even says the output from the two processes were going to different drives. Probably won't happen that often.. (though convertx v1 beta was notorious for it) and I can see how having a disk low on space (and likely fragged to hell too) would cause a buffer collision in this way as both running instances will be having to shuttle data in and out of the ram "cache" .. now there are a couple of ways to allocate ram caching space.. static or relative. Seems convertx is using static.. hehehe.. ain't logical deduction great? (btw.. you can make azureus do the exact same thing.. you have to alter the source code because as written it uses relative addressing not static offset.. start it twice and make sure you only have about 40mb's ram left.. then set the cache to 30mb's for each instance and let them run live for a while.. sooner or later one or both will collide and throw the same apparent fault.. oddly it's only the one which gets the error handler interrupt first which reports it and stalls.. the other carries on like nothing happened.. ram data collision.. tested on linux they will always BOTH error.. this exposes something about multitasking vs single process operating systems.. a multitasking setup will tell both they have crashed.. not just one.. and both will stop and wait for instructions instead of one carrying on and destroying the other applications cached data..) It's better not running two instances of a transcoding tool.. you don't gain any time by doing that and run a greater likelihood of buffering problems and bugged output.. stuttering and pixelations etc.. if you do.
Doesn't make a whole lot of sense to me but, like I said, problems already been solved. ...Soooo not fragged to hell either
you sure?.. my drives stay at less than 1% fragmented.. never seen a windoze drive less than 5% ever.. hehehe anyhooo.. you asked what the error was about and I tried to explain in rather simple terms.. but obviously the "modern" computer user doesn't have the slightest grasp of how programs actually do what they do under the pretty gui It was most likely just a one off bug caused by system overload and a single process operating system.. I have had a debug of convertx running in a vm.. and it does statically allocate ram cache on offset 0x00960000 and specifies 10MB's .. so either something had already dropped a bit of "protected" variable data there or the other convertx which was running was right in the middle of using it.. It's an interesting access error.. the kind of thing hackers look for when they are trying to break open proprietary systems.. like games consoles.. getting one process to overwrite anothers ram data, catching the error process handler and instead of reporting the error running arbitrary code.. many application writers rely on inbuilt operating system api handlers and don't always check they are "signed" (or because so many parts of proprietary software are hidden from plain sight by obfustication and never published) because they don't know which parts are and are not checked.. stupid really.. a bad malware backdoor risk.. I could exploit that error by grabbing the error handler and making it instead of displaying an error window run pretty much any code I wanted it to.. by simply moving the pointer location to something which is sitting quietly in ram.. maybe something that has come from an IE session online.. perhaps as simple as a cookie which is actually an embedded script.. (IE is well known for not exiting properly and leaving loads of junk in ram) and people would blame convertx for having malware when it's nothing to do with that at all really.... welcome to virus world.. teach and learn.. no worries.. it's working now If it happens again let me know the output.. it may be a sign of some ram going off..
Riiiiiiiight... "Rather simple terms" not a long winded and or bloated rant about something already solved? I believe Albert Einstein once said “If you can't explain it simply, you don't understand it well enough” Now, multiple instances? If my modern computer user brain is grasping this, That's more than one. I don't know what gave you that seemingly incorrect impression, because that's not the case, unless by merely saving the output to a different drive it caused the program to run in a separate instance.
