LIGHTNING UK!

Yes, it's normal for the cell immediately after the layer break to be marked as 'non-seamless'. If it's not already marked as such, ImgBurn will do it automatically. You can of course change that by putting a tick in the appropriate box.

You'd get more of a glitch on PTP media than on OTP! With OTP the drive just has to switch layers, with PTP it has to switch layers and move the laser back to track 0. It's the media that determines how things are burnt and all DL media you can buy is OTP. No software can change that. Simply buffering in the player can eliminate the glitch. If you mark the cell as 'seamless', it can also help to eliminate it.

Ah ok, the camera just changes angles rather than it being an 'angle' feature on the dvd If the dvd will look better with the glitch just before the 2nd entry, put the layer break there. Compatibility should not really be an issue. Where I've quoted stuff like that, I just meant that according to the specs, a 50/50 split of data between layers should produce the most easily readable disc. That said, most drives will burn nothingness to the end of the 2nd layer so they're both equal anyway.

close your browser, clear it's cache/history thingy and then load it up again. Log into the forum then select the 'delete cookies set by this board' option. Close / reopen your browser again and login once more. Hopefully that'll have refreshed whatever was causing the problem.

I've never seen or heard of POSG06. So long as it doesn't stand for 'Piece Of Shit', you might be ok If you have a drive that supports PIPO scanning in DVDInfoPro/CdSpeed, you can test them for yourself.

Perhaps the server was in trouble at that precise moment? It's that or you have something else restricting your uploads. If all else fails, use one of those free hosting places - just as dontasciime did.

I'm pretty sure this is all covered in the FAQ Weird how 1 drives appears to be visible though and the others are not! If they'd all failed with 'Access is denied' (as I would have expected them to), it would have displayed a message about needing admin privileges to run with SPTI. That error would have then tied into what's mentioned in the FAQ much more closely.

Ah, if these two entries are the same thing (but different angles), select the first one. That was overlooked in v2.1.0.0 (i.e. a bug), it should never have shown 'other' angles as options. That's because the different angles of one scene must be on the same side of the disc - from what I've been told.

Actually, it's done like that because of how the queue works - it was an addon to existing code remember. If I had to start from scratch again, I may well do things differently. At the moment the queue is merely basic automation of program functions. Just before the 'Operation Successfully Completed' box pops up, it does the file deletion... I believe that is the correct order. The queue is processed after that and that's why things happen in the order they do. 'Bad Copies' DO count towards the 'Total Copies' the program has burnt of any given image and hence has an effect on 'Remaining Copies' too. I could have just left it without prompting the users if they want to retry failed burns for a given image, but I chose not to. If I hadn't bothered, none of this would be an issue. You have my apologies for the program prematurely deleting your image but you just hit a minor snag that I myself had never run into - I don't get 'failed' burns and I delete my stuff manually. Perhaps you should spend less time playing the typical arrogant programmer (yes, I do it too) and more time fixing all the problems you have with your setup, then this wouldn't be an issue for you either. lol I know how this writing stuff works thanks, I certainly don't need you explaining it to me! When ImgBurn refers to the 'Write Type' of SAO/DAO, it's talking about 1 field within the 'Write Parameters' mode page. I just use those names as they're copied verbatim from the MMC specs. SAO and DAO are one in the same - so far as 'write type' and that mode page are concerned. The multisession field is totally seperate.

I think this is probably just the same issue a lot of other people are having! I believe the problem is something to do with the exe compressor I use on ImgBurn.exe. I will avoid using it on the next release. Until then, I'm afraid you'll have to make do without ImgBurn

Happy Birthday DB!

Ok cool, now get us the same log but with the hdd connected internally. I should think you'd hit at least 60mb/s on it, no? I really wish someone would make an enclosure that could happily support 20x dvd burning. Mine seem to give up the ghost at anything over 13x

As it (kinda) says, pxhelp20 is part of the driver system installed by software using the 'Sonic Solutions' I/O interface. LOADS of programs use it and I see it all the time (even on my own PC's). It won't be the cause of your buffer emptying all the time. Do you have an IBG / DVDInfoPro screenshot showing what you're seeing? As I've mentioned several times before, it's normal for the buffer to empty out every so often (due to WOPC). This is especially true on NEC drives. From your previous post I'd have to say you have much bigger issues! It's certainly not the drives at fault here. I've got a cupboard full of drives and I've never had buffer issues on any of them. You're barking up the wrong tree.

The 'Device Buffer' in the Verify stage is not the same as the one in the Write stage. In Write, the device buffer is the drives internal cache - ImgBurn has no control over it. The drive will use its cache as it sees fit and it often empties when burning due to WOPC - that's what's supposed to happen. In Verify it's the programs internal buffer that's caching the data read from the drive - where the 'Image Buffer' is then caching the data read from the file. The data within these two buffer is what gets compared. As reading from the HDD should be far faster than reading from the CD/DVD drive, Verify mode's 'Device Buffer' should remain on 0% and the 'Image Buffer' should be on 100%.

If you get a BSOD you should be able to examine the memory dump in WinDbg and find which driver is causing the issue.

You thought wrong. The website clearly states it's just a continuation of DVD Decrypter's (R.I.P.) 'ISO Write' feature - nothing more. Sorry, we can't help you copy protected CDs.

1. It should already work like that. When it's done burning, the 'Close Program' and 'Shutdown Computer' options kick in. 2. See above. 3. Save queue on close is already an option in the settings. 4. It does that already 5. The option to put a job on hold could indeed be useful. Currently if I don't want to burn something, I just remove it from the queue! 6. I would expect the majority of people to either be in favour of always ejecting discs or not ejecting them. I can't see why you'd want to burn 10 different images and only have a few of them eject the disc. 7. Not likely any time soon.

Hmm I hadn't really thought about that particular situation/issue DoIt. All it does before deleting the image is: 1. Check the last burn was successful. 2. Check there are no other queued burns that need the image. It doesn't take into account failed burns within a multi copy burn that you may or may not want to retry. The image deletion code is in a different part of the program (and it's run first) to the bit that asks if you want to retry failed burns. So it's not a case of it failing to check properly, just at the time when it does check, so far as the program is concerned, the image is finished with. SAO is the naming scheme for CD, for DVD it's DAO. That's just what the MMC specs say. They're the same thing in reality.

ImgBurn doesn't really 'copy' anything, it's just a burning tool - hence the name!

It's probably copy protected, in which case, ImgBurn cannot help you.

No, the device buffer should always work. It's updated about 4 or 5 times per second and will always display the value returned by the drive.

Try burning with some better quality disc - i.e. Verbatim (MCC dye) or Taiyo Yuden. Your log shows the drive is having real trouble burning as it's taking 4 minutes for the 'abort' to kick in - and that's only happening because the drive is timing out (perhaps where you say you're unplugging it?) USB is never as reliable as IDE etc but internal laptop drives are normally awful... tough situation to be in!

Yes, the next version supports unicode. That should cover everything you've said / asked!

Well do you have a blank disc in the drive? If not, the program can't possibly be ready for burning anything. Do please remember that ImgBurn is a burning tool, nothing more.

That's a warning message, nothing more. It's just so you know that if you try to make a file thats > 4GB and save it on the D: drive, it'll fail and it'll be all your own fault!