Alright.... after alot of fiddling both software and hardware wise, I've kinda given up. I need the polling feature to make sure that the disc actually went into the drive. I can't seem to find any decent linux alternatives to looking at what is in the drive from the CD-Rom standpoint. I really need to be able to poll the DC016RW as to what it thinks is in the drive.
Knight.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeremy, yes and no. The svn version supports most functions of the DC016RW device. My last comment from nearly a decade ago was that there was a compatibility issue between the HID layer and the USB layer, in that libcdorganizer boots off the HID-layer controller so it can control it, and that causes the DVD device to not read properly. I think I was wrong with that assumption at this point. Looking back at the history of this thread, if what Knight wrote is correct (and he has been very accurate with everything he has written, so I have no reason to doubt it), the HID layer detachment should not affect the drive inside the device, because it registers as a completely different device. So... I'll have to go back and investigate this.
Beyond that, nearly all vendor functions should work with the SVN version of libcdorganizer. If any functions do not work, please submit a bug report and I'll track it down to the best of my ability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
lcdoctl
lcdoctl: error while loading shared libraries: libcdorganizer.so.3.1.2: cannot open shared object file: No such file or directory Where is it expecting to find ibcdorganizer.so.3.1.2 ?
./lcdoctl -d dacal:1094e -x dacalcheckstatus
Causes the following:
The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
/trunk/libcdorganizer/src/plugins/dacaldc300.c:dacalcheckstatus(482) - Cannot store result in a NULL pointer!
Segmentation fault (core dumped)
Try to restart :
cdorganizerd -f
/trunk/libcdorganizer/src/cdorganizer/cdorganizerd.c:locksignal(186) - Could not open lock file: No such device or address
=
Where is the lockfile stored so as i can purge it?
More to follow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've updated the source and amd64 binary release for libcdorganizer after merging the 4.0.0 branch into the trunk... so try testing with that version. It looks like you were using the older 3.1.2 version from SVN. Working with your other questions, the lock file should have been under /var/run. Let me know what you experience when you use the newer version...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Had to run ldconfig -v to get the libiaries reconised.
I now get the following error when running the deamon.
cdorganizerd[1971]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/pluginmanager.c:pluginloader(27) - ltdlopen(/usr/lib/libcdorganizer/dacal): file not found
cdorganizerd[1971]: The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
cdorganizerd[1971]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/pluginmanager.c:pluginloader(27) - ltdlopen(/usr/lib/libcdorganizer/kds): file not found
cdorganizerd[1971]: Creating local socket: /tmp/cdorganizerd
cdorganizerd[1971]: Local socket '/tmp/cdorganizerd' created as 4
cdorganizerd[1971]: Entering server loop
usr/lib/libcdorganizer/ has a dacal.so and kds.so
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tryed running and pointing to the plugin DIR and error is still there:
cdorganizerd[2021]: /home/rich/svn/test/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/home/jeremy/usr/local/lib/libcdorganizer/dac al): file not found
cdorganizerd[2021]: The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
cdorganizerd[2021]: /home/rich/svn/test/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/home/jeremy/usr/local/lib/libcdorganizer/kds ): file not found
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure... what build options did you pass to cmake? You can get a console-based configuration browser by running 'ccmake' on the source directory, which should let you tweak whatever values you need to make it work properly in your environment.
The only dependencies for libcdorganizer are libusb-1.x and libtool.
Your plugin loading issue is a bit strange... I can successfully load my plugins in my testing environment. It has me scratching my head that the daemon appears to know that the dacal and kds plugins exist... but then claims they don't exist. Permissions, maybe? But then I don't understand why it wouldn't just say permission denied rather than file not found.
Also, the line "The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic" comes directly from the KDS plugin... which it's claiming it can't find. So it can't find it, yet it executed it.
Here's my output from my testing environment:
graendal /home/rich/local/usr/sbin # LD_LIBRARY_PATH=/home/rich/local/usr/lib ./cdorganizerd -f
./cdorganizerd[25594]: The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
./cdorganizerd[25594]: Creating local socket: /tmp/cdorganizerd
./cdorganizerd[25594]: Local socket '/tmp/cdorganizerd' created as 13
./cdorganizerd[25594]: Entering server loop
Note that in my testing environment, I defined LD_LIBRARY_PATH because this is a local install rather than a system install (ie, libs are in /home/rich/local/usr/lib)
Last edit: KShots 2018-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Help:
vendor device_id List vendor commands and exit
exec cmd_id data device_id Execute a given vendor command with the given data (. for NULL) on the given device id
The only way this will work is:
lcdoctl -d dacal:0001094E exec 0 dacal:0001094E
I.E Device ID twice.
lcdoctl -d dacal:0001094E exec 3 dacal:0001094E - No response. Just Command executed sucssfully. Should give status?
Commands that don't work:
lcdoctl -d dacal:0001094E eject slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(409) - At this point
lcdoctl -d dacal:0001094E insert slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(319) - At this point
Do you have a document with the control commands:
For example how did you discover 0x10 = LED Off?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can see I screwed up the help - the vendor command should simply look
at the '-d' argument, not requiring an additional device_id after the
vendor command. At least, that's how it works programmatically. So the
proper usage would be:
lcdoctl -d dacal:0001094E vendor
The control commands were reverse-engineered using a USB sniffer and the
Windows control API to trigger and capture event traffic. As such, some
commands are supported... if you know how to use it. The 'get status' is
a good example. It was unclear to me when I wrote the command what the
expected responses were, so I capture it as a void * and return it to
the client through the library. lcdoctl isn't smart enough to know how
to handle the response, and given it's undocumented, I'm not sure how to
handle it myself without a fair amount of trial & error. Another client
could be written that is smart enough to handle the response, but the
generic utility probably won't do.
For the eject and insert commands, I see my error condition codes are
inconsistent (returns a -1 on error, I'm checking for a 0), but you're
also using it wrong. I'll update the code, but the correct usage would
be:
lcdoctl -d dacal:0001094E eject 10
lcdoctl -d dacal:0001094E insert 10
It's interpreting the string "slot" to mean slot 0, and returning 0 from
the function (apparently it executes successfully if there are no error
messages from the dacal plugin itself, but 0 would not be a legal slot).
I'll update the plugins to include some boundary testing so accepted
input should range from 0 < slot <= max_slots, and throw a sensible
error message if it's out of range.
On 2018-03-13 09:44, Jeremy Turner wrote:
Hi
I think there maybe an issue with lcdoctl:
Help:
vendor device_id List vendor commands and exit
exec cmd_id data device_id Execute a given vendor command with the
given data (. for NULL) on the given device id
The only way this will work is:
lcdoctl -d dacal:0001094E exec 0 dacal:0001094E
I.E Device ID twice.
lcdoctl -d dacal:0001094E exec 3 dacal:0001094E - No response. Just
Command executed sucssfully. Should give status?
COMMANDS THAT DON'T WORK:
lcdoctl -d dacal:0001094E eject slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(409)
- At this point
lcdoctl -d dacal:0001094E insert slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(319)
- At this point
lcdoctl doesn't parse the data returned from vendor functions, as they
could be pretty much anything (strings, ints, binary blobs, etc).
For adding additional commands, you'll need to modify dacal.c (the
plugin) to support additional functions. You'll need to add any new
commands to the exec function and the list function.
On 2018-03-13 14:57, Jeremy Turner wrote:
Hi
Thanks
Can the error be displayed as is in lcdoctl ?
I belive my unit may also use some commands that you have not sniffed.
I would like to be able to send aborty commands ie 0x10 0x15 etc
Does lcdoctl process the commands or can i pass a command though and
create a new fucntion in the plug in to pass the command out to the
device.
Nearly there. Seems they dont want to make it easy!
The returned data is simply dropped by lcdoctl. If you want to monitor
the returned data, you'll need to tie into the library functions
directly. I'd considered some advanced tuning on lcdoctl that lets the
user attempt to define the data returned for user-friendly parsing, but
had not implemented it. Essentially, I'd need to write a parser for each
type of data (char, string, short, long, binary blob (as hex? ), etc).
Even then, depending on the data it may not handle it correctly - for
example, if a vendor function were to return an array of shorts. Best I
could offer is a hex dump of the data in that case.
If you want to use it for development purposes, it is stored in a
temporary buffer after returning from the exec function. You could point
a debugger at the buffer to see what's in there.
I could probably also write a quick hack function to dump the returned
data to a file, which would not require any kind of parsing on the part
of lcdoctl.
On 2018-03-13 16:20, Jeremy Turner wrote:
Hi
Where is the returned data? Can this be output to the logs?
The vendor functions are implemented exclusively in the plugins. lcdoctl
simply passes them through. There shouldn't be any changes necessary in
lcdoctl to add more functions.
On 2018-03-13 16:40, Jeremy Turner wrote:
Hi
Quick hack sounds great.
My c experience is only limited. So any help will be great.
You'll need to add any new commands to the exec function and the
list function.
eject is working now. The unit is at my office so cannot test insert.
These command fails.
lcdoctl -d dacal:0001094E exec 4.
results in damon crash with error:
Segmentation fault (core dumped)
As I read the help this should show the slot number in the drive
lcdoctl -d dacal:0001094E exec 6 .
results in damon crash with error:
/home/jeremy/libcdorganizer-code/libcdorganizer/src/plugin/dacal/dacal.c:dacal_eject_drive(247) - Device sent strange response
cdorganizerd[6987]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/msg.c:handle_exec_vendor_cmd(125) - Failed to execute vendor command id 6 on device id 'dacal:0001094E'
cdorganizerd[6987]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/loop.c:loop(196) - At this point
Any idea?
Last edit: Jeremy Turner 2018-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alright.... after alot of fiddling both software and hardware wise, I've kinda given up. I need the polling feature to make sure that the disc actually went into the drive. I can't seem to find any decent linux alternatives to looking at what is in the drive from the CD-Rom standpoint. I really need to be able to poll the DC016RW as to what it thinks is in the drive.
Knight.
I'll look into it
Hi Did the DC016 ever get implmented?
Jeremy, yes and no. The svn version supports most functions of the DC016RW device. My last comment from nearly a decade ago was that there was a compatibility issue between the HID layer and the USB layer, in that libcdorganizer boots off the HID-layer controller so it can control it, and that causes the DVD device to not read properly. I think I was wrong with that assumption at this point. Looking back at the history of this thread, if what Knight wrote is correct (and he has been very accurate with everything he has written, so I have no reason to doubt it), the HID layer detachment should not affect the drive inside the device, because it registers as a completely different device. So... I'll have to go back and investigate this.
Beyond that, nearly all vendor functions should work with the SVN version of libcdorganizer. If any functions do not work, please submit a bug report and I'll track it down to the best of my ability.
Hi
You are corrext there are two seperate USB devices. 1 is the changer the other the drive.
I have a Blu-Ray version the intention is to add this to my disc copier to stack up 100 discs copy them and then repeate with the next batch.
I think there will be some trail and error to find some of the missing functions.
I cannot find any API docs do you have these?
I can find the SVN link but not sure how to get this to work once its complied any pointers would be a great help.
Thanks
Update:
I have got the SVN version installed.
The following issues arise:
lcdoctl
lcdoctl: error while loading shared libraries: libcdorganizer.so.3.1.2: cannot open shared object file: No such file or directory
Where is it expecting to find ibcdorganizer.so.3.1.2 ?
./lcdoctl -d dacal:1094e -x dacalcheckstatus
Causes the following:
The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
/trunk/libcdorganizer/src/plugins/dacaldc300.c:dacalcheckstatus(482) - Cannot store result in a NULL pointer!
Segmentation fault (core dumped)
Try to restart :
cdorganizerd -f
/trunk/libcdorganizer/src/cdorganizer/cdorganizerd.c:locksignal(186) - Could not open lock file: No such device or address
=
Where is the lockfile stored so as i can purge it?
More to follow.
Jeremy,
I've updated the source and amd64 binary release for libcdorganizer after merging the 4.0.0 branch into the trunk... so try testing with that version. It looks like you were using the older 3.1.2 version from SVN. Working with your other questions, the lock file should have been under /var/run. Let me know what you experience when you use the newer version...
Hi
I have updated.
Had to run ldconfig -v to get the libiaries reconised.
I now get the following error when running the deamon.
cdorganizerd[1971]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/pluginmanager.c:pluginloader(27) - ltdlopen(/usr/lib/libcdorganizer/dacal): file not found
cdorganizerd[1971]: The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
cdorganizerd[1971]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/pluginmanager.c:pluginloader(27) - ltdlopen(/usr/lib/libcdorganizer/kds): file not found
cdorganizerd[1971]: Creating local socket: /tmp/cdorganizerd
cdorganizerd[1971]: Local socket '/tmp/cdorganizerd' created as 4
cdorganizerd[1971]: Entering server loop
usr/lib/libcdorganizer/ has a dacal.so and kds.so
Thanks
Hi
Coped over the precomplied cdoranizerd. The error stopped so I am missing somthing to complie. Any idea on the dependiencies.
Now if i run lcdoctl list no devices are shown. The device appeared in the old version and i could send some commands.
Help.....
Thanks
Hi
Tryed running and pointing to the plugin DIR and error is still there:
cdorganizerd[2021]: /home/rich/svn/test/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/home/jeremy/usr/local/lib/libcdorganizer/dac al): file not found
cdorganizerd[2021]: The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic
cdorganizerd[2021]: /home/rich/svn/test/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/home/jeremy/usr/local/lib/libcdorganizer/kds ): file not found
Thanks
Jeremy,
Not sure... what build options did you pass to cmake? You can get a console-based configuration browser by running 'ccmake' on the source directory, which should let you tweak whatever values you need to make it work properly in your environment.
The only dependencies for libcdorganizer are libusb-1.x and libtool.
Your plugin loading issue is a bit strange... I can successfully load my plugins in my testing environment. It has me scratching my head that the daemon appears to know that the dacal and kds plugins exist... but then claims they don't exist. Permissions, maybe? But then I don't understand why it wouldn't just say permission denied rather than file not found.
Also, the line "The KDS plugin is only capable of running a single device at a time as a unique id has not yet been deciphered from the USB traffic" comes directly from the KDS plugin... which it's claiming it can't find. So it can't find it, yet it executed it.
Here's my output from my testing environment:
Note that in my testing environment, I defined LD_LIBRARY_PATH because this is a local install rather than a system install (ie, libs are in /home/rich/local/usr/lib)
Last edit: KShots 2018-03-12
Which model are you using? The Dacal DC-300, the DC016RW, or something else?
Hi
Ok so used ccmake and fixed the issue. The configuration was pointing to a different version of libusb.
lcdoctl now shows the following:
Daemon reports the following device IDs:
Trying to run:
lcdoctl vendor dacal:0001094E
Returns:
* listing vendor commands requires a device argument*
What device argument ?
Thanks
Hi
I think there maybe an issue with lcdoctl:
Help:
vendor device_id List vendor commands and exit
exec cmd_id data device_id Execute a given vendor command with the given data (. for NULL) on the given device id
The only way this will work is:
lcdoctl -d dacal:0001094E exec 0 dacal:0001094E
I.E Device ID twice.
lcdoctl -d dacal:0001094E exec 3 dacal:0001094E - No response. Just Command executed sucssfully. Should give status?
Commands that don't work:
lcdoctl -d dacal:0001094E eject slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(409) - At this point
lcdoctl -d dacal:0001094E insert slot 10
/home/jeremy/libcdorganizer-code/libcdorganizer/src/utility/main.c:main(319) - At this point
Do you have a document with the control commands:
For example how did you discover 0x10 = LED Off?
Thanks
Ok, now we're getting somewhere!
I can see I screwed up the help - the vendor command should simply look
at the '-d' argument, not requiring an additional device_id after the
vendor command. At least, that's how it works programmatically. So the
proper usage would be:
lcdoctl -d dacal:0001094E vendor
The control commands were reverse-engineered using a USB sniffer and the
Windows control API to trigger and capture event traffic. As such, some
commands are supported... if you know how to use it. The 'get status' is
a good example. It was unclear to me when I wrote the command what the
expected responses were, so I capture it as a void * and return it to
the client through the library. lcdoctl isn't smart enough to know how
to handle the response, and given it's undocumented, I'm not sure how to
handle it myself without a fair amount of trial & error. Another client
could be written that is smart enough to handle the response, but the
generic utility probably won't do.
For the eject and insert commands, I see my error condition codes are
inconsistent (returns a -1 on error, I'm checking for a 0), but you're
also using it wrong. I'll update the code, but the correct usage would
be:
lcdoctl -d dacal:0001094E eject 10
lcdoctl -d dacal:0001094E insert 10
It's interpreting the string "slot" to mean slot 0, and returning 0 from
the function (apparently it executes successfully if there are no error
messages from the dacal plugin itself, but 0 would not be a legal slot).
I'll update the plugins to include some boundary testing so accepted
input should range from 0 < slot <= max_slots, and throw a sensible
error message if it's out of range.
On 2018-03-13 09:44, Jeremy Turner wrote:
--
Life without passion is death in disguise
Hi
Thanks
Can the error be displayed as is in lcdoctl ?
I belive my unit may also use some commands that you have not sniffed.
I would like to be able to send aborty commands ie 0x10 0x15 etc
Does lcdoctl process the commands or can i pass a command though and create a new fucntion in the plug in to pass the command out to the device.
Nearly there. Seems they dont want to make it easy!
lcdoctl doesn't parse the data returned from vendor functions, as they
could be pretty much anything (strings, ints, binary blobs, etc).
For adding additional commands, you'll need to modify dacal.c (the
plugin) to support additional functions. You'll need to add any new
commands to the exec function and the list function.
On 2018-03-13 14:57, Jeremy Turner wrote:
--
Life without passion is death in disguise
Hi
Where is the returned data? Can this be output to the logs?
The returned data is simply dropped by lcdoctl. If you want to monitor
the returned data, you'll need to tie into the library functions
directly. I'd considered some advanced tuning on lcdoctl that lets the
user attempt to define the data returned for user-friendly parsing, but
had not implemented it. Essentially, I'd need to write a parser for each
type of data (char, string, short, long, binary blob (as hex? ), etc).
Even then, depending on the data it may not handle it correctly - for
example, if a vendor function were to return an array of shorts. Best I
could offer is a hex dump of the data in that case.
If you want to use it for development purposes, it is stored in a
temporary buffer after returning from the exec function. You could point
a debugger at the buffer to see what's in there.
I could probably also write a quick hack function to dump the returned
data to a file, which would not require any kind of parsing on the part
of lcdoctl.
On 2018-03-13 16:20, Jeremy Turner wrote:
--
Life without passion is death in disguise
Hi
Quick hack sounds great.
My c experience is only limited. So any help will be great.
Is this in lcdoctl as well as dacal.c ?
Ok, I'll see what I can crank out.
The vendor functions are implemented exclusively in the plugins. lcdoctl
simply passes them through. There shouldn't be any changes necessary in
lcdoctl to add more functions.
On 2018-03-13 16:40, Jeremy Turner wrote:
--
Life without passion is death in disguise
Thanks
eject is working now. The unit is at my office so cannot test insert.
These command fails.
lcdoctl -d dacal:0001094E exec 4.
results in damon crash with error:
As I read the help this should show the slot number in the drive
lcdoctl -d dacal:0001094E exec 6 .
results in damon crash with error:
/home/jeremy/libcdorganizer-code/libcdorganizer/src/plugin/dacal/dacal.c:dacal_eject_drive(247) - Device sent strange response
cdorganizerd[6987]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/msg.c:handle_exec_vendor_cmd(125) - Failed to execute vendor command id 6 on device id 'dacal:0001094E'
cdorganizerd[6987]: /home/jeremy/libcdorganizer-code/libcdorganizer/src/daemon/loop.c:loop(196) - At this point
Any idea?
Last edit: Jeremy Turner 2018-03-13
I've done some refactoring that may have affected these... see what happens with revision 161.
Hi
Testing out the new version:
lcdoctl -d dacal:0001094E exec execredirect 3 dacal:0001094E /tmp/test.txt
Results in: Segmentation fault (core dumped)
What am I missing?
Thanks
Jeremy
Opps seen it. Sorry