RPI4 webcam passthrough issue

So far I have one purchased license on a 2GB PoE-hatted RPi4.

It's intended purpose is not webcam stuff, as I intended on purchasing another license later for a dedicated rpi 4 to pass what will be 3 webcams through to a dedicated pc meant to record the security footage. However I am using the one I have presently with the license and the optimized for rpi4 special build image.

For the intended function of passing through a usb-bluetooth dongle, and a usb3 blue-ray disk drive this tool works flawlessly

for the testing function of running a 5MP web cam the connection is unreliable. The windows built-in app works mostly if not always but doesn't allow much in the way of settings changes and defaults to some low resolution. Use of any other app that has setting that can go to the camera's full potential and often times the moment you select the camera (even before tinkering with setting) you hear the windows disconnected usb chime and you may or may not hear the connect, reconnect chime repeatedly and then just gives up with the app that I am attempting to use just failing to connect, in one case it even said usb device malfunctioned forcing me to ssh into the PI and reboot it.

I should mention this is with 1 webcam, and the bluetooth dongle and blueray drive were not in use, and as part of troubleshooting were directly unplugged (to no effect).

I suspect the issue is a dataspeed/dataflow issue but do not know for sure. I don't think it's a available power issue because that should have resolved it's self when I unplugged the other things (bluetooth, blue-ray).

I am dubious if there is a work around for this which would be sad, and require a course correction on my part for what I am building out, but I can hope.

At the moment I am testing with a powered usb2 hub over a ethernet line (not ip based just uses a ethernet wire between the 2 halves of its adapting self, and the pc is clueless it is even in the mix. This hub is working perfectly for the 1 webcam I have presently but I am dubious about the 2 others (3 total) I wanted to add (there are 4 jacks available, but I suspect the throughput there would be too high, and the reason for looking at virtualhere was it's usb3 support to which I assumed (perhaps in error) that implied transfer speed in excess of what a typical usb2 bus could handle and thus being bottlenecked only by network speed (or not even if compression is in play...).

#3

Thank you,

using those instructions I increased the memory buffer to 1500mb (running headless on a minimal raspbian install with only virtualhere, dedicated for the task box) of the available 2GB. the software I am using is still being temperamental but I have not controlled as yet for other variables xsplit vcam (which was installed to test and not removed, and apparently like to run ontop of other camera feeds) maybe part of the current issues or it could be a remnant of the prior issue. Movavi (free) is my current platform for testing functionality (blue iris, will be purchased when the project is ready to go 'live).

What is different now from before is the webcam will engage and can be used.

what is acting up is if I close out of the camera feed so as to be able to get into the options menu, the camera disconnects (with the windows disconnected chime ) and I have to tell virtualhere to disconnect and reconnect, then go back into that same menu select the camera then configure the options.

What was mentioned on that form but not done as yet due to a incomplete explanation and no directions on how/what to do (but there is a topic I can google, just haven't yet) is the topic of frame buffers and manual/auto mode and their configurations.

cannot yet say fixed; but I can certainly say big step in the right direction.

#4

OK good, on the pi can you run

tail -f /var/log/syslog

and see if it says "SURPRISE UNBOUND" when it drops the camera connection. If so the camera is disconnecting itself.

Also have a look in dmesg when you use the camera and see if there are messages there like out of buffer space or something like that

#5

that tail command gave this:

Apr 6 19:56:42 Livingroom-USB kernel: [50300.838557] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
Apr 6 19:56:42 Livingroom-USB kernel: [50300.838571] xhci_hcd 0000:01:00.0: @000000041ed05670 00000000 00000000 0f000000 02038000
Apr 6 19:57:30 Livingroom-USB kernel: [50348.692216] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
Apr 6 19:57:33 Livingroom-USB kernel: [50351.462217] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd

(omitted logs present immediately upon entering command but before doing anything to prompt changes. the reset high-speed logs coincided exactly with the windows disconnect chime)

#6

Dmesg provided the following:

[ 2812.328829] xhci_hcd 0000:01:00.0: @000000041ed054c0 00000000 00000000 0f000000 02038001
[ 2812.989451] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 2816.556074] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2816.556088] xhci_hcd 0000:01:00.0: @000000041ed06100 00000000 00000000 0f000000 02038001
[ 2817.239491] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 2820.312332] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2820.312347] xhci_hcd 0000:01:00.0: @000000041ed07f30 00000000 00000000 0f000000 02038001
[ 2821.275832] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2821.275846] xhci_hcd 0000:01:00.0: @000000041ed0a660 00000000 00000000 0f000000 02038001
[ 2822.216086] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2822.216101] xhci_hcd 0000:01:00.0: @000000041ed034d0 00000000 00000000 0f000000 02038000
[ 2823.136025] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2823.136039] xhci_hcd 0000:01:00.0: @000000041ed04320 00000000 00000000 0f000000 02038000
[ 2887.665850] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 2887.665864] xhci_hcd 0000:01:00.0: @000000041ed06f00 00000000 00000000 0f000000 02038000
[ 2933.090545] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 2936.080581] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[50300.838557] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[50300.838571] xhci_hcd 0000:01:00.0: @000000041ed05670 00000000 00000000 0f000000 02038000
[50348.692216] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[50351.462217] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
pi@Livingroom-USB:~ $

