LIGHTNING UK!

In response to a question posted in your previous reply, no, the MD5 isn't used to determine if it was a success verify or not. The seemingly random nature of this problem made is very difficult to pinpoint the actual cause. Unlike most bugs, this one wasn't something you could reproduce 100% of the time given a certain image file etc. Those kinds of bugs are easy to locate and fix, this one was not. I'd like to take this opportunity to apologise for being human and thank you for the time you've spent reporting the issue (for a 2nd time!), even though I was being quite rude and you could quite easily have just told me to F off!

Right, I just did some thinking from outside the box... (EDIT: long before your 5:11 post, I just didn't hit reply straight away) The problems in 2.1.0.0 were related to how I was calling the API's and so that's kinda why I figured it must still be that in 2.2.0.0 - even though I couldn't fault my new code. Well it turns out that it wasn't anything to do with the MD5 calculation stuff at all, it was simply a case of 1 thread being faster than the other - and that's something that following the code line by line (as I'd been doing) wouldn't show. The MD5 value (stored in a string) was being queried before it had finished being calculated. Because the string was empty (at that precise second), no 'Device MD5' value was being logged. This same problem could have occurred during a burn too, where the 'Image MD5' would then have been missing. I've moved some lines of code above some others and I'm confident that's fixed the problem.

No we're not shareholders, we just recommend them because it makes our lives so much easier. Once people start using them, they stop having problems. This forum is meant for the program, not for sorting out media issues. After a while (5 years), you get tired of telling people the same things over and over again - use shit discs and you'll get shit burns - you get what you pay for. As for 2.1.0.0 working and 2.2.0.0 not, the fact of the matter is, the drive controls the burn quality, not the software. I couldn't have made this one create lower quality burns if I'd tried, it just doesn't work like that. The software simply supplies the data and tells the drive which sector to write it to - and if that was wrong, the program wouldn't work for anyone, ever!

Correct, ImgBurn doesn't use sub channel data. It won't write it and it won't read it. If it's present in an image, it just gets discarded. I very much doubt that'll change to be honest - it's simply not required for the type of reading/writing ImgBurn is aimed at. I've no intention of making ImgBurn a freeware version of Alcohol 120%/BlindWrite/CloneCD! I'm sure multitrack/session support will be added one day. When I do it, it will (have to) be implemented for both mode (Read/Write). I don't often see multitrack images unless they're CD Audio - and once I start to support that, I then probably have to do mp3 burning etc - so it's quite bit of work and opens up a whole new can of worms!

Sorry fordman, I know that what I put earlier was pretty harsh! It's just that from my point of view - i.e. looking at the code, line by line - I simply cannot fault it! After the initial problems you were having in 2.1.0.0, I went through it and quickly found the issue and fixed it. Not only did I fix it, but there's not a single error that could slip past without something being logged - and you've no such log entries! So the only thing that can be failing is the API itself - even though it's still returning that it completed successfully. Hopefully you see / agree that those sorts of problems are totally out of my control. I don't write the cryptography DLLs in windows! As I said in my last post, I've now included logging for times when the API's complete successfully but when the data they return could be invalid or not quite what I'm expecting. I will email you a beta in due course and hopefully we'll get to the bottom of this problem.

It just failed the first time around. The drive reports the errors, ImgBurn simply displays them.

Verify your burns as part of the 'Write' process - i.e. check the little 'Verify' box. That way we'll know the drive can read what it just wrote.

Follow what it says in the FAQ.

How big is that VTS_02_0.IFO file?

ImgBurn is not designed to copy your commercial DVDs.

Advanced -> Restrictions -> ISO9660 / Joliet -> 'Allow Files Without Extensions'.

Well I actually never had an issue with 2.1.0.0 either. I found what I thought could be causing the issue on your PC - because the code wasn't quite 'by the book'. I changed it in 2.2.0.0 so that it is and put in error messages EVERYWHERE to do with the MD5 stuff when any API call failed. The fact that you're not getting any messages means it's not actually failing! You're getting 'Good' status return codes but must be getting odd numbers (i.e. zero (0) ) for the length of the returned data. Just for you, I've added more logging in to tell us about that too. There really is nothing I can do about it now. I'm perfectly happy with my current implementation and if it's just not working for you then I will live with that. I've looked though all the logs of the beta team and none of those have shown any issues reporting the device md5, so no, I don't agree there's an issue. Seeing as how both PC's are yours, there's every chance that whatever messed up one machine has also been put onto the other machine and messed that up too. I don't know the inner workings of the Crypt API's but I do know none of them are failing and so it's out of my hands.

Unless I'm just not getting something here, the whole idea of CDRW is that you can erase them and start again. Burning an ISO to the disc doesn't change that fact.

2.1.0.0 doesn't retrieve TOC information, that's new to v2.2.0.0 I've just tried my 107 via USB and it worked fine. (Mine isn't the XL version though, just the normal DVR-107D) Have you tried updating your enclosure's firmware? Maybe there's a bug in it.

Nope, I'm afraid not

What does it say in the statusbar when you have a blank disc in the drive? What does it say in the log? What does it say in the info panel on the right? An uninstall won't fix anything, the program doesn't work like that.

It depends what's on the DVDs. If they're commerical movies, no it won't copy them, it's not supposed to. Otherwise, yes you should be able to.

ImgBurn won't copy your protected movies, it's not meant to.

It depends on if the 'bin' is actually a multi session / track image. If it's not, ImgBurn will burn it just fine. There's no point in me making ImgBurn read something I know it won't write back again. So until (if ever) I support multiple tracks etc, it'll stay as it is.

The queue doesn't work like that. The setting in there just manipulate the options on the main screen. So unless an image specifies something different, the next image will use whatever they're currently set to.

I've had it on every single one of my burns so I'm still totally clueless as to why it doesn't work on your pc.

The 'IFO' section in IsoBuster is showing the LBA/Sizes as a player that strictly follows the IFO pointers would see it. It's not anything to do with the filesystem. All being well, the LBA in UDF and the LBA in IFO should match.

It doesn't interest me, sorry. Stick to using whatever it is that you use now.

You drive doesn't support the media and won't initialise it - or at least it didn't when you last inserted it. Eject + reinsert. Does it say the same thing? If so, yeah, it doesn't support it. You'll have to get some other discs. You should also check and see if there are any firmware updates available for your drive.

You need to include the 'Joliet' filesystem. Otherwise it'll just read ISO9660 which is (as you say), captial letters and only 8.3 format.