The logs provided don’t look like a cellular “drop” first, they look like the USB/QMI control channel is getting torn down.
QmiWwanThread poll err/hup/inval followed by write=-1, errno: 5 (Input/output error) is what you typically see when the /dev/cdc-wdmX endpoint stops responding because the modem’s USB interface reset/disconnected (even briefly). Once that happens, quectel-cm tries to recover by deactivating and setting the link down/up again, then re-running DHCP. Streaming video increases sustained traffic and current draw, so marginal USB power/signal issues show up only under load while “idle state” looks stable.
What to do to make this stable on an Orange Pi with many modems:
Eliminate USB power management and autosuspend
On Linux SBCs, USB autosuspend can randomly suspend endpoints under load or after brief idle gaps, and with multiple modems it can get messy.
Disable autosuspend globally (kernel cmdline usbcore.autosuspend=-1) or per device in /sys/bus/usb/devices/.../power/control set to on.
Also disable any “USB power saving” settings in the OS if present.
Treat this as a power integrity problem first (even with powered hubs)
EC25 class modems can draw large burst current during uplink scheduling and high throughput. Seven modems streaming can exceed what the hubs can supply per port, or you can hit voltage drop across cables.
Use short, good quality USB cables (voltage drop matters a lot).
Prefer hubs with strong 5V rail per port; many “12V 3A” hubs still regulate to 5V internally with limited per-port current.
If the hub supports it, avoid “charging detection” style ports and use true data ports.
Add ferrites on USB cables if you see random resets.
Avoid USB3 interference and controller saturation
USB3 can radiate noise that interferes with LTE and can also stress the host controller when many composite devices enumerate.
Try forcing the hubs/modems to run in USB2 mode (connect to a USB2 port or use a USB2 hub) and compare stability.
Spread modems across different root hubs/controllers if possible (Orange Pi ports may share the same controller).
Confirm whether the OS is reporting USB disconnect/reset events
Right around the failure time, run:
dmesg -Tw and look for “USB disconnect”, “reset high-speed USB device”, “device descriptor read/64, error”, etc.
If you see those, it confirms the issue is USB transport instability, not APN or network.
Reduce churn in the recovery path
Your log shows repeated reconnect + DHCP + “File exists” / “No route items found”.
Make sure the wrapper cleans routes and addresses cleanly before restarting and confirm each modem interface is unique and not racing with another instance. Also confirm raw_ip mode is applied to the correct interface every time.
Check modem thermal and RF conditions (secondary, but worth validating)
If the modems are physically close and streaming, they can heat up and/or desense each other, which can trigger instability or resets.
Check temperature (and ensure airflow).
Separate antennas and modems physically as much as practical.
If you provide:
dmesg lines around one failure,
lsusb -t showing how the modems are distributed across buses,
and whether the modems actually disappear/re-enumerate when the error occurs,
I can tell you immediately whether this is (a) USB reset/disconnect, (b) host controller overload, or (c) modem crash/reboot under load and the fastest way to stabilize your setup.