abrogard

I recently tried to use DVDShrink to copy a DVD which it wouldn't do.

The DVDShrink experts told me that it was because the DVD I was using was old and scratched. (I know, that's why I wanted to copy it)

But DVDShrink didn't just give up. What it did was take dozens of hours. It went all night and still wasn't there.

When I looked at the Task Manager the Idle process was using 98% of cpu cycles. When I looked closer I couldn't find any process that had anything to do with DVDShrink.

Now how can a program spend so much time doing nothing? What is it doing?

Is this acceptable behaviour or is this a programming mistake and if it is, what is the mistake?

regards,

ab

InfoGeek

May be the program is trying to do something over and over again and failing every time.

__________________
PFO - My daily dose of technology.

nnxion

I've had a CD that was very bad, I wanted a virtual CD of it, one block wasn't getting read, it failed and failed and failed, but after 24 hours it finally got the block read. Don't ask me how, 'cause I don't know.

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

DaWei

Despite the code posted on the forum, there is error checking in the world. Typically, for a disk read, there will be a number of retries. If the read is critical, the number of retries may be high. If the read is absolutely essential, a large number of retries will be followed by giving up. You may even have seen this phenomenon if you've tried to install an OS with a flakey medium. I am not into the characteristics of CDs, but I can tell you that there are many reasons for magnetic media to fail at first, then eventually succeed. There are also ways to jink with the media reader at a low level, but they aren't commonly employed.

One thing that can be done with flakey media (such as a bar-code on a fiche) is to make many reads and derive some composite result. One may do this a few times and accept the most likely candidate by 'vote'. Sometimes one deals with probabilities of success rather than absolute tolerancing.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

PPoA

Some copy-protection actually defeats copying a disk. From what I've heard, they purposely put broken sectors or something on the disk, and without such and such a key, you don't get a clean copy.

DaWei

I guess programs are like programmers, too. Turn your back, some of 'em do nothing.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

Yeah, but I've yet to encounter a program that will try to convince other programs to do their work.

Back on topic: I/O operations will tend to be pretty slow and not all that demanding on a CPU. If I/O operations are failing and being repetitively retried, a program waiting for them to succeed will appear idle. Which is consistent with what you've been told: the problem is in your media.

DaWei

I think this fact is often lost, down in the grass, since modern OSes tend to move ahead of the actual requirements that will (maybe) be imposed for data, and just toss it all on the ground, unused, if the demand doesn't materialize. Some unbuffered operations to a floppy with a supremely fast (maybe 1 MHz) cpu would undoubtedly be surprising to many. The cpu is loafing.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

Yup. This was common back in the 80s and early 90s, when floppies were the primary media for commercial software. One protection scheme on a game I used to play employed it; they had unformatted sectors on the disk, so when these sectors were read, it was essentially noise. The drive would interpret it as a series of binary values, but they wouldn't be consistent. The protection method was to read these bad sectors several times, and compare the results; if they were all identical, it concluded the sectors were formatted, and thus, the disk was a copy.

Of course, it wouldn't immediately reject the disk. The programmers were sneaky, and would have the game continue for some time, and mysteriously fail at some later point. Intermittent crashes with the game were a common result of a pirated disk.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

nnxion

Of course you can reverse engineer the method, and then by using lowlevel I/O copying the bad sectors, and making them unidentical.

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates