Progress for Verifying: Parsing File System

[brit0n]

These are extracted lines from log to save you searching through the guff.... I can send the whole thing if you want (see note at end):

 

I 16:38:03 Operation Started!

I 16:38:03 Building Image Tree...

I 16:38:15 Operation Successfully Completed! - Duration: 00:00:11

I 16:38:15 Operation Started!

I 16:38:15 Writing Image...

I 16:46:25 Operation Successfully Completed! - Duration: 00:08:08

(USER DELAY)

I 17:11:39 Operation Started!

I 17:11:39 Filling Buffer... (20 MB)

I 17:32:48 Operation Successfully Completed! - Duration: 00:21:09

I 17:32:48 Cycling Tray before Verify...

W 17:32:54 Waiting for device to become ready...

I 17:33:01 Device Ready!

----------------------------------------------------------------------------------------------

SOME PROGRESS INDICATION WOULD BE NICE HERE (Parsing File System...)

Could be either "Parsing File System..... 0%" in status bar or else a progress bar.

----------------------------------------------------------------------------------------------

I 18:54:28 Operation Started!

I 18:59:05 Operation Successfully Completed! - Duration: 00:04:37

 

Delay probably caused by ISO being in CIFS on a NAS partition so there is LAN delay as well as translation of filesystem(s). However, original files were in CIFS through the LAN and ISO was saved to CIFS through the LAN and that didn't take any time at all!

 

Some time, I'll do a comparison with an identical operation but moving/copying the files from NAS to hard disk partition, build, save ISO to hard disk, burn from hard disk and then move/copy the ISO to NAS but I am reasonably certain it will be a lot faster! Still, progress indication would be good compared with either checking LAN bandwidth usage or running to another room to check the NAS device activity lights lol

 

(Thanks for great program with some very clean coding! Sometime I'll search to see whether you have posted what language you code in and what builder you use etc. If you haven't, could you?)

[Shamus_McFartfinger]

Some time, I'll do a comparison with an identical operation but moving/copying the files from NAS to hard disk partition, build, save ISO to hard disk, burn from hard disk and then move/copy the ISO to NAS but I am reasonably certain it will be a lot faster! Still, progress indication would be good compared with either checking LAN bandwidth usage or running to another room to check the NAS device activity lights lol

 

You've lost me. Why would you go through all this crap instead of building an ISO directly from the NAS unit?

 

(Thanks for great program with some very clean coding! Sometime I'll search to see whether you have posted what language you code in and what builder you use etc. If you haven't, could you?)

 

Borland.

[brit0n]

You've lost me. Why would you go through all this crap instead of building an ISO directly from the NAS unit?

OK I lost you. I DID use the NAS. The IMG file came from the NAS, the content files came from the NAS and the ISO went to the NAS. Then the burn was from the ISO which was still on the NAS.

 

Why would I try it from the PC hard disk partitions instead? Well, to see if it was all that LAN/NAS stuff which meant that ImgBurn took no less than 1 hr 21 mins 27 secs to parse the file system from Device Ready status to starting the verification! At that rate, it would be quicker to copy the whole thing to hard disk, build, burn, verify and throw the ISO back at NAS afterwards and probably save more than an hour. But without testing it or getting an explanation here that the 1hr 21mins is NOT caused by the PC to NAS to PC to NAS during the parsing. It sure as heck isn't the burner!

 

 

Anyway, my only point was to request progress status updates even during phases which others may not find longer than a matter of a few seconds if there is ANY chance of users having configurations which might last more than an hour! (Most users would have reported this as a bug wouldn't they? I mean it SEEMS as though it HANGS for that time - if it does, let me know.)

Borland.

Thanks.

[lfcrule1972]

It seems I just do it the easy way to suit my intellect !!

[LIGHTNING UK!]

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!

[brit0n]

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!

 

You've lost me. Why would you go through all this crap instead of building an ISO directly from the NAS unit?

 

It seems I just do it the easy way to suit my intellect !!

 

Well guys, considering I was making a simple suggestion for some (possibly way in the) future small improvement to this great program, it's interesting.

 

Lightning, if Shamus meant that, surely he wouldn't have put "building an ISO" which where I come from means making a file which is saved on a disk. Anyway, I explained as I thought he must want to know why.... #036;

 

lfcrule so do I. The easy way to do what I needed to do (which was to test the program to see if it could do it actually, which it can't - so far anyway, but the tests go on as with the other burning programs) was what I did: with all the files required for the build (IMG for the boot and contents files for the CD) on NAS and requiring both an ISO saved to disk and a burned CD, I built and saved the ISO from/to the NAS and burned it from there. Moving it would NOT be simpler, but I said I would do it because it TESTS my theory that it would be a LOT FASTER.

 

Any questions or are you attempting a put down job on a useful forum (i.e. being trolls)?

[LIGHTNING UK!]

We often still (or at least I do!) call it 'building an ISO' even if it's on-the-fly. 'building a disc' doesn't quite sound right. I often add the word 'directly' when i mean it goes straight to disc rather than to an image file. Oh and lets not forget it's called 'build' mode, hence 'build/building/built' gets thrown around a lot anyway.

 

In any case, I've spent some time this afternoon trying to speed up the parsing code. There was a bit of semi non-sequential reading going on and I can only guess that might be what was playing havoc with your NAS. That's not to say the changes I've made will perform miracles! An hour and a half to parse the filesystem sounds somewhat ridiculous! Over my LAN, I could probably have an ISO with a billion files in it and it wouldn't take that long!

 

Let's just wait and see if 2.3.1.0 is better for you.

[Shamus_McFartfinger]

Lightning, if Shamus meant that, surely he wouldn't have put "building an ISO" which where I come from means making a file which is saved on a disk. Anyway, I explained as I thought he must want to know why.... #036;

 

Building is building, regardless of the destination. Shall we move on or continue debating the terms we've been using for years?

 

The easy way to do what I needed to do (which was to test the program to see if it could do it actually, which it can't - so far anyway, but the tests go on as with the other burning programs) was what I did: with all the files required for the build (IMG for the boot and contents files for the CD) on NAS and requiring both an ISO saved to disk and a burned CD, I built and saved the ISO from/to the NAS and burned it from there. Moving it would NOT be simpler, but I said I would do it because it TESTS my theory that it would be a LOT FASTER.

 

I've used many NAS units in the past. Even one running NASLite on a Celeron 333. The speed wasn't great (around 6MB/sec) but it was certainly acceptable and usable.

 

Any questions or are you attempting a put down job on a useful forum (i.e. being trolls)?

 

The same might be asked of a new member jumping into a help forum and proclaiming that the software doesn't work properly. We build and burn hundreds of images before each major release. We can't test every piece of hardware but if it took 90 minutes to parse and process 8gigs of data from a network device, we'd have noticed. Given that you obviously have a problem with the way ImgBurn handles files from your NAS, how about giving us some info on the NAS in question so we can see what it is? It's not one of those Netgear SC-101 things, is it?

[brit0n]

I've used many NAS units in the past. Even one running NASLite on a Celeron 333. The speed wasn't great (around 6MB/sec) but it was certainly acceptable and usable.

Hence the need for me to test the difference. Sorry if you were joking and I took it wrong. Testing is usually taken as a good thing which saves the devs time provided they get accurate feedback.

 

The same might be asked of a new member jumping into a help forum and proclaiming that the software doesn't work properly.

I said that? Before you responded to a simple suggestion? Sorry if I did. But actually, if I wanted to say it didn't work, I would report a bug.

We build and burn hundreds of images before each major release. We can't test every piece of hardware but if it took 90 minutes to parse and process 8gigs of data from a network device, we'd have noticed. Given that you obviously have a problem with the way ImgBurn handles files from your NAS, how about giving us some info on the NAS in question so we can see what it is? It's not one of those Netgear SC-101 things, is it?

No it isn't. But as I said, if it IS the NAS (I haven't had time on any of the boxes to run a true comparison test without which I would be wasting YOUR time!), the test will show it. And if it does, it probably needs a different suggestion..... coming up....

 

Look, Shamus, sorry if I responded wrong. But I don't spend time typing on boards to do anything other than help - either the devs for the time they have already given ME, or to others (once I know enough about the software) to save the devs having to do EVERYTHING.

[brit0n]

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!

OK. So either I missed it if it already exists (can't find it yet, but this software of yours has a lot of combinations of options for its configuration) or the suggestion should be different. Can we build and burn OTF AND save the ISO in a single step? I have some burning software on a box here somewhere which doesn't TELL you it will, but which, when you finish an OTF burn asks if you want to save it. I assumed that if I set it up to build and burn, there would be an option before starting to save the ISO (and then supply its destination) but assume means exactly that. Apologies if I missed it. But surely if ImgBurn knew in advance that I wanted to DO that, it would save extra effort as it wouldn't need to parse the filesystem as it already built the darned image it was burning. Just a thought. I suppose the a separate verify might work for the ISO but that wouldn't need the burner and could be done in the background. Maybe I am wrong in thinking that verification would be quicker/simpler if the program knew that verification was required before the build/burn/save_ISO started.

 

We often still (or at least I do!) call it 'building an ISO' even if it's on-the-fly. 'building a disc' doesn't quite sound right. I often add the word 'directly' when i mean it goes straight to disc rather than to an image file. Oh and lets not forget it's called 'build' mode, hence 'build/building/built' gets thrown around a lot anyway.

Oh well, language and semantics. Like the age-old question "does compile mean build and save/burn or just build?". Compilation used to mean getting the stuff together which actually meant you didn't even NEED a CD/DVD drive, let alone a burner or any software to do it. Which is probably why we use build so much.

 

In any case, I seem to have had one of those moments last night some time. Sorry and delete any posts that need deleting. I am working so many different types of forums, I am probably not getting the level right.

 

There was a bit of semi non-sequential reading going on and I can only guess that might be what was playing havoc with your NAS. That's not to say the changes I've made will perform miracles! An hour and a half to parse the filesystem sounds somewhat ridiculous! Over my LAN, I could probably have an ISO with a billion files in it and it wouldn't take that long!

 

Let's just wait and see if 2.3.1.0 is better for you.

OK. I'm about to run the comparison test as one of the boxes is just about to finish some bench-tests on something else so if I can stay awake, I'll try it and then use the same box/build for 2.3.1.0 and see what the difference is.

 

If there is anything useful out of either of them, I'll provide the technical stuff that might help you. I'm not impressed with NAS drives compared with an old box doing nothing but storage, but they are cheap which might explain it lol

[LIGHTNING UK!]

Yes, when in 'Build' mode, simply switch the 'Output' to either 'Image File' or 'Device'.

 

There's also a little button for it just under the 'Destination' box.

 

If you 'Build' to a file and then 'Write' to a disc, the two processes are completely different/separate and that's why it parses the file system of the image when the 'Verify' starts.

 

If you 'Build' direct to a disc, the 'Verify' stage will use the info that's already in memory for the file system data.

[Shamus_McFartfinger]

Testing is usually taken as a good thing which saves the devs time provided they get accurate feedback.

 

Testing, as you'd imagine from Lightnings' perpective, is often hit and miss. What works fine with some hardware will fall over on others. What works fine with XP dies on 98.... etc.. etc... A report about buggy s/ware when it seems (to us, at least) that there's a problem with the hardware used is a sure way to get up the nose of pretty much everyone here. In either case, I'm happy just to let the subject drop and die a lingering death so we can get on with finding the cause of the problem. Agreed?

 

No it isn't. But as I said, if it IS the NAS (I haven't had time on any of the boxes to run a true comparison test without which I would be wasting YOUR time!), the test will show it. And if it does, it probably needs a different suggestion..... coming up....

 

A comparison test isn't wasting our time. *WE* want to know where the problem lies. I'm sure Lightning_UK! (as resident Great Poobah ) is curious also. The latest beta (which I haven't played with yet) makes some changes that I don't pretend to understand with the way files are treated which will, apparently, speed things up a bit.

 

Look, Shamus, sorry if I responded wrong. But I don't spend time typing on boards to do anything other than help - either the devs for the time they have already given ME, or to others (once I know enough about the software) to save the devs having to do EVERYTHING.

 

That's the exact reason the rest of us leeches.... err... regulars are here.

 

 

FWIW, this is the log of a larg-ish ISO I just built for testing purposes. The source drive was a networked, crappy, 5400rpm, IDE drive on a pretty ordinary PC. Not bad for 90 minutes though.

 

 

I 22:51:12 ImgBurn Version 2.3.0.3 Beta started!

I 22:51:12 Microsoft Windows 2000 Professional (5.0, Build 2195 : Service Pack 4)

I 22:51:12 Total Physical Memory: 1,048,048 KB - Available: 597,732 KB

I 22:51:13 Initialising SPTI...

I 22:51:13 Searching for SCSI / ATAPI devices...

I 22:51:14 Found 1 DVD-ROM and 1 DVD?RW!

I 22:51:22 Operation Started!

I 22:51:22 Building Image Tree...

I 22:52:36 Calculating Totals...

I 22:52:36 Preparing Image...

I 22:53:57 Checking Path Length...

I 22:53:57 Image Size: 93,066,428,416 bytes

I 22:53:57 Image Sectors: 45,442,592

I 22:53:57 Operation Successfully Completed! - Duration: 00:02:35

I 22:54:08 Operation Started!

I 22:54:08 Building Image Tree...

I 22:55:25 Calculating Totals...

I 22:55:25 Preparing Image...

I 22:56:47 Checking Path Length...

I 22:56:47 Image Size: 93,066,428,416 bytes

I 22:56:47 Image Sectors: 45,442,592

I 22:56:51 Operation Successfully Completed! - Duration: 00:02:43

I 22:56:51 Operation Started!

I 22:56:51 Image Contents: 76,325 Files, 16,728 Folders

I 22:56:51 Image Sectors: 45,442,592

I 22:56:51 Image Size: 93,066,428,416 bytes

I 22:56:51 Image Layer Break Position: 22,721,296

I 22:56:51 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,298,496)

I 22:56:51 Image Double Layer Profile: DVD+R DL (Min L0: 0, Max L0: 2,086,912, Media Capacity: 4,173,824)

I 22:56:51 Image Volume Identifier: testicle

I 22:56:51 Image Application Identifier: IMGBURN V2.3.1.0 - THE ULTIMATE IMAGE BURNER!

I 22:56:51 Image Implementation Identifier: ImgBurn

I 22:56:51 Image File System(s): ISO9660, UDF (1.02)

I 22:56:51 Destination File: R:\testicle.iso

I 22:56:51 Destination Free Space: 778,676,097,024 bytes (760,425,876 KB) (742,603 MB) (725 GB)

I 22:56:51 Destination File System: NTFS

I 22:56:51 File Splitting: Auto

I 22:56:51 Writing Image...

I 00:29:29 Image MD5: 3d7e339d7aa7daace58e1046d9fbd494

I 00:29:29 Operation Successfully Completed! - Duration: 01:32:37

I 00:29:29 Average Write Rate: 16,355 KB/s (11.8x) - Maximum Write Rate: 33,660 KB/s (24.3x)

[dontasciime]

Thats one huge testicle.

[Shamus_McFartfinger]

It's something I've learned to live with. *cough*

[lfcrule1972]

and Mrs Shamus ??

[Shamus_McFartfinger]

I sling it over my shoulder and tell her I'm a bell ringer.

[brit0n]

I sling it over my shoulder and tell her I'm a bell ringer.

An over the shoulder boulder holster suddenly takes on a new meaning - I mean they were supposed to be at the front and there were two of them when I were a lad, ba goom.

 

(Oh, technical? I missed the log entry which refers to the verification process but never mind cos that would make the testicular size even larger.)

 

Sorry not to come back with anything useful - the temp here in Georgia just decided not to require the usual air-conditioning and I hadn't prepared for more winter so it's log-splitting time again

Edited April 7, 2007 by brit0n

[polopony]

yeah its dropped to the high sixties in West Palm Beach ,I'm thinking of burning the furniture for heat or maybe wait till tomorrow when It'll get back to about 80

[brit0n]

OK I now tried ImgBurn Version 2.3.2.0 to build an iso (very quick) and then burn a bootable CD from it. ISO built from files/boot image on a NAS partition and saved to same partition. CD written from there. Verification delay (parsing file system?) remains more than one hour (1:21:30):

 

04:21:17 Cycling Tray before Verify...

04:21:23 Waiting for device to become ready...

04:21:31 Device Ready!

05:43:01 Operation Started!

 

Obviously, the problem does NOT exist if I move the source files to a partition on a disk on the PC running ImgBurn and burn from there so that is the method I use for working builds/burns. Just thought you might like the information in case sometime in future dev, you identify a possible cause.

 

To see if the CIFS was causing the problem in v2.3.0.0, I repeated the original build/burn sequence with the source and destination files on a FAT32 partition on another PC on the LAN. I got the same kind of delay. (I haven't repeated that test with v2.3.2.0 because it is unlikely to produce different results, but sometime soon I'll try it using a NTFS partition on another box on the LAN.)

 

This is a standard peer-to-peer Windows wired 100Mbps Ethernet LAN running on TCP/IP and in all other respects it operates fine including streaming video off those NAS partitions which is unusual for this setup. For me, it isn't an issue - ImgBurn is still so far ahead of the field that moving source files/ISOs from/to the PC running the program and then moving them back afterwards isn't too high a cost although it would need slightly different storage plans for DVD burning in order to have large enough partitions in the right place to do that, but again, cost is small. I just thought you might like to know there is something odd happening here. Am I really the only one having some weird delay when I do this through the network?

 

Lightning_UK, if you want me to try something to get you more information, let me know . I don't know if there is a way to get some kind of detailed report out of that period to see what is happening - I am happy to install something to do that if you want.

Edited April 20, 2007 by brit0n

[LIGHTNING UK!]

What if you only add 1 file into Build mode for buring? Does it still takes ages to parse the filesystem during a verify?

 

How does that time change as you add more files?

 

Oh and is the EXACT text in the status bar 'Parsing File System' or does it say something in addition to that? I'd actually made 2.3.2.0 change the status a bit more depending on what it was doing.

 

The exact message 'Parsing File System' shouldn't actually be visible for all that long.

 

Just to be clear, this is with you burning + verifying an ISO file that you've already built yeah? Not one you're building on-the-fly direct to a disc?

[dontasciime]

Not sure exactly what you mean or rather which mode you used etc but I have just built a dvd movie from video_ts stored on my core2duo comp to this amd64 one with output as device pioneer 108 (amd64 comp) (on the fly writing etc) and all was well and took very little time.

 

I 18:45:22 ImgBurn Version 2.3.2.0 started!
I 18:45:22 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)
I 18:45:22 Total Physical Memory: 1,048,048 KB  -  Available: 604,808 KB
W 18:45:22 Drive C:\ (FAT32) does not support single files > 4 GB in size.
W 18:45:22 Drive D:\ (FAT32) does not support single files > 4 GB in size.
I 18:45:22 Initialising SPTI...
I 18:45:22 Searching for SCSI / ATAPI devices...
I 18:45:52 Found 1 DVD-ROM and 1 DVD?RW!
I 18:46:01 Operation Started!
I 18:46:01 Building Image Tree...
I 18:46:03 Checking Directory Depth...
I 18:46:03 Calculating Totals...
I 18:46:03 Preparing Image...
I 18:46:03 Checking Path Length...
I 18:46:03 Image Size: 3,839,983,616 bytes
I 18:46:03 Image Sectors: 1,874,992
I 18:46:06 Operation Successfully Completed! - Duration: 00:00:04
I 18:46:06 Operation Started!
I 18:46:06 Source File: -==/\/[BUILD IMAGE]\/\==-
I 18:46:06 Source File Sectors: 1,874,992 (MODE1/2048)
I 18:46:06 Source File Size: 3,839,983,616 bytes
I 18:46:06 Source File Volume Identifier: MY_TEST
I 18:46:06 Source File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 18:46:06 Source File Implementation Identifier: ImgBurn
I 18:46:06 Source File File System(s): ISO9660, UDF (1.02)
I 18:46:06 Destination Device: [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 18:46:06 Destination Media Type: DVD-R (Disc ID: MCC 02RG20) (Speeds: 4x, 6x, 8x, 12x, 16x)
I 18:46:06 Destination Media Sectors: 2,298,496
I 18:46:06 Write Mode: DVD
I 18:46:06 Write Type: DAO
I 18:46:06 Write Speed: 8x
I 18:46:06 Link Size: Auto
I 18:46:06 Test Mode: No
I 18:46:06 BURN-Proof: Enabled
I 18:46:06 Filling Buffer... (40 MB)
I 18:46:07 Writing LeadIn...
I 18:46:32 Writing Image... (LBA: 0 - 1874991)
I 18:52:41 Synchronising Cache...
I 18:52:59 Image MD5: abe1546f6a29ab9823d33bff409b6eb2
I 18:52:59 Operation Successfully Completed! - Duration: 00:06:53
I 18:52:59 Average Write Rate: 10,162 KB/s (7.3x) - Maximum Write Rate: 11,176 KB/s (8.1x)
I 18:52:59 Cycling Tray before Verify...
I 18:53:27 Device Ready!
I 18:53:27 Operation Started!
I 18:53:27 Source Device: [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 18:53:27 Source Media Type: DVD-R (Book Type: DVD-R) (Disc ID: MCC 02RG20) (Speeds: 4x, 6x, 8x, 12x, 16x)
I 18:53:27 Image File: -==/\/[BUILD IMAGE]\/\==-
I 18:53:27 Image File Sectors: 1,874,992 (MODE1/2048)
I 18:53:27 Image File Size: 3,839,983,616 bytes
I 18:53:27 Image File Volume Identifier: MY_TEST
I 18:53:27 Image File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 18:53:27 Image File Implementation Identifier: ImgBurn
I 18:53:27 Image File File System(s): ISO9660, UDF (1.02)
I 18:53:27 Verifying Sectors... (LBA: 0 - 1874991)
I 19:01:13 Device MD5: abe1546f6a29ab9823d33bff409b6eb2
I 19:01:13 Image MD5: abe1546f6a29ab9823d33bff409b6eb2
I 19:01:13 Operation Successfully Completed! - Duration: 00:07:46
I 19:01:13 Average Verify Rate: 8,047 KB/s (5.8x) - Maximum Verify Rate: 15,787 KB/s (11.4x)

 

 

This one I used build mode Video_ts on core2duo and Iso created on my amd 64 to maxtor drive

 

I 19:44:14 ImgBurn Version 2.3.2.0 started!
I 19:44:14 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)
I 19:44:14 Total Physical Memory: 1,048,048 KB  -  Available: 471,524 KB
W 19:44:14 Drive C:\ (FAT32) does not support single files > 4 GB in size.
W 19:44:14 Drive D:\ (FAT32) does not support single files > 4 GB in size.
I 19:44:14 Initialising SPTI...
I 19:44:14 Searching for SCSI / ATAPI devices...
I 19:44:14 Found 1 DVD-ROM and 1 DVD?RW!
I 19:45:03 Operation Started!
I 19:45:03 Building Image Tree...
I 19:45:04 Checking Directory Depth...
I 19:45:05 Calculating Totals...
I 19:45:05 Preparing Image...
I 19:45:05 Checking Path Length...
I 19:45:05 Image Size: 3,839,983,616 bytes
I 19:45:05 Image Sectors: 1,874,992
I 19:45:07 Operation Successfully Completed! - Duration: 00:00:04
I 19:45:07 Operation Started!
I 19:45:07 Image Contents: 8 Files, 2 Folders
I 19:45:07 Image Sectors: 1,874,992
I 19:45:07 Image Size: 3,839,983,616 bytes
I 19:45:07 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,298,496)
I 19:45:07 Image Volume Identifier: MY_TEST
I 19:45:07 Image Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 19:45:07 Image Implementation Identifier: ImgBurn
I 19:45:07 Image File System(s): ISO9660, UDF (1.02)
I 19:45:07 Destination File: L:\test_then_delete.iso
I 19:45:07 Destination Free Space: 61,814,226,944 bytes (60,365,456 KB) (58,950 MB) (57 GB)
I 19:45:07 Destination File System: NTFS
I 19:45:07 File Splitting: Auto
I 19:45:07 Writing Image...
I 19:46:27 Image MD5: 54573dd1059169f155853f149a080904
I 19:46:27 Operation Successfully Completed! - Duration: 00:01:20
I 19:46:27 Average Write Rate: 46,874 KB/s (33.8x) - Maximum Write Rate: 55,586 KB/s (40.1x)

 

 

This one controlled Via ImgBurn on AMD64 build mode / video_ts on core2duo and ISO created on same hardrive as source on core2duo from amd machine

 

 

I 19:58:10 ImgBurn Version 2.3.2.0 started!
I 19:58:10 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)
I 19:58:10 Total Physical Memory: 1,048,048 KB  -  Available: 510,828 KB
W 19:58:10 Drive C:\ (FAT32) does not support single files > 4 GB in size.
W 19:58:10 Drive D:\ (FAT32) does not support single files > 4 GB in size.
I 19:58:10 Initialising SPTI...
I 19:58:10 Searching for SCSI / ATAPI devices...
I 19:58:10 Found 1 DVD-ROM and 1 DVD?RW!
I 20:00:39 Operation Started!
I 20:00:39 Building Image Tree...
I 20:00:40 Checking Directory Depth...
I 20:00:40 Calculating Totals...
I 20:00:40 Preparing Image...
I 20:00:40 Checking Path Length...
I 20:00:40 Image Size: 3,839,983,616 bytes
I 20:00:40 Image Sectors: 1,874,992
I 20:00:42 Operation Successfully Completed! - Duration: 00:00:03
I 20:00:42 Operation Started!
I 20:00:42 Image Contents: 8 Files, 2 Folders
I 20:00:42 Image Sectors: 1,874,992
I 20:00:42 Image Size: 3,839,983,616 bytes
I 20:00:42 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,298,496)
I 20:00:42 Image Volume Identifier: MY_TEST
I 20:00:42 Image Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 20:00:42 Image Implementation Identifier: ImgBurn
I 20:00:42 Image File System(s): ISO9660, UDF (1.02)
I 20:00:42 Destination File: \\Ascii-core2-duo\shrink\my_test\cb.iso
I 20:00:42 Destination Free Space: 20,950,519,808 bytes (20,459,492 KB) (19,979 MB) (19 GB)
I 20:00:42 Destination File System: NTFS
I 20:00:42 File Splitting: Auto
I 20:00:42 Writing Image...
I 20:03:40 Image MD5: 5d87ef06a8623f8d37be49f28171bc74
I 20:03:40 Operation Successfully Completed! - Duration: 00:02:57
I 20:03:40 Average Write Rate: 21,186 KB/s (15.3x) - Maximum Write Rate: 33,075 KB/s (23.9x)

 

