User Activity

  • Posted a comment on ticket #2 on libcdorganizer

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

  • Posted a comment on ticket #2 on libcdorganizer

    No, if you never had a previous version installed, that shouldn't be a possibility :(

  • Posted a comment on ticket #2 on libcdorganizer

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

  • Posted a comment on ticket #2 on libcdorganizer

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

  • Modified a comment on ticket #2 on libcdorganizer

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

  • Posted a comment on ticket #2 on libcdorganizer

    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?

  • Modified a comment on ticket #2 on libcdorganizer

    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?

  • Posted a comment on ticket #2 on libcdorganizer

    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?

View All

Personal Data

Username:
kshots
Joined:
2005-10-11 14:04:57

Projects

This is a list of open source software projects that KShots is associated with:

Personal Tools