dBpoweramp Batch Ripper: Discussions

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Another spoon question:

Regarding end of batch behavior...

For now, with my in-development version of the ULCLI, I just throw up a dialog (and beep every minute or so) when a load fails and tell the user to close the dialog and then click End Batch. That works, but I bet people won't comment positively on that approach (why do I have to click twice?).

Is the a more appropriate way for the load.exe to tell the batch ripper that the end of the stack(s) of CDs have been reached? Perhaps pass a string through the logging functionality or create a temporary file that the batcher is looking for?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

The ripping speed is the last reported speed from CD ripper, it is possible in secure mode that that speed is not the real one during re-reads.

-------
The file (passed on the command line as "passerrorsback"), if you return any string with "[cancel batch]" it will end the batch.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon:

I'm still seeing an issue in the most recent batch ripper that troubles me, as I thought this was already addressed in the past.

I have a robot that came with a TEAC CD-W552DA (CD-RW) drive (one of the Kodak Kiosk units). If the next disc in the input pile is a non-CD disc (e.g. a DVD+R), this is the sequence of events that I see occur:

Batch Ripper calls load.exe
Batch Ripper waits for load.exe to exit.
Batch Ripper examines that drive and/or disc.
Batch Ripper calls load.exe

I was expecting that the Batch Ripper would call reject.exe before the next load.exe. It's almost as if the batch ripper cannot see there is a disc in the drive and therefore assumes there isn't one.

Naturally, the above steps lead to a double load condition, which is bad.

A while back I had some scripts set up to code around it, but now my internal code is reporting that the "Get Configuration" CDB (0x46) returns a disc type of CD-ROM when this DVD-R is in the CD-RW drive. *sigh* So, my load.exe knows there's a disc in the drive and the drive is reporting the wrong type, I think.

My question is: is there a way the Batch Ripper can be more proactive and force it to issue a reject first under these circumstances?

In the mean time, I'll go through my code and see if I can figure out a way to detect that the successful load of a disc leads to a non-readable disc situation and perhaps auto-reject at that point...but it would be nice if the Batch Ripper were able to do it.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

An addendum (if slightly off-topic) :
---
Ah. The "Get Configuration" call would of course return CD-ROM, since that's the only profile the drive has. It wasn't telling me what kind of disc was in the device, but rather, what drive profile is being used with the disc. Later drives change the profile in effect based on the disc type placed in them, but not so CD-RW drives.

So, if I want to determine whether there is a valid disc in the drive, I'll have to use another method.
---

I still think the "disc is loaded but not recognized" situation should cause the Batch Ripper to call reject.exe, of course. Your thoughts, Spoon?

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

Doh.

You *did* take care of it. Sorry about that, chief.

(thanks)

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

You need to add --rejectifnodisc on to your command line string for load (it is not used by your load.exe, but batch ripper).

One oddity: if you have no disc inserted (or one the drive/software does not recognize) and a reject occurs because of this, a Disc # is shown associated with this Reject. If multiple ones happen in a row, the same Disc # shows up.

It's a curious mix of not incrementing the disc # since no disc was processed, but at the same time, giving this reject of (potentially) no disc a disc # anyway...

Ok, sorry, I can't help myself Spoon...another question:

1. Is there a flag you give (or can add) to rejects triggered by this rule to differentiate them from rejects flagged for other reasons?

In this specific instance, I'd want to know there might be a good reason that the hardware reject process I am about to start could expect a failure on the grab which might be OK (because there might not be a disc) unlike normal accept/reject situations. That is, if I know the reason for this reject, because, say, I was passed "--rejectreason=nodiscfound", I might script the ULCLI to ignore the grab error and not notify the operator of the failed grab+reject and just move on to the next load.

Which, of course, leads to another question...

2. In the general case, this links up with a previously asked-for feature of specifying the "reason" for a reject so that the driver can be scripted to put different reject types (nodiscfound, nometadatafound, noaccurateripfound, failedaccuraterip, failedsecurerip, riptimeexeceeded, etc.) in different output stacks for loaders capable of direct stack output, such as the composermax or even the large capacity medatechnics/mf-digital loaders with changes to their macros.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

If the Batch Ripper is in the "Post-Load Waiting for CD" stage, hitting End Batch still waits the full timeout (90 seconds? more? drive dependent?) before canceling that stage and moving to the Unload stage.

More of an annoyance when dealing with problem discs and/or blanks in the stack.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Another suggestion:

It would be nice if after you End Batch (or the called driver does so via the "[cancel batch]" text), the next time you click start by clicking Rip, the Batch Ripper asks if you would like to continue the last batch or start a new one.

