Timing/sync on one camera

[lilfellabob]

Hi, I'm runnning motioneye 0.42.1 on a raspberry pi 3 model B plus rev 1.3 (with raspbian 10) and am having issues with 1 out of my two cameras. One camera is completely fine but the second one is running at a reduced speed. What I mean by this is that the camera's on screen text showing the time starts out the same as the motioneye time overlay but over time becomes further and further behind. It's very strange as it's not conventional lag where it's always x seconds behind, it actually gets worse the longer it runs for. This camera is a higher definition than the first but I've tried dropping all the quality settings, FPS and resolution but none of these have any impact. I would have thought the 3 B plus could handle two cameras at 720p..

Any ideas?

Thanks, Josh

[starbasessd]

Which version of motion? What is your base OS? Anything like docker, or Home Assistant involved? Make and model of camera? What URL are you using? If RTSP, try removing the camera, then re-adding it, but use TCP/UDP instead of RTSP/TCP use RTSP/UDP. If your camera supports RTMP try it.

[zagrim]

I have MotionEye running on a RPi 3 (can't really remember the exact model but likely it is B+) with two RTSP cams with the main stream set to 1280x960@10fps, but doing motion detection with that setup ended up being way too much for the Pi (CPU load at 100% and overheating quickly, even 720p with lower fps was still too much as far as I remember), so now motion detection is done using a secondary stream of 704x564@4fps and video is saved from the better quality stream using movie passthrough. So, in addition of what he asked above :point_up: please also check the CPU load of your Pi.

Myself I had similar increasing lag when initially trying to set things up using Shinobi (before trying ME) and couldn't figure out what caused that. With ME I've never noticed anything similar. Trying out UDP instead of TCP (as suggested in above comment) as well as RTMP (if supported) are worth checking anyway.

[starbasessd]

@zagrim May I ask how you split detection and recording?

[starbasessd]

@lilfellabob just for good measure, if you can get to console (keyboard & monitor) or SSH, could you please run the command and report the results here: vcgencmd get_throttled Thanks...

[zagrim]

@starbasessd I'm using "Movie Passthrough" feature (movie_passthrough & netcam_highres Motion config options).

[lilfellabob]

Thanks for all the suggestions! I will try these and report back on the cpu use and output of that command tomorrow

[lilfellabob]

Hi again, responses below! Motion version is 4.2.2 Base os is raspbian 10 No docker or HA Camera is an 'eyes.sys' not sure on the model (was an ebay purchase) I can't find a url format for RTMP - is this generic?

I'll try the UDP vs TCP but not noticable difference from when I first added it.

It seems that lower quality is now making a difference and isn't too far behind after leaving it on all day. The CPU looks like it's copping a beating though - do you know why there's so many motioneye lines?

Thanks again!

[starbasessd]

Output of vcgencmd get_throttled? What else are you running? Swap is 100% used. I looked here: https://www.ispyconnect.com/cameras/E but do not see 'eyes.sys' listed.

[lilfellabob]

Oops forgot that one. I get throttled=0x80000 yeah it's not a super common brand unfortunately

[starbasessd]

You are thermal throttling, getting too hot so it slows itself down until it cools down. That can be / is a big issue. Heat sinks, micro fans, better cases, cooler location, lower resolution & frame rate, etc. You can see the 'instant'/current temperature with the command: vcgencmd measure_temp and a neat little script to figure out the get_throttled info is attached. extract to somewhere convenient (/home/pi or similar) run sudo chmod +x oops.py then run ./oops.py in that folder This will tell you if there are continuing heat or power issues. On the devices before the 4Bs, the lower limits were 60C (soft limit) and 85C (hard limit) Pi 4 operates hotter, and needs to be cooled and set up to follow those rules. See: https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md

oops.zip

[lilfellabob]

Thanks heaps for all your help, I'll start with some heatsinks and see how I go!

[zagrim]

As for the question "do you know why there's so many motioneye lines", if you mean all the lines with /usr/bin/motion -n -c /etc/motioneye/motion.conf -d 5, there really shouldn't be any more than one process with that command line, but it also seems both top and htop show threads spawned out of a process that way. The one with white text (which I guess is also highlighted and is thus shown otherwise differently in the screenshot) is the actual process (you have only one running as it should be) and the green ones are the threads within that process. IMO it's confusing that threads are shown as processes with bogus process IDs but I guess there's some good excuse related to history and backwards compatibility for that.

[smokeybandit]

If RTSP, try removing the camera, then re-adding it, but use TCP/UDP instead of RTSP/TCP use RTSP/UDP. If your camera supports RTMP try it.

I've been fighting this for some time. Using UDP instead of TCP did the trick.

Hint: just add "netcam_use_tcp off" to your camera conf file and restart motioneye. No need to delete/re-add the camera.