V5.2.3 copy is 3x+ faster than v6+

[jmasles]

Have been using the old V5 release to do DVD copy with full disc option and noticed a significant slow down when upgrading to V6. I thought perhaps with each subsequent release the situation might improve, but alas no. I've eliminated any DMA issues by using a USB drive. For a test I used the same DVD and ran the copy twice without rebooting. The movie with V5 hit peak speeds of 15 MB/sec and a lapse time of 5:25. Using the latest V8 I only saw a peak transfer rate of just under 5 MB/sec and lapse time was 17:02. I could not find any V5 specific logs but I've attached the V8 ones ....

[AGJ]

logs posted are useless and the V5 you have was released January 2009 and not even the last up to date version for the 5 series of DVDFab. If you want help with Version 8 then read what is listed below and post all info mentioned to your next post reply to this thread

Help Us Help You


If you are posting about an operational problem with one of the DVDFab products, you will improve the speed and accuracy of the response by providing some information in the very first post that will probably be needed.

First, make note of any error codes or messages that appear in popup boxes and put them in your post. Information on error codes that appear in the DVDFab UI are captured in one of the logs we request below.

DVDFab keeps logs of its activities that supply basic system information and can help pinpoint where and when an error happened and help pinpoint the cause. The default location for these logs on most Windows systems is:

C:\Documents and Settings\your username\My Documents\DVDFab\Log

The logs are simple text files that can be opened with Windows Notepad if you want to read them. If the size exceeds the forum’s attachment size limit, you may need to delete older entries or copy and paste the relevant ones into a new file. The log files can be attached to a post using the "Manage Attachments" button below the editing box.

dvdfab_burn_vso.log Attach for all problems. The entries are time stamped with the most recent at the top.

dvdfab_burn_imgburn.log Attach if you have ImgBurn set as the burning engine and the problem concerns disc burning. Time stamped with the most recent at the bottom.

dvdfab_process.log Attach if DVDFab crashes and the crash report window does not come up or complete correctly or if internal error codes appear in the DVDFab window (“Task Failed…”). Time stamped, most recent at the bottom.

dvdfab_internal.log Attach for all problems. Time stamped, most recent at the bottom. Please edit to include only the most recent or relevant log session.

Other Information:

Depending on the nature of the problem, it can help to know:
If this happens with all discs or just one
Your operating system/CPU/memory configuration
If you are using external hard drives or optical drives
If you have made any recent changes to your OS or system hardware
If you have other DVD or BD software installed, particularly if recently added.

Posts with all the requested information will be answered first.

[jmasles]

Regarding your "logs are useless" comment, I cleared the log directory and then ran my test cases. The logs I posted are what your program generated, if you have some secret settings to improve your logging, I'm all ears. As for my reference to V5, that is the last version I had that doesn't exhibit this problem, v6,v7,and v8 are all 1/3 the speed of v5. I've conducted further experiments and discovered that it's not your front end ripping code but rather the code on the back end writing the results to disc that is the problem. I have 3 target devices in my system and normally I run a full disc copy with a 3Ware Raid5 lun as the destination device. It's a normal lun under Windows XP32 and can sustain 50+ MB/sec throughput during file copy operations. Running 2 copies of dvdfab ripping from 1 sata and 1 usb drive to this lun, the ripping speed was around 3 MB/sec each. I ran the exact same setup but used my boot drive which is 2 SSD's striped together and the performance jumped up to 15 MB/sec. DvdFab V5 will rip at the same rate regardless of the target file system. Something changed in V6 on with your backend code and how it writes to file systems.

[signals]

I have changed the prefix and title of your thread. It has nothing to do with v8.0.0.5.

[AGJ]

How many DVDs have you tried and are they newer DVDs or older ones? As you could try with Pathplayer Disabled if they older ones. Also when it comes to DVD Copy the only logs that help are mainly the Burn logs if you burn to DVD and that the problem. The only thing that helps for the Internal logs is to see if the Copy protection is new or if pathplayer is enabled/disabled.

Also I'm just a DVDFab user like you who volunteer my time to help out others and am not developer of DVDFab

[jmasles]

Copy speed seems independent of the age of the DVDs. Ran a test case with 2 dvds one in Sata drive and 1 in USB drive. With DVDFab5 ripping speed reached about 20MB/sec total to the file system. Reran the test with DVDFab8 to exactly the same place, and the 2 rips topped out at a combined 4 MB/sec. The raid controller on my system has 1 lun in a raid5 configuration and the second is a 2 drive stripe set. It's the second that I'm using as a destination and it should have no trouble keeping up with dvd ripping. I'm guessing the back end of dvdfab v6-v8 was changed and no longer aggregates writes to the OS very well. Really the only way to muck up write performance to a stripe set is to do small block writes at random locations so the drive performance is dominated by seek time. Given that, I have no illusions about anyone addressing this issue, so I'll continue with "plan B" ripping to my SSDs and then copying to the stripe set under Windows.

[signals]

Normally the bottleneck to processing speed for DVDFab is the optical drive from which the content is being read, not the hard drive I/O. Maybe one of the developers can comment on what you should expect with your unusual drive configuration. I have not noticed any decrease in DVDFab processing speed, in fact it seems to be a little faster. I have been using it since v2.9x (but not on the same hardware, and nothing as high-end as what you have).