-
Posts
30,514 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by LIGHTNING UK!
-
Sorry, it's a glitch in 2.3.1.0. (my bad ) Gimme 12 hours and there will be a new 2.3.2.0 release.
-
Nope, I dunno what you mean. I just opened up 2 instances of ImgBurn, both pointing to the same drive and then tried to burn something with one of them. I got the 'unable to lock....' error as expected.
-
That's just not possible with how the entire thing works. ImgBurn's build mode is basic (yet highly configurable?!). It wants an existing folder structure to burn rather than you making up a pretty one in a tree as you might do in Nero. If you need that sort of functionality, you need to stick with the big boys.
-
Doesn't work in what way? I don't remember touching it! The only thing I might have done is fail silently when specific error codes are returned - but of course if it doesn't error out in the first place, that doesn't come into it.
-
Try doing the booktype stuff and setting it to DVD-ROM for when you burn DVD+R and DVD+R DL discs.
-
That's fine, I might even release it tonight!
-
"Waiting for hard disk activity to reach threshold level"
LIGHTNING UK! replied to hunginator's topic in ImgBurn Support
I have no control over the speed the drive returns to using, it'll return to whatever speed it wants to. If you watch the main buffer buring a burn, does it keep moving? It should be rock steady at 100% the whole time - hdd transfer speeds and access times far exceed those of your burner. -
Assuming you've checked for a firmware update, try cleaning the drive's lens. It appears to just be having problems burning to those discs. If all else fails, you might need to start looking for a new drive.
-
When you put the disc in your PC, does it have a VIDEO_TS folder if you look at it via 'My Computer' / 'Explorer' ? It's always helpful if you post your full log of the burn / verify. It saves us guessing lots of stuff.
-
Damnit, it was because of the new FAT16/FAT32 detection code. On some images of certain sizes, it could get the sector size wrong by matching a signature code earlier than it should have been. I guess I'll be releasing 2.3.2.0 VERY soon then!
-
Hmm ok, I've seen a similar report about an image being found as 2336 elsewhere so I will look into this asap. Thanks for reporting it.
-
I'm sure you could manage a screenshot / picture though? Or a copy of the log (Copy + Paste it) ?! Failing that, type in your native language and I'll get Google to translate it!
-
Personally I'd just extract it from the real xp bootable cd!
-
"Waiting for hard disk activity to reach threshold level"
LIGHTNING UK! replied to hunginator's topic in ImgBurn Support
Tsk, tsk, you know should know better than to put work before your forum duties -
Silly me, I didn't force the one to remove the file version, just the one to allow files without extensions It's done for the next release.
-
"Waiting for hard disk activity to reach threshold level"
LIGHTNING UK! replied to hunginator's topic in ImgBurn Support
You don't need to use the bustrace program now, I added a similar feature into ImgBurn under the Tools menu. To change the buffer, click Tools -> Settings and switch to the I/O tab. On there you'll find a 'Buffer Size' slider bar thingy. As for the firmware update, it's just like any other program. You download the firmware file and run it. It'll detect the drive and just ask you to confirm you want to update it - to which you simply press the 'Yes' button (or type the 'Y' key). You can download the update for the 112D from here: http://wwwbsc.pioneer.co.jp/cgi-bin/www1/d...12D_FW115EU.EXE (Just click 'Agree' at the bottom of the page) -
lol yes that's one way of doing it I guess! If the two markers aren't in there, none of the settings get changed because it doesn't attempt to parse the IBB file for them. I'm not sure if the way you're using it is 'by design', but so long as it works! lol
-
Yup, that's the bit i mentioned about IBB text field stuff overriding GUI (even from CLI) stuff - even if it wasn't actually specified in the IBB. That won't happen in the next version. (2.3.2.0 / 2.4.0.0 etc)
-
From an advanced users point of view (which I like to think I am ), I quite like that you can burn as much as will fit onto the disc even though it'll probably error out at the end. It's known as overburning - but not all drives support it. You're more likely to have it error out at the start if you use DVD-R/RW media (because the initial 'Reserve Track' command will fail). With DVD+R/RW media it would error out at the end (No 'Reserve Track' command is issued). I also find it useful during testing where I can burn any image I want to on a smaller disc, if say I know I only need the first part anyway.
-
OH... well it seemed to work ok on mine If you have 'Auto Calculate' enabled, try unchecking that box and try again. Also, your command line should include /BUILDMODE IMAGEFILE Oh and incase it's of any interest, if you pass an IBB as the source and do so without a path name (hence it can't be found), I've now made it so it'll look in the current directory for the file, and if it finds one, use that file. That means you can leave off the 'F:\' bit if it's in the same folder as your batch file.
-
If you want an updated DVD Shrink, just look towards Nero Recode. It's not anything I'd ever do.
-
It says unknown if all your images are ISO9660 / Joliet only. Otherwise, that info is available.
-
wow, dial up in this day and age! 5k/s would drive me totally nuts!
-
"Waiting for hard disk activity to reach threshold level"
LIGHTNING UK! replied to hunginator's topic in ImgBurn Support
Try upping the buffer to 40MB. It would seem your machine just wont sustain a constant flow of data from the hdd to the program's internal buffer. As you have a new machine, I doubt this is the case, but are your drives sharing the same cable? Whilst you're here, I'll just mention the ImgBurn 2.3.1.0 update, and firmware 1.15 for your Pioneer Remember to check for updates or you'll get left behind! -
It's fine to leave stuff out of the IBB (as well you know), but due to the way things work at startup, the IBB will normally load after some of the CLI bits (i.e. volume labels) have been shoved in the approriate boxes. I've just made a few changes (I noticed some odd goings on!) and have added additional code to the IBB loading function so that it won't erase the text from fields that weren't actually present in the IBB. It should have worked like that right from the start to be honest, my bad! Do you have an example of where the program gets nonresponsive? I obviously need to stop it ever getting to that stage! - although having said that, some of the changes I've just made might already do it.