« previous next »
Pages: 1 ... 18 19 20 21 22 [23] 24 25 26 27 28 ... 98   Go Down

chdkptp - alternative ptp client

  • 976 Replies
  • 132971 Views
*

Offline frojnd

  • *
  • 45
Re: alternative ptp client
« Reply #220 on: 10 / August / 2012, 14:22:42 »
Advertisements
Hi reyalp!

I've checked the versions of svn:

Working version cd ~/ptpcam/svn/chdkptp/chdkptp && svnversion
257M

Not working version cd ~/chdkptp/chdkptp/trunk && svnversion
272M

backtrace of crash of not working svn:
Code: [Select]
$ ./chdkptp-sample.sh -i   
GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/streznik/chdkptp/chdkptp/trunk/chdkptp...done.
(gdb) run
Starting program: /home/streznik/chdkptp/chdkptp/trunk/chdkptp -i
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3200.4-gdb.py", line 9, in <module>
    from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
    import gdb.backtrace
ImportError: No module named backtrace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
___> c

Program received signal SIGSEGV, Segmentation fault.
0xb7d7d9da in usb_bulk_write () from /lib/libusb-0.1.so.4
(gdb) bt
#0  0xb7d7d9da in usb_bulk_write () from /lib/libusb-0.1.so.4
#1  0x0805023e in ptp_write_func (bytes=0x805eb80 "\020", size=16, data=
    0x80b81c0) at chdkptp.c:203
#2  0x0804df65 in ptp_usb_sendreq (params=0x80970b4, req=0xbfffedd8)
    at ptp.c:116
#3  0x0804e4da in ptp_transaction (params=0x80970b4, ptp=0xbfffedd8, flags=0,
    sendlen=0, data=0x0) at ptp.c:325
#4  0x0804e967 in ptp_opensession (params=0x80970b4, session=1) at ptp.c:479
#5  0x080512dd in open_camera_dev (dev=0x80adf90, ptp_usb=0x80b81c0, params=
    0x80970b4) at chdkptp.c:669
#6  0x080517a9 in chdk_connect (L=0x80605b0) at chdkptp.c:783
#7  0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#8  0xb7f537ab in ?? () from /lib/liblua.so.5.1
#9  0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#10 0xb7f43240 in ?? () from /lib/liblua.so.5.1
#11 0xb7f48130 in ?? () from /lib/liblua.so.5.1
#12 0xb7f490cf in ?? () from /lib/liblua.so.5.1
#13 0xb7f44804 in lua_pcall () from /lib/liblua.so.5.1
#14 0xb7f56434 in ?? () from /lib/liblua.so.5.1
#15 0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#16 0xb7f537ab in ?? () from /lib/liblua.so.5.1
#17 0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#18 0xb7f44757 in lua_call () from /lib/liblua.so.5.1
---Type <return> to continue, or q <return> to quit---
#19 0xb7f5f96a in ?? () from /lib/liblua.so.5.1
#20 0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#21 0xb7f537ab in ?? () from /lib/liblua.so.5.1
#22 0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#23 0xb7f43240 in ?? () from /lib/liblua.so.5.1
#24 0xb7f48130 in ?? () from /lib/liblua.so.5.1
#25 0xb7f490cf in ?? () from /lib/liblua.so.5.1
#26 0xb7f44804 in lua_pcall () from /lib/liblua.so.5.1
#27 0x08053574 in exec_lua_string (L=0x80605b0, luacode=
    0x8058aa9 "require('main')") at chdkptp.c:1614
#28 0x08053645 in main (argc=2, argv=0xbffff6a4) at chdkptp.c:1638
(gdb) quit
A debugging session is active.

Inferior 1 [process 17038] will be killed.

Quit anyway? (y or n) y

Hope it helps?
« Last Edit: 10 / August / 2012, 14:25:14 by frojnd »
Logged
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #221 on: 11 / August / 2012, 14:27:23 »
Thanks frojnd, having the SVN revisions is very helpful. The most significant change I see to the PTP code is http://trac.assembla.com/chdkptp/changeset?reponame=&new=258%40trunk&old=257%40trunk

I'll take a closer look at this.

both of your svnversions have "M" at the end, meaning some of the code is modified. If you've modified the actual code, please let me know (you can use svn diff).

