1.6.4 vs 1.6.3 - disc read speed

[rcork]

I had previously used MediaCodeSpeedEdit to modify the firmware for my LG CH10LS20 to enable higher ripping speeds. After 1.6.4 was released i restored my original firmware so that i could see if the new version had overcome the speed limiting issues. Unfortunately, 1.6.4 with the original drive firmware is much slower than i had using a modified firmware and 1.6.4. With my modified firmware i could get between 4X and 6X. With the original firmware and 1.6.3 i hover between 2X and 3X.

Please, please, at least specify your OS.

Sorry Mike. I'm running MakeMKV 1.6.4 on OSX 10.6.6 with an LG CH10LS20 with firmware 1.00-00.

@Krobar, where did you get 1.00-03 and do you know if that is an official firmware?

[ptr727]

Comparing 1.6.3 against 1.6.5.
Same speed, 1.6.3 ripped in 0:27:55, 1.6.5 ripped in 0.27.46, max rip speed about 22.9M/s / 5.3x
OS is Win7 Ultimate x64 SP1.
No UDF driver.
Test BD is X2, part of X-Men Trilogy pack, UPC 024543581321.
Drive is LG UH10LS20, original LG 1.00 firmware, with riplock removed using MediaCodeSpeedEdit.

[ptr727]

I notice that with riplock removed, the optical drive never maintains full speed.
It reads, picks up speed, then slows down, picks up speed again, and slows down.

If I correlate this this with the MakeMKV UI, I can see the write rate going up, stopping, restarting, going up, stopping restarting.
I can also correlate this with the disk IO to the taget drive, that is higly cyclic.
I have not yet found a way to monitor the optical disc read rate, as the device appears locked.

It seems that MakeMKV is not able to keep up with processing and writing the data as it is read, i.e. the optical drive can read faster that MakeMKV can write.
This results in the drive spinning up, slowing down, spinning up, slowing down, overall this decreases the effectiveness as the drive stops and needs to spin up again.

I tried changing the read buffer from auto to 2MB, made no difference.
I am testing on a Core i7 Extreme with 24GB RAM, so processing power is not an issue.

Is there any way that increasing the read buffer would keep the drive spinning at full speed?
Or caching the read data to a fifo on disk before writing to MKV?
Or limiting the read rate based on throughput in order to keep the optical drive spinning at a constant rate?

I am using Win7 x64 SP1, MakeMKV 1.65, LG UH10LS20, riplock removed.

[mike admin]

If I correlate this this with the MakeMKV UI, I can see the write rate going up, stopping, restarting, going up, stopping restarting.
I can also correlate this with the disk IO to the taget drive, that is higly cyclic.

That sounds like a bottleneck on a target drive. If program reads data faster then it could write to hard disk, it will first throttle read speed a bit to flush internal buffers, and if it doesn't help then it will print an informational message "program reads data faster...". It seems that in your case the disk drive is slow enough to cause throttling but not slow enough for a warning message.

[RickH]

Did it became faster or slower? How much?
Much slower.
Average DVD read rate for 1.6.3 9.0 M/s, 1.6.5 1.5 M/s

What OS are you using, and on what architecture (32 or 64 bit)
32 bit Windows XP Pro SP3

For Windows, please indicate whether you have a 3rd party UDF driver or on the fly decryption software installed
None that I know of.

What drive do you use and how it is attached (internal or external)
External USB HP DVD1040

Did you test DVD or blu-ray disc
DVDs only

[ptr727]

If I correlate this this with the MakeMKV UI, I can see the write rate going up, stopping, restarting, going up, stopping restarting.
I can also correlate this with the disk IO to the taget drive, that is higly cyclic.

That sounds like a bottleneck on a target drive. If program reads data faster then it could write to hard disk, it will first throttle read speed a bit to flush internal buffers, and if it doesn't help then it will print an informational message "program reads data faster...". It seems that in your case the disk drive is slow enough to cause throttling but not slow enough for a warning message.

The target drive is a 4 x 2TB Hitachi RAID5 array backed by a LSI 6Gb/s enterprise class RAID controller.
Sustainable data write rates to the array is 120MB/s.

The target drive throughput is not the problem.

P.

[Mnemos]

I don't have a detailed speed comparison between 1.6.3 and 1.6.4, but I have noticed that discs frequently are ripping at only .1x or .2x. At other times, it's ripping over 5x IIRC. So, it's definitely inconsistent, but overall, I'd say that it's definitely worse.

I'm use 64-bit Arch Linux with a Phenom II X6. The internal drive is an internal 2TB Western Digital Black Caviar HDD with a SATA II connection. There's general other I/O going on on other disks (from torrents and other system activity) but very little, if any, on the disk that the Blu-rays get ripped to. I haven't tried it with an DVDs yet. Just Blu-rays, and they're definitely slow.

[mike admin]

