chdkptp - alternative ptp client - page 83 - General Discussion and Assistance - CHDK Forum

chdkptp - alternative ptp client

  • 1097 Replies
  • 397124 Views
Re: alternative ptp client
« Reply #820 on: 15 / July / 2015, 17:56:12 »
Advertisements
I did not build the GUI because it required more dependencies.
As I stated a bit earlier, after getting rid of gvfs I get more consistent behaviour.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:

open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.

The sequence is the following:

1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)

Currently going back to 2) fails (ie: the python call never returns)

The steps above should be very similar to what chdkptp's GUI does, right? Or am I missing some obvious step?

One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)

Thanks a lot in advance!

About the steps above, here is the commandline that can be used to reproduce it. Note that it works some times, so it maybe be a timing issue (even though I'm actually using sys.sleep() between steps)

./chdkptp.sh -c -e'rec' -e"lvdumpimg -vp='convert - -resize 640x480! chdkptp_preview.jpg' -pipevp -count=1" -e'exec sys.sleep(1000)' -e'rs .' -e'exec sys.sleep(1000)' -e'play' -e'exec sys.sleep(1000)' -e'rec' -e"lvdumpimg -vp='convert - -resize 640x480! chdkptp_preview.jpg' -pipevp -count=1" -e'exec sys.sleep(1000)' -e'rs .' -e'exec sys.sleep(1000)' -e'play' -e'exec sys.sleep(1000)'

Has anybody experienced such issues?

I also tried to see how the GUI does, but I'm not versed in Lua, so any help would be highly appreciated.


*

Offline srsa_4c

  • ******
  • 4426
Re: alternative ptp client
« Reply #821 on: 15 / July / 2015, 18:18:12 »
Actually I had done that (ie: chmod -x the file you mention)
For completeness: that file is not executable, I just removed its r attribute, so that I can restore this functionality when I need it.

However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:

open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.
That's a known issue unfortunately, see http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues . (This table doesn't yet list the sx260 as problematic, but it does list the sx240 which has identical firmware).
Theory is that the firmware expects the recently shot photos to be present on the card and gets confused because those files are missing.
There might be a solution to this, but not for the average user.

Quote
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
You can try either adjusting the Canon power saving settings, or use CHDK Settings -> Disable LCD Off [Always]. Or, you can wake up the cam with a keypress before you issue rs.

*

Offline reyalp

  • ******
  • 13432
Re: alternative ptp client
« Reply #822 on: 15 / July / 2015, 22:59:01 »
I guess I could do the onion skinning with some ImageMagick commands.
Sorry, not suggesting you should, just wanted to make sure because "grab" was used for a specific thing in that discussion.

Quote
Actually my goal is to use a python wrapper (chdkptp.py https://pypi.python.org/pypi/chdkptp.py/0.1.2 ) because in that case I don't need to save the live view images to disk nor spawn a process for each frame of the live view.
That's fine, but I'd still suggest you verify that you can do each step in the chdkptp CLI.
Quote
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?
I'm not sure what you are asking for. If the camera screen goes black, then 99% certain, some non CHDK software on your PC is accessing the camera. You need to make it stop. How you do that is dependent on your OS. If you are using linux, it probably involves udev, but the details are distro specific and udev documentation is so lacking that there is no way I can provide specific steps to debug it. This issue is mentioned, with links to some relevant forum threads in https://www.assembla.com/spaces/chdkptp/wiki/Install

I did not build the GUI because it required more dependencies.
OK, I assumed earlier from the "live view" references that you were using the GUI, but now I understand you are using lvdumpimg or similar. What I meant was, if you enter the commands individually instead of trying to run it all with -e commands. GUI or CLI is not relevant.

Quote
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.
If it says "a script is already running" it almost certainly means a script is running, I don't see any way this error could be generated if the camera has crashed. You could use killscript to kill the script, assuming you are using a vaguely recent version of CHDK.

The earlier "opensession failed" message suggests something was already connected to the camera. It could be different CHDK client (another instance of chdkptp or the python lib) or the gvfs stuff.

Quote
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
As srsa said, switching to playback after using remoteshoot is problematic on many cameras. However, this should result in an actual crash, not the "script is already running" error you posted above.

Quote
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
The simplest solution would be to set "Disable LCD Off" to "always" in the CHDK settings, which will prevent the screen from turning off, and also prevent the camera from eventually shutting off.

The camera shutting down the sensor when it turns the display off is expected, since it takes a lot of power.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #823 on: 16 / July / 2015, 03:11:07 »
Actually I had done that (ie: chmod -x the file you mention)
For completeness: that file is not executable, I just removed its r attribute, so that I can restore this functionality when I need it.

Ok thanks.

However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:

open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.
That's a known issue unfortunately, see http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues . (This table doesn't yet list the sx260 as problematic, but it does list the sx240 which has identical firmware).
Theory is that the firmware expects the recently shot photos to be present on the card and gets confused because those files are missing.

