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

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

Hi Roger!


uvcdynctrl -f -d /dev/video3 ==> The RPi didn’t know the command (and 
yes, I did change to /dev/video0). Ubuntu 18.04 (I haven’t updated to 
20.04 for various reasons) didn’t find but did suggest how to install. 
...Well, OK, what the heck, I have room on the Pi’s SD card….



pi@raspberrypi:~ $ uvcdynctrl -f -d /dev/video0

[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, 
name = 'User Controls', type = 6

[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x00980001, name = 'User Controls'

[libwebcam] Unknown V4L2 user control ID encountered: 0x00980927 
(V4L2_CID_USER_BASE + 39)

[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, 
name = 'User Controls', type = 6

[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x00980001, name = 'User Controls'

[libwebcam] Unknown V4L2 user control ID encountered: 0x0098090E 
(V4L2_CID_USER_BASE + 14)

[libwebcam] Unknown V4L2 user control ID encountered: 0x0098090F 
(V4L2_CID_USER_BASE + 15)

[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x009F0001, 
name = 'Image Processing Controls', type = 6

[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x009F0001, name = 'Image Processing Controls'

[libwebcam] Unknown V4L2 control ID encountered: 0x009F0905

[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x009F0905, name = 'Digital Gain'

[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00990001, 
name = 'Codec Controls', type = 6

[libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 
0x00990001, name = 'Codec Controls'

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x009909CE 
(V4L2_CID_MPEG_BASE + 206)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x009909CF 
(V4L2_CID_MPEG_BASE + 207)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x009909D8 
(V4L2_CID_MPEG_BASE + 216)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x009909E2 
(V4L2_CID_MPEG_BASE + 226)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x009909E5 
(V4L2_CID_MPEG_BASE + 229)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x00990A66 
(V4L2_CID_MPEG_BASE + 358)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x00990A67 
(V4L2_CID_MPEG_BASE + 359)

[libwebcam] Unknown V4L2 MPEG control ID encountered: 0x00990A6B 
(V4L2_CID_MPEG_BASE + 363)

Listing available frame formats for device /dev/video0:

Pixel format: MJPG (Motion-JPEG; MIME type: image/jpeg)

Frame size: 1920x1080

Frame rates: 30, 25, 15, 30, 25, 15

Frame size: 1280x720

Frame rates: 30, 25, 15

Frame size: 800x600

Frame rates: 30, 25, 15

Frame size: 640x480

Frame rates: 30, 25, 15

Frame size: 640x360

Frame rates: 30, 25, 15

Frame size: 352x288

Frame rates: 30, 25, 15

Frame size: 320x240

Frame rates: 30, 25, 15

Frame size: 1920x1080

Frame rates: 30, 25, 15, 30, 25, 15

Pixel format: YUYV (YUYV 4:2:2; MIME type: video/x-raw-yuv)

Frame size: 640x480

Frame rates: 30, 25, 15, 30, 25, 15

Frame size: 800x600

Frame rates: 15

Frame size: 640x360

Frame rates: 30, 25, 15

Frame size: 352x288

Frame rates: 30, 25, 15

Frame size: 320x240

Frame rates: 30, 25, 15

Frame size: 640x480

Frame rates: 30, 25, 15, 30, 25, 15



Sort of hate posting all that and filling the mail up; no idea if those 
invalid, unsupported and unknown listings at the top are a clue. And 
I’ll admit setting motion.conf’s framerate to 5 (or the previous 10) 
seems like the camera wouldn’t work as the lowest frame rate is 15. Us 
neophytes get confused easily! <g>





I would not count on the spec having actually been tested.  They 
probably needed a spec and as such guessed, and never actually did a test.

I was chuckling at that one: had that with a motherboard I used in what 
was to be my new computer. Ended up the CPU they said would work 
wouldn’t as too fast. Found that out when constant crashes and boot 
failures lead me to Googling. So purchase a CPU down one step (and 
recommended by the people running tests). Old CPU went into a new/second 
motherboard (yes fine tooth comb checked!). Credit card was a little 
limp that period!





    The RPi itself is in a clothes closet which gets warm in Summer –
    the Storage Area is on the other side. Not recalling if I added the
    heat sinks to it (probably) but it is in a case with a fan. vcgencmd
    measure_temp was running 49-54°C yesterday – seems the highest was
    just after a loss of the video (several times I caught it black out
    and so was able to check immediately). (Right now it’s 49.1°C. and
    appears to be running normally. ...Hmmm: Rube Goldberg script: if
    temp >52 do motion reset !!) 

That could be.  Note that I have had 2 separate laptops were the USB 
chips got flakey and stopped working.  Given it is a laptop I suspected 
that the heat design around the usb was less than great.   It might be 
that other chips on the PI need heatsinks.   If it was just the usb chip 
overheating that would probably not crash the PI since the usb hardware 
seems to get random bad data all of the time and the usb driver/software 
stack reports it and does not crash.  Does dmesg show weird USB messages?

dmesg wasn’t updated, or at least not with the errors needed a motion 
restart this morning:

[ 23.212552] CIFS: Attempting to mount //192.168.4.120/Motion

[ 23.212597] CIFS: VFS: Use of the less secure dialect vers=1.0 is not 
recommended unless required for access to very old servers

[ 160.208978] v3d fec00000.v3d: MMU error from client L2T (0) at 
0x1d21000, pte invalid

[ 6746.167332] ieee80211 phy0: brcmf_escan_timeout: timer expire

The [23] lines are to my old NAS, which won’t connect without the 
version 1.0 command (another project is to see about building a new NAS 
– might be more fun than buying, plus use a few spare parts!).

The [160] line – hmm: there’s that pte thing!

[6746] has been the last line since early this morning and I’ve done a 
couple motion restarts. Good news (I guess) is watchdog or somebody has 
done a motion restart: my recorded video file numbering was restarted 
(from 01).



And semi-quirkie: Camera 1’s video feed has been frozen for a little 
over two hours; Camera 2’s is fine and generally smoothly clicking along 
(per the seconds in the time display). Both cameras are recording motion 
events.





why on this motherboard we kept having the network port simply die 
permanently.  The heat was causing the link loss and was also causing 
the chips to die really fast   Note the chip itself was an intel, but 
the motherboard maker did not put a heat sink on it (the other mb's we 
checked all had heat sinks).


Nothing like saving 2¢! I found out the “AMD-approved” heatsink-and-fan 
for the CPU I’m used (the lower wattage/slightly slower one – same 
cooler for both versions) barely works. Someone said they’re provided 
with the expectation they’ll be thrown away and replaced by a real heat 
sink during the build. (Personally I would have rather not have a 
fan/heatsink included and spend the money saved to go to the correct 
heatsink.) BTW the “AMD-approved” heatsink allowed it to overheat to the 
point it would shutdown.





Often the MB sensor do not have the offset set right (ie +5 is more or 
less +5 but the base of 49 maybe 40 or may be 59).  I would probably 
heat sink everything you can and see where the airflow is. The network 
chipset that overheated tended to be in a 2u and/or 4u machines...the 
tiny 1u's were just find because the airflow was well constrained and 
flowing over the heatsinkless chip enough to cool it.  On the 4u/2u's 
the cases had greater airflow than the 1u cases but the airflow was not 
where it needed to be.  This would probably be a good usage for one of 
those thermal cameras.  You might just see what all you can put on a 
heat sink, and you might see if there are any air holes/inlets in the 
case that would provide airflow across the USB chip.


New toy! <g> ...I’m not so sure the problem is overheating. Won’t 
exclude, but right now sort of setting aside. The outdoor temperature 
has been in the upper 50’s (F) all day. Woke up this morning to no video 
feed to the monitor – a little investigation and looks like it shut off 
a little after 6 a.m., so Storage Area cool, cameras cool. The Pi itself 
reasonably cool.

vcgencmd measure_temp has been between 40.4 and 49.1°C so far all day. 
AFAIK this measures the Pi CPU temperature, so some other chip could be 
sweatin’.

vcgencmd get_throttled 0x0 so no undervoltage nor throttling issues 
since rebooted (yesterday morning?).

vcgencmd get_mem arm /and /gpu This one has me confused. Both report 
512. raspi-config reports gpu_mem set at 512. So must be a gig of memory 
shared by the CPU and GPU and the 4GB is actual RAM?? (I’ll have to 
decrease the gpu_mem later, which wil require a reboot, which will 
‘thaw’ camera1’s video feed.)

free Probably the memory report I wanted above but /get_mem/ might be 
telling me I’m starving the CPU. And as I typed someplace read where 
memory in the Pi4’s is handled differently than in the earlier versions: 
512 is the upper limit.

No idea if this reading/comparison points to anything:

Camera 1’s video feed froze at 13:34:27; video recording (to the NAS) 
still working.

>From my notes – <start>

14:10 Cam 1 video still frozen, Cam 2 seems fine -----

vcgencmd measure_temp temp=49.1'C

vcgencmd get_throttled throttled=0x0

vcgencmd get_mem arm arm=512M

vcgencmd get_mem gpu gpu=512M


pi@raspberrypi:~ $ free

total used free shared buff/cache available

Mem: (13:46) 3478284 *252028* *120272 * 196164 3105984 2863692

Mem: (14:10) 3478284 253476 *2598312 * 204092 626496 2856816

Swap: 102396 2816 99580


<end notes>


I did the bolding – the drastic change in free memory seems like it 
might be significant. Or just the video feed isn’t working so the memory 
became free. I’ll admit to flailing around.


OK, time to send this off – thanks for reading through! Was fun chatting 
about the manufactures guessing their stuff works!

Barry