Progress for Verifying: Parsing File System

[LIGHTNING UK!]

44 minutes?!

 

That's 44 seconds and that's not even where the program does the parsing.

 

The parsing takes place AFTER the 'Device Ready' message comes up.

 

i.e. between these two:

 

I 01:12:36 Device Ready!

I 01:12:39 Operation Started!

 

Making 3 seconds.

 

The 44 seconds is the time taken for the drive to reinitialise the disc after the tray has been opened / closed - and that's nothing at all to do with the program.

[brit0n]

44 minutes?!

 

That's 44 seconds and that's not even where the program does the parsing.

 

The parsing takes place AFTER the 'Device Ready' message comes up.

.....

Sorry, I slipped a cog - my bad!

 

I'm trying to fit a different activity monitor on the LAN so that I can see whether I am right in thinking there is no continuous activity during that hour+, but Windows is fighting me lol. I'll let you know when I try the single file etc runs.

[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?

OK, back on track (I think), Lightning. Slow but sure lol

 

I took a single CD sized (approx) AVI file from a torrent and build it to an ISO using the same source/destination machine/storage device. This bit will sound weird if anyone reads it not realising this was simply a test..... I made the CD bootable using the same 2.88MB boot image full of small DOS files as the previous burns.

 

No significant lag - extract from log:

 

I 22:29:36 Cycling Tray before Verify...

W 22:29:42 Waiting for device to become ready...

I 22:29:51 Device Ready!

I 22:29:53 Operation Started!

.......

I 22:39:33 Operation Successfully Completed! - Duration: 00:09:40

I 22:39:33 Average Verify Rate: 1,199 KB/s (8.0x) - Maximum Verify Rate: 1,255 KB/s (8.4x)

 

The only oddment was that it asked for another CD, but I probably went over the size limit (the previous time I tried it, it simply warned me before I started, so I changed to a smaller file - dunno what that was about, but I need to read the forums to learn what the options for that are - I seem to remember seeing an option to automatically divide large files). I hope that didn't make a difference, but as it verified that disk, I can't see how it could.

 

So as I see it "so far", the obvious advice for anyone burning a disk from an ISO on a remote storage medium where the ISO contains many small files is to move the ISO to the burning machine.

 

Hardly something you can change ImgBurn to do anything about unless it is gonna count files/filesizes which is a little off the map compared with the average user!

 

I'll test sometime with the largest number of small files removed from that other build and see what happens and let you know. (That's only going to remove approx. 50MB but that's 2,433 files in 53 folders so it should show some kind of difference if that is the cause of that long period.) And I'll let you know what the status bar is showing during any long period for the original burn when I can do that one "attended".

 

One question.... hope this edit is before you reply: Would verification look inside .CAB files? If so, I would need to remove those and test too (you gotta KNOW Windows has a lot of CAB files).

Edited April 25, 2007 by brit0n

[brit0n]

Here's extracts from the log for a similar ISO as the original ones I reported, but after removing 66MB in 3,102 files in 77 folders (no extra files added so the overall size is somewhat less):

 

; ImgBurn Version 2.3.2.0 - Log

 

.....

 

I 22:13:14 Operation Successfully Completed! - Duration: 00:20:44

I 22:13:14 Average Write Rate: 601 KB/s (4.0x) - Maximum Write Rate: 626 KB/s (4.2x)

I 22:13:14 Cycling Tray before Verify...

W 22:13:20 Waiting for device to become ready...

I 22:13:28 Device Ready!

I 23:22:09 Operation Started!

 

.....

 

I 23:33:58 Operation Successfully Completed! - Duration: 00:11:49

I 23:33:58 Average Verify Rate: 988 KB/s (6.6x) - Maximum Verify Rate: 1,256 KB/s (8.4x)

 

Approx timings of status bar text (HH:MM):

 

22:13 Checking File Systems...

22:14 Parsing UDF FileSystem...

until

23:21 Parsing UDF FileSystem...

 

then other items too fast (see log) until

 

23:22 Verifying Sectors...

and then continue normally.

 

So the long activity shows Parsing UDF FileSystem...

 

For me, the answer is the workaround when using these kinds of ISOs - data disks with plenty of small files (some games might have that problem as well as OS install disks, but they are comparitively easy to move to local disk for the write. There is no problem with Movies/Music etc where most of the content is in one or a few files.

 

If you want me to further reduce numbers of files, I can. The removed files did indeed shorten that time, but it is hardly significant - I didn't add any files to make the size similar either.

 

The files in the boot image don't affect it adversely at all so I presume that is verified as a single IMG file. Presumably the CAB files are also treated as single files - I can't believe that verification goes inside them because if it did, it would probably take 12 hours or several days instead of 1 hour!

 

Hope this helps in some way even if it is just to make you leave well alone! (Maybe amend that status bar text to something like Parsing UDF FileSystem (may take a while)... so users don't think it is hanging and crash the program never to use it again lol (if they haven't sensibly gone to bed and left the queue to run through and shut down).

[blutach]

I took a single CD sized (approx) AVI file from a torrent

You just lost us brit0n - well, me at least.

 

Most of these AVIs are of copyrighted material.

 

This forum is about helping people with burning, but not when they are downloading stuff from torrents.

 

Regards

[LIGHTNING UK!]

The two lines in bold show the time taken to parse the file system (plus other stuff) when buring the Win98 SE ISO from a networked PC.

 

Again, my 4 seconds is nothing like the 1 hour yours takes!

 

I 12:17:56 ImgBurn Version 2.3.2.1 started!

I 12:17:56 Microsoft Windows Server 2003, Standard Edition (5.2, Build 3790 : Service Pack 2)

I 12:17:56 Total Physical Memory: 2,094,704 KB - Available: 587,956 KB

I 12:17:56 Initialising SPTI...

I 12:17:56 Searching for SCSI / ATAPI devices...

I 12:17:56 Found 2 DVD-ROMs, 2 DVD?RWs and 4 DVD?RW/RAMs!

I 12:18:03 Operation Started!

I 12:18:03 Source File: \\amd4000\e$\WIN98_SE.ISO

I 12:18:03 Source File Sectors: 320,412 (MODE1/2048)

I 12:18:03 Source File Size: 656,203,776 bytes

I 12:18:03 Source File Volume Identifier: Win98 SE

I 12:18:03 Source File Application Identifier: CDIMAGE 2.39 (12/04/97 TM)

I 12:18:03 Source File File System(s): ISO9660 (Bootable), Joliet

I 12:18:03 Destination Device: [3:0:0] LITE-ON DVDRW LH-20A1H LL0A (O:) (SCSI)

I 12:18:03 Destination Media Type: CD-RW (Disc ID: 97m34s25f) (Speeds: 16x, 24x, 32x)

I 12:18:03 Destination Media Sectors: 359,847

I 12:18:03 Write Mode: CD

I 12:18:03 Write Type: SAO

I 12:18:03 Write Speed: MAX

I 12:18:03 Test Mode: No

I 12:18:03 BURN-Proof: Enabled

I 12:18:04 Filling Buffer... (40 MB)

I 12:18:05 Writing LeadIn...

I 12:18:16 Writing Session 1 of 1... (1 Track, LBA: 0 - 320411)

I 12:18:16 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 320411)

I 12:21:26 Synchronising Cache...

I 12:21:31 Image MD5: ceb2663047db6633eddb3ed98eb9c545

I 12:21:31 Exporting Graph Data...

I 12:21:31 Graph Data File: C:\Documents and Settings\Administrator\Application Data\ImgBurn\IBG Files\LITE-ON_DVDRW_LH-20A1H_LL0A_25-APRIL-2007_12-18_97m34s25f_MAX.ibg

I 12:21:31 Export Successfully Completed!

I 12:21:31 Operation Successfully Completed! - Duration: 00:03:27

I 12:21:31 Average Write Rate: 3,372 KB/s (22.5x) - Maximum Write Rate: 4,846 KB/s (32.3x)

I 12:21:31 Cycling Tray before Verify...

W 12:21:38 Waiting for device to become ready...

I 12:21:49 Device Ready!

I 12:21:53 Operation Started!

I 12:21:53 Source Device: [3:0:0] LITE-ON DVDRW LH-20A1H LL0A (O:) (SCSI)

I 12:21:53 Source Media Type: CD-RW (Disc ID: 97m34s25f) (Speeds: 16x, 24x, 32x)

I 12:21:53 Image File: \\amd4000\e$\WIN98_SE.ISO

I 12:21:53 Image File Sectors: 320,412 (MODE1/2048)

I 12:21:53 Image File Size: 656,203,776 bytes

I 12:21:53 Image File Volume Identifier: Win98 SE

I 12:21:53 Image File Application Identifier: CDIMAGE 2.39 (12/04/97 TM)

I 12:21:53 Image File File System(s): ISO9660 (Bootable), Joliet

I 12:21:53 Verifying Session 1 of 1... (1 Track, LBA: 0 - 320411)

I 12:21:53 Verifying Track 1 of 1... (MODE1/2048, LBA: 0 - 320411)

I 12:24:50 Device MD5: ceb2663047db6633eddb3ed98eb9c545

I 12:24:50 Image MD5: ceb2663047db6633eddb3ed98eb9c545

I 12:24:50 Exporting Graph Data...

I 12:24:50 Graph Data File: C:\Documents and Settings\Administrator\Application Data\ImgBurn\IBG Files\LITE-ON_DVDRW_LH-20A1H_LL0A_25-APRIL-2007_12-18_97m34s25f_MAX.ibg

I 12:24:50 Export Successfully Completed!

I 12:24:50 Operation Successfully Completed! - Duration: 00:02:56

I 12:24:50 Average Verify Rate: 3,641 KB/s (24.3x) - Maximum Verify Rate: 4,974 KB/s (33.2x)

[dontasciime]

And I am sure that if you look at my log the same applies for an xp pro disc burnt across network, unless of course I would get different result if I had the ISO stored on a Usb 2 external Hd on the remote machine. Which I will try Later

[LIGHTNING UK!]

In post 21 donta?

 

Building on the fly is not a fair test. It will use the file structure info that's already in memory.

 

You have to burn + verify an existing ISO that lives on a networked PC.

[brit0n]

I took a single CD sized (approx) AVI file from a torrent

You just lost us brit0n - well, me at least.

 

Most of these AVIs are of copyrighted material.

 

This forum is about helping people with burning, but not when they are downloading stuff from torrents.

 

Regards

I read the forum rules and I totally agree with you. I took a file which fit the test I needed to do. I didn't break any copyrights and I didn't condone anyone else doing so.

 

As it happens, the file I used is a public domain file released by the U.S. Department of Homeland Security but I only chose that one because it was about the right size. I have NO idea what is on it!

 

So tell me, what is your problem? I was trying to help here - you think I NEED to be doing these tests? I thought Lightning might want the info and I am happy to spend a little time getting it. What did YOUR post contribute to these forums?

[dontasciime]

In post 21 donta?

 

Building on the fly is not a fair test. It will use the file structure info that's already in memory.

 

You have to burn + verify an existing ISO that lives on a networked PC

 

 

Thought I had

[dontasciime]

ok I thought I had tried with operating system install disc

 

This is my slipstreamed XpSp2 XpPro

 

 

 

 

So it took 1.54 to read ahead the sectors and 6 secs to parse so 2 minutes in all with 6201 files

[LIGHTNING UK!]

You can't actually count the 6 seconds as the parsing time, that's just the time it took to loop through the file list and display everything in the listbox!

 

Any chance you could time how long the actual 'read ahead' process takes? i.e. by watching the status bar and using a stopwatch!

 

The read ahead should be the quick bit because that's a single api call to read the data from the file in one long stream.

 

That actual parsing is lots of individual file accesses, reading 1 sector at a time - and potentially from all over the place within the file. At the moment that also involves a lot of opening / closing of files, but I've removed that overhead in the latest (unreleased) beta.

[blutach]

I took a single CD sized (approx) AVI file from a torrent

You just lost us brit0n - well, me at least.

 

Most of these AVIs are of copyrighted material.

 

This forum is about helping people with burning, but not when they are downloading stuff from torrents.

 

Regards

I read the forum rules and I totally agree with you. I took a file which fit the test I needed to do. I didn't break any copyrights and I didn't condone anyone else doing so.

 

As it happens, the file I used is a public domain file released by the U.S. Department of Homeland Security but I only chose that one because it was about the right size. I have NO idea what is on it!

 

So tell me, what is your problem? I was trying to help here - you think I NEED to be doing these tests? I thought Lightning might want the info and I am happy to spend a little time getting it. What did YOUR post contribute to these forums?

You just might like to think before saying stuff like "I downloaded a torrent". If you know anything of LUK!'s previous experience, you will know that no-one wants it repeated.

 

So what did MY post contribute? Possibly the de-risking of the forum. Use YOUR brains in future.

 

Regards

[brit0n]

You just might like to think before saying stuff like "I downloaded a torrent". If you know anything of LUK!'s previous experience, you will know that no-one wants it repeated.

 

So what did MY post contribute? Possibly the de-risking of the forum. Use YOUR brains in future.

 

Regards

It must be a UK thing. I may be British, but people here use Torrents for a whole host of things. Our main use on this network is to share very large chunks of data. Government departments use them for (mis)information etc.

 

It was just a file the right kind of size. Apart from the size and type, the only other thing I needed to know about it was that it didn't have any malware.

 

But point taken.

[brit0n]

Again, my 4 seconds is nothing like the 1 hour yours takes!

Yes, I got that - when I put my brain back in gear and read the logged times correctly!

 

The single file (plus boot image) test showed it was file numbers/quantities causing the hour plus period.

 

The later test I did, I observed the status bar text - results posted above. The long activity was Parsing UDF File Sustem... which was what you thought it probably was. Verifying when burning from local disk took even less time on CD-R than CD-RW (the whole parsing thing was logged at 1 second).

 

I am guessing the length of this stage is simply a sliding scale thing which gets worse the more small files included in the ISO (you intimated that in an earlier post). If so, ImgBurn and any other burners aren't going to do anything different unless they save a detailed file system file alongside the ISO which isn't very much use (I think it was Nero that tried it for a while a few years ago and gave it up). Lightning, let me know if you want more tests/information with varying number of files, but I think we're done.

 

(If anyone ELSE wants to try this to see if they get similar results, say with a different network setup, all you have to do is dig out an old OS installation CD, copy the files from it, fill it with other files, fill a 2.88MB boot image and build the ISO or you could probably just download a Linux ISO - find one of the bloated distros. You don't have to be able to USE it or break any copyrights - the ISO simply has to contain large numbers of small files (maybe you have one of those CDs from the photo processing lab which contain a gazillion different types of thumbnails and different resolution images from your vacation in Biarritz lol. Just so long as you have large numbers of small files, a full CD's worth in the ISO and the ISO stored on a remote storage device so that ImgBurn has to work through the network. Burn it from there and verify.)

 

If anyone has an ISO with large numbers of small files (this will almost certainly be a DATA or GAME CD) and tries burning it from a remote storage device with verirification and finds that ImgBurn seems to "hang" after the write is successfully completed but before the verify phase gets going, copy or move the ISO to the PC doing the burning to speed up verifying. OR start the operation, tell ImgBurn to shutdown after completion and go and do something else. (By the way, ImgBurn works better in the background than any other burning software we've tested so far - "another great feature"!)

Edited April 26, 2007 by brit0n

[blutach]

Fair nuff, then

 

BTW: Rules? Wot rules?

 

Regards

[dontasciime]

Any chance you could time how long the actual 'read ahead' process takes? i.e. by watching the status bar and using a stopwatch!

 

Did not think I would need a stop watch as I went off everything in log

 

2 minutes was parse time in all , way i typed did not demonstrate this 1.54 and 6 seconds read ahead and parse according to logs, so 2 minutes to parse and read ahead.

 

eg log

 

I 20:14:35 Device Ready!
I 20:14:36 [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:14:36 CDB: 46 02 00 00 00 00 00 00 0C 00
I 20:14:36 CDB Interpretation: Get Configuration
I 20:14:36 BUFFER: 00 00 00 30 00 00 00 08 00 00 03 28
D 20:16:29 File System - File: AUTORUN.INF - LBA: 7312 - 7312 - Size: 110 bytes

 

at 20:14.35 I was watching the screen point where it says parsing udf file...

 

Then looked at log at

 

D 20:16:35 __ParseFS - Found 6201 Files
I 20:16:35 [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:16:35 CDB: 25 00 00 00 00 00 00 00 00 00
I 20:16:35 CDB Interpretation: Read Capacity
I 20:16:35 BUFFER: 00 03 AB 3F 00 00 08 00
I 20:16:35 [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:16:35 CDB: 46 02 00 00 00 00 00 00 0C 00
I 20:16:35 CDB Interpretation: Get Configuration
I 20:16:35 BUFFER: 00 00 00 30 00 00 00 08 00 00 03 28
I 20:16:35 [5:0:0] PIONEER DVD-RW  DVR-108 1.14 (S:) (ATA)
I 20:16:35 CDB: AC 00 00 00 00 00 00 00 00 32 03 00
I 20:16:35 CDB Interpretation: Get Performance
I 20:16:35 BUFFER: 00 00 00 54 00 00 00 00 00 00 00 00 00 05 7D A5 00 00 02 C1 00 00 16 0C 00 00 00 00 00 05 7D A5 00 00 02 C1 00 00 10 89 00 00 00 00 00 05 7D A5 00 00 02 C1 00 00 0B 06 00 00 00 00 00 05 7D A5
I 20:16:35 Operation Started!

 

2 minutes at which point it started to verify

 

Dunno where i got 1:54 from, oh actually I see what I did

 

D 20:16:29 File System - File: AUTORUN.INF - LBA: 7312 - 7312 - Size: 110 bytes

 

D 20:16:35 __ParseFS - Found 6201 Files

 

time difference between 20:16.29 and 20:16.35 6 seconds so anything previous to that was 1 minute 54

 

So i was looking at it saying parsing udf file system for 2 minutes before some action was visible again on screen

 

So my wording was wrong at saying 6 secs to parse as that was in your words to show log list of file used etc.