Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take-picture followed by Liveview #16

Open
sbjtbanik opened this issue Jun 18, 2023 · 3 comments
Open

Take-picture followed by Liveview #16

sbjtbanik opened this issue Jun 18, 2023 · 3 comments

Comments

@sbjtbanik
Copy link

After liveview process if I am using take-picture server is getting abruptly shut down.(I am having two different APIs for liveview and capture using express js. So, if liveview api is called first and then take picture, server is getting stoped without any error. Though I can hear a shutter sound before the server shuts down. Also tried camera.disconnect after liveview process is finished.)

Can you please help what might be the issue.

@tonyjang0814
Copy link

tonyjang0814 commented Oct 11, 2023

I am experiencing same issue. Any solution for this yet?

@joe27g
Copy link

joe27g commented Oct 13, 2023

What OS are you using? Have you checked the exit code when the app crashes?

I've been developing an app that uses live view and takes pictures, and on Windows it would often crash with error code 3221226505 without taking a few precautions:

  • I've found that calling stopLiveView() tends to cause crashes, so instead of calling that, I've just been pausing the calls to getLiveViewImage() instead. However, this is specific to my use case (resuming the live view after the picture is taken) so this may not work for you. And if it does, it's still a workaround, not a solution. 😕
  • Make sure to stop the live view (or stop calling getLiveViewImage()) a little while before taking a picture; I'm using a 50ms delay and it's done well.
  • Requesting an image from live view too often (i.e. >30fps with 1/30 shutter speed) without proper error handling will cause crashes for sure.
  • If you're doing other camera communication such as handling PropertyChangeEvents, this can become an issue. I found that logging the results of all these events would crash the process when too many events came in quickly (i.e. when connecting a new camera.)
  • If the process it's running in is very busy, you may want to consider using child processes. I ended up doing this so camera communication could be automatically restarted from the main process if and when the EDSDK crashes.

Not sure if any of this is relevant to Linux or macOS, as I've only tested it on Windows so far, but I figured it was worth sharing in case one of these was the root cause of your problems.

@tonyjang0814
Copy link

What OS are you using? Have you checked the exit code when the app crashes?

I've been developing an app that uses live view and takes pictures, and on Windows it would often crash with error code 3221226505 without taking a few precautions:

  • I've found that calling stopLiveView() tends to cause crashes, so instead of calling that, I've just been pausing the calls to getLiveViewImage() instead. However, this is specific to my use case (resuming the live view after the picture is taken) so this may not work for you. And if it does, it's still a workaround, not a solution. 😕
  • Make sure to stop the live view (or stop calling getLiveViewImage()) a little while before taking a picture; I'm using a 50ms delay and it's done well.
  • Requesting an image from live view too often (i.e. >30fps with 1/30 shutter speed) without proper error handling will cause crashes for sure.
  • If you're doing other camera communication such as handling PropertyChangeEvents, this can become an issue. I found that logging the results of all these events would crash the process when too many events came in quickly (i.e. when connecting a new camera.)
  • If the process it's running in is very busy, you may want to consider using child processes. I ended up doing this so camera communication could be automatically restarted from the main process if and when the EDSDK crashes.

Not sure if any of this is relevant to Linux or macOS, as I've only tested it on Windows so far, but I figured it was worth sharing in case one of these was the root cause of your problems.

Hey @joe27g Thank you for sharing these helpful tips! I'm using Windows 11, and your advice has certainly reduced the frequency of crashes, though not completely. I particularly appreciate your suggestion of implementing child processes, which has made crash handling smoother, even if it's still a workaround. Thanks once more! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants