Batch Ripper Bug?

**Spoon** · September 08, 2008, 12:29 PM

Re: Batch Ripper Bug?

You only ripped on one drive? J:\

**bhoar** · September 08, 2008, 12:48 PM

Re: Batch Ripper Bug?

Originally posted by Spoon

You only ripped on one drive? J:\

I'll note some other oddities:

1. Both rip logs start at the same date/time, which is normal.
2. Both rip logs point to drive J:/, which is abnormal.
3. The second log took about 22 minutes to rip (very long, looks like about 2x), yet was Accurate with no frame rereads. Evidence that another cdgrab.exe task was also trying to read from that drive?
4. The first three tracks from the second log also took about 22 minutes to rip (very very long, substantially slower than 1x). After that, the last two tracks ripped normally. Again evidence that two cdgrab.exe tasks were reading from the same drive at the same time.

This kind of result is characteristic of running multiple instances of the cdgrab.exe manually which can cause one instance of the cdgrab.exe to switch drive letter at an unexpected time. Now, this isn't supposed to happen when the batch ripper calls them.

The most recent (or next to last) release of R13.1 is supposed to address a concern of this nature, at least when manually running more than one instance.

Also, is it possible that during or right before these two rips, you happened to open and close another instance of cdgrab.exe, perhaps to manually rip from another drive, or perhaps to read or change a setting somewhere?

-brendan

**egd** · September 09, 2008, 10:25 PM

Re: Batch Ripper Bug?

Hi

I don't recall manually invoking cdgrab - in fact I've never even taken a peek inside the dbp folders, so unless cdgrab gets invoked by running the standalone configuration I'm not quite sure what happened. Strange also that the drive letters are the same as clearly one cannot rip two CDs from the same drive simultaneously. I'll check the logs of the other rips for drive letters and revert - one thing that does spring to mind is that there are 5 identical cd/dvd drives in this box, albeit they're clearly all assigned different drive letters. If the logs all report J:, then it would explain the drive letter anomaly.

In any event, great program and having to rerip the odd album is no biggie. There is no way I could have ripped that many CDs inside a week spending only a few hours most nights. Tagging on the other hand, remains a PITA, but that's never going to change so long as we all have differing requirements.

**bhoar** · September 10, 2008, 01:00 AM

Re: Batch Ripper Bug?

Originally posted by egd

I don't recall manually invoking cdgrab - in fact I've never even taken a peek inside the dbp folders, so unless cdgrab gets invoked by running the standalone configuration I'm not quite sure what happened.

cdgrab.exe is also known as "dbpoweramp CD Ripper". It can be run manually and is also harnessed (one per drive) by the batch ripper.

Originally posted by egd

Strange also that the drive letters are the same as clearly one cannot rip two CDs from the same drive simultaneously.

Actually, my point about the inordinate amount of time required to rip the CD was that it appeared you *were* actually running two rips at the same time from one drive. Luckily one of the discs it thought it was ripping was short, otherwise it may have taken an hour or more.

-brendan

**egd** · September 10, 2008, 10:12 AM

Re: Batch Ripper Bug?

Originally posted by bhoar

Actually, my point about the inordinate amount of time required to rip the CD was that it appeared you *were* actually running two rips at the same time from one drive. Luckily one of the discs it thought it was ripping was short, otherwise it may have taken an hour or more.

I hear you but clearly that doesn't explain differing metadata.

I'll attribute it to user error and leave it at that...

Batch Ripper Bug?

Batch Ripper Bug?

Comment

Comment

Comment

Comment

Comment