Updated SDRPlay device notes (markdown)

SDRPlay-device-notes.md

@@ -54,4 +54,14 @@ The SDRPlay API comes with a dedicated SDRPlay API service that manages interact
 
 The process `sdrplay_apiService` has been seen consuming noticable amounts of CPU (especially on SBCs like the Raspberry Pi) during normal operation. This seems to be expected, so please don't be alarmed if it does.
 
-If your device stops working and cannot be detected, the API service may have stopped working. You can restart it using the command `sudo systemctl restart sdrplay`.
+If your device stops working and cannot be detected, the API service may have stopped working. You can restart it using the command `sudo systemctl restart sdrplay`.
+
+# Using SDRPlay devices in docker containers
+
+From observation, it seems like some (if not all) SDRPlay devices will re-register on the host USB bus on their first, "cold" init. This suggests that the SDRPlay software needs to perform some kind of firmware upload to the device.
+
+The docker device forwarding unfortunately does not handle newly added USB devices once the container has been started. This means that the USB re-registration only shows up as a device removal from the perspective of the docker container. The new device that is created during the re-registration never becomes visible inside the docker container.
+
+These two behaviours combined result in the first startup of an SDRPlay device from inside a docker container to fail, always.
+
+The only currently known way to work around this is by restarting the docker container. This will initiate a fresh scan of devices to forward, and luckily the software does not attempt another re-initialization of the device.