#7

I think possibly "ERROR Transfer event for disabled endpoint slot" is a kernel bug.

Can you make sure you have the very latest firmware/kernel on the pi by doing this

sudo apt update;sudo apt upgrade -y;reboot

This is currently the lastest kernel (after i run those commands above on my pi4):

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux
#8

So it seems I was on a older build 5.4.??? from December something...

Updated as per your instructions and I am now on the same build as you. reliability remains unchanged post update dmesg below:

[ 14.141241] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 14.141563] Bluetooth: HCI UART protocol Broadcom registered
[ 14.313334] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 14.313343] Bluetooth: BNEP filters: protocol multicast
[ 14.313356] Bluetooth: BNEP socket layer initialized
[ 18.553928] Bluetooth: hci0: command 0x1003 tx timeout
[ 20.633925] Bluetooth: hci0: command 0x1001 tx timeout
[ 22.713932] Bluetooth: hci0: command 0x1009 tx timeout
[ 289.046087] usb 1-1.3: new high-speed USB device number 3 using xhci_hcd
[ 289.229367] usb 1-1.3: New USB device found, idVendor=0edc, idProduct=2050, bcdDevice= 1.08
[ 289.229389] usb 1-1.3: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 289.229407] usb 1-1.3: Product: USB Camera
[ 289.229425] usb 1-1.3: Manufacturer: YJX
[ 289.229441] usb 1-1.3: SerialNumber: 20181208
[ 289.336317] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 289.756352] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 290.092794] usbcore: registered new interface driver uvcvideo
[ 290.092814] USB Video Class driver (1.1.1)
[ 352.656825] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 354.806838] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 371.599289] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 371.599304] xhci_hcd 0000:01:00.0: @000000041ed093a0 00000000 00000000 0f000000 02038001
[ 376.276956] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 379.076984] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 384.396993] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 387.167044] usb 1-1.3: reset high-speed USB device number 3 using xhci_hcd
[ 390.091800] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 2 ep 2
[ 390.091815] xhci_hcd 0000:01:00.0: @000000041ed04fc0 00000000 00000000 0f000000 02038001

===================================
other notes;

Xsplit has been uninstalled and is no longer a variable in this equation.

the 2 other cameras arrived earlier today so I can actually test with the intended 3 instead of dry running just one.

have not yet had the time to look into the auto/manual buffer setting listed of that page you linked to, though the available usbfs memory remains (with no intent to lower, may press higher) at 1500MB.

the usb2 over ethernet wire adapter thing has no connection issues for 1 camera, and will see all 3 cameras but will not initialize a video signal from more then one at a time. So rpi4 something solution will have to be made to work.

Simultaneously working the problem from this angle here with you, and just recently came across a rpi capable linux program to broadcast cameras as a ip stream so researching that angle as well... To that end I have just flashed a SD card with a fresh rasbian lite image with the ssh file and have another 2gig pi4 (not yet deployed will be eventually licensed with this software and used similarly to the already licensed one as a usb endpoint at a display whose video signal runs through the walls to a central computer room). The RPi (or other adapter)for this project has not yet been procured and the plan there is fluid based on the outcomes of all of this....

#9

Maybe putting a powered hub between the pi4 and the cameras if you can and/or reduce the memory slightly e.g down to 512mb and see if that error goes away. Otherwise i think you are stuck with stopping use/reusing the camera.

This error is not from virtualhere, its from the kernel, so you might have to wait for it to be fixed by someone.

Also another idea is to try 64-bit ubuntu build for the pi4. (And run the vhusbdarm64a72 build of virtualhere) and see if that has an error. Maybe 64-bit firmware on the pi is better.

#10

In lu of your comment about it being a kernel issue I though I would try the cloud hub version... and I can try it with(1) device, but I am not seeing where it will let me paste in my existing key I bought. Is the cloud hub different in this regard to the normal server that runs atop another linux distro?

I can click buy and it kicks over to a web site, but there is no enter previous liscense....

#11

well the question of license on the cloud hub is moot; for the one device allowed as a trial is is just as if not more unreliable in the same way

#12

So the upshot is I used a separate SD card and can pop the licensed Raspbian instance back in and use with no issue. I thought the rpi was generic and was afraid serial numbers and supposedly unique identifiers are not held over, to the point I straight up asked in another thread before purchasing the license I have.... about my concern on the matter and if the SD card should fail....

well the exact same RPi4 with that raspbian install reads with a SN of 10000000a0d3ae0e for which I have a license tied...
Same exact pi with 64 bit ubuntu reads in the client as having a SN of e45f010f35be for which the key will not activate and my fears on that topic seem justified!.... so I cannot use the build you suggested......

#13

OK that sounds like a bug in virtualhere (note same key it works fine on my pi with ubuntu 64 or raspbian), the license should still work, anyway ill email a key for that.

#14

So I have tried copying the key that I have (starts with the serial number the virtual here reported when using raspbian and ends with a equals symbol= with a bunch of stuff and a few commas in the middle) and pasting it into the enter license box. the box disappears and nothing appears to happen. I close the client and reopen and it says invalid license. I tried replacing that first part with what virtualhere is reporting the SN to be with ubuntu64 installed and the effect is unchanged.

so far nothing in my email if that is a thing....

#15

Can you email me

#16

ok it's definitely a bug in virtual here and the bug is somewhere on the ubuntu side of things.

I have popped the rasbian sd back it it reported the same SN it always did, I ssh in and did the following command ( cat /proc/cpuinfo ) which listed a bunch of info including the serial number which matched what VirtualHere client reported.

I popped the Ubuntu 64 SD back in and VirtualHere still reports that other Serial Number; however when I SSH into Ubuntu and do the same ( cat /proc/cpuinfo ) command the Serial Number bit matches what Raspbian says it is...

#17

Thank you for the activation info.

Unfortunately the issue does remain, below is ubuntu 64 dmesg log (copied further up this time just incase...) :

