LIGHTNING UK!

You should use v2.2.0.0 and preview each cell to find out where you'd be least likely to notice the layer jump glitch.

Yeah that's fine by me.

Did you submit that bug report to them for the unicode combobox? Even if the bug isn't directly in wine, I'd be interest to see what they have to say

I'd leave the write speed at 8x and also try to get some Verbatim DVD+R discs rather than DVD-R. Your drive might perfer +R over -R.

We'd burnt hundreds of DL discs with 2.2 during the beta cycle, and as always, it's the drive that controls the 'write strategies' (and ultimately, the burn quality), not the software. The software simply sends the data - and if that didn't work, nothing would work! I did another one last night upon reading this and it's working fine.

It would actually be the opposite to that. The calc is done by the read thread, not the write one. The write thread is the one that displays it.

Either it's an unprotected disc or you played it (perhaps automatically via 'autoplay') before loading ImgBurn.

That doesn't look/sound like an ImgBurn error. Do you know how to use an 'open file' dialog box? Once you've clicked the browse button you have to select a file. If it's a 'save file' dialog box, you have to browse to a folder and then type in the name of the file you want to create (or select and existing file to overwrite). This is basic windows stuff and nothing to do with ImgBurn really.

What EXACTLY does the error message say? Can you get a screenshot? I would guess you're trying to open a file that links to another one, and that 'other' one doesn't exist (it probably has a different name).

That's excellent advice about the booktype stuff, but it's actually automatic with v2.2.0.0 for LG and Samsung drives.

Yes, you have DMA issues. Check you're using a decent 80 wire IDE cable. Check the drive is set to master / slave and that other devices are correct too. Positioning on the cable may also be important - the master drive goes at one end, slave in the middle, motherboard at the other end. Reset windows DMA using the info provided in the FAQ. Ensure the drive is correctly configured in your motherboard bios and that it sees the drive as Ultra-DMA 2 (or 4). If you have 2 drives on the same cable, try disconnecting one of them, it might be screwing things up for the other one.

lol it wasn't so much me defending my baby, as it was just not having a clue why it wasn't working! I'd already spent a while researching after the 2.1.0.0 bug report and was a bit pissed off that you said it STILL didn't work! (Please note that I wasn't pissed off at you, just in general) I hate not being able to solve problems and this one had me completely stumped because the MD5 calculation code looked spot on

Read the guides section. Burning an image is VERY simple.

I looked at this earlier on today but couldn't see anything obviously wrong. Can you copy that file to somewhere else on your hdd? The function that's having problems just reads the file into a buffer, it's tricky to say where it's going wrong! I've added a bit of debug info to the function now so I may email you a version you can perform additional testing with.

I gave up waiting for LG / Samsung to follow suite with the rest of the manufacturers! I just made it user configurable, so besides the default device id string the program supports, the others are down to the user. That gets around me actually having to keep things updated.

For what it's worth, I just burnt a file in nero to a cd-rw disc with the option to 'start multisession disc' selected and 'finalise disc' NOT selected. The resulting disc could be read ok in ImgBurn. The info panel on the right said the following: HL-DT-ST DVD-RAM GSA-H22L 1.00 (ATA) Current Profile: CD-RW Disc Information: Status: Incomplete Erasable: Yes Sessions: 2 Sectors: 17,417 Size: 35,670,016 bytes Time: 03:54:17 (MM:SS:FF) TOC Information: Session 1... -> Track 01 (Mode 1, LBA: 0 - 17416) -> LeadOut (LBA: 17419) ATIP Information: Start Time of LeadIn (MID): 97m34s23f Last Possible Start Time of LeadOut: 79m59s74f What does it say on your machine when you put this problem disc in the drive?

Your idea of sector by sector and my idea of it must be different. You can't just write the sectors and expect the drive to insert new sessions / tracks etc in the right places - it won't. The same goes for reading. Sessions and tracks are defined by additional commands - ImgBurn doesn't currently support them. If the CD only had 1 session / track but was still 'open', the 2nd (non existant) track/session must have been identified in such a way that imgburn thought it was not empty and hence it really was a multisession disc.

Your post already contained both these answers: 1. Update your drives firmware. 2. Ditch the Riteks and buy Verbatim DVD+R DL media instead.

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.