Send Motion-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: Gray glitching but only one of of two identical cameras
(Barry Martin)
2. Re: Gray glitching but only one of of two identical cameras
(Barry Martin)
----------------------------------------------------------------------
Message: 1
Date: Sun, 23 May 2021 09:12:46 -0500
From: Barry Martin <[email protected]>
To: Mark Cooke <[email protected]>
Cc: [email protected]
Subject: Re: [Motion-user] Gray glitching but only one of of two
identical cameras
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Sun, 23 May 2021 17:43:02 -0500
From: Barry Martin <[email protected]>
To: [email protected]
Cc: Mark Cooke <[email protected]>
Subject: Re: [Motion-user] Gray glitching but only one of of two
identical cameras
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Mark!
Update ? probably bad form not to wait for a reply so I apologize for
that but followed through on some of my considerations from the earlier
post.
Verified I had been using two different versions of Motion; listed on
the IP_addr:8080 webpage ? of course I look at the individual cameras
pages where I get full screen and so don?t see.Eventually found /motion
-h/ displays the version also. So, the RPi with the two glitching
cameras I?ve been playing with is version 4.1.1 and a different RPi with
one camera and AFAIK never glitches is version 4.3.2. Is this the ?It?s
this!? we?ve been looking for??!!
<modify-test-correct typo-retest> Nope, not the cure. I don?t think even
made any difference. Good news is at least I?m using the current version
of Motion now.
I?m starting to think the problem is with the cameras. Right now not
sure how to test in a live scenario ? getting to the window where the
current cameras are isn?t all that easy. It seems the glitching problem
is worse with a bright day, though also occurs when overcast, just to a
lesser degree Might be able to rig a test out a different window but
requires two, maybe three USB extensions (that could give a garbage
signal!)?. Powered hub partway??. (I?m sort of typing to myself to get
ideas.)
I tried to do a bit of investigation with the vendor:model number from
lsusb:
32e4:9422 Both cameras of the RPi with the glitching.
SV-USBFHD06H-BL36 (SVPRO Brand), which appears to be the same as the
ELP ELP-USBFHD06H-BL36.
32e4:9320 ELP-USB130W01MT-BL21 ? camera has no glitching; this RPi
had the newer Motion version and so I cloned from this unit to the
one that glitches.
I couldn?t find these codes when I went to https://usb-ids.gowdy.us
<https://usb-ids.gowdy.us/> and that?s the only site I know of.
OK, ?nuff for now.
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 179, Issue 26
********************************************