edit:
I guess the M is probably just from editing chdkptp-sample.sh (I usually copy it to chdkptp.sh)
« Last Edit: 11 / August / 2012, 16:46:19 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #222 on: 11 / August / 2012, 21:46:28 »
frojnd:
Can you try this
after the crash in gdb, type
up
This should output a line that looks something like
#1  0x0805023e in ptp_write_func (bytes=0x805eb80 "\020", size=16, data=0x80b81c0) at chdkptp.c:203
Then type
print *ptp_usb

Also (separate from the above) try running chdkptp as root.
On arch/raspberry pi, I get a similar segfault, but only if not running as root. Note I also get this segfault on r257, so it may not be the same.

edit:
As of chdkptp changeset 273, if you are hitting the the same problem I was having on raspberry pi, it should print an error instead of crashing.

edit:
I think you mentioned that a different user worked ? If a non-root user worked, check if the account was a member of the "camera" group.
« Last Edit: 11 / August / 2012, 22:34:10 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #223 on: 12 / August / 2012, 18:30:25 »
Summarizing yesterdays observations:
The crash I found was due to permissions not allowing access to the device. This can also happen under debian based distros (see earlier comments on raspbian distro) but it appears that in depending on the distro usb_open returns NULL (arch case, ended up causing a segfault due to poor error checking in chdkptp) or it can succeed with only the later calls failing (raspbian case). All this should apply to ptpcam as well.

In changeset 273, I improved the error checking, so chdkptp should fail gracefully with an access denied error in the arch case.

Next question, why can't we access the USB device ?
It turns out, this is complicated under Linux, and varies depending on distro, version, desktop environment, whether the user is on the local desktop etc, what other ptp related packages are installed etc. Some references:
http://gphoto.org/doc/manual/permissions-usb.html
https://wiki.archlinux.org/index.php/Digital_Cameras

Note the above refer to gphoto2, but the same will generally apply to chdkptp. If you have gphoto2 installed, then checking whether you can connect to the camera with gphoto2 should be a good test (but note that installing libgphoto2 etc may affect how the camera is handled.)

More details:
udev is generally responsible for dealing with devices like this. In some configuration, udev sets the group on freshly plugged devices (this is the case on my Ubuntu 10.04 laptop). In other cases, something else (consolekit and systemd are mentioned on the arch page) are responsible.

On my arch install was headless and didn't have any of the consolekit stuff, so I attempted to set up a udev rule on arch to set the permissions. This lead me to another oddity:
The device appears on
/dev/usbdevN.M and /dev/bus/usb/N/M
both of these are actual devices, not symlinks. When I set group/mode in a udev rule e.g.:
Code: [Select]
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", GROUP="camera", MODE="660"
This is applied the /dev/usbdev* device. However, both chdkptp and gphoto appear to use the /dev/bus/usb* device, so it doesn't solve the problem. Manually chmod'ing does the /dev/bus/usb* one does allow them to work. This should be possible using RUN to execute a shell script in the udev rule. I didn't get to test this yet because for some reason my arch install refuses to boot.

My laptop (again, older ubuntu) only has the /dev/bus/usb* device, and the default udev scripts installed change the group to plugdev and set the mode. chdkptp works out of the box for a normal user in this setup.

If someone knows more about why these different devices are used, I'd like to hear about it.

somewhat old guide to udev rules
http://www.reactivated.net/writing_udev_rules.html
Note most of the commands mentioned are now sub-commands of udevadm

If you decide to write your own udev rules, keep in mind that the distros may have default rules which apply to the camera. These may appear in a variety  of locations: on arch they appear in /etc/udev/rules.d, /lib/udev/rules.d, and /usr/lib/udev/rules.d


Edit:
for raspbian (Debian wheezy based), adding the following as /etc/udev/rules.d/40-chdkptp.rules allows me to use chdkptp as a standard user
Code: [Select]
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev"
311b is the pid, so that's the only thing that should need to change for other cameras.

