OpenGoPro icon indicating copy to clipboard operation
OpenGoPro copied to clipboard

Camera Stuck In Buggy State - Commands Broken 500 Internal Server Error

Open codercoder117 opened this issue 3 years ago • 7 comments

Component BLE and HTTP software on Hero10 camera.

Describe the bug While attempting to record a 75 minute clip session remotely through bluetooth commands (with shutter ON/OFF), it seems like the camera stopped recording at the 60 minute mark due to the max time recording setting on the camera. After 75 minutes, the bluetooth device attempted to send the Shutter-OFF command which returned an incorrect response (due to the fact that the camera already stopped recording) and when the bluetooth device attempted to reconnect it seems like the camera entered the buggy state that it has been in since.

A bunch of functionality on the camera from bluetooth no longer works and the commands return invalid responses or a 500 internal server error. The camera seems to be stuck in a weird state such that some commands work fine, while other commands return 02:05:02 on BLE or 500 Internal Server Error on HTTP. I am currently unable to access camera physically, so being able to debug or fix remotely would be hugely invaluable.

At the moment, I can connect to the camera via a bluetooth device. I am able to disable or enable the WiFi AP successfully and it returns the correct response '02:17:00 via bluetooth API. I am also able to communicate with the HTTP API on the camera with some commands such as /gopro/media/list which works properly and also initiating downloads of media files works as well.

However, on the bluetooth API, there are many commands that do not work and send the incorrect response code such as the sleep command which return the response code 02:05:02 instead of powering off the camera. Also if I send the shutter ON or shutter OFF commands, those also send incorrect response codes and do not function properly.

In addition to that, the HTTP API also does not work with certain commands such as the /gopro/media/delete command which returns a 500 Internal Server Error, and also the /gopro/camera/state command which returns a 500 Internal Server Error.

Summary: Some commands are broken on both the BLE and HTTP API's of the camera, while some commands work on both of them.

To Reproduce Steps to reproduce the behavior:

  1. Connect to camera via bluetooth device
  2. Set the camera setting so that it will only record a maximum of 60 minutes
  3. Sent a Shutter-ON command
  4. Wait 75 minutes and then send the Shutter-OFF command (it should return an incorrect response code since the camera already stopped recording)
  5. Re-connect to camera via bluetooth device and attempt to send a /gopro/media/delete command on a media file which returned a 400 Client Error: requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://10.5.5.9:8080/gopro/media/delete/file?path=100GOPRO/GX010206.MP4
  6. Camera is now stuck in the bugged state described above

Hardware

  • Camera: Hero10, software v1.42.0

codercoder117 avatar Jun 06 '22 14:06 codercoder117

Hi @codercoder117,

How often are you encountering this issue? Are you able to reproduce it consistently? Does it persist after power cycling the camera?

bfreeland-gpsw avatar Nov 03 '22 19:11 bfreeland-gpsw

Has there been any progress fixing this bug? I get this error every time i restart my pc and try to send a HTTP command. It says USB connected until i try to send a HTTP command and then i get the 500 internal server error. The only fix is to reconnect the usb c cable but for the system we are building we can't access the camera.

I use the Gopro 11 mini.

ImJulester avatar Dec 19 '22 10:12 ImJulester

Dear OpenGoPro team,

thanx for the library, great work - maybe we can fix some issues together here. We encountered a similar issue with the same state the camera gets in (somehow stuck, somehow working) and can reproduce it.

Setup: Ubuntu 20.04, Python 3.10, dev through pycharm HW: NanoPC-T6 - two GoPro's 11 black connected

Purpose: ... of our software is to record high speed events in defined intervals for ~ 10-20 seconds and this every minute which have to be researched later then. We would not be able to use WiFi or BLE due to environmental issues and security of the IOT product (this is an absolute no-go). Thus we have to rely on USB only.

Approach: We connect the cameras through USB and use wired functionality only. After connecting the camera to USB we can connect (to each separately), set it up properly (sloMo 240FPS video) and can trigger time by time the recording (shutter.enabled/disabled). As long as the cameras are connected once and no mounting (through MTP) occurs everything is fine. We can stop, start, restart the software and the whole initialization process also sets up the cameras every time properly to our 240 fps video, etc.

Tests: (note, this is done everytime after we 1st turned on the camera and 2nd connected the camera through an USB cable)

a) If we connect to the camera through an adopted version of PyMTP and as long we "only connect" and do no file/mounting operations, everything is fine.

