Re: [Motion-user] Gray glitching but only one of of two identical cameras

[Barry M. <bar...@gm...>]

Hi Mark!

Sending this out to you plus the Motion mailing list.


> No worries.  One possible source of glitching will be if the cameras 
> each try to reserve all of the USB bandwidth.  My home-brew CCTV 
> systems with Pi's suffers from this with old Microsoft Lifecam 
> Cinemas, to the point that I bought a PiW per camera (and then wished 
> I'd gone for Pi's with ethernet sockets, but that's another story).


<chuckle> Sounds like when I’ve purchased stuff and don’t know about 
other options so don’t know the questions to ask about those other options!


I think I tested the ‘grabbing of all the USB bandwidth’ yesterday: 
copied the current SD card, modified to a different IP, and commented 
out the second camera (in motion.conf). Unplug one camera from the 
original Pi, plugged into the test Pi – and still got glitching! :(


Not sure what that is telling me. The common points off the top of my 
head between camera sets that are not glitching and this one that is are:


  *

    Not glitch: single camera units. Eliminated that with the test unit
    yesterday.


  *

    Cameras themselves: The glitching cameras are SV-something, which
    /look/ like the ELP cameras I generally use. (Cheaper webcams have
    been used for tests and they work fine. Not sure if this is a clue
    but the SV (glitching) cameras don’t have human-readable text in lsusb.

  *

    Motion itself. The test was made using a clone of the card with the
    glitching. What I’ll try later is clone a different card which isn’t
    glitching and see what happens.


BTW, you had asked about cards: Samsung Evo Plus (32 GB). I have also 
use SanDisk Ultra. I have a few old FileMate floating around so at the 
time wasn’t sure what was in the Pi.


The wall wart is a Vilros 5.1v @3000mA, plugged in to a small UPS




> You may be able to use 'usbtop' to see if there is a disproportionate 
> allocation of USB bandwidth.

Thanks! ...Not sure what it tells me (the Stack Overflow post sailed 
over my head!)


Bus ID 0 (All USB buses) To device From device

Device ID 1 : 0.00 kb/s 0.00 kb/s

Device ID 2 : 0.00 kb/s 0.00 kb/s

Device ID 3 : 141.74 kb/s 12508.48 kb/s

Device ID 4 : 141.72 kb/s 12512.75 kb/s

Bus ID 1 (USB bus number 1) To device From device

Device ID 1 : 0.00 kb/s 0.00 kb/s

Device ID 2 : 0.00 kb/s 0.00 kb/s

Device ID 3 : 141.74 kb/s 12507.94 kb/s

Device ID 4 : 141.72 kb/s 12513.47 kb/s

Bus ID 2 (USB bus number 2) To device From device

Device ID 1 : 0.00 kb/s 0.00 kb/s


The results are very similar to another Pi with a single camera which 
isn’t glitching.




> https://stackoverflow.com/questions/25619309/how-do-i-enable-the-uvc-quirk-fix-bandwidth-quirk-in-linux-uvc-driver/25619508 
> covers some of the knowledge of bandwidth reservation issues - caution 
> that the resolution is also dependent on which frame format is being 
> used.

Yes, lots of intertwined variables!



> On power supplies - I have had a couple of official PSUs fail after 3 
> years.  Symptoms are that the Pi mostly works fine, but sometimes 
> get's to the point even reboots don't help.  It needs to be a full 
> unplug from the wall, waiting 15 minutes, then plugging back in.

Yuuuup! Aware of that little issue. Chargers aren’t the same as power 
supplies. An output of 5.1 volts will frequently take care of voltage 
drop in the power cable; using proper quality cable definitely makes a 
difference.


And putting a Pi in a hot storage area (think ‘attic’) in the summer 
causes some really strange issues!




> To help isolate power issues, a powered USB hub with one (or both) of 
> the cameras plugged in will reduce the load on the PSU to the Pi. 
> Depending on the rating of the hub, you might be able to power the Pi 
> and cameras from the hub and retire the offical PSU.

I had tried that a while back but I don’t recall when or with which 
utility: I had used MotionEye for some time (year or so) but didn’t like 
some of the ways it handled triggers. Motion resolved 99% of them.



> On USB3 vs USB2 - most chipsets don't cap USB3 devices to USB2 speeds 
> if you plug a USB2 device into a USB3 socket, but internally switch it 
> onto the USB2 bus.  'usbtop' has some extra options to show you where 
> devices appear.

I was thinking more along the lines of maybe the extra 
bandwidth/throughput available on the USB3, possibly extra current; not 
sure if that’s applicable to the Pi4’s. I have an older USB2 scanner and 
on an old (mini-tower) computer it grunted on USB2 but purred on USB3.


> Nothing jumping out as an 'It's this!' moment, but a few more things 
> to look at, at least.

Yes, thanks! I’m not sure what to look for so admittedly peeking here 
and there at stuff that seems a logical possibility –without screwing 
things up too badly!


I’m going to try cloning a different camera’s Motion. Yesterday’s test 
used a clone of the unit that’s glitching.


Barry