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

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

Hi Roger!


frame rate and  fps are both the same.  If it is unable to sustain the 
framerate I would think that means that is not always able to get the 
needed usb bandwidth. Maybe reduce both camera's framerate to lower 
until both are able to keep the framerate.    Anything set in the main 
motion.conf file seems to be inherited by the thread*.conf files. The 
thread*.conf files settings overrides for the specific camera from what 
I can tell.


Thanks to the confirmation on both (framerate = fps and *.conf 
overriding motion.conf, or conversely passing through). One (of many!) 
things that confused me is I had set framerate to various values and 
generally didn’t seem to get followed: I sort of expected it to be the 
ten (currently five) value in the %fps variable in the camera name: 
*text_left Front Yard CAMERA 1 - fps %fps-*


The recorded videos seem to have five ‘steps’ – HH:MM:SS-qq In 
motion.conf the command line is

/text_right %Y-%m-%d\n%T-%q/ – the old version had a list of variables 
built in, current ones doesn’t. The ones when set at framerate 10 would 
‘count to ten’.



Are you using mjpeg/x264 for the usb camera streams?


Yes: *v4l2_palette 8* is in the commands. The other day I was 
experimenting with a few of the palette numbers (7, 9, 21, maybe a few 
others) and “oddly” (for me?!) they all gave a 4:3 output instead of 
16:9. sudo service motion restart to upate.


FWIW: *v4l2-ctl -V -d /dev/video4* (same for /dev/video0, Camera 2 and 
1, respectively)

Format Video Capture:

Width/Height : 1280/720

Pixel Format : 'MJPG' (Motion-JPEG)

Field : None

Bytes per Line : 0

Size Image : 1843789

Colorspace : Default

Transfer Function : Default (maps to Rec. 709)

YCbCr/HSV Encoding: Default (maps to ITU-R 601)

Quantization : Default (maps to Full Range)

Flags :


Just in case you or someone sees something.


Almost no computer is going to survive 120-130.

Heck, I’m almost not going to survive! Don’t treat your computer(s) to 
stuff you wouldn’t like! <g> (Knew it got rather warm in there, didn’t 
know it got_that_hot!)


As for the possibility of the cameras overheating, the working 
temperature of the ELP camera I think is the equivalent of the SVPro 
cameras I have is -10～70℃ (14° - 158°F). I’m not sure the SVPro camera 
has the same specifications. Have measured 103°F at the window – within 
the ELP specs…..


...OK, started last night, continuing this morning. Woke up to no video 
feed. <grumble> No idea when it quit. Both cameras have recordings 
through 6:07 a.m.: Camera1 is a 0 byte mkv file, Camera2 was doing a 
recording starting about a minute earlier. Get close to the end of 6:06 
it starts to freeze-continue-freeze at early in 6:07. which is the time 
Camera1 should have picked up the motion being tracked. It’s also 55°F 
out there, so the cameras should be cool. Not saying heat isn’t an 
issue, but should be an issue this instance.


I need to get get individual logging going. Tried yesterday and caused 
the video feed to not occur: read as offline/incorrect, same as when I 
need to restart Motion. I did try to place the log to my NAS, same as to 
where the videos are recorded, if that’s a clue.



Most of my cams are POE cams, so I might just have to run a wire or 2 
out to where I needed it.  I already ran one remote wire/power/water and 
have a cam sitting on the end of about 400ft of 100mbit/POE and it is 
working even though it is at least 70ft over officially supported 
distance.    POE is nice since I can have a single much larger machine 
sitting on a UPS someplace cool, with the UPS also powering the POE 
cameras so all has battery backup.


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 !!)


The RPi is on it’s own UPS – not the HAT type, regular standalone.




The pte would seem to be related to memory mapping for the video card, 
and seems to limit the video resolution that the 32bit version can do.


OK – semi-understand that. The setting of GPU Memory in the RPI4’s seems 
to be opposite of what was done with the RPi3’s. In the 3’s more memory 
allocated for the GPU just mean less (so slower) for the CPU. In the 
RPi4 too much gpu_mem and the system won’t boot (!). A while back I 
happily upped it to 1024 (so one-quarter of the total memory) – wouldn’t 
boot. Read where people have used 512 and their Pi wouldn’t boot. 
...Mine’s at 512 (wonder if maybe I should cut that).


Barry