b) If we use the built in and default file explorer of Ubuntu 20.04 (Kernel 5.10.x) things get stuck some when ... b.1) if the camera was automounted before we use our Python program, our program works fine b.2) if the file explorer lost connection (due to unknown circumstances - eg. timeout/no keep alive/... - our program works fine b.3) Mounting or unmounting through file explorer: b.3.a) If the camera was automounted and we unmount it in file explorer, we got the 500 Error (shutter.enable, the bug is similar to the mentioned on at the thread start) b.3.b) If the camera was not mounted and we mount it through the file explorer, 500 Error ...

c) If we run into the 500 Error ... and we disconnect the USB cable and connect it again, everything works properly again (until we do an active un/mounting through the operating systems file explorer again, etc.)

So the issue can be reproduced easily. We'll try some further tests, but our options are limited already because we can just kill our instanced object and/or try to open/close the camera - but in the past this didn't work. As well, the error only occurs when we shutter.ENABLE, disabling it is done always through initialization/instancing our object to make sure we can set all configuration properly (and as mentioned above, this works fine all the time). Disconnecting the USB cable won't be an option as well, because the device is on a remote site.

Thank you for your help Robert

robertgalo avatar Aug 08 '23 07:08 robertgalo

Update to the previous issue (above):

Following we found out to "resolve" the issue by a workaround (we used the browser for simplification) and didn't do any python stuff until now:

  1. Fact/Impact of the tests a) - c) from above: The USB connection "p=1" gets "somehow" destroyed ... - some commands work, some not - generally the cam through its USB connection is in a indifferent state.

  2. we could reproduce the error as well we can reproduce then the solution (workaround), which is as the following (sequence of http-commands through browser):

start (cam through USB connected, notation: URL --> http response, 200 = OK, 500 = Error):

http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=1 --> 200 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200 http://172.2X.1YZ.51:8080/gopro/camera/state --> 200 (plus JSON output) http://172.2X.1YZ.51:8080/gopro/camera/shutter/start --> 200 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200

Check, video recorded ok!

Now we unmounted the cam through the file explorer http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=1 --> 200 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200 http://172.2X.1YZ.51:8080/gopro/camera/state --> 200 (plus JSON output) http://172.2X.1YZ.51:8080/gopro/camera/shutter/start --> 500 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200

We can repeat now this from above, the camera will stay/reply when starting always 500 ...

Solution: Before we http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=1 --> 200 we do a http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=0 --> 200 and then again http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=1 --> 200 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200 http://172.2X.1YZ.51:8080/gopro/camera/state --> 200 (plus JSON output) http://172.2X.1YZ.51:8080/gopro/camera/shutter/start --> 200 http://172.2X.1YZ.51:8080/gopro/camera/shutter/stop --> 200

everything works fine again. For now, we have to put this into our python code including some checks. This is done by: ...http_command.wired_usb_control(control=Params.Toggle.DISABLE) (like: http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=0) and ...http_command.wired_usb_control(control=Params.Toggle.ENABLE) (like: http://172.2X.1YZ.51:8080/gopro/camera/control/wired_usb?p=1)

It would be great, if there would be a smart fix within the OpenGoPro lib (every time when connecting there will be some sort of check or similar). And yes, we know, this is not an basic issues of the OpenGoPro lib itself - it's moreover something within the API/GoPro.

Thanx a lot Robert

robertgalo avatar Aug 08 '23 08:08 robertgalo

having the same issue. Response 500 when requesting a state every 5 seconds. Getting an error once in 1-2 minutes. Haven't seen this problem much, but it looks like the more i use the camera, the more frequently i experience the bug. Year ago, half a year ago I've seen this bug only a couple of times, but now i see it all the time.

Faulty 1.50 firmware?

pavlosharhan2 avatar Aug 11 '23 13:08 pavlosharhan2

having the same issue. Response 500 when requesting a state every 5 seconds. Getting an error once in 1-2 minutes. Haven't seen this problem much, but it looks like the more i use the camera, the more frequently i experience the bug. Year ago, half a year ago I've seen this bug only a couple of times, but now i see it all the time.

Faulty 1.50 firmware?

Yes, probably. It seems not to be an issue of OpenGoPro.

robertgalo avatar Aug 14 '23 14:08 robertgalo

I have found that on Ubuntu 18, the usb connection is dropped and reconnected, necessitating you to resend the usb control command before shutter start. You can check the usb control state by looking at status 116 in the state response.

If you try to do shutter commands without usb control, you get a 500

tony-gutierrez avatar Apr 19 '24 12:04 tony-gutierrez