LIGHTNING UK!

I know laptop drives are a little slow but not even being able to keep up with 600k/s is pretty pathetic! Are you sure there's nothing else going on? Burning lots of little files, you'd be better off creating an image and then burning that, rather than doing it on-the-fly. I suspect the random access involved in reading all the little files is just killing things. If you have a lot of memory, you could of course try increasing the buffer to something more useful.

Perhaps the disc has no valid file system on it that windows can understand?

I don't know but this has nothing to do with ImgBurn - or burning in general. You'd be better off asking these types of question on a forum that deals with that type of thing - i.e. Doom9

everybody understands the term 'thingy', it's a globally recognisable word

What exactly did you do to burn the disc? Did you burn it in 'Discovery' mode? Discovery mode doesn't burn actual (real) data, it just burns zeroes!

Tools -> Settings -> Device -> Eject Tray (various modes).

1. You might want to double check that. The program will ONLY processes the close / shutdown commands if the queue is considered to be empty. Of course if you switch to another 'mode' and still have things in the queue, the queue doesn't count. The queue only counts when you're in 'Write' mode. If you find the program closes down, it wouldn't have processed any more images / copies anyway - something must be wrong with how you're manipulating the queue. 5. Ok, I might add a pause option for queued items in a future version (not the next one). Moving items up and down is already in there - although not via drag + drop which I might do one day. I personally prefer the 'Queue Again' option working the way it does rather than changing the existing one. It makes more sense to have a new entry with 0 of 1 copies burnt than it would changing the old one to read 1 of 2 copies (or whatever). I guess I could make it copy certain other attributes (drive, option to delete, write speed etc) from the existing one though. 6. Same as above, I might add a per image eject option in a future version (not the next one). 8. pause entire queue after current burn - same as above

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.