Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Motion in motionEyeOS killed after some time when accessed via Homebridge Camera FFmpeg #3016

Open
devmarcstorm opened this issue Dec 3, 2023 · 6 comments

Comments

@devmarcstorm
Copy link

Preliminary Docs

I confirm that I have read the CONTRIBUTING guide before opening this issue.

I confirm that I have read the FAQ before opening this issue.

motionEyeOS Version

I am running motionEyeOS version: dev20201026

Board Model

I am using the following board/model: Raspberry Pi 4 Model B Rev 1.4

Camera

I am using the following type of camera: V4L2 Camera

My camera model is: ELP 1megapixel 720p USB camera

Network Connection

My motionEyeOS unit is connected to the network via: Ethernet

Peripherals

I am using the following peripherals that I consider relevant to this issue:

  • Powered usb dock to connect the camera to the Pi
  • The original Raspberry Pi power supply

Log Files

I consider the following log files relevant to this issue:

I have changed some host and camera names in the log files.

My Setup

I operate a Homebridge on a 2nd Pi, on which the camera stream is accessed via the "Homebridge Camera FFmpeg" plugin (https://github.com/Sunoo/homebridge-camera-ffmpeg#readme).

Apart from "Video Streaming" and "Text Overlay", I don't currently use any other motionEye functions.

If I connect two cameras, I have to use /dev/video0 and /dev/video1, as the cameras unfortunately have the same USB ID. Currently I only have one camera connected and use /dev/v4l/by-id/.... The problem occurred with both configurations. The cameras did not freeze at the same time.

Problem

After some time (a few hours after the last restart), the stream stops. Both in the motionEye web interface and in the Homekit app. The only option I have found that works is to restart the Pi via the motionEye interface.

What I've tried so far

  • I had originally used 2 of the cameras mentioned. I currently only use one. (same problem)
  • I have tried different resolutions (including some with modulo 16) and quality settings. (same problem)
  • I have connected the camera(s) to the Pi with and without the USB hub. (same problem)
  • I have used different versions of motionEyeOS. (same problem)
  • I have used HomeAssistant instead of Homebridge. (Problem could not be observed)

Thank you for your help and suggestions

@starbasessd
Copy link

The logs seem to be mixed. A couple of things needed, noticed.
Are you running multiple PIs?
Some of the logs indicate the PI may be outside (15C temps).
What is the operating temperature range for the camera & hub? If it is an indoor camera, it may be too low.
It would also be helpful to have timestamps for the issue in question.
Could you run the command:

vcgencmd get_throttled

right after you notice the issue, but before you run a reboot, please?

After you answer these, I may be able to help more.

@devmarcstorm
Copy link
Author

devmarcstorm commented Dec 3, 2023

Hello and thank you for your help.

I only use one Pi that runs motionEyeOS. I will provide new logs.

The motionEyeOS-Pi is located together with the hub in a room whose indoor temperature is kept above 5° Celsius. The indoor temperature at the current time of year should be between 5°C and 12°C for the Pi and the hub and is currently 10.8°C.

The camera itself is sold as an outdoor camera and is located on the outside wall of the room. I currently measure an outside temperature of -0.5° C.

The problem already occurred a few weeks earlier, when the temperatures were still above 10°C.

I am in the Central European time zone and will restart the Pi as late as possible today (I think otherwise the problem will occur unnoticed during the night) and run the command tomorrow as soon as I notice that the problem reoccurs. I can then also provide the new log files.

Thanks again

@starbasessd
Copy link

If you can, before you reboot, run the command

logrotate -f /etc/logrotate.conf

to clear the logs, that would also be helpful.

@devmarcstorm
Copy link
Author

Ok, it happened much earlier than I thought. Here is the timeline:

  • 00:06 CET: logrotate -f /etc/logrotate.conf
  • 00:07 CET: Reboot
  • 00:45 CET: According to the timestamp, the stream stopped at this time
  • 01:00 CET: Download of the new logs
  • 01:00 CET: vcgencmd get_throttledoutput: throttled=0x0

@starbasessd
Copy link

motioneye log: 2023-12-04 00:07:33: [motioneye] WARNING: 403 GET /login/?_=1701644853339 (192.168.2.164) 1.53ms
motion log: [1:ml1:Camera1] [CRT] [NET] motion_init: Substream not available. Image sizes not modulo 16.
I think the username & password for the camera itself may be wrong. If it uses 'special' characters, it will probably fail.
Camera resolutions both directions (vert and horiz) need to be evenly divisible by 16, especially for rtsp:// addresses.

@devmarcstorm
Copy link
Author

Thank you again for your help.

After the restart at 00:07 CET, I logged in via the web interface to see if the stream was running and entered my password incorrectly once.

I ran v4l2-ctl --list-formats-ext yesterday to get the resolutions supported by my camera.

ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'MJPG' (Motion-JPEG, compressed)
		Size: Discrete 1280x720
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 640x480
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 352x288
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 320x240
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 176x144
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 160x120
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 800x600
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 960x720
			Interval: Discrete 0.033s (30.000 fps)
	[1]: 'YUYV' (YUYV 4:2:2)
		Size: Discrete 1280x720
			Interval: Discrete 0.100s (10.000 fps)
		Size: Discrete 640x480
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 352x288
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 320x240
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 176x144
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 160x120
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 800x600
			Interval: Discrete 0.050s (20.000 fps)
		Size: Discrete 960x720
			Interval: Discrete 0.067s (15.000 fps)
  • 05:00 CET: I changed the resolution to 960x720, did a logrotate, and restarted the Pi.
  • 05:40 CET: ERROR: mjpg client timed out receiving data for camera 1 on port 8081 appeared in the motioneye.log
  • 06:00 CET: According to the timestamp on the frozen camera image, the problem occurred again at that time.
  • Between 06:05 and 6:11 CET: I downloaded the new log files and executed vcgencmd get_throttled.

boot.log
dmesg.log
messages.log
motion.log
motioneye.log
vcgencmd get_throttled output: throttled=0x0

Could there be something wrong with my configuration?

My settings for "Video Device"

  • Video Resolution: 960x720
  • Frame Rate: 10
  • Extra Motion Options: noting

My settings for "Expert Settings"

  • Network Link Watch: ON
  • Network Link Timeout: 20
  • Connectivity Watch: ON
  • Motion Keep-alive: ON
  • Fast Network Camera: OFF
  • GPU Memory: 256
  • Enable CSI Camera Led: ON
  • Enable System Monitoring: ON

My settings for "Video Streaming"

  • Streaming Frame Rate: 15
  • Streaming Quality: 75%
  • Streaming Image Resizing: OFF
  • Authentication Mode: Basic
  • Motion Optimization: OFF

My "Homebridge Camera FFmpeg" configuration on the second Pi running Homebridge

  • Video Source: -re -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -i http://<surveillance username>:<passw>@192.168.2.137:8081
  • Maximum Concurrent Streams: 3
  • Maximum Width/Height/Framerate: 0 ("If set to 0, the resolution of the source is used. If not set, will use any size HomeKit requests.")
  • Maximum Bitrate: 250

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants