When finding cameras on linux systems, look at camera ID before path or video* #476
Conversation
| @@ -79,6 +79,7 @@ func init() { | |||
| // Initialize finds and registers camera devices. This is part of an experimental API. | |||
| func Initialize() { | |||
| discovered := make(map[string]struct{}) | |||
| discover(discovered, "/dev/v4l/by-id/*") | |||
There was a problem hiding this comment.
Can you write a test for this and also describe how you've manually tested this?
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #476 +/- ##
==========================================
+ Coverage 58.32% 58.33% +0.01%
==========================================
Files 62 62
Lines 3736 3737 +1
==========================================
+ Hits 2179 2180 +1
Misses 1430 1430
Partials 127 127
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
@martha-johnston it looks like CI is failing. Can you take a look? |
It's passing locally so not 100% sure but I think this change should fix it |
|
That's still failing unfortunately. You may want to try using https://github.com/nektos/act to run that linux action to see if you can reproduce it. |
Should be solved now. Was able to reproduce and fix locally |
|
HOORAY |
Problem Description
Currently, it is not possible to detect a camera that has moved from one USB port to another on a linux system. This is the case because the
camera_linux.gofile implementation first looks at the paths in/dev/v4l/by-path/*and then in/dev/video*when looking for a camera object. The problem is that when USB cameras are moved around between USB ports on the linux system, theby-pathandvideo*addresses may change. If there is a reference to the camera path, and then the camera is physically moved to a different USB port, the old path no longer exists and the camera cannot be opened.For example, observe the naming schema in
/dev/v4l/by-path/*for a camera mapped to/dev/video0The USB port is part of the name. For comparison, here is the same camera moved to a different USB port
Note that the path has changed. When the camera is first connected to
video0, the associated path is saved, and when the camera is unplugged and plugged back in to a different port, it may still be identified asvideo0, however the associated path is no longer the same. If the path is identical, i.e., it has been plugged back into the same USB port, then there’s no issue. However, if it moves USB ports, the old path no longer exists so it cannot be opened.Solution
In order to allow cameras to be switched between USB ports and still be accessible, the cameras must be identified by their ID, as that will never change regardless of where the camera is plugged in. This is a very simple change of looking in
dev/v4l/by-id/*beforeby-pathorvideo*.Here is an example of a camera ID found in the newly created
dev/v4l/by-idfolder.And after the camera is moved to a different USB port, the path remains exactly the same.
This change will allow for more flexibility for users who want to adjust their physical set up, as well as hopefully decrease troubleshooting and reinitializing when users do change their physical set ups and run in to issues.
Testing
For manually testing, I attached two webcams to a Raspberry Pi and switched them around to different USB ports to observe their behavior. I tried every combination of the two webcams, and with this new implementation, the cameras will consistently reconnect, and the video stream will resume normally. Previously, the cameras would only reconnect and resume the video stream if they were plugged in to the same USB port. Additionally, I added a new test to the
camera_linux_test.gofile that tests the camera discoveriesby-idin addition to the currently existing test that testsby-path