Ok, so if instead of 'remote shoot' I used 'shoot' would it work consistently?
Alternatively, if I did not went back to 'play', would it work consistently?
Because I see two solutions then:
1) use 'shoot' so that the file is saved on the camera and retrieve it later (or use a wifi sd card to get it automatically)
2) do not go back to 'play' (which I was doing to save battery), let the camera power down by itself (like it seems to do) and just issue a "press('half_shoot')" or something to wake it up before using it again.

Do you guys think those solutions are viable?
Do you know which one would use less battery?

There might be a solution to this, but not for the average user.

Indeed :(

Quote
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
You can try either adjusting the Canon power saving settings, or use CHDK Settings -> Disable LCD Off [Always]. Or, you can wake up the cam with a keypress before you issue rs.

By "keypress" you mean and automated script-generated keypress, right?


Re: alternative ptp client
« Reply #824 on: 16 / July / 2015, 03:50:44 »
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?
I'm not sure what you are asking for. If the camera screen goes black, then 99% certain, some non CHDK software on your PC is accessing the camera. You need to make it stop. How you do that is dependent on your OS. If you are using linux, it probably involves udev, but the details are distro specific and udev documentation is so lacking that there is no way I can provide specific steps to debug it. This issue is mentioned, with links to some relevant forum threads in https://www.assembla.com/spaces/chdkptp/wiki/Install

Thanks. I meant mentioning the "black screen" issue on chdkptp's wiki.
As you point out the "possible interference" is mentioned, just that the actual behaviour that shows that something is interfering (ie: "black screen") is not mentioned.
In a nutshell, if the wiki said "On Linux, default camera software may connect to the camera automatically. If the camera's screen turns black when connecting to a computer, then some software is active on the computer and will interfere with chdkptp." or something like that, it would be much clearer.

OK, I assumed earlier from the "live view" references that you were using the GUI, but now I understand you are using lvdumpimg or similar. What I meant was, if you enter the commands individually instead of trying to run it all with -e commands. GUI or CLI is not relevant.

Ok.

Quote
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.
If it says "a script is already running" it almost certainly means a script is running, I don't see any way this error could be generated if the camera has crashed. You could use killscript to kill the script, assuming you are using a vaguely recent version of CHDK.

The earlier "opensession failed" message suggests something was already connected to the camera. It could be different CHDK client (another instance of chdkptp or the python lib) or the gvfs stuff.

It is another instance of chdkptp, since I use it in scripting (or with the python wrapper), when it fails I cannot use the same session that is blocked.

Quote
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
As srsa said, switching to playback after using remoteshoot is problematic on many cameras. However, this should result in an actual crash, not the "script is already running" error you posted above.

Ok, about that, I just did more tests, in case it helps.
In interactive mode if I do:

1) rec
2) shoot
3) play
4) go to 1)

I can repeat the sequence many times. The lens retracts with every call to "play".

If I do:

1) rec
2) play
3) go to 1)

I can repeat the sequence many times. The lens retracts with every call to "play".

But if I do:

1) rec
2) wait until camera power off (display turns off)
3) play

the lens retracts but the screen stays black and the led will blink periodically.

Under those conditions, I can issue a 'reboot' command and the camera will restart, the connection is lost but a 'c' command will reconnect.

If I do:

1) rec
2) rs .
3) reboot

The lens does not retract, the led does not blink (it is turned off), but the camera is totally unresponsive, I need to take out the battery to make it work again.


Quote
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
The simplest solution would be to set "Disable LCD Off" to "always" in the CHDK settings, which will prevent the screen from turning off, and also prevent the camera from eventually shutting off.

The camera shutting down the sensor when it turns the display off is expected, since it takes a lot of power.

So the camera will eventually shut itself off completely? Because I'm trying to maximize run time by reducing power usage. Do you guys have any suggestions?

Thanks!

*

Offline reyalp

  • ******
  • 13432
Re: alternative ptp client
« Reply #825 on: 16 / July / 2015, 16:26:31 »
Thanks. I meant mentioning the "black screen" issue on chdkptp's wiki.
As you point out the "possible interference" is mentioned, just that the actual behaviour that shows that something is interfering (ie: "black screen") is not mentioned.
Good point. I've adjusted the wiki.
Quote
It is another instance of chdkptp, since I use it in scripting (or with the python wrapper), when it fails I cannot use the same session that is blocked.
In that case, killscript should take care of whatever script is running, although depending why the other client hung, there may be other problems. Debugging the hang would probably be better than relying on killscript.

Note that the PTP implementation on these cameras (in the Canon firmware as well as CHDK) can only handle one session at a time.

Quote
Ok, about that, I just did more tests, in case it helps.
In interactive mode if I do:

1) rec
2) shoot
3) play
4) go to 1)

I can repeat the sequence many times. The lens retracts with every call to "play".

If I do:

1) rec
2) play
3) go to 1)

I can repeat the sequence many times. The lens retracts with every call to "play".

But if I do:

1) rec
2) wait until camera power off (display turns off)
3) play

the lens retracts but the screen stays black and the led will blink periodically.
Good debugging work. Then my suggestion is "don't do that"  :P CHDK is a hack, and the PTP mode switching stuff is particularly hacky.

You could try sending a scripted key press wake the camera up before going to play. I'd suggest a small delay in between.


Quote
So the camera will eventually shut itself off completely? Because I'm trying to maximize run time by reducing power usage. Do you guys have any suggestions?
There are two or three stages in Canon power saving, which vary some depending on the model
1) Display and sensor turns off
2) Lens retracts, camera goes to play mode
3) Camera physically powers off.

There should be some settings to control them in the Canon menu, and they should be described in your camera manual. Again, these will vary some by model.

As far as saving power saving goes, this thread http://chdk.setepontos.com/index.php?topic=9049.0 and the older threads linked from it should give you an idea. Generally speaking, display + sensor off is pretty good, play is probably a bit better.

On some cameras, you can use a button press to trigger #1 without waiting for the delay. This may be the "disp" button (mostly on cameras with an optical viewfinder) or a "sleep" function that can be assigned in the canon firmware.

You can also use CHDK set_lcd_display() to turn off the display, but this does not turn off the sensor so will save less power than the sleep mode.

Quote
Because I see two solutions then:
1) use 'shoot' so that the file is saved on the camera and retrieve it later (or use a wifi sd card to get it automatically)
2) do not go back to 'play' (which I was doing to save battery), let the camera power down by itself (like it seems to do) and just issue a "press('half_shoot')" or something to wake it up before using it again.
Either of these should work, though note "power down" is really a sleep mode, not an actual power off.

You can use shoot -dl to shoot and download. shoot -dl -rm will shoot, download and delete, but will probably cause the same problems when you try to switch to play. You can probably delete the images after you switch to play with imrm.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #826 on: 17 / July / 2015, 03:09:08 »
In that case, killscript should take care of whatever script is running, although depending why the other client hung, there may be other problems. Debugging the hang would probably be better than relying on killscript.

Note that the PTP implementation on these cameras (in the Canon firmware as well as CHDK) can only handle one session at a time.

Ok, I see.

Good debugging work. Then my suggestion is "don't do that"  :P CHDK is a hack, and the PTP mode switching stuff is particularly hacky.

Really? But if simulating key presses is ok, changing modes could be done that way and not need to be so hacky, right?