I'm still wondering exactly what you did and therfore trying to cover all modes etc you then mention burning the files did you urn the disc over network.

 

 

This one files stored on on core2duo comp (XP pro disc) files, build mode on AMD64 and output to device , wrote and verified

 

I did get a potential error *buffer recovery wait etc and the first time any of my computers has given this error, Either my network dragged or IMO because windows hates the source files, IE lots of small files within lots of folders etc.

 

I 20:26:05 ImgBurn Version 2.3.2.0 started!
I 20:26:05 Microsoft Windows XP Professional (5.1, Build 2600 : Service Pack 2)
I 20:26:05 Total Physical Memory: 1,048,048 KB  -  Available: 625,144 KB
W 20:26:05 Drive C:\ (FAT32) does not support single files > 4 GB in size.
W 20:26:05 Drive D:\ (FAT32) does not support single files > 4 GB in size.
I 20:26:06 Initialising SPTI...
I 20:26:06 Searching for SCSI / ATAPI devices...
I 20:26:06 Found 1 DVD-ROM and 1 DVD?RW!
I 20:26:55 Operation Started!
I 20:26:55 Building Image Tree...
I 20:27:00 Calculating Totals...
I 20:27:00 Preparing Image...
I 20:27:08 Checking Path Length...
I 20:27:08 Image Size: 492,437,504 bytes
I 20:27:08 Image Sectors: 240,448
I 20:27:09 Operation Successfully Completed! - Duration: 00:00:14
I 20:27:10 Operation Started!
I 20:27:10 Source File: -==/\/[BUILD IMAGE]\/\==-
I 20:27:10 Source File Sectors: 240,448 (MODE1/2048)
I 20:27:10 Source File Size: 492,437,504 bytes
I 20:27:10 Source File Volume Identifier: ASCII_TOOL_XP
I 20:27:10 Source File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 20:27:10 Source File Implementation Identifier: ImgBurn
I 20:27:10 Source File File System(s): ISO9660 (Bootable), UDF (1.02)
I 20:27:10 Destination Device: [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:27:10 Destination Media Type: CD-R (Disc ID: 97m26s66f) (Speeds: 4x, 10x, 16x, 24x, 32x)
I 20:27:10 Destination Media Sectors: 359,844
I 20:27:10 Write Mode: CD
I 20:27:10 Write Type: SAO
I 20:27:10 Write Speed: 16x
I 20:27:10 Test Mode: No
I 20:27:10 BURN-Proof: Enabled
I 20:27:10 Filling Buffer... (40 MB)
I 20:27:33 Writing LeadIn...
I 20:27:56 Writing Image... (LBA: 0 - 240447)
W 20:29:18 Waiting for buffers to recover...
W 20:29:33 Waiting for hard disk activity to reach threshold level...
I 20:29:34 Writing Image...
W 20:30:25 Waiting for buffers to recover...
W 20:31:29 Waiting for hard disk activity to reach threshold level...
I 20:31:30 Writing Image...
W 20:32:01 Waiting for buffers to recover...
W 20:32:24 Waiting for hard disk activity to reach threshold level...
I 20:32:25 Writing Image...
I 20:33:11 Synchronising Cache...
I 20:33:21 Image MD5: 5c80a5d2ef1d51f5fc3b1424ca20c571
I 20:33:21 Operation Successfully Completed! - Duration: 00:06:10
I 20:33:21 Average Write Rate: 1,526 KB/s (10.2x) - Maximum Write Rate: 2,535 KB/s (16.9x)
I 20:33:21 Cycling Tray before Verify...
I 20:33:45 Device Ready!
I 20:33:45 Operation Started!
I 20:33:45 Source Device: [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:33:45 Source Media Type: CD-ROM (Speeds: 4x, 10x, 16x, 24x, 32x)
I 20:33:45 Image File: -==/\/[BUILD IMAGE]\/\==-
I 20:33:45 Image File Sectors: 240,448 (MODE1/2048)
I 20:33:45 Image File Size: 492,437,504 bytes
I 20:33:45 Image File Volume Identifier: ASCII_TOOL_XP
I 20:33:45 Image File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER!
I 20:33:45 Image File Implementation Identifier: ImgBurn
I 20:33:45 Image File File System(s): ISO9660 (Bootable), UDF (1.02)
I 20:33:45 Verifying Sectors... (LBA: 0 - 240447)
I 20:35:44 Device MD5: 5c80a5d2ef1d51f5fc3b1424ca20c571
I 20:35:44 Image MD5: 5c80a5d2ef1d51f5fc3b1424ca20c571
I 20:35:44 Operation Successfully Completed! - Duration: 00:01:58
I 20:35:44 Average Verify Rate: 4,075 KB/s (27.2x) - Maximum Verify Rate: 5,344 KB/s (35.6x)

[brit0n]

What if you only add 1 file into Build mode for buring? Does it still takes ages to parse the filesystem during a verify?

 

How does that time change as you add more files?

If I get this right, in order to check that, I have to build ISOs with differing numbers of files in them and then check that time lag each time? I'll do that when I get a chance unless I see here there is a different way.

Oh and is the EXACT text in the status bar 'Parsing File System' or does it say something in addition to that? I'd actually made 2.3.2.0 change the status a bit more depending on what it was doing.

 

The exact message 'Parsing File System' shouldn't actually be visible for all that long.

I need to check that. I missed that in the release notes so I didn't watch it. (To be honest, I was kinda hoping with this version that it would flash past too quickly for me to see lol.)

Just to be clear, this is with you burning + verifying an ISO file that you've already built yeah? Not one you're building on-the-fly direct to a disc?

Yes, ISO to Burner. ISO remote on the LAN. The only connection is that the build immediately precedes the burn and is auto-queued, but I understand that ImgBurn has to forget the build and sees the ISO as just another ISO and starts from scratch. So I assume I can do tests with previously built ISOs already sitting there.

 

I haven't actually noticed it with an on-the-fly burn, but unless I am misunderstanding how it is verifying, it will already have the file system under its belt even if the files are remote on the LAN.

 

It'll be a while before I can check enough to make sense, but I will get back when I have all those answers.

 

One question that arises - if I have 2GB RAM and we are talking a standard CD burn, does ImgBurn actually go back (and forth) to (and from) the ISO to verify or does it hold it in memory? (I ask because this is all caused by the ISO being on the LAN.)

Edited April 21, 2007 by brit0n

[brit0n]

Not sure exactly what you mean or rather which mode you used etc

OK. We are talking the following:

 

Build Mode: Build an ISO to make a bootable CD from files on a remote machine on a Windows P2P LAN. ISO destination on the remote machine.

 

No problems, very fast, great!

 

Now ignore that because unless ImgBurn is weird, once built, saved to disk, log updated to show build is complete, it won't remember what it just did except that the Queue will now show another action which is:

 

Write Mode: From that ISO still on the remote machine, write to CD with verification.

 

No problems, very fast, great ..... IF you don't verify. Which is why I am only quoting that small part of the log.

 

It's a LAN thing, not a processor/memory limitation. But we're talking minutes for the build and for the burn and for the verification itself so it's only this phase we're talking about.

 

The only oddment is that it is a bootable CD and contains many (some small) files - the one I keep repeating so that it is reasonably consistent is a standard Win98SE install CD with some drivers and other stuff on it which makes it nearly full. The boot image is standard El Torito using a 2.88MB diskette image which again is about full of DOS files.

 

L_UK knows the phase and seems to have spent quite some time wandering around that area of code. The only reason I can think of for him to bother is that this is a fairly standard setup which more and more people may use (more network storage being used for huge BitTorrent etc downloads - more media center PCs hungry for more burned DVDs) so this delay might put them off using ImgBurn more than once. That would be dumb as the workaround is TOO simple - move the stuff to the PC doing the job, save the ISO there and then archive the ISO somewhere else if you want to keep it. I'm only doing the remote thing any more so that I can feed back. If L_UK wants to drop this, I can go back to moving the stuff which is quicker, but I'm happy to try to identify the little beggar which is causing that seemingly nasty hour+ extension. I am just hoping it isn't some dumb Windows networking thing.

Edited April 21, 2007 by brit0n

[LIGHTNING UK!]

One question that arises - if I have 2GB RAM and we are talking a standard CD burn, does ImgBurn actually go back (and forth) to (and from) the ISO to verify or does it hold it in memory? (I ask because this is all caused by the ISO being on the LAN.)

 

No, it only buffers what can fit in the allowed buffer size. i.e 20MB, 40MB etc.

 

Getting back to the intial problem...

 

I think it's when parsing the UDF filesystem more than anything.

 

Due to the nature of it, there's a lot of single sector (random) reading that takes place and the overhead of that just kills network transfer speed.

 

I've made a few more speed ups now so lets see if the next version is any better!

 

That's not to say my tests came out ANYTHING like yours. I built an ISO containing 5500 files shared over 11 directories. It probably took 10 - 20 seconds to parse the filesystem. That to me, is a long time... but then I'm used to it taking about 1 - 2 seconds from a local hdd!

 

This was just me going from machine to machine via a router - running at 1 gigabit. The actual throughput didn't exceed 10MB/s though during the parsing.

 

This is my latest log after a those few extra changes. It would probably be quicker still, but I've got a memory checker running within the debug environment to check for access violations.

 

I 01:11:52 Operation Successfully Completed! - Duration: 00:02:07

I 01:11:52 Average Write Rate: 6,195 KB/s (4.5x) - Maximum Write Rate: 6,984 KB/s (5.0x)

I 01:11:52 Cycling Tray before Verify...

I 01:12:36 Device Ready!

I 01:12:39 Operation Started!

I 01:12:39 Source Device: [3:3:0] Optiarc DVD RW AD-7173A 1-02 (R:) (SCSI)

 

Please note that this was burning to a DVDRAM hence the 5x max speed

[brit0n]

No, it only buffers what can fit in the allowed buffer size. i.e 20MB, 40MB etc.

Thanks - it makes sense.

That's not to say my tests came out ANYTHING like yours.

I remember noticing when letting a DOS batchfile copy the Win98 directory off the CD onto HDD it goes through a terrible phase when it hits large numbers of tiny files - Tour or Help stuff probably. It is probably that.

This was just me going from machine to machine via a router - running at 1 gigabit. The actual throughput didn't exceed 10MB/s though during the parsing.

I didn't think it was bandwidth that was causing it even though it's a slower network.

I 01:11:52 Cycling Tray before Verify...

I 01:12:36 Device Ready!

.....

Please note that this was burning to a DVDRAM hence the 5x max speed

Well, I could use the DVDRAM but it isn't the burn speed I am worried about. What is a relief is that you had 44 minutes in that "lull". So it isn't just me cos that is a significant time. But if that's what it takes to verify a large file group, so be it! Everything has its cost and this one is easy to work around.

 

When I try again, I'll let you know. Thanks for all the help and info.