[BUG] Encoder Problem With Latest Raspberry Pi OS

So we discovered in internal testing, thanks to Chris, that after upgrading our Raspberry Pi’s to the latest Raspberry Pi OS (with dist-upgrade, exact version below) that the DepthAI video encoder is not stable, so this example (04 - RGB Encoding) fails quickly. Prior to this upgrade to Raspberry Pi OS (the latest as of this writing), this instability did not happen. And we do not see the instability on other platforms (to our knowledge).

But on the latest Raspberry Pi OS, every Gen2 DepthAI version we tested has this instability.

The versions tested are below:

1.
depthai==2.0.0.1+4450dc3a7246f6d80f143c57db3f7f797f677882
segmentation fault after ~2 minutes
2.
depthai==2.0.0.1+31e14bdf1d2de39e85ab2d4806ad63f28970baf2
    h264Packet = q.get()  # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: 'h265' (X_LINK_ERROR)'
3.
depthai==0.0.2.1+c9a19df719cb668e438d6eafd193cdf60a0d9354
    h264Packet = q.get()  # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message '[json.exception.parse_error.110] parse error at byte 1: syntax error while parsing MessagePack value: unexpected end of input'
4.
depthai==0.0.2.1+1adf28f17fc3c5409f8226f309eb7122a7eb24bb
    h264Packet = q.get()  # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Error while reading data from xlink channel: h265 (X_LINK_ERROR)'
5.
depthai==0.0.2.1+e9930fcf2bf2f6d81b7c5ba8455e9d2f6a8d8685
    h264Packet = q.get()  # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Error while reading data from xlink channel: h265 (X_LINK_ERROR)'
6.
depthai==0.0.2.1+9ad44703a6d25d42d1418cc8660f19a8ed8d5346
    h264Packet = q.get()  # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Error while reading data from xlink channel: h265 (X_LINK_ERROR)'

And we have found that Gen1 does not suffer from this issue on Raspberry Pi OS. We are continuing to debug.

Raspberry Pi OS version where we first noticed the problem:

OS version:
VERSION="10 (buster)"
kernel version:
Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux

[uchihatashi]

I am also facing the same error on Raspberry Pi OS on gen2 API. Please let me know how to solve this error: ‘Error while reading data from xlink channel: (my_nn) (X_LINK_ERROR)’ and I am using Linux raspberry pi 5.10.17

I need some suggestions from you guys:

1. So should I downgrade from pi 5.10.17, and will it solve the error?
2. Or should I wait for the new update to come, and how long will it take?
3. Also, sometimes it crashes (throwing errors), and sometimes it’s not crashing at all.
4. One of the errors I m getting is the device not found even when the device is connected properly.

• with dai.Device(pipeline) as device:
• RuntimeError: Failed to find device after booting, error message: X_LINK_DEVICE_NOT_FOUND ---- [After running the code, it freeze my Raspberry Pi and gives this error, and also I m getting this error when I run my program first time, when I start my Raspberry Pi, or when I removed connect my OAC-D to Pi]

[Luxonis-Brandon]

So we are learning more as we dig in. We have 2 engineers trying to figure out the crash behavior here. One is full-time on this and the other wrapping up https://github.com/luxonis/depthai-core/issues/94 while testing.

What we’ve found so far is that it doesn’t crash with non-blocking queue IIRC, which was the default behaviour in gen1 (if we remember correctly). We were excited that we thought we found an is that was culprit, but it was from the previous PR. (So that was found/fixed at least.)

As @aviogit mentioned, it definitely something related to the fact that the packets are not consumed in time by the host, on RPI4 is working fine, while RPI3 queues get full.

And yes, @jasonopto 's case it was because we do not yet have Pi Zero wheels prebuilt (which is largely because the thing is so slow/hard to work with, ha, like @jasonopto mentioned - we’d need to figure out some reliable cross or cloud-compile for armv6/PiZero).