Hardware recommendation?

[mega99]

I currently have a setup on a raspberry pi 4, yet with only 5 IP cameras running at fairly basic resolution and framerate, the cpu load is balls to the walls and there is noticable lag between when something happens in front of one of the cameras and when it shows in the stream (And was hoping to ad 3 or 4 more cameras)

Does anyone have any recommendation for more capable hardware to run on? Something short of a full PC build, preferrable some single-box small device?

Is it possible to reflash any of those sub-$100 "NVR" devices you can find on amazon to run motion/motioneye instead? (I would use one of those, but they all require MSIE or windows and plugins in order to manage/access from a PC, and microsoft software isn't allowed on my network - I want to be able to access it from a chromium browser on a linux pc)

[StarbaseSSD]

MotionEye or motionEyeOS?

What kind (make/model) of cameras?

My Production motionEye hub is a Lenovo M73 (<$100) i5/16GB/1TB TFF PC on a GBit Ethernet network with 6 cameras which gets 5-20 FPS per camera. Resolution affects it quite a bit. My HTTP & USB cameras are 800x600, the RTSPs are 1280x720.

A Pi4-8GB motionEyeOS with the same 6 cameras gets about the same frame rate.

All are very close to 'live' (< 1 second difference). Most cameras are HTTP MJPeg, 2 are RTSP, one is a USB Webcam direct connect.

As to re-flashing, not unless you want to compile it yourself. The board choices available are on the website for motionEyeOS: https://github.com/ccrisan/motioneyeos/releases.

Some of the boards are more powerful, but all are ARM architecture.

You could build a very lite Linux on the TFF PC, or run it as a Docker on MAC or Linux on an existing machine.

[StarbaseSSD]

" I did try a MotionEyeOS image, but I booted it, and it never came up on the network "

Usually caused by running an older rpi-eeprom, and anything but dev20201026 on a Pi4-4GB or -8GB.

" Pretty sure that are all rtsp"

That may be an issue. If you go to the iSpy database, are you using the RTSP connection suggestions there?

If you are using the RTSP, are you using TCP or UDP? UDP sometimes works better, as does RTMP (if supported)

[mega99]

Straight Motioneye, with a seperate install of motion, on regular Raspibian.

I did try a MotionEyeOS image, but I booted it, and it never came up on the network, never requested an IP from the DHCP server, so I never was able to connect. I don't know if it failed boot, or if something else failed.

The cameras are various PoE IP ones, and some Pelco/Sarix IP non-POE ones. No wifi.

Pretty sure that are all rtsp.

I don't want to use my existing linux workstation, I want a dedicated box.

I guess an old laptop with sufficient horsepower could handle it..

On Tuesday, September 14, 2021 at 6:54:29 PM UTC-4 StarbaseSSD wrote:

[mega99]

How would I check/resolve an "older rpi eeprom" ? This is the first I've ever heard that such a thing even existed.

As far as the rest, I'm mostly using the ME defaults, aside from lowering the framerate and the resolution. And I haven't even enabled any recording yet either.

[StarbaseSSD]

Run on a Terminal Window or remote in with SSH:

sudo rpi-eeprom-update

If it is the latest, it'll report:

pi@raspi1:~ $ sudo rpi-eeprom-update
BOOTLOADER: up to date
   CURRENT: Thu 29 Apr 2021 04:11:25 PM UTC (1619712685)
    LATEST: Thu 29 Apr 2021 04:11:25 PM UTC (1619712685)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

A lot of recently purchased Pi4-4GB and -8GB have eeproms dated last year, depending on when manufactured and how long they've been on the shelf.

When you add an RTSP camera, the last box in the Add Camera window will default to "RTSP/TCP Camera"

If that camera is showing delay, you can try to delete and re-add the camera as "RTSP/UDP Camera"

You can also see if your camera supports RTMP protocol in the iSpy database.

https://www.ispyconnect.com/cameras

[Rolf Pedersen]

--
You received this message because you are subscribed to the Google Groups "motioneye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motioneye+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/motioneye/795bfcc2-d59b-4c51-8a25-6c8c264bd05bn%40googlegroups.com.

Howdy,
FWIW, I'm using a Pi4, 8G memory with 4 rtsp-connected cameras and it seems relatively unfazed.  3 are PoE and 1 is wifi, IIRC.  Camera settings are probably influential.  I watch the streams in chrome running on a more powerful i5 machine and it keeps up on 4 monitors.  I'll paste htop screenies from ssh sessions below, first for the pi, then for i5-6500 on Z170I PRO GAMING.
Rolf

[mega99]

Load average on that pi is 2.70 - doesnt seem "unfazed" to me.

[Rolf Pedersen]

On 9/15/21 9:52 PM, mega99 wrote:

Load average on that pi is 2.70 - doesnt seem "unfazed" to me.

Sorry, I'd never learned how to interpret load average.  My, perhaps naive, take was that no core was even approaching 50% usage, swap was not being used, after 15 days+ (in fact, memory usage looks quite low), and none of the 4 feeds had any lag.  Looking around at various explanations of cpu load, I've come to the point of view that a load of 1 would mean no process is waiting for processor time, so not problematic except this is a load average where instantaneous load likely goes above 1 at times, causing production delays on the fazed processor.  A load of 2.70 for one core would, indeed, be not a good situation.  However, from what I read, a load of 2.70 for 4 cores indicates each core is running at an average of about 68% capacity, which seems to me to qualify as "relatively unfazed".  I'd imagine that the motion process executes in a multi-threaded fashion is relevant and point out that the pi has no other tasks set by me before it, only handling the streams.  Also, I've found that settings for images, streaming, movies, motion, and capture can create lag.  In a nutshell, I've only got manual snapshots enabled and motion detection disabled, just using the cameras as surveillance monitors.  Is there something I'm missing?

To view this discussion on the web visit https://groups.google.com/d/msgid/motioneye/94ad8941-d8f5-4992-8f35-c33f3cedc2d4n%40googlegroups.com.

[StarbaseSSD]

On a quad core processor, 2.7 is not worrisome. (2/3rds full use)

A good explanation is here:

https://www.site24x7.com/blog/load-average-what-is-it-and-whats-the-best-load-average-for-your-linux-servers

Motion detection and video processing is very CPU and GPU intensive, especially in a processor like an ARM.

[sbmi...@gmail.com]

I have not yet tried RPi4, but I certainly tried RPi 3B+ and it was not up to the task.
So, I got an ODROID HC1, which uses the same CPU as XU4 and therefore runs that version of MotionEye.  It handles 3 cameras much better than Pi 3B+ ever did.  

HC1: https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
XU4: https://www.hardkernel.com/shop/odroid-xu4-special-price/

[Dave Winstone]

On my setup I have a raspberry pi 4 and 4 high resolution cameras connected via Ethernet. 

The Load as reported by MontionEyeOs used to be more than 4 for most of the time, and at least 2 of the camera's were laggy, with nearly 30 seconds or even minutes between different cameras. I could be seen in all 4 cameras at the same time - even though they were pointing in different directions!

Then, one of my camera's broke and I had to replace it - and the problems with lagginess (is that a word?) and load got even worse - so I was looking to upgrade from the RPI4.

Then I discovered the netcam_highres option - and what a difference that has made! I made a few other tweaks too - and now my load is around the 2.0 mark for most of the time, and literally maybe a seconds difference between the cameras.

As I understand it, by using the netcam_highres option, when you are recording your motion detected movies - they are in full high resolution - but what you see on streaming is the low resolution version - and it's also the low resolution version that motion detection is being run against. Previously I was doing everything on the high resolution feed including motion detection and that was having a big impact on the load.

Another tweak that I did was to make the camera do as much as possible - so this included removing any overlays - such as the text overlays with the time and 

To view this discussion on the web visit https://groups.google.com/d/msgid/motioneye/fcfc432a-9686-4ea1-828c-2002f20c08aen%40googlegroups.com.

[Dave Winstone]

Oops - accidentally pressed send!

Try again:

On my setup I have a raspberry pi 4 and 4 high resolution cameras connected via Ethernet. 

The Load as reported by MontionEyeOs used to be more than 4 for most of the time, and at least 2 of the camera's were laggy, with nearly 30 seconds or even minutes between different cameras. I could be seen in all 4 cameras at the same time - even though they were pointing in different directions!

Then, one of my camera's broke and I had to replace it - and the problems with lagginess (is that a word?) and load got even worse - so I was looking to upgrade from the RPI4.

Then I discovered the netcam_highres option - and what a difference that has made! I made a few other tweaks too - and now my load is around the 2.0 mark for most of the time, and literally maybe a seconds difference between the cameras.

As I understand it, by using the netcam_highres option, when you are recording your motion detected movies - they are in full high resolution - but what you see on streaming is the low resolution version - and it's also the low resolution version that motion detection is being run against. Previously I was doing everything on the high resolution feed including motion detection and that was having a big impact on the load.

Another tweak that I did was to make the camera do as much as possible - so this included removing any overlays - such as the text overlays with the time and camera name, and have the Camera place those on the stream instead.

On the Movie recording options - I also used the Movie Passthrough feature - which also improved things, and now when I play back the recorded movies - they are smooth and really high quality.

Quick screenshot below showing the netcam_highres option where it shows the high res channel on my camera, whilst Camera Device is the low resolution version. You'll see that the time is the same on 3 of the cameras with one just being 1 second behind

[Jx J]

My Pi4B 2GB model is currently running well with 3 network cameras and a PS2 camera connected by USB.

I've no idea if it makes a difference, but I've turned off network streaming from MotionEyeOS, as I have no use at all for that.

I also have a second Pi connected, which I think is one of the first generation models.    That is set to take one picture every 30 minutes (with a slight difference in interval).   It manages that with two network cameras, but seems to fall over every time I try to connect the third.   Am still trying to figure out how to fix that.

[StarbaseSSD]

For the Pi that is having issues:

Model?

Cooling?

Which version of motionEye or motionEyeOS?

Any logs? (messages, motion.log, and motioneye.log are helpful) (in motionEyeOS they are found in Settings, Expert Settings)

[Jx J]

The Pi with the issues is a Raspberry Pi B 700MHz Broadcom BCM2835 CPU with 512MB RAM.

I only started using it as I'd retired it from it's previous temperature logging role & it makes a nice little back up option.       The OS version is   motionEyeOS 20200606  

As for cooling, it doesn't even have a passive heat sink.    Perhaps a modest investment is in order here.

[My Pi4B has a heat sink and fan]

[StarbaseSSD]

For most usages (especially on the newest hardware, and the oldest) I recommend 20200203 or dev20201026.

If you run 20200606 or dev20201026 it logs CPU temps to the messages log (handy)... Need to see if it is overloaded, as it is like a PiZero (underpowered for the level of work asked of it from motion and motionEye even in motionEyeOS)

[Jx J]

Thank you.

Here's a sample of the log (2 cameras).

Nov 15 13:15:00 Old_Pi_B cron.info crond[966]: USER root pid 23901 cmd /usr/sbin/dyndns-update
Nov 15 13:15:42 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 36 C
Nov 15 13:16:42 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 37 C
Nov 15 13:17:14 Old_Pi_B user.err motion: [4:nc4:Rear Garden] [ERR] [NET] Above message repeats 1 times
Nov 15 13:17:14 Old_Pi_B user.err motion: [4:nc4:Rear Garden] [ERR] [NET] netcam_rtsp_handler_reconnect: Normal resolution: Reconnecting with camera....
Nov 15 13:17:42 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 37 C
Nov 15 13:18:13 Old_Pi_B user.err motion: [3:nc3:North of Ho] [ERR] [NET] netcam_rtsp_handler_reconnect: Normal resolution: Reconnecting with camera....
Nov 15 13:18:35 Old_Pi_B user.err motion: [4:nc4:Rear Garden] [ERR] [NET] netcam_rtsp_handler_reconnect: Normal resolution: Reconnecting with camera....
Nov 15 13:18:42 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 37 C
Nov 15 13:19:43 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 37 C

I noticed the "under-voltage throttled".

As I have no idea if that's normal, I swapped the 1A power supply for a 2A power supply and a better cable.  Then re-added the third camera.   Still not working. 

It fails to connect to the cam with the same settings the other Pi is successfully using.   

Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file /data/etc/motion.conf
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-1.conf
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-2.conf
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] config_camera: Processing camera config file camera-3.conf
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] motion_startup: Logging to syslog
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] motion_startup: Motion 4.2.2+gitUNKNOWN Started
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] motion_startup: Using default log type (ALL)
Nov 15 13:33:48 Old_Pi_B user.notice motion: [0:motion] [NTC] [ALL] motion_startup: Using log type (ALL) log level (WRN)
Nov 15 13:34:09 Old_Pi_B user.err motion: [3:ml3:Camera3] [ERR] [NET] netcam_rtsp_open_context: Normal resolution: Unable to find stream info: Success
Nov 15 13:34:09 Old_Pi_B user.err motion: [3:ml3:Camera3] [ERR] [VID] vid_start: Netcam RTSP failed to open
Nov 15 13:34:09 Old_Pi_B user.warn motion: [3:ml3:Camera3] [WRN] [ALL] motion_init: Could not fetch initial image from camera
Nov 15 13:34:09 Old_Pi_B user.warn motion: [3:ml3:Camera3] [WRN] [ALL] motion_init: Motion continues using width and height from config file(s)
Nov 15 13:34:10 Old_Pi_B user.warn motion: [3:ml3:Camera3] [WRN] [ALL] mlp_retry: Retrying until successful connection with camera
Nov 15 13:34:19 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 36 C
Nov 15 13:34:35 Old_Pi_B user.err motion: [3:ml3:Camera3] [ERR] [NET] netcam_rtsp_open_context: Normal resolution: Unable to find stream info: Success
Nov 15 13:34:35 Old_Pi_B user.err motion: [3:ml3:Camera3] [ERR] [VID] vid_start: Netcam RTSP failed to open

[StarbaseSSD]

No, the Nov 15 13:34:19 Old_Pi_B user.notice throttlewatch: currently: under-voltage throttled , temperature: 36 C

is not 'normal' and can cause corruption of files.

I would re-flash and start over. The error seems to have not shown back up, so that's a Good Thing(tm).