LIGHTNING UK!

Arse!

You can't. When it doesn't fit, you have to shrink it. Can't help you any more than that I'm afraid, that's not what this forum is for. Google is your friend.

lol seriously, multisession is so far down the todo list that it's pretty much not even on it.

That's odd... it's quite a well known fact that SPTI is only available under and admin account. SPTI gives you total access to write what you like to the hardware. So in theory, you could easily wipe a hdd or whatever - hence why it's Admin only! That group policy option in the FAQ can get around it though. You may also have some odd driver thing that's acting as a go-between and allowing you to bypass XP's security.

It means you can only change the setting itself 500 times. After that, I believe the firmware blocks it (even this can be reset though so don't worry). Changing the setting itself is NOTHING to do with changing the booktype on the disc. The settings will stick on what you set it to and that will last for the life of the drive. In all honesty, there shouldn't really be any reason for you to change it again once you've set it to DVDROM. So all you need to do is set the DVD+R DL option to DVDROM once, then you can forget about it. The drive will then automatically set DVD+R DL media's booktype to DVDROM each and every time you burn.

There's also a post in the FAQ about a possible workaround for the SPTI/Admin thing. It worked for me once when I tried it. I'm not sure chewy's idea is quite what we're talking about. Surely that's just for the installation part, not the actual running of the apps? It would indeed be a massive bug in windows if you could change account types/permissions and yet still retain those of a previously applied security group!!! As most apps probably work on a 'computer' basis rather than per user, I would think the general admin could have installed them and they'd work. If not, I'd say they weren't written very well - i.e. if they REALLY relied on something being there in HKCU. For that kind of thing we'd tend to use group policy to push the apps out rather than having to install them manually. I guess it depends on how many machines you're working with though.

lol i ended up editing the registry, enabling the real administrator account and then logging in as that! Having to click 'yes' to everything I tried to do was driving me nuts too! On the topic of Vista (but off topic from ImgBurn): I still can't get the poxy file sharing to work how I want it though. It's weird that when you install it and create that single admin account, it then uses that for the admin account if you try to access the admin shares (c$, d$ etc). So even when you try to connect to the vista PC using 'Administrator' as the name, it uses the name you created on the Vista box. As I had no use for that account once I'd enabled Administrator, I deleted it. It could just be a generic thing but even when I recreate that account with the same password etc, I'm still denied access to the admin shares. I just wanted to have a single username / password between my machines / virtual machines and let it do pass through authentication so I didn't have to enter names + passwords each time. It works fine between xp / 2003 but vista just won't play nicely My machines aren't in a domain or it would probably work ok. If you have any thoughts on the matter I'd be happy to hear them!

SPTI allows the use of a bunch of other functions - like locking the volume so other programs don't interrupt the burn process, disabling MCN etc. I've tried to implement some of them in the others where possible... sometimes the others have their own versions of said IOCTLs. It will always default to SPTI under NT based OS's, and then ASPI under 9x. Yes, it does that because it's built in and so works for the vast majority of people. I'm glad MS decided to allow device communication under Vista (as standard/limited user) via SPTI, it will make things much easier! The other interfaces all need to be installed as an admin user, but after that they're available to any user. I guess that's the only benefit of them. I use SPTI exclusively, so that's the one that undergoes all the testing. That said, I never have reason to change the underlying I/O functions so there's no reason for anything to ever break.

Yup. When it fails to write to the hkcr branch, it'll switch to hkcu\software\classes. Either way around, it now fails silently as these issues are hardly show stoppers! Had XP have worked with SPTI under a limited account, I would no doubt have noticed it. As it didn't, I didn't bother with too much testing (if any). MS seem to allow people to use SPTI now, even as (what they now call) a standard user. That's a good think to know

Right, that's all fixed now. Cheers

ah hang on, I see the problem! You're running under a 'standard' account probably. Under XP that wasn't possible because SPTI didn't work - you could of course have used another I/O interface though I guess! I have to be honest, I don't think I've ever really tried ImgBurn as a 'standard' user - because I knew SPTI didn't work. Those errors could have always been there!

In the BUGS forum?!?!!? Please look where you're posting before posting. ImgBurn v2 can write files on-the-fly to cd /dvd. It won't do multisession though, just erase the disc and reburn the entire disc. Obviously v2 isn't out yet though! (oh and I've moved your post to 'Chat')

Sorry, I probably wasn't clear what I was asking! Is the main ImgBurn window still open when you get this error message? If so, what does it say in the statusbar at this time?

