libcdorganizer Activity
Brought to you by:
kshots
Activity for libcdorganizer
-
Neal Logan posted a comment on ticket #2
Alas. I am not C programmer but I will give it try to see if I can set it up properly and see what is going on. Not a lot of hope that I will be successful at this. The Dacal has been sitting idle on my system for a while now so I am used to it being furniture and not useful on my Linux system. Thanks for trying to help.
-
KShots posted a comment on ticket #2
Actually, I was wrong - it shouldn't return "0" on success, it should return a positive number representing the file descriptor assigned. In your case, it successfully opened dacal.so and gave it a file descriptor of 3, then read it, and closed it (all successfully)... so yes, it definately successfully loaded the plugin. As far as uninstalling and starting over, that's usually up to the package manager. If you didn't use a package manager, you can see where cmake installs each file by setting up...
-
I did the trace and there does seem to be some problems. "dacal.so" returns a code of 3 and it seems to be looking for file "dacal.la" which returns a code of -1 (file not found). But, even before then, two files seem to be missing: access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) From what I read, ld.so files are not issues, just glibc checking to see if the files are there as a standard routine....
-
I did the trace and there does seem to be some problems. "dacal.so" returns a code of 3 and it seems to be looking for file "dacal.la" which returns a code of -1 (file not found). But, even before then, two files seem to be missing: access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) From what I read, ld.so files are not issues, just glibc checking to see if the files are there as a standard routine....
-
I did the trace and there does seem to be some problems. "dacal.so" returns a code of 3 and it seems to be looking for file "dacal.la" which returns a code of -1 (file not found). But, even before then, two files seem to be missing: access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) From what I read, ld.so files are not issues, just glibc checking to see if the files are there as a standard routine....
-
I did the trace and there does seem to be some problems. "dacal.so" returns a code of 3 and it seems to be looking for file "dacal.la" which returns a code of -1 (file not found). But, even before then, two files seem to be missing: access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) From what I read, ld.so files are not issues, just glibc checking to see if the files are there as a standard routine....
-
No, if you never had a previous version installed, that shouldn't be a possibility :(
-
To respond to your version question, it was all expanded from "libcdorganizer-src-4.0.0.tar.bz2". If the wrong version is in there, then that is a possiblity.
-
To respond to your version question, it was all expanded from "libcdorganizer-gnu-linux-amd64-4.0.0.tar.bz2". If the wrong version is in there, then that is a possiblity.
-
Ok, so we'll say that's not a possibility. Let's make 100% sure it's loading the plugin. Use 'strace' to run the daemon. It will put out a TONNE of data, be warned. Look for any lines involving 'dacal.so', and more specifically, make sure that one such line returns "0" (success). ... if it's truly loading the plugin and not finding the organizer, I'm not sure what else to do at this point. If you know any C, I'd recommend running the dacal.c constructor code through a debugger (set a breakpoint in...
-
Maybe it fails to load the "dacal" and "kds" files (ergo file load error) but loads the .so versions ok Tried it as Root, no success. same result.
-
Maybe it fails to load the "dacal" and "kds" files but loads the .so versions ok Tried it as Root, no success. same result.
-
Neal, The daemon searches the plugin directory and tries to load each file there. I've been puzzled why it puts out those "file not found" messages, but libtool appears to try both with and without a '.so' extension (and fails without the extension, but succeeds with it). From the output, it is successfully loading the KDS plugin (despite the message) because the notification about the KDS plugin capabilities is from the KDS plugin. So... if it's loading the plugin successfully, it will poll the...
-
I did as you requested as follows: neal@Lith-Serv:~$ sudo cdorganizerd -P /usr/lib/libcdorganizer/ -f cdorganizerd[15575]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/usr/lib/libcdorganizer/dacal): file not found cdorganizerd[15575]: 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[15575]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27)...
-
Only other thing I can think of is if it's not loading the dacal plugin. It looks for the vendor ID 04B4 and product ID 5A9B to find the organizer, and if the plugin finds it the daemon outputs the string "Found a device for the dacal plugin at (some address)". Can you find where your plugin was installed (should be 'dacal.so') and tell the daemon where to find it via the '-P' option? If you don't have a DC-016RW, the svn version shouldn't make much of a difference... it has a bit more tolerance...
-
Only other thing I can think of is if it's not loading the dacal plugin. It looks for the vendor ID 04B4 and product ID 5A9B to find the organizer, and if the plugin finds it the daemon outputs the string "Found a device for the dacal plugin at (some address)". Can you find where your plugin was installed (should be 'dacal.so') and tell the daemon where to find it via the '-P' option?
-
Nope, it is a Dacal 300 Model on the box says DC-300 This is new for me, so what is the SVN version? Or, I should ask, where is the latest SVN version? Also this unit does not have a built in media player
-
Nope, it is a Dacal 300 Model on the box says DC-300 This is new for me, so what is the SVN version? Or, I should ask, where is the latest SVN version?
-
Nope, it is a Dacal 300 Model on the box says DC-300 This is new for me, so what is the SVN version?
-
Nope, it is a Dacal 300 Model on the box says DC-300
-
Also, just to confirm, you're using the latest released version, right? From your lsusb output, it showed you might have a Dacal 016RW, which wasn't supported until recently. I'd even go so far as to say that after some recent back-and-forth with another recent user, that I'd recommend using the latest version from the svn for the DC-016RW. Can you try the svn version?
-
Also, just to confirm, you're using the latest released version, right? From your lsusb output, it showed you had a Dacal 016RW, which wasn't supported until recently. I'd even go so far as to say that after some recent back-and-forth with another recent user, that I'd recommend using the latest version from the svn for the DC-016RW. Can you try the svn version?
-
Sorry. got called away. Returned absolutely nothing neal@Lith-Serv:~$ lcdoctl list all Daemon reports the following device IDs: (blank)
-
Sorry. got called away. Returned absolutely nothing
-
Ok, the traffic on the daemon looks appropriate... did the client not return anything useful?
-
Sorry, let me clarify, ran lcdoctl list all in the second terminal and got no devices found
-
Sorry, let me clarify, ran lcdoctl list all in the second terminal
-
I opened another terminal session and ran the following (since the first terminal window was in a loop). neal@Lith-Serv:~$ lcdoctl list all organizerd[12988]: Creating local socket: /tmp/cdorganizerd cdorganizerd[12988]: Local socket '/tmp/cdorganizerd' created as 4 cdorganizerd[12988]: Entering server loop cdorganizerd[12988]: Accepted a connection on 6 from a local client cdorganizerd[12988]: Received a message from a local client on 6 cdorganizerd[12988]: handling list organizers request cdorganizerd[12988]:...
-
Killed all cdorganizerd processes. There was no /tmp/cdorganizerd when I looked. Ran cdorganizerd in foreground as follows: neal@Lith-Serv:~$ sudo cdorganizerd -f cdorganizerd[12988]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/usr/lib/libcdorganizer/dacal): file not found cdorganizerd[12988]: 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[12988]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27)...
-
Looks like it's aborting because something else is already bound to the socket. Check to see if it's already running, and if not, delete the socket (it's stale) and try again. If it is running, kill it and run it again in the foreground
-
Neal, Pass the daemon a '-f' parameter to run in the foreground, so you do the following: sudo cdorganizerd -f You can also run it with '-h' to show what other knobs you can tweak.
-
Ok, I figured out how to run it in foreground. I got the following: sudo cdorganizerd -f [sudo] password for neal: cdorganizerd[11653]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27) - lt_dlopen(/usr/lib/libcdorganizer/dacal): file not found cdorganizerd[11653]: 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[11653]: /home/neal/Downloads/libcdorganizer/src/daemon/plugin_manager.c:plugin_loader(27)...
-
I did start the daemon with "sudo cdorganizerd" (just in case I needed supervisor authority to start it correctly. That should give me authority I believe. Also aince I am the only person on this system, I have read/write control I would think, but if not, what should I check to verify? How do I start it in the foreground (sorry for the stupid question)? I thought entering it in terminal mode after the system starts does that? I did not create any auto daemon startup on boot yet. When I start it...
-
I did start the daemon with "sudo cdorganizerd" (just in case I needed supervisor authority to start it correctly. That should give me authority I believe). Also since I am the only person on this system, I have read/write control I would think, but if not, what should I check to verify? How do I start it in the foreground (sorry for the stupid question)? I thought entering it in terminal mode after the system starts does that? I did not create any auto daemon startup on boot yet. When I start it...
-
Neal, Let's dig into this a bit... To confirm, you are running the daemon, right? I assume so because you did at one point find that the socket was created. If running into problems, recommend running the daemon in the foreground to observe any output. Make sure you are running the daemon with a user that has read/write access to the device. The lcdoctl utility can be run by any user (non-root). Let's start with that...
-
Hi KShots Sorry, on further investigation and reading your file, I do see a /tmp/organizerd sock file get created but once I execute the lcdoctl command and it fails, it disappears. Still do not see my Dacal on the list though. sudo lcdoctl list Daemon reports the following device IDs: Any suggestions. It does get reconginzed om boot and lsusb shows it: lsusb (excerpt) Bus 001 Device 009: ID 04b4:5a9b Cypress Semiconductor Corp. Dacal CD/DVD Library D-101/DC-300/DC-016RW Bus 001 Device 007: ID 04b4:5203...
-
Hi KShots Just got back to trying to work on getting my Dacal 300 working on Ubuntu. My Dacal does not get listed (nor does any other device) when I try to list libraries (ldoctl list), Also, when I try to do any commands using my library's ID (04b4:5a9b) I get failure to connect issues. E.G. when I tried lcdoctl vendor 04b4:5a9b, I get /home/neal/Downloads/libcdorganizer/src/lib/cdorganizer_controller.c:cdo_controller_init_local(48) - connect: No such file or directory Failed to connect to a local...
-
Hi Thanks for that info Daemon was started ok but when I try to list devices, I get the following: "/home/neal/Downloads/libcdorganizer/src/lib/cdorganizer_controller.c:cdo_controller_init_local(48) - connect: No such file or directory Failed to connect to a local socket at /tmp/cdorganizerd" Now, I know my Dacal was recognized at boot up and is listed during the boot but it seems to me that the Daemon is not seeing it. Am I interpreting this error correctly? Any suggestions? Also, when I go to the...
-
Neal, Sounds like you're almost there. You can start the daemon (cdorganizerd) with the '-h' or '--help' parameter to give you some idea of what parameters are available. Man pages are also installed - try "man cdorganizerd" and "man lcdoctl", although if you had to reconfigure ldconfig to get it running, the man pages may not have installed to the system. At a high level, the concept is that the daemon controls the organizer and runs in the background, and you can use lcdoctl to talk to the daemon...
-
Kind of Newbie needs help to get Dacal 300 operational on Ubuntu
-
* Fixed execution of insert disc code so it only executes DC016-specific code on insert on a DC016 device, rather than both DC016 and DC300 code
-
* Fixed issues with the dacal plugin returning messages to the daemon on the DC016RW for vendor command 4
-
* Fixed some boundary-checking cases for command execution
-
Jeremy Turner posted a comment on discussion Open Discussion
lcdoctl -d dacal:0001094E execredirect 4 /tmp/test.txt Segmentation fault (core dumped)
-
lcdoctl -d dacal:0001094E execredirect 4 /tmp/test.txt Segmentation fault (core dumped)
-
Try:lcdoctl -d dacal:0001094E execredirect 4 /tmp/test.txtStill shouldn't segfault, though... I'll have to investigate that.On Apr 4, 2018 11:59, Jeremy Turner <fabltd@users.sourceforge.net> wrote:Ok this fails: lcdoctl -d dacal:0001094E execredirect 4 dacal:0001094E /tmp/test.txt Results in: Segmentation fault (core dumped) Support for the DC016RW Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/libcdorganizer/discussion/613438/ To unsubscribe from further messages,...
-
Ok this fails: lcdoctl -d dacal:0001094E execredirect 4 dacal:0001094E /tmp/test.txt Results in: Segmentation fault (core dumped)
-
Opps seen it. Sorry
-
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
-
I've done some refactoring that may have affected these... see what happens with revision 161.
-
* Fixed busy loop error in code that prevented all functions from working properly...
-
* Refactored the dacal plugin to call a function for its busy wait loops rather than pasting the same loops everywhere...
-
* Fixed pointer handling on vendor functions...
-
* Updated the interface to support bidirectional communication with plugins. I thought this was ironed out 10 years ago, but some refactoring was in order to handle error conditions in a sane manner
-
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: 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)...
-
Thanks eject is working now. The unit is at my office so cannot test insert. This command fails. lcdoctl -d dacal:0001094E exec 4 Segmentation fault (core dumped) As I read the help this should show the slot number in the drive?
-
Hi Eddie Longshot do you still have this protocol document?
-
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: 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. Is this in lcdoctl as well as dacal.c ? Support for the DC016RW [1] Sent from sourceforge.net...
-
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. Is this in lcdoctl as well as dacal.c ?
-
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,...
-
Hi Where is the returned data? Can this be output to the logs?
-
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...
-
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!
-
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...
-
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)...
-
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: dacal:0001094E Trying to run: lcdoctl vendor dacal:0001094E Returns: * listing vendor commands requires a device argument* What device argument ? Thanks
-
Which model are you using? The Dacal DC-300, the DC016RW, or something else?
-
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...
-
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...
-
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)...
-
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 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)...
-
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...
-
libcdorganizer released /Binary/libcdorganizer-gnu-linux-amd64-4.0.0.tar.bz2
-
-
-
* Merged the 4.0.0 branch into the trunk
-
* Updated to include man pages for all components and public functions
-
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)...
-
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
-
Hi @Kshots Are you still able to assit. It looks like this does what i want but i cannot get the code to complie. I am trying to get DC016 working.
-
I realize this thread is very old, but if someone is experiencing this issue, can you tell me what you're running on the command line, what the response is, and what the physical device is doing? I'm no longer convinced this is a HID device detachment issue.
-
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...
-
Hi Did the DC016 ever get implmented?
-
-
-
-
James posted a comment on discussion Open Discussion
After looking at the code I decided to try some things. ./lcdoctl -d dacal:105b2...
1
