LIGHTNING UK!

lil man, The drive in your machine should support all formats of DVD media - as you can see from the log, it's listed as a 'DVD?RW/RAM' drive. You must just have some discs that the firmware doesn't support. Try looking for a firmware update or get some different discs.

Not really a great 'find', Chris made it

1. /DEST already has that ability... it just appears I didn't document it Use '[DISC_LABEL]'. 2. /LOG just automates saving whatever's in the log window when the program closes. If you want to see what would be put in the log in realtime, why not just open the log window?! 3. Never gonna happen in a million years! It's a GUI app that I've spent a long time writing. Why would I want people to be able to hide it and make their programs look like they're doing that hard work?

I can do the top one, no idea how to do the 2nd one though.

I think Shamus just meant, why didn't you build on the fly from the NAS rather than going via an ISO file? Also, it's a little hard to estimate progress on something you don't really know the size of - that's the whole point in parsing it!

I thought about this the other day after someone else mentioned it. Now that there are more 'modes', it's certainly worth considering. I may well end up implementing it (as an option of course!) if it's not going to be a pain in the butt and mess up the GUI too much.

Filter drivers are what all I/O has to pass through. So the path of Program -> Drive is not actually quite that simple and there's room for error. Click the Tools menu and you'll see the 'Filter Driver' tool. Copy to the clipboard and then paste the info. Then we'll be able to see what your I/O has to go through - if anything. As for the discs, we recommend Verbatim (I prefer +R ones) or Taiyo Yuden. All others are pretty useless in comparison.

Yes, Verbatims would much improve your chances of getting a decent burn. You're actually just getting a 'Write Error' at those sectors which in turn means the retry fails with that 'Invalid Address For Write' error. Don't worry about the ASPI / SPTI thing, you should have been using SPTI anyway! I get my discs from www.svp.co.uk I believe they ship to most places in europe.

Ah well reminded... I've been meaning to add a 'Defaults' button for the build mode options for some time now but I keep forgetting. There will be another new release tonight so unless you want to uninstall / reinstall (or, with the programs closed down, just delete HKCU\Software\ImgBurn), leave worrying about the defaults until later But basically, on the restrictions tab, all the checkboxes should be left unchecked and the radio buttons on their top / left most options (level 1 etc).

There's no date field (that I can see) in the structures for ElTorito. I certainly don't do anything with dates anyway. My Guess is that whatever you're extracting them with is just making a date up.

Yes, 'not stored in the file or anything' (don't take it out of context!) - I was simply saying that the actual user data of the file doesn't contain the file attributes, that's down to the filesystem - be it FAT, FAT32, NTFS etc. Reading every byte of the file and then writing that to a new file does not mean that new file will have the same attributes. The 'hidden' attribute is already supported, that's not really the issue here. It's the 'bit' for a 'system' attribute that I couldn't locate.

As I said in my previous post, the test image I built used ISO9660 + Joliet + UDF. The real Win98 bootdisk I have only read the ISO9660 filesystem on the CD, but it did so correctly (root folder + all sub folders). I don't know how you managed to get yours to display lower case filenames once booted into DOS, because mine certainly didn't. If you relax the ISO9660 spec restrictions when you build, I guess that might be possible, but then you always run the risk of the parser not working correctly. Disabling Unicode support within the UDF filesystem shouldn't have anything to with this. If the parser supports UDF it should support Unicode - and as mentioned above, DOS isn't even looking at the UDF filesystem.

Ok, I've tested it! (quick aren't I ) I read my year 2000 Win98 bootable floppy disc to an image, mounted that as a floppy disc in a vmware session. I then made an image based on a folder (with subfolders) using iso9660, joliet and udf filesystem. I mounted that as a drive and then started the virtual machine. It booted into the win98 floppy, loaded all the cdrom drivers and i was then able to browse the entire cd without any problems. btw, it seems to just read the iso9660 filesystem. Chances are that it won't allow the 8.3 restrictions to be broken so don't mess with the settings

So you've made a boot disc and used that as the image for the bootable cd yeah? You're obviously also loading the cdrom drivers and mscdex yeah or else you've no chance of reading the actual content of the CD, only the bootable image itself - which would be drive A: or B: I would guess. That aside, if you make a bootable win98 floppy disc (on a real floppy!), load all the right CD drivers, but it can't parse the filesystem on a normal (non bootable and without messing with any of the 'restrictions' stuff) disc, I guess something's not right with my filesystem. I don't know which filesystem DOS would try and read on the disc. Joliet at best I would guess. I have a similar problem here with Win95 (GUI) reading a DVD Video disc. It will see the root folder and show files / folders within it, but you can't go down to the next level. When I get a minute I'll do some testing.

If it won't write the leadin and nothing else it preventing that from happening (i.e. dodgy filter drivers etc not returning from I/O calls), your drive must not like the discs you're using.

That's probably writing in RAW mode or something (rather than TAO / SAO / Incremental). ImgBurn doesn't do that, it always uses SAO for CD. As such, I'm afraid that option doesn't apply.

I really can't account for buffer issues. The program always reads as quickly as it can from the hdd and sends the data to the drive as often as it lets it. From start to finish, the program just repeats the same 'Write (10)' command over and over and over again (with only the LBA changing), so percentages don't even come into it. Again, I can't introduce errors onto the disc, only the drive can do that. I truely have no idea why you're getting them. If I did, I'd tell you. At the moment, iffy burnproof code is my only explaination (based on what you've said about buffer issues). The IBG file (Graph Data) would have shown us any slow downs / buffer issues - it's good practice to autoexport that info (configured in the settings) and then you've always got it to refer back to.

I've no idea what it even is! I don't control the size of the LeadIn / Out, the drive does it.

Happy Birthday Spinner! (Glad we got the forum back online just in time )

The drive doesn't care about the content of your image, it could be all zeroes for all it cares. The problem here is just that it can't read back (full stop) what it just wrote. Of course, that should NEVER happen unless: 1. your media is rubbish 2. your drive is rubbish 3. the drive doesn't support the media By 'rubbish' I mean it could be rubbish in general, just a 1 off fluke or that it needs cleaning.

If someone wants to provide me with such a device, that's fine by me

Load ImgBurn Select 'Read' mode. Read disc to image file. Select 'Write' mode. Write image file to blank disc. It should all be pretty straight forward!

Yup. Obviously you have to remember that you're not backing up the attributes... they're not stored in the file or anything. It has to be something that's also available in the filesystem you then use on the optical media. From what I could find, the ISO9660 filesystem only allows for a very basic set of attributes - and by 'very basic' I mean 1 attribute - the 'hidden' one! I guess 'system' just wasn't really considered for ISO9660 as it's an optical disc and not your hdd where you'd run the OS from. It could be different for UDF if you add structures for extended file attributes, I've really can't remember and reading filesystem specs isn't my idea of a good time

8 bad sectors in a row (at least)... are you sure you can't see any visible defects on the media? There's not a different colour ring around the 2/3rds mark on the disc? Like I say, I couldn't make the program burn a sector that then couldn't be read back even if I tried! Whatever's going on there, it's out of my control. If the buffers are dying and the drive coughs and splutters, it's burnproof stuff will kick in. If that's not doing it's job properly and isn't zero loss linking as it should do, that's where your errors might be coming from.

As this is major, I'm working my arse off to get it ready (2.3.1.0) within 24hours. I've had a few other bits to sort out too