LIGHTNING UK!

Thanks. I know we all like to flame and make a stand, but it's gotta end sometime - right? Anyway, I think the original purpose of this thread has been dealt with so I'll close it.

Deleting the IDE controller and rebooting will fix your DMA problem. That'll then fix your speed issues too (as they're one in the same thing). It's pretty simple if you read + try it at the same time. To read it without doing it might make it seem difficult.

I'm going to assume you were typing that as I typed (and posted) my last reply MJ

ConvertXtoDVD is a good one, can't be sure if it'll read asf files though. http://www.vso-software.fr/

It's not really a burning apps job I don't think. I've added support for reading that info - for volume label purposes - but I think that's about as far as I'd go. Sorry

Pllllllleeeease don't turn this into another flame thread, I'm bored of them! Talk technical or don't talk at all please. If you reply, they'll relpy - and vice versa. So just don't!

First things first, update to the latest KS0B firmware... http://forum.rpc1.org/dl_firmware.php?download_id=2056 ...then try again. If it still fails, read the following! The thing with bad media is that you never know how close to failing the ones that 'worked' were. It's easy to go between working / not working several times when going through a spindle of cheapo discs. If you look at the log, it's taken your drive 2 minutes to burn 1690 sectors when it should have burnt closer to a million! So basically your drive is having real trouble with that media and it certainly wouldn't hurt to at least give something else a try. You only need to buy 25 or whatever, so you're looking at spending ?7 odd. Get some Verbatim MMC dye discs or some Taiyo Yuden ones. If you still get the same error with those, THEN you can start messing around with the million other things it may / may not be.

Avoid CMC MAG media. Use Verbatim MMC dye discs or Taiyo Yuden ones.

Nope, scrap that, I see now the LCISOCreator just does a sector by sector read of the disc. That's different to actually building a new filesystem. The size of the ISO should match (exactly) the size of the original disc.

Defen, That LCISOCreator might just do things slightly differently, or might miss a filesystem descriptor here and there. That's not to say the filesystem would then be invalid, just maybe not as compliant as it could be.

No, it will always prompt. Each time you click that calc/build button it creates a whole new instance of the 'ImageBuilder' class and so it has to be told how to be configured. I'm not even going to attempt to remember every little detail between instances (it's just not worth trying!) - hence it'll prompt each time so problems are limited to user selection rather that incorrect guessing on the programs part. The harder you make things to guess, the more it has to prompt - hence it's easier if you put files in VIDEO_TS folders etc like how they're supposed to be.

Hmm working through the logic, the time taken for the actual burn is the difference between the 'Writing Image...' and 'Synchronising Cache...' log entries. So I make that 6 mins, 6 seconds = 366 seconds. The image is 4,681,463,808 bytes. 4,681,463,808 / 366 = 12,790,884.72 bytes per second. 12,790,884.72 / 1024 = 12,491.09 KB/s 1x DVD write speed = 1,385 KB/s, making this ~9.0x. So give or take a little, the average speed value is actually ok. The code states that the max speed can't be lower than the average speed. For that reason, it gets set to the value of average speed - that's why they're exactly the same number (which would be rare otherwise). Looking at those figures, I honestly have no idea where the issue is right now, sorry!

1 probably came from the 'calculate' bit, the other just before the burn. It's intentional to prompt (well, do everything) twice. There is no 'same session' in ImgBurn, it's ALL the same session and you could easily have changed something between doing a calc and then pressing the 'Write' button.

It does look like the average write rate in the log is wrong. Some internal calculation may have failed and hence it's just using the one of 'max' instead.

The one in the log is averaged over 10 seconds or so, whereas the IBG one is a point sample at 100ms intervals. If you uncheck the 'Averaged' button in DIP, you might see the line start to go slightly mad. Move the 'Shift Sampled Position' sider for extra effect. That could account for the differences. If one sample misses a write of 32 sectors on both ends, the one in the middle may have 64 more. Sampling at that rate means 64 sectors is actually quite a lot and so the speeds can jump around all over the place. I've fixed the IBG upload problem now so feel free to post it. btw, do your screenshots as png file, they look much better than jpg ones.

ok, It's now being set to the value of 'creation date / time'.

Surely this is best asked at a DVD Rebuilder forum?!

How big is the boot bit it extracted? The floppy disc emulation sizes should be obvious. For other stuff, the 'custom' sectors to load is the size of the boot image / 512. I guess I should add a log entry to say what emulation type was used on the original disc if it's from a cd. Never really thought of that

It could be bad media, it could also be that laptop drives are normally pretty shitty - and it's easy to stick your fingers all over the lens. Try running a cleaning disc through it.

As far as I can remember, all dates pass through the same function - and that's the one that uses different dates depending on what you've selected in the options. Maybe I missed one - it could be a 'text' date or something, which would be different to the others, so that could explain it. I'll check the specs and see what it says regarding what's supposed to be there (once I find it of course!)

Hmm maybe I messed up when I looked at images made by other programs... I could have sworn it (Nero) didn't copy the date over for directories last time I tried it! I've added the code now (well, removed some) so that 'modified' dates are preserved for directories too.

Folder dates are not preserved, this was on purpose as I believe it's also how Nero works.

I've implemented support for adding ';1' to joliet filenames within the code now. It was easier to do that than it would be to hexedit the image file!

Your error was totally different Savage03. You were getting a 'Write Error'.

Talking about the ;1 thing, the Nero image actually has ';1' appended to ISO9660 AND Joliet filenames. God knows why they've added them to the Joliet ones, even Microsofts tool doesn't do that - and as it's their spec, I'd hope they know what they're doing with it! So maybe that's the problem, maybe your player needs the ';1' bit on Joliet filenames to or it can't find the extension? But then why would it recognise the avi ok and not the srt one? While you're testing things, try not adding an avi at all and see if it sees the srt file properly. Again, for some weird reason nero puts the srt file data before the avi file data.