dBpoweramp Batch Ripper: Discussions

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Perhaps your drive letters are shifting around when you disconnect/connect drives (or drives in changers) or when you reboot. Also, if you ran the config when the drives weren't attached.

Whenever the batch ripper or it's configuration (same .exe different parameters) starts, it does some sanity checking. It goes through the table of drive letters it stored per-drive configurations in...first checking to verify that the maker/model (and firmware) match what was configured. If they do not, that drive letter is marked as misconfigured and you will have to manually reconfigure it. If unconfigured drive letters exist now, those will also need to be configured.

If it happens to be that an unconfigured drive letter points to a real drive that used to be configured at another drive letter, it has no way of knowing that's the same drive.

-brendan

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

Can anybody tell me why I occasionaly get a message stating "Drive Different To Configured" in the Batch Ripper right next to one (or more) of the drives. Normally it says "Medium Changer" here. When this message is displayed I try to re-configure the drive and test all the CLI calls. All CLI call report successful and I here the changer doing its thing but even after doing this the message remains.

Any thoughts
Steve

More Info:
When this message is there the drive is not seen at all in CD Ripper nor Windows Explorer. It still works fine in the Batch Ripper though.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

If you get something working I am not bothered either way. You might find the code I sent you, just needs the device ID number tweaking.

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

No, what I am saying is that my load.exe and unload.exe, for example are duplicates of the same file, just with different names. The behavior differences exist because the command line is different, not because the executable itself is different.

-brendan

Ah, I see

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

So are you saying that Spoon changed the Batch Ripper for robots so that it only called 1 file instead of the five? I wonder if I could get the same concession for changers. I would rather have a single executable that took the action (load, reject, unload, etc.) as another command line argument.



Yes this one architectural decision was indeed very wise.

No, what I am saying is that my load.exe and unload.exe, for example are duplicates of the same file, just with different names. The behavior differences exist because the command line is different, not because the executable itself is different.

-brendan

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

So are you saying that Spoon changed the Batch Ripper for robots so that it only called 1 file instead of the five? I wonder if I could get the same concession for changers. I would rather have a single executable that took the action (load, reject, unload, etc.) as another command line argument.



Yes this one architectural decision was indeed very wise.

Spoon,

Would you have an issue if continue down this development path with the idea being that when finished I will provide you with the "driver" to make available to any other user who wanted it.

I ask because I would like to ask other users here what features they would like to see and try to add those features to the driver as well as features I have requested.

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

After a friendly back and forth with spoon to clarify some things, get some small requests implemented and getting shot down on other requests, serial robots are a go. The same executable is used for all five commands, called with different parameters for each, and supports at least a dozen brands/models of robots.

So are you saying that Spoon changed the Batch Ripper for robots so that it only called 1 file instead of the five? I wonder if I could get the same concession for changers. I would rather have a single executable that took the action (load, reject, unload, etc.) as another command line argument.

* I think this makes me appreciate spoon's approach to the batch ripper<->driver interface even more. Keep it simple, clean and well thought out...and people will build drivers for you...out of whatever tools they have at their disposal.

Yes this one architectural decision was indeed very wise.

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Well I have had a look at the driver code Spoon sent. I have a significant problem...it is written in C++. I had assumed when he asked if I had VS 2005 that the code was in some managed .Net language (VB, C#). Well I guess thats what I get for assuming. My C++ skills are very rusty as I haven't done any C++ is better than 10 years now.

I think I may have come upon a more workable solution for my need (and skill set) after re-reading some of Brendans previous posts.

What I think I can do is to create my own Load.exe, Reject.exe and unload.exe programs. Then drop my versions inplace of the supplied ones. These exes of mine would simply be wrappers around the MediaChanger.exe. Additionaly these exes of mine would need to follow the calling convention described by Spoon here http://forum.dbpoweramp.com/showthre...0285#post70285. In this way I could completely control the way the changer is managed to include what slot is loaded to what drive for every load call.

Brendan can you confirm the viability of this concept.

Short answer: Yes most definitely.

---

Long answer:

When the first alpha of the batch ripper came out with the drivers for the datatronics-family (baxter, etc.) type loaders, I took at look at how the drivers were configured, asked spoon a few questions (which may have led to his posting the calling convention at that time), and spied on the process interaction using Process Explorer's ability to track the full command line used.

I quickly came to the conclusion that I should put aside what I had been working on, which was an app to monitor the GUI of applications and operate robots 'around' non-robotic apps and instead write a command line client that could be called in the same manner as Illustrate's own drivers (but could also be used in other ways as well for other projects).

After a friendly back and forth with spoon to clarify some things, get some small requests implemented and getting shot down on other requests, serial robots are a go. The same executable is used for all five commands, called with different parameters for each, and supports at least a dozen brands/models of robots.

And heck...my drivers are written in AutoIT for frak sake.*

So, yes, most definitely, that approach will work.

---

I'm glad you took a look back over what I wrote and I hope it comes in handy going forward.

Also, don't forget about the pre-batch.exe and post-batch.exe. They can be very useful places for handling system state checking and adjustments for multiple-drive devices, such as the powerfiles you're trying to support.

-brendan

* I think this makes me appreciate spoon's approach to the batch ripper<->driver interface even more. Keep it simple, clean and well thought out...and people will build drivers for you...out of whatever tools they have at their disposal.

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

That's awesome guys. Hope this works out!

-brendan

Well I have had a look at the driver code Spoon sent. I have a significant problem...it is written in C++. I had assumed when he asked if I had VS 2005 that the code was in some managed .Net language (VB, C#). Well I guess thats what I get for assuming. My C++ skills are very rusty as I haven't done any C++ is better than 10 years now.

I think I may have come upon a more workable solution for my needs (and skill set) after re-reading some of Brendans previous posts.

What I think I can do is to create my own Load.exe, Reject.exe and unload.exe programs. Then drop my versions inplace of the supplied ones. These exes of mine would simply be wrappers around the MediaChanger.exe. Additionaly these exes of mine would need to follow the calling convention described by Spoon here http://forum.dbpoweramp.com/showthre...0285#post70285. In this way I could completely control the way the changer is managed to include what slot is loaded to what drive for every load call.

Brendan can you confirm the viability of this concept.

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

The problem I had is that I did some test conversion with the CD Ripper and the Batch ripper switched from FLAC to Test, so it wasn't really ripping...

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

Eli - one thing I've noticed in the dbpa suite is that the drive settings (burst vs. secure, secure settings) are global, not set per drive.

-brendan

[EliC]

Re: dBpoweramp Batch Ripper: Discussions

I am having problems using the Batch Ripper at the same time as using the CD Ripper. It would be nice if the batch ripper had its own menu for setting a rip to directory, codec, and dsps.

I lost a large amount of work because I opened the CD Ripper while the batch ripper was running and change some settings on a drive that was not set up for the batch ripper, but the batch ripper picked up these changes in the middle of a batch.

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

At the top is manual input and review under freedb.

I have your email and will be sending code shortly.

Thanks...I knew it was some setting I just could not find it.

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

>Interestingly, Ctl-Alt-Del is not working during this crash

Nothing on the system should be able to block Ctrl Alt Del...

[Spoon]

Re: dBpoweramp Batch Ripper: Discussions

At the top is manual input and review under freedb.

I have your email and will be sending code shortly.