This appears to set the permissions on both /dev/bus/usb/... and /dev/usbdev1...
« Last Edit: 13 / August / 2012, 01:51:38 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #224 on: 15 / August / 2012, 17:52:26 »
Reyalp,  I posted earlier in the thread ( http://chdk.setepontos.com/index.php?topic=6231.150 ) about memory issues for the mdl command on the A490 camera. I didn't solve the problem and have since then been transferring the files manually through a SD card reader in the PC. Today I tried chdkptp-r272-win32. Same problem as before with mdl on the command line. But if I run chdkptp GUI, connect and go to "Files" tab I can download all the images. Does the gui download images in a different way compared to mdl ? Is the new command available on the command line too?

EDIT: my mistake. The memory issue is there also with the GUI. I mixed up results from two test runs.

Quote from: reyalp on 24 / July / 2012, 00:27:08
The current code is single threaded, so long running USB operations like downloads block the rest of the application. However, having the USB stuff in a separate thread or process should be fine, and is on my TODO list.
If I understand the above then if/when that separation is added I guess my download problems can be solved another way instead - by downloading the image to a PC (and deleting it from the camera) immediately after the shot, while shooting the next image.
« Last Edit: 15 / August / 2012, 18:39:00 by tpont »
Logged
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #225 on: 16 / August / 2012, 17:36:01 »
Quote from: tpont on 15 / August / 2012, 17:52:26
Reyalp,  I posted earlier in the thread ( http://chdk.setepontos.com/index.php?topic=6231.150 ) about memory issues for the mdl command on the A490 camera.
What CHDK build are you using ? Some CHDK changes since that thread may help. If you can try the latest trunk autobuild http://mighty-hoernsche.de/trunk/

What firmware version is your a490 ?

Quote
If I understand the above then if/when that separation is added I guess my download problems can be solved another way instead - by downloading the image to a PC (and deleting it from the camera) immediately after the shot, while shooting the next image.
No, this is totally unrelated. The "single threaded" comment refers to the client application, not the camera. You could probably download files while shooting with the current code (see earlier comments regarding running live view while shooting), although you'd have to jump through some hoops to do it, and I wouldn't be surprised if it caused some instability.

In any case, an "out of memory" error from lua means camera RAM. Images are saved on your SD card so deleting them isn't going to help. The camera actually does keep a small amount of  in-memory information for each file on the card, but it doesn't notice when CHDK deletes a file. See http://chdk.wikia.com/wiki/CHDK/Camera_RAM_memory_usage for some information. If you are shooting, downloading / deleting lots of files, shooting again, this could actually be part of your problem. In that case, a reboot after each download might help.
Logged
Don't forget what the H stands for.
*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #226 on: 18 / August / 2012, 05:21:58 »
My A490 has 100F firmware.

My last test was with the lastest stable from http://mighty-hoernsche.de/
a490-100f-1.1.0-2079-full_BETA.zip  . I'll try the trunk/nightly version now.

Update: No go. The chdkptp GUI says "error: :243: not enough memory  rlib msg_batcher:18" when trying to download 150 images.
« Last Edit: 18 / August / 2012, 05:41:58 by tpont »
Logged
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #227 on: 18 / August / 2012, 17:46:30 »
Quote from: tpont on 18 / August / 2012, 05:21:58
Update: No go. The chdkptp GUI says "error: :243: not enough memory  rlib msg_batcher:18" when trying to download 150 images.
Just to confirm, that's from the 1.2 trunk ?
Logged
Don't forget what the H stands for.
*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #228 on: 19 / August / 2012, 12:05:34 »
Yes, a490-100f-1.2.0-2086-full_BETA.zip
Logged
*

Offline reyalp

  • ******
  • 10787
Re: alternative ptp client
« Reply #229 on: 20 / August / 2012, 02:14:14 »
Quote from: tpont on 19 / August / 2012, 12:05:34
Yes, a490-100f-1.2.0-2086-full_BETA.zip
Thanks for confirming. In chdkptp svn r278, I've improved the memory usage for multiple downloads. Please try it and let me know if it still gets the error.

I've also added some options to the mdownload command
-batchsize lets you control the batch size. Smaller values will be slower but use less memory
-dbgmem will print out memory usage for each batch that is sent. Please use this and post the output if you still have problems.
-pretend will build the file list but won't actually download the files. This is useful for testing, since the file list is the memory intensive part, you don't have to wait for all the files to download.

In my testing it peaked at about 100kb used by lua for batchsize=20, with ~230 images on the card.
Logged
Don't forget what the H stands for.
Pages: 1 ... 18 19 20 21 22 [23] 24 25 26 27 28 ... 98   Go Up
« previous next »
 

Related Topics