Closed tony-gutierrez closed 1 month ago
The heart beat timeout is a self reboot as the camera was stuck waiting too long for something. This is not likely a Labs issue, as you aren't running any Labs commands (in a loop), so I'm guessing this would also happen on stock firmware. Have you ask the question to the open gopro team?
The open GoPro team does not seem to put much effort into issues they consider firmware related, and I'm not using their SDK, as it was buggy and limited and moving too slow.
Is there any way to get more detail out of the camera about what exactly is happening? I see an mdb12.db file, but I'm not sure what format it is in.
I'll try testing on stock firmware.
I have noticed that key 111 in the state status is reporting that my SD card is too slow. I am using fast SD cards. Can this value be trusted? This is the card that I am using:
I don't know what key 111 is? I'm sure that card is plenty fast, although I haven't used a 1TB card. From Labs there isn't anymore information to extract, as the crash is likely related to a network error, which is happening in another operating system. Labs run on the RTOS, networking is in Linux. This is also why Labs and Open GoPro are separate. Mdb12 is propriety file used by Quik, I don't know it's format.
Odd that Open GoPro considers this is firmware issue, didn't you say it only happens during transfers? True the under lying file I/o is RTOS. Is there any Labs only that causes this? Looking for a lead to investigate.
I am using opengopro commands to configure 4 cameras, record a timewarp of about 90 seconds, DL it to a local machine, delete it , and repeat. Cameras are powered via a usb hub, no batteries. Using gplabs trust usb and wake on power.
This can run fine for 40 or so iterations, but at some point the cameras reboot in some manner. They revert to default recording settings. The reboot always happens during the video file download, which will then time out. I have retry logic, and often the file will DL fine on the second attempt after the reboot. This happens on all cams (~20 in service) occasionally.
I tried the undocumented !MDBGL=1 and this is what is in the limited logs. The recording video is timestamped 15:25.