LIGHTNING UK!

I don't mind people commenting, I was just saying it's like that on purpose. I took my inspiration from my all time favourite burning program - cdrwin (from Goldenhawk), and not the newbie friendly Nero. ImgBurn's build mode was only ever supposed to be pretty basic, hence why I said if you want/need extra flexibility, stick with Nero.

Ok, you're loading 'ImgTool Burn' there, not ImgBurn. They're different programs too!

Ok so you open windbg yeah? Then File -> Open Executable. Browse to + open ImgBurn.exe Click 'Debug' -> 'Go' so it actually loads up. Then when you close ImgBurn down, it should crash as you say it does and hopefully write the error into the debugger window. Just copy + paste what it says / get a screenshot or something. EDIT: Oh, you might also want to click 'File' -> 'Symbol File Path' and enter the following: srv*C:\Windows\Symbols*http://msdl.microsoft.com/download/symbols then click ok. That'll mean the stack trace should show nice names for the functions being called.

The only thing is, multiple source files should be passed as 1 string but with a pipe (' | ') between then. The reg key thingy doesn't allow for that - hence why you'd need another program (dll) to take care of it and format it properly. For one folder / file, what you've put is ok though

Thinking about it, if you use build mode, it will attempt to add all the padding it can to all the cells in order to see if they'd be ok for a layer break cell. So if act 2 already fits on L1 ok but act 1 is smaller (and hence L0 smaller), then it'll apply padding before act 1 so that it grows to the same size as act 2. So you should really just need to find the first cell of act 2 (or maybe you've done it via chapter... I don't know that encore program) and select that. The layer break dialog box shows you the current time offset within the PGC etc so you could probably guess it from that. EDIT: lol that's pretty much what fordman just said in his first sentence!

It's probably the creation (first date) and then modified (second date) that you're seeing in the ISO9660 filesystem. Both of which are configurable on that same 'Dates' tab.

Hmm ok, maybe it's not failing then! I've just gone over the code again and have tweaked some of the API calls after having a bit of a re-think on how to interpret them! Basically I think one of them was returning 0 for the length of the hash and so it was never really calculated and put into string format - which would then be displayed in the log. Sorry but you'll just have to wait until v2.2.0.0 gets released and then test that one. (No date planned as yet)

No it's not possible. L0 must be bigger than (or equal to) L1. Why do you need to split exactly at the end of an 'act' ? I guess it's because it looks nicer! Sometimes you have to compromise though I'm afraid If the pgc has multiple cells, just use one that leaves L0 > L1. If it doesn't, you'll need to put some in so that you can!

Tools -> ISO -> Display IFO Layer Break Information. If that doesn't find one, you'll have to go back to the raw video_ts folder + files and use ImgBurn's 'Build' mode to make a decent new image.

There's a shell extension out for doing it with a video_ts folder but that's about it. I have no plans to make my own (beyond the existing right click on image files of course). The program itself keeps me busy enough without worrying about extra dll's too

ImgBurn is more simplistic and it was designed that way on purpose. The box represents the root folder, that's all you have to remember. If you want something more flexible, stick with Nero.

Rastus2, How did you get WMIDiag from my saying WinDbg?! They're two completely different programs.

bootsector, ImgBurn is already run using codeguard for a large portion of the beta stage. If there were memory errors to catch, it would find them. ....and not only do I test on XP and 2003, I test on all OS's dating back to 95! Never once have I had an error on closedown like that.

If it's not the discs its the drive / firmware. If the discs are ok and you can't update the firmware, give up and buy a new drive!

lol of course it might just be easier to enable the server service and do a test burn?! If you've got a firewall, you don't really need to worry about file and print sharing anyway. Most people have 2 levels of security, The 1st in their router (+ NAT), and then a 2nd on the actual pc.

This is not an ImgBurn problem, you'd be better off posting on a VSO forum, not here.

What you really need to do is attach a debugger to the exe and see what's going on when it crashes. Something like windbg from microsoft (it's free) would do the trick. Those addresses are not part of my exe so it's probably some extension not playing nicely.

If you're referring to this as the increased size... ... that value is in bytes, not MB. You can't just move the decimal point and call it 4.68GB, it's not. You have to divide by 1024 each time, not 1000. So it's actually 4.36 GB

You can do this yourself now anyway. The md5 of the data read from the disc is displayed in the log. Your eyes can compare the two

Using SAO/DAO recording methods, you cannot get away from DVD-R taking (seemingly) ages at the 'Synchronising Cache...' stage if you burn something Turning off the high compatibilty option in Nero forces it to use the 'Packet / Incremental' write mode. ImgBurn can do that if you tell it to. At the end of the day though, these things are done for a reason, even if you do find them annoying! For DVD+R, page 306 of the MMC5 specs (File name: mmc5r03c0.pdf) shows two different 'Close' functions for finalising the disc. One for finalising with minimal radius (the 1 GB one) and the other is for just finalising normally. That's the only one I would implement as it's the only REAL function defined for such a thing. (I have implemented this now btw)

I'll never make any of these options auto controlled by the program - same goes for bitsetting. I just don't want to tie myself down to having to update it for every model drive that comes out.

Already done both of those actually It always used to say 'finished' but then I added the padding bit and forgot to relocate the 'finished' bit to after that was done.

Hmm how weird! There must be some counter there somewhere that can monitor cpu usage or task manager wouldn't work in that respect!

Something odd must have just happened the first time and the MD5 calculation code either never got started for the 'device' buffer or it gave an error part way through - which would then disable it. It's impossible to say what caused it without catching it in the act of failing. Feel free to keep logging the extra debug stuff (when you remember) until it happens again (if it happens again). Then let me see the log and maybe between us we can work out why it's happening. Now back to the performance counters... So if you try to add a counter, do not get 'Processor' in the 'Performance Object' drop down list? (or anything like it?) I find it odd that simply disabling file + print sharing would have such an impact on performance counters!

Yup, looks like a DMA issue to me. Something's limiting it to 2x and it's not ImgBurn / user settings / the drive / the media.