motioneye-project/motioneye

One camera overrides the feed of another camera. Same feed twice. One missing.

Closed

#1,286 opened on May 21, 2019

View on GitHub
 (5 comments) (0 reactions) (0 assignees)Python (636 forks)batch import
help wantedquestion

Repository metrics

Stars
 (3,533 stars)
PR merge metrics
 (Avg merge 16d 14h) (33 merged PRs in 30d)

Description

motionEye version: 0.40 Motion Version: 4.0 OS Version: Debian 9.9

Not totally sure this isn't some oversight on my end...

I've narrowed down the issue to two specific cameras. I currently have only these two cameras installed in MotionEye and the I'm seeing the behaviour. Both cameras are Trendnet IP Cameras Model TV-IP310PI Both cameras are being accessed with AUTH via a URL like: rtsp://HOSTNAME.lan/Streaming/Channels/1

If I disable one (toggle Video Device switch) then the remaining one correctly shows its video feed. When they are both enabled, then one of their feeds is displayed for both camera views.

To rule out conflicts with other NVR apps I've been evaluating, I just did a completely fresh install of a minimal Debian 9 and have only installed motionEye following the instructions for Debian on the wiki. The problem still occurs.

This happens identically in Chrome, Safari and Firefox.

Find attached a screencap of the duplicate feeds. Also attaching the two camera-x.conf files. Also attaching the motion.conf file.

Really enjoying setting this up so far. Hopefully can get past this hurdle. Please advise.

camera-1.conf.txt camera-5.conf.txt motion.conf.txt

Contributor guide

Research direction
Investigate the camera configuration files (camera 1.conf, camera 5.conf) and motion.conf for conflicting settings like port numbers or channel assignments. Compare the configurations of the two cameras to identify any duplicated parameters. Check if the issue is related to authentication or stream URI. Consider testing with different cameras to isolate the problem.
Tech stack
pythonshell
Domain
backend
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
Half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Mostly clear
Prerequisites
basic understanding of motionEye configurationaccess to two RTSP cameras
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30