dBpoweramp Batch Ripper: Discussions

[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

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...

[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.

[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

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.

[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.

[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

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

[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

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.

[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

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

Good catch Brendan...as it happens I had just finished connecting and disconnecting a USB stick prior to this happening. I guess I will have to reboot to get windows to recognise this drive again.

thanks

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

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.

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.

Ok guys (and gals), for any of you who are using the Batch Ripper with the Powerfile/Sony disc changers, I am planning to write a new "driver" for these units. I found this to be necessary as the driver supplied with the Batch Ripper application is somewhat limited in its management of these devices.

Specifically I am writing this driver to address the following needs/desires of my own.
1) Support for using both drives within the Powerfile simultaneously.
2) Mount discs by their position not simply sequentially. This will minimize load time.
3) Support multiple powerfile/sony devices within the same batch.
4) Allow the user to specify the start and stop discs for the ripping process.
5) Batch report listing rejected discs.

In order to make this new driver as full-featured as possible, I would like to get the input of other users of the Batch Ripper with these devices. What I would like to hear is what features of the device (which are not supported currently) you would like to see handled by the Batch Ripper.

Thanks,
Steve

[bhoar]

Re: dBpoweramp Batch Ripper: Discussions

I can do testing, but I don't have many ideas. I suggest creating a new topic here in the beta forum (using your last post) just for development for the XL1B/Powerfile units and then cross-posting to the AVS Forum XL1B{,2,3} thread(s) inviting others to join in and participate.

However, set expectations in the invitation - this won't be a free for all asking for the batch ripper to do everything, but rather, getting the most out of the xl1b/powerfile units within the contraints of the batch ripper (e.g. don't ask for dvd ripping, etc.).

-brendan

[sredmyer]

Re: dBpoweramp Batch Ripper: Discussions

I can do testing, but I don't have many ideas. I suggest creating a new topic here in the beta forum (using your last post) just for development for the XL1B/Powerfile units and then cross-posting to the AVS Forum XL1B{,2,3} thread(s) inviting others to join in and participate.

However, set expectations in the invitation - this won't be a free for all asking for the batch ripper to do everything, but rather, getting the most out of the xl1b/powerfile units within the contraints of the batch ripper (e.g. don't ask for dvd ripping, etc.).

-brendan

Great idea...but I have no idea how to:
1) use my last post to create a new topic
2) cross post to the AVS forum