Hmm can't say as I've seen that problem myself actually. I installed Vista beta 2 (x86 version) the other day and I did find a couple of issues but that wasn't one of them. Have all the windows closed when that happens? i.e. so that's the only thing you see that says 'ImgBurn' on it.

I don't like doing things like that because you can miss stuff. If I report exactly what's being told to me by the drive, nobody has a leg to stand on - as if there's a problem, it's the drives fault! (As is the case here ) Oh and as for the 65535 Vs 65536 stuff, I actually had to double check my code when I posted my initial response. I too found it odd that it could never actually get to 100%. However, the value was/is taken from the specs and who am I to argue with them?! Also, many drives stick on 99% (FF FF) for ages. I'd rather they did that than stuck on 100%.

Samsung drives are a pain in the arse and their bitsetting commands are useless! I ordered a Samsung drive especially for implementing the bitsetting stuff that you see in the program today - trouble is, there is no way (or at least there wasn't back then) any way to find out the current setting. The whole thing was such a mess I kinda gave up on it. However, it DID work (even if there was no feedback in the 'Current Setting' field) on the drive that I'd purchased. It's quite possible Samsung have sorted out the commands now and as such, my code is now wrong. I have even less use for another samsung drive now (I already have a cupboard full of drives) so I'm very reluctant to buy another one so I can update / fix anything, sorry. Best I can do is dig out my samsung, update it's firmware and see if / how things have progressed.

Oh ok, I was under the impression the 0% lasted ages - so I thought it would have been the background part of the forum. No there is no way the 0% could stay there otherwise. If the status valid byte is not set to 0x80, the percentage is removed from the status bar and task bar. At the end of that function, it's set to 100% - so if it was ever a 'static text' problem, it would read 100%, not 0%.

This isn't a bug, DVD+RW erasing (formatting) is a 2 part process. The drive basically reports progress for both parts individually - and as you said, I report what the drive says. So you'd get a 0 - 100% (or 99%) quickly - that's the foreground part. Then the background part starts - hence it goes back to 0%. You drive must not report the status properly for background formatting, and yet it's telling ImgBurn that the 'progress' bytes are valid in the sense data it's returning. So the bug is in your firmware I'm afraid You can confirm this by pressing F8 and watching the 'Sense Area' info during an erase / format. Byte 15 will be set to 0x80 if status/progress is being reported - or at least if it SHOULD be being reported! Bytes 16 + 17 (as a WORD) are the progress, ((progress / 65536) * 100) to get the % complete value. 1) ImgBurn always closes the discs automatically. 2) Borland uses a hidden main form so you can set the taskbar caption to whatever you want (being that it's really setting the main 'hidden' window caption). You can then set the logical main form caption to whatever you want without effecting the taskbar. 3) It'll still send the speed you've selected regardless of what it is and what's supported or not. It really doesn't care! The drive handles it from there. For erasing/formatting though, this is always performed at max speed and the 'Write Speed' box isn't even looked at.

You cannot ask to enter it, you're 'chosen' !

Betas are for internal folk only I'm afraid. Hope to pass another one out to them all some time today/tomorrow. After that, it just whenever we're happy it's almost bug free!

Just letting you know, 'Copies' has now been added to the main window - and what a pain in the arse it was too! Still, it gave me a chance to rework a lot of the back end queuing code and tidy it up a bit.

Just letting you know this has been implemented now. Will be available as of the next version (v2.0.0.0)

New OS's are pretty good at hiding memory errors because all apps run in their own little memory space. Not that it's a good thing (from a programmers point of view), but you can get away with a lot more without the user ever seeing an error message. Also, the problem I experienced in Vista was due to it sending different messages (and dealing with them differently) to XP and older OS's. Even just adding the little arrows to the column headers is actually quite tricky using Borland. You'd think there'd just be a 'Add Sort Arrows' Yes/No type thing... but believe me, there's not!

It's ok, I think I found the issue anyway. It showed it's ugly head when I tried it in Vista the other day. Was all to do with those new sort arrows on the list column header!

Ignore the bit where it says 'Reason: No additional sense information', that's a bug in the program. The real error is this one: W 12:47:14 Potential 'WaitImmediateIO' Deferred Error - Write Error. and that bit in bold should be copied to where it say the 'no additional sense information' stuff. So.... yes you're getting write errors as the drive tries to finalise the disc. That's not a good sign.