You could try sending a scripted key press wake the camera up before going to play. I'd suggest a small delay in between.

Thanks. Does CHDK or CHDKPTP have timing issues?

There are two or three stages in Canon power saving, which vary some depending on the model
1) Display and sensor turns off
2) Lens retracts, camera goes to play mode
3) Camera physically powers off.

There should be some settings to control them in the Canon menu, and they should be described in your camera manual. Again, these will vary some by model.

As far as saving power saving goes, this thread http://chdk.setepontos.com/index.php?topic=9049.0 and the older threads linked from it should give you an idea. Generally speaking, display + sensor off is pretty good, play is probably a bit better.

On some cameras, you can use a button press to trigger #1 without waiting for the delay. This may be the "disp" button (mostly on cameras with an optical viewfinder) or a "sleep" function that can be assigned in the canon firmware.

You can also use CHDK set_lcd_display() to turn off the display, but this does not turn off the sensor so will save less power than the sleep mode.

Ok, I see.
I think that letting the camera go to sleep is probably better than what I was trying to do.
I mean, when it goes to sleep it also turns off the display automatically, while if I put it in 'play', it would keep it on unless I also turn it off with the script.


Either of these should work, though note "power down" is really a sleep mode, not an actual power off.

You can use shoot -dl to shoot and download. shoot -dl -rm will shoot, download and delete, but will probably cause the same problems when you try to switch to play. You can probably delete the images after you switch to play with imrm.

Yes, I did some more tests and it seems that "shoot -dl -rm" does trigger the same crash when going back to 'play'.
However, thanks to the answers I got here I managed to do what I wanted.
I'm letting the camera go to sleep, then wake it up when necessary, keep it awake periodically (it can go to sleep even if we are making calls to live view), and so on. I gave up on going back to 'play'.

Thanks a lot!

Re: alternative ptp client
« Reply #827 on: 17 / July / 2015, 12:58:23 »
Hello

I hope this is thr right way for my question.
If not, please let me know.

I use CHDK with a Timelapsscript on my G7 (the old one).
The Cam stands on a very high construction, so i can not easily get the SD-card.

With CHDK-PTP it is possible to get the pictures of the camera,
but not if the script is running.

I get an error: "a script is already running"

Is there a way to start the camera and the script
and to copy & delete files from the SD-card without touching the camera,
by using CHDK-PTP?

 
Greetings 

Kolja


*

Offline reyalp

  • ******
  • 13432
Re: alternative ptp client
« Reply #828 on: 17 / July / 2015, 16:39:26 »
Really? But if simulating key presses is ok, changing modes could be done that way and not need to be so hacky, right?
When the camera is connected to USB, it ignores key presses that would switch modes. The hacks are needed to "unlock" it in USB mode.

Quote
Thanks. Does CHDK or CHDKPTP have timing issues?
Almost certainly, but that's not exactly the issue here. If you send a key press to wake up, that may trigger a bunch of actions in the camera firmware, and there's no guarantee they will all be done by the time the key press call returns. If you try to switch to play while it's still waking up, something might get confused. I don't know whether there is a problem in this specific case, just a general caution.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13432
Re: alternative ptp client
« Reply #829 on: 17 / July / 2015, 17:10:57 »
Is there a way to start the camera and the script
and to copy & delete files from the SD-card without touching the camera,
by using CHDK-PTP?
If you have wifi available you could use a wifi SD card like eye-fi or http://chdk.setepontos.com/index.php?topic=11262.0

If you want to use chdkptp, you need to use a timelapse script that can cooperate with chdkptp.

There are two things you need to deal with
1) If USB isn't connected all the time, the camera may react when it is plugged/unplugged, for example by retracting the lens when you plug it in. Exactly what happens depends on the camera model.
2) Stopping and restarting the script when you want to download images. You can make the script detect the presence of USB, or check for a USB message to stop. You can restart it over PTP.

http://chdk.wikia.com/wiki/Ultimate_Intervalometer#Pause_when_USB_connected.3F
Has an option to switch to play if USB is detected. I'm not sure if this will do exactly what you need.
Don't forget what the H stands for.

 

Related Topics