VIDIOC_DQBUF error 19 no such device: diagnose USB camera drops

Your capture program starts, negotiates formats, maybe even shows a few frames — and then dies with VIDIOC_DQBUF error 19, No such device. The camera that was streaming a second ago is gone from /dev/video*. This guide is for engineers integrating USB3 or depth cameras on Linux hosts who need to find why the link drops and stop it. You will learn what error 19 means at the kernel level, the causes ordered by likelihood, a one-variable-at-a-time isolation procedure, and the checks that prevent it coming back on the production line.

What error 19 means: the device left the bus

VIDIOC_DQBUF is the ioctl that dequeues a filled buffer from the kernel's capture queue. Error 19 is ENODEV: the device the buffer belongs to no longer exists. The V4L2 node was created when the camera enumerated over USB; when the USB connection drops, the kernel tears the node down and every queued ioctl returns ENODEV.

Two consequences follow. First, this is not a software-format problem — a bad pixel format or unsupported frame rate fails earlier, at format negotiation, with a different error. Second, the exception surfacing in your application is a symptom; the fault happened on the wire or in the controller before it. Diagnose the physical layer, not the capture loop.

The signature in the system log confirms it. Run dmesg -w in a second terminal while streaming:

Look for lines like usb 2-1.1: USB disconnect, uvcvideo ... resume error -5, or failed control queries with -32 (EPIPE). Any of those means the link dropped mid-stream. If dmesg stays silent while the error appears, jump to the host-software causes at the end.

Likely causes, in order of probability

1. Cable or extension. The most common cause by far. Long runs, chained extensions, thin unshielded cables and worn connectors degrade SuperSpeed signalling until the link drops under load. Several field reports of exactly this error traced it to a USB extension cable; the same camera on its supplied short cable ran flawlessly.
2. Power. A bus-powered hub or a port that cannot deliver the current the camera draws causes brownouts, especially at stream start when multiple subdevices power up together.
3. Controller bandwidth. Each isochronous stream reserves bandwidth on the root hub. Two or three cameras behind one controller, or any two behind one unpowered hub, can exceed it; the controller resets the offending device.
4. Hub renegotiation. Inexpensive hubs re-enumerate their downstream devices when another device plugs in or a link trains up, tearing down an active stream.
5. Host software and kernel. Old kernels had UVC bugs — failed commit controls and even NULL-pointer panics — and an SDK built against a mismatched kernel patch can break streaming while a simple viewer still works.

Isolation procedure: one variable at a time

Work down this list, changing exactly one thing per step, and keep dmesg -w running.

1. Stream one camera, one stream. Open a single subdevice at a modest format. If that is stable, stream the camera's full set simultaneously. Failure only at full load points at bandwidth or power, not the cable.
2. Read the log at the moment of failure. Note whether the camera disconnects entirely (physical drop) or only a control query fails (host-side). This single observation sorts the rest of the procedure.
3. Remove every extension. Plug the camera directly into a root-hub port on the machine with one known-good cable. Many cases end here.
4. Swap the cable. Replace it with a quality USB3 cable of the needed length. For fixed installations, drag-chain-rated cable survives robot and gantry movement.

5. Move to a different port, then a different controller. Check the topology with lsusb -t: ports sharing a hub share bandwidth. Move the camera to a controller of its own — an add-in USB3 card gives streaming cameras a private root hub.
6. Insert a self-powered industrial hub. A hub with its own supply isolates power problems from bandwidth problems: if the drop stops, the port was starving the camera.
7. Add cameras back one at a time. If the error returns with the second camera, you have measured your controller's limit. Spread cameras across controllers, or lower formats and frame rates.

What the topology tells you

lsusb -t prints the tree of hubs and devices with their link speed. A camera showing 480M instead of 5000M has trained down — a sign of cable or connector trouble long before it drops outright. Two cameras under the same hub entry share that hub's budget; two cameras under different root entries usually do not.

Budgeting isochronous bandwidth is arithmetic you can do beforehand: a 640 × 480 YUYV stream at 30 fps is roughly 640 × 480 × 2 × 30 ≈ 18 MB/s, and USB3's practical sustained payload is far lower than its 5 Gb/s headline once overhead and other traffic count. When several depth or colour subdevices sum toward a controller's ceiling, plan for a second controller from the start — the same reasoning behind our guide to multiple USB cameras and connection limits and the deeper bus analysis in finding the USB cause of LIBUSB_ERROR_IO.

When the cable is not the culprit

If dmesg is silent, or the log shows failed UVC control commits and kernel oopses rather than clean disconnects, the physical layer is probably fine and the host stack is at fault.

• Kernel version. Vendors support recent long-term-support kernels; early USB3-era kernels carry known UVC defects that produce exactly these signatures under load. Moving to a supported kernel and reapplying the camera's UVC patch is the legitimate fix — see matching a UVC patch to the kernel source tree.
• SDK and viewer mismatch. A viewer such as VLC opening one stream while your SDK opens all subdevices is not a fair comparison. Verify with the SDK itself, one stream at a time, before concluding the library is broken.
• Callbacks and threads. Multi-camera applications using per-camera callbacks are more sensitive to bus hiccups than polling loops; if callbacks die where polling survives, read multi-camera acquisition freezes and buffer queues before touching hardware.

A related pattern on embedded Android hosts — frame drops tied to the USB connection rather than the camera — is covered in this knowledgebase article on reducing UVC frame drops over Android USB.

Hardware choices that prevent the error

Cable discipline solves most cases permanently. Choose a single cable of the right length rather than joined extensions; use locking or screw-secured connectors where vibration exists; and route camera cable away from motor and drive wiring. For GigE cameras the same class of mid-stream loss has its own causes — our guide to PoE camera stream drops and device recovery covers that interface.

Give each high-bandwidth camera its own controller or a powered industrial hub, and budget power for the worst case: cameras draw most at simultaneous multi-stream start. Depth and ToF sensors add structured-light projectors to that budget — a depth/ToF camera next to a colour camera on one unpowered hub is a classic error-19 setup.

For new stations, the camera finder lets you filter by interface, and the system configurator walks camera, cable and host choices together, which is where bandwidth conflicts are cheapest to avoid. If a station keeps dropping cameras after these checks, contact us with the dmesg output and the lsusb -t topology and we will help you pin it down.

Checklist before you call it fixed

• Camera streams its full format set for at least 30 minutes with zero dmesg events.
• Every streaming camera sits on its own controller, or on a powered hub with measured headroom.
• No extension cables anywhere in a production run; one continuous rated cable per camera.
• lsusb -t shows each camera at its full link speed, not trained down.
• Kernel is a supported long-term-support version, with the vendor patch reapplied after any update.
• Capture code handles ENODEV by reopening the device after re-enumeration, not by retrying the dead handle.

Get those six right and VIDIOC_DQBUF error 19 stays a one-time diagnosis instead of a recurring line stoppage.