[ 10.455999] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[ 10.456005] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[ 10.456011] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[ 10.456141] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[ 10.460264] uvcvideo 1-1.3:1.0: Entity type for entity Extension 4 was not initialized!
[ 10.460277] uvcvideo 1-1.3:1.0: Entity type for entity Processing 2 was not initialized!
[ 10.460283] uvcvideo 1-1.3:1.0: Entity type for entity Camera 1 was not initialized!
[ 10.460465] input: USB Camera: 5M USB CAM as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input12
[ 10.460703] usbcore: registered new interface driver uvcvideo
[ 10.460708] USB Video Class driver (1.1.1)
[ 10.468820] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 10.468862] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 10.475895] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 10.475933] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 10.573169] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 10.583094] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 10.594104] usbcore: registered new interface driver brcmfmac
[ 10.756225] Bluetooth: Core ver 2.22
[ 10.756312] NET: Registered protocol family 31
[ 10.756316] Bluetooth: HCI device and connection manager initialized
[ 10.756333] Bluetooth: HCI socket layer initialized
[ 10.756351] Bluetooth: L2CAP socket layer initialized
[ 10.756365] Bluetooth: SCO socket layer initialized
[ 10.854923] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 10.879003] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea
[ 12.231128] alua: device handler registered
[ 12.234231] emc: device handler registered
[ 12.237733] rdac: device handler registered
[ 13.140577] audit: type=1400 audit(1600975635.787:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1576 comm="apparmor_parser"
[ 13.140598] audit: type=1400 audit(1600975635.787:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=1576 comm="apparmor_parser"
[ 13.142406] audit: type=1400 audit(1600975635.787:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1573 comm="apparmor_parser"
[ 13.142426] audit: type=1400 audit(1600975635.787:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=1573 comm="apparmor_parser"
[ 13.142437] audit: type=1400 audit(1600975635.787:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=1573 comm="apparmor_parser"
[ 13.166642] audit: type=1400 audit(1600975635.811:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="tcpdump" pid=1574 comm="apparmor_parser"
[ 13.174611] audit: type=1400 audit(1600975635.819:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=1577 comm="apparmor_parser"
[ 13.182552] audit: type=1400 audit(1600975635.827:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=1575 comm="apparmor_parser"
[ 13.182795] audit: type=1400 audit(1600975635.831:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1575 comm="apparmor_parser"
[ 13.182836] audit: type=1400 audit(1600975635.831:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=1575 comm="apparmor_parser"
[ 13.868190] random: crng init done
[ 16.676487] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[ 16.676842] bcmgenet fd580000.ethernet eth0: Link is Down
[ 20.766906] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 20.766945] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 7456.881005] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7457.257034] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7473.765188] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7476.377203] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7481.053254] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7485.193295] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
[ 7488.137299] usb 1-1.3: reset high-speed USB device number 4 using xhci_hcd
ubuntu@ubuntu:~$

#18

Do you have a powered hub you can put between? Otherwise i think you will just have to "Auto-Use" the camera so when it drops it used again automatically

#19

I had other reasons to believe power delivery wasn't an issue but sense you mentioned this explicit test of that and I did indeed have a powered usb3 hub (complete with 2 fast charge higher amp ports...) I plugged it up as described and tested everything from the top situation remains unchanged.

Considering the persistence of the problem across raspbian/ubuntu64/cloud hub, it would appear that it is either a issue with the server program or a shared Linux component that is common across all of the named varieties...

bed time now, but tomorrow I shall test one of your windows versions of your server (I have more then one standard windows pc) and see what happens from a non-Linux server

#20

Actually 1 other possibility per a hypothesis, not sure how to test

if the data stream on the receiving end is either lagging, or inconsistent in its speed, it is possible (I think) that either the program or a windows subsystem is requesting the device reset to try and 'fix' the issue...

#21

if this last idea has any merit (dunno that it does...) at the cost of latency a data stream buffer(assuming there isnt one already... there could be, I can only guess how the program was implemented) at the receiving end could ensure the data flow has a consistent uninterrupted/or corrupted stream (maybe a check box or a auto detect function to determine 'lowest possible latency', or 'highest data integrity' based on need...)

#22

The USB stream is never dropped or corrupted, its not allowed according to the USB spec..

#23

welp whatever it is, it is not specific to linux...
Put the server on my windows laptop plugged one of these camera used the client on my desktop and selected the camera for use and the results were //exactly// the same....!

As to prior mentioned Idea, never really considered 'drops' so much as inconsistent speed ie a variable bit rate incurred due to random overhead from cpu clock cycles and network traffic and their varied loads resulting in hypothetical-illustrative-made-up-example of 150mbps one instant and the next instant 32mbps. All the data arrives but does it arrive in the time window the receiver is expecting it?

#24

"All the data arrives but does it arrive in the time window the receiver is expecting it?" yes that is the core issue.

Data cannot be guaranteed to arrive on time. Isochronous transfers are the type of data transfer that is used by webcams. They dont guarantee latency either but since a USB cable has minimal latency because its well shielded and is only connected to one device, its not an issue.

But over a network latency is entirely variable. So using webcams via virtualhere requires an Ethernet connection, or a good WiFi connection to minimize this added latency.

Normally buffers help with this issue but virtualhere doesn't have control over buffering (it happens at the next higher layer in the webcam driver itself) so that's why some camera work fine via virtualhere and some are inconsistent.

#25

"So using webcams via virtualhere requires an Ethernet connection"

with the singular exception of the windows-laptop test every test so far has been done over gigabit ethernet, hell the rpi's are using the official PoE hat along with a 2960 PoE cisco switch for their power source.

I suppose one thing I could try for testing purposes is create a vlan dedicated for this kind of traffic to clear any other traffic from the equation tht might cause latency...

#26

" or a good WiFi connection" - my test webcam C270 works fine on wifi...