Why? If you are dealing with a disc misload on a robot, and you prefer to keep your batch results organized the current forcing of a new match designation can be frustrating.

Additionally:

Maybe it should always ask, perhaps you ended the batch due to a power outage and the need to shut down before the UPS failed?

Perhaps this could be a configurable behavior if others would find the dialog bothersome?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Spoon,

The testing that I am doing tonight involves four drives inside three separate robots controlled by a single batch ripper instance.

I've uncovered what might be a threading issue causing some delays in the batch ripper (most recent version).

Sometimes when the batch ripper has a disc in the "post-load waiting for CD" status (includes drive spin up and drive disc recognition, which can take a while depending on disc and drive) but also some other times (such as when the end of the disc is being processed?), pending loads and unloads associated with another drive on a different robot do show as pending or queued up (as show in the status lines for the drive in the batch ripper) but the external load.exe/unload.exe/reject.exe calls don't get made until the disc in the other drive gets beyond the "post-load waiting for CD status" or whatever else the threadlock(?) was waiting for.

Any ideas?

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I've uncovered what might be a threading issue causing some delays in the batch ripper (most recent version).

The pause before robotic action on drive B might also be due to a pending metadata lookup for drive A taking a very long time...

...unrelated to whether or not drive A is on the same robot as drive B, of course. It appears that during these delays the entire GUI display contents of the batch ripper are not updated.

-brendan

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

1. Is there a flag you give (or can add) to rejects triggered by this rule to differentiate them from rejects flagged for other reasons?

No, it will be R2 before reject reasons are added.

Adding to an existing batch is planned from the start, but is full of hidden software 'gotchas' so perahps R2.

Disc load / unresponsiveness - all programs suffer this, even Nero (insert a blank DVD and watch Nero show (Unresponsive application in the title), it is the bad design of CD drivers and the system.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

No, it will be R2 before reject reasons are added.

Ok, that's fine for now. I believe/hope that the newly implemented ULCLI feature for unknown parameters (where any unknown --parameter=value string encountered on the command line gets stored as a variable with drive scope that can later be used for flow of control changes) will cope with a future "reject reasons" feature without requiring actual code updates to the ULCLI.

Adding to an existing batch is planned from the start, but is full of hidden software 'gotchas' so perahps R2.

Glad to hear that's on the todo list.

Disc load / unresponsiveness - all programs suffer this, even Nero (insert a blank DVD and watch Nero show (Unresponsive application in the title), it is the bad design of CD drivers and the system.

Sure, I do understand that certain Windows or even direct SPTI calls to optical drives can take a long time to respond.

However, if those calls were placed in their own separate thread then the delay doesn't have to hit other threads as long as the other threads are aware enough to not try to interact with the stuck thread or make calls that require the other thread's "stuck" call to finish.

Before these types of calls are made by the child thread, it should let the parent thread know that the child thread is about to be super-busy and it will therefore send a message to the parent when it is done and it shouldn't be queried in any way that might lock the parent until the child responds. e.g. perhaps the parent thread would then mark that drive as one in the GUI that shouldn't be have the drive status until the child thread is done.

It was just a bit frustrating to find the calls to the robotic handler (esp. pending unloads/rejects on a different drive) being delayed because a disc spinup/recognition or metadata check was taking a long time in an unrelated drive (or even on an unrelated robot!). It may have less impact in manual operation, of course, but these delays shave precious time off of the process during automated operation. In addition, I fear that my own drivers are going to get the "blame" for that.

Something to consider for future releases of the batch ripper, I suppose.

-brendan

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Two suggestions for the Batch Ripper Configuration interface...on the Configure drive subscreen, I'd like to see two changes:

1. Change the order from alphabetical to logical: Pre-Batch, Load, Unload, Reject, Post-Batch.

2. Add two additional buttons for open-tray and close-tray (or alternately one button for toggle-tray). It's useful, before going to the test subsubscreen, to make sure you're working with the right drive.

-brendan

[daxb]

Re: dBpoweramp Batch Ripper: Discussions

Another note on logic within the interface. In the batch ripper, pressing the metadata button brings up a configuration window while in CD ripper it refreshes the metadata for the currently loaded disc. I would suggest an options button rather than a metadata button in batch ripper. It would be more intuitive between both programs.

As I said in a previous post somewhere on these forums, I am assuming that some of the options in the CD Ripper ought to be mirrored in the batch ripper. Even better, get rid of redundant options and only have batch ripper specific options in the batch ripper.

Keep up the great work!