Pi Zero w CPU constantly high

[almcbs]

Raspberry Pi zero w + Pi cam v2 Motioneye version: 0.39.2 Motion version: 4.1.1 OS version: motionEyeOS 20180627

**If you read my previous issue, I since changed from raspbian + motioneye to just motioneye OS on this device in order to see if that fixed the CPU issue.

Issue: CPU consistently sits around 95-98% utilized and this is with or without motion detection active or not. Also it should be noted that this is occurring with no streams of that camera. This is obviously effecting my fps and causing the recordings to be choppy, as well as motion being detected later than it should have. I pasted below a copy of my thread-1.conf file, figured that would be easier than manually typing all my settings.

@webcam_resolution 100 @upload_subfolders on @upload_server @enabled on @network_server @upload_username @motion_detection on @upload_port @upload_location blah/ @preserve_movies 30 @network_username @upload_movie on @id 1 @manual_record off @upload_password @upload_method post @upload_picture off @working_schedule_type outside @network_password @upload_service blah @name Camera2 @preserve_pictures 30 @storage_device custom-path @manual_snapshots on @network_share_name @upload_enabled on @webcam_server_resize off @working_schedule

ffmpeg_output_movies on height 600 stream_quality 85 threshold 24576 quality 50 noise_level 31 ffmpeg_output_debug_movies off pre_capture 5 noise_tune on smart_mask_speed 0 stream_maxrate 7 output_pictures best stream_localhost off ffmpeg_variable_bitrate 100 ffmpeg_video_codec mp4:h264_omx text_changes on movie_filename %Y-%m-%d/%H-%M-%S auto_brightness on stream_port 8081 rotate 270 stream_auth_method 2 lightswitch 25 framerate 29 emulate_motion off snapshot_filename blah despeckle_filter snapshot_interval 0 minimum_motion_frames 6 stream_motion off target_dir /data/blah text_double on post_capture 1 stream_authentication blah:blah output_debug_pictures off on_picture_save /usr/lib/python2.7/site-packages/motioneye/scripts/relayevent.sh "/data/etc/motioneye.conf" picture_save %t %f on_movie_end /usr/lib/python2.7/site-packages/motioneye/scripts/relayevent.sh "/data/etc/motioneye.conf" movie_end %t %f text_left Camera2 picture_filename blah locate_motion_style redbox locate_motion_mode on mmalcam_name vc.ril.camera max_movie_time 10 on_event_end /usr/lib/python2.7/site-packages/motioneye/scripts/relayevent.sh "/data/etc/motioneye.conf" stop %t text_right %Y-%m-%d\n%T on_event_start /usr/lib/python2.7/site-packages/motioneye/scripts/relayevent.sh "/data/etc/motioneye.conf" start %t event_gap 15 mask_file width 1024

[2boot]

Hi Hope you don't mind me advising my experience= My History - I found h264_omx was blacklisted by watching debug files and changed to h264, but h264_omx is the default when motioneye is loaded. The stretch of June 2018 caused me endless problems on all Pi's which I could not resolve until I fresh loaded stretch Nov 2018.

I have 2 ZeroW and 1 ZeroWH all standalone motioneye on raspian stretch November 2018 each using the PIZERO camera whilst also watching the camera by 192.168.1.XX:8765 in a browser via wifi, streaming is off.

In terminal by putty SSH typing sudo top I get similar to these screen shots, they move about a bit but approx. 17% total

this is with motion detection off

this is with motion detection on

Please note I am only an amateur and am no substitute for the real thing, there are many areas where I won't have a clue.

[almcbs]

I attempted to switch it to H264 in order to see if it would change anything, but CPU usage remained the same.

[jasaw]

@2boot is right that h264_omx has been blacklisted, so motion reverts to x264 CPU encoding, but will only cause high CPU usage when recording a movie. MotionEyeOS has all the required patches to enable h264_omx.

@almcbs Try reducing your frame rate to 15 or 20 fps. The live video stream to web browser uses CPU to encode mjpeg, so causes high CPU load. Close your web browser and you should see a significant drop in CPU load. locate_motion_mode on also adds to CPU load, but only during movie recording. After you are happy with your motion detection settings, you can turn off locate_motion_mode.

[almcbs]

@2boot is right that h264_omx has been blacklisted, so motion reverts to x264 CPU encoding, but will only cause high CPU usage when recording a movie. MotionEyeOS has all the required patches to enable h264_omx.

@almcbs Try reducing your frame rate to 15 or 20 fps. The live video stream to web browser uses CPU to encode mjpeg, so causes high CPU load. Close your web browser and you should see a significant drop in CPU load. locate_motion_mode on also adds to CPU load, but only during movie recording. After you are happy with your motion detection settings, you can turn off locate_motion_mode.

Adjusted frame rate down to 15. All browser (mine was the only one) are closed. Didn't adjust location_motion since im seeing high usage all the time and not just during recording. With the frame rate adjusted im still sitting at 96-97%

[B0rax]

was there any solution for this problem?

[starbasessd]

Several. My favorite is "Fast Network Camera" functionality which offloads all processes except network streaming. This allows another PI or PC to do the heavy lifting of motion detection and recoding video.