My setup has two PTZ cameras with integrated USB serial ports on a Linux (Ubuntu 26.4) platform. In order to make sure there is a predictable name for the devices in /dev, I have a UDEV rule that creates a symlink for each camera in-turn when the USB connection is plugged in (/dev/camera1-control and /dev/camera2-control respectively). I have OBS-PTZ configured to associate those /dev entries to the actual camera sources and, if I plug in my cameras and launch OBS everything works fine.
Occasionally, my cameras glitch and the PTZ control to them stops working. This forces me to power-cycle the affected camera, which causes it to disconnect from USB and then re-connect. At this point, even though the symlinks move to point to the newly enumerated /dev/ entry for the USB device, The PTZ control freezes and remains frozen until I drop into the properties menu and change the device assignment to use the non-symlink ttyUSBx device entry (for example ttyUSB2). Attempting to re-use the symlink entry does not restore PTZ operation, even if I move to the non-symlink device entry and then back to the symlink. From that point on, I can only use the ttyUSBx entry until I restart OBS. I believe this is, at least partly, because the internal state of the QT Serial Port object believes it is still connected to the same device and never actually re-connects, though that does not entirely explain the behavior.
What I would like to see is two things, in order of importance:
- When the
apply button is pushed in the properties menu, fully disconnect from and reconnect to the selected serial device entry, even if it appears not to have changed, to allow users to force a reconnect.
- Present a forced reconnect action for the currently selected camera as part of the controls (a button) to make that process easier and quicker at production time.
I am not asking to detect the disconnection of the USB device and reconnect because, as far as I can tell, that is not possible using the QT Serial Port abstraction. My brief experiments with trying to detect failed send operations and then trying to reconnect did not detect the failed send (the full packet appeared to be sent even though it had nowhere to go).
My setup has two PTZ cameras with integrated USB serial ports on a Linux (Ubuntu 26.4) platform. In order to make sure there is a predictable name for the devices in /dev, I have a UDEV rule that creates a symlink for each camera in-turn when the USB connection is plugged in (
/dev/camera1-controland/dev/camera2-controlrespectively). I have OBS-PTZ configured to associate those /dev entries to the actual camera sources and, if I plug in my cameras and launch OBS everything works fine.Occasionally, my cameras glitch and the PTZ control to them stops working. This forces me to power-cycle the affected camera, which causes it to disconnect from USB and then re-connect. At this point, even though the symlinks move to point to the newly enumerated /dev/ entry for the USB device, The PTZ control freezes and remains frozen until I drop into the
propertiesmenu and change the device assignment to use the non-symlink ttyUSBx device entry (for example ttyUSB2). Attempting to re-use the symlink entry does not restore PTZ operation, even if I move to the non-symlink device entry and then back to the symlink. From that point on, I can only use the ttyUSBx entry until I restart OBS. I believe this is, at least partly, because the internal state of the QT Serial Port object believes it is still connected to the same device and never actually re-connects, though that does not entirely explain the behavior.What I would like to see is two things, in order of importance:
applybutton is pushed in the properties menu, fully disconnect from and reconnect to the selected serial device entry, even if it appears not to have changed, to allow users to force a reconnect.I am not asking to detect the disconnection of the USB device and reconnect because, as far as I can tell, that is not possible using the QT Serial Port abstraction. My brief experiments with trying to detect failed
sendoperations and then trying to reconnect did not detect the failed send (the full packet appeared to be sent even though it had nowhere to go).