If I correlate this this with the MakeMKV UI, I can see the write rate going up, stopping, restarting, going up, stopping restarting.
I can also correlate this with the disk IO to the taget drive, that is higly cyclic.

That sounds like a bottleneck on a target drive. If program reads data faster then it could write to hard disk, it will first throttle read speed a bit to flush internal buffers, and if it doesn't help then it will print an informational message "program reads data faster...". It seems that in your case the disk drive is slow enough to cause throttling but not slow enough for a warning message.

The target drive is a 4 x 2TB Hitachi RAID5 array backed by a LSI 6Gb/s enterprise class RAID controller.
Sustainable data write rates to the array is 120MB/s.

The target drive throughput is not the problem.

P.

Interesting. Do you see any spikes in CPU usage when it pauses?

[twa000]

OK this is 1.6.3 vs 1.6.5 usaing my laptop
Setup:
1.73 gigahertz Intel Core I7 Q 740 8GB Memory
Win 7 64bit
Internal BD RW drive (LG CT21N)
Makemkv use's a 2048MB I/O read buffer
Target drive internal Seagate SATA 7200 rpm drive
film Million Dollar Baby, ripped main film with 2 audio tracks, size 35GB
1.6.3 took 36mins 45 secs with a cpu utilisation between 8 -> 10 % and ran between 3.2 and 4.5(max) x rip speed
1.6.5 took 34mins 30 secs with a cpu utilisation between 3 -> 5 % and ran between 3.2 and 4.7(max) rip speed

Conclusion: in this totally unrestricted environment, 1.6.5 basically used significantly less CPU and was minimally faster, ripping just over a GB per minute. So for anyone concurrently ripping DVD's 1.6.5 should be better.
Somewhere in this thread someone noticed higher memory utilisation with 1.6.4, so wonder if some of the problems are with Windows and memory utilisation causing bottlenecks?

When I find time I will try on my desktop which has a slower BD drive, and chip, but no memory restriction.

[nicolo69]

1) VERY Much Slower

1.6.3 : 4.5-5.5X speed
1.6.4 : less than 1.0X speed
1.6.5 : idem 1.6.4

2) Windows XP SP3 32 Bit

3) No UDF Driver

4) Source: Internal PATA : TDK DVDRW1616N firmware 2.7A

5) Tested with DVDs, same result each time

I want 1.6.3 version back !!! An 1.6.3 installation isn't possible because I've a message saying version too old...

[MikeMcr]

1.6.5 is MUCH slower for me.

Windows 7 x64.

LG BD-RE BH10LS30, Internal, SATA. Rip lock removed with MediaSpeedCodeEdit.

Ripping a Blu-ray with seamless branching is now painful with the new version. For example, Star Trek TOS Blu-ray has hundreds of M2TS files to process and its seems to constantly speed up and slow down. In fact, it failed on Episode 2 and then refused to abort. I had to force a reboot. Reverted back to 1.6.3 and it ripped perfectly, at full speed.

[SamuriHL]

Mine's slightly slower in 1.6.4/1.6.5 than it was in 1.6.3 and earlier. Not by much, though. I'm on W7 SP1 x64 with an LG GGW-H20L with a modified firmware for riplock. I'm wondering if it's possible to put an option in to allow people to switch back and forth between the method used in 1.6.3 and 1.6.5+? At least for the time being so people can do some real world comparisons to help you better guage what works and what doesn't. Is that possible?

[caveman38]

When I had the speed problem with V1.6.4 last month I reverted to 1.6.3 and everything was OK. Today I am prompted with version too old - upgrade or register. But the application closes before I can put in March S/N.
I have tried to reinstall 1.6.3 but the program still clears. How can I enter the March S/N so that I can keep the older version.
I cannot use the latest versions as my drive speed lowers to X1. Any ideas please.

[cigamit]

Update to my earlier post. Tested out 1.6.5 today, same issue as 1.6.4, super slow. I completely uninstalled every other application that has anything to do with codecs / videos, issue still exists. Got 1.6.3 to re-install and extend itself out another 30 days, so I guess I am good for tonight. My new SSD drive comes in tomorrow, so I will be updating to Win7 x64. I will then test again and see if I clean install fixes everything.

[TheNoxier]

* Did it became faster or slower? How much?
Much Slower
* What OS are you using, and on what architecture (32 or 64 bit)
Windows XP SP 3 - 32BIT
* For Windows, please indicate whether you have a 3rd party UDF driver or on the fly decryption software installed
None that I know of?!
* What drive do you use and how it is attached (internal or external)
LG HL-DT-ST BD-RE GGW-H20L YL05
Internal SATA
* Did you test DVD or blu-ray disc
Blu-ray disc

Since 1.6.5 I cannot go back to 1.6.3 and my HP 6 Blu-ray will take 8 hours to complete instead of 20 minutes.


Please, help - Or I am no longer able to use makemkv ...

nox