mirror of
https://github.com/motioneye-project/motioneye.git
synced 2026-03-02 22:57:06 -05:00
All recorded videos have a 3 seconds freeze in the beginning #2466
Labels
No labels
Android app
Arch Linux
CI/CD
CSS
FreeBSD
HTML/HTTP
Home Assistant addon
JavaScript
Python
Raspberry Pi
Stale No Activity 60 Days
bug
code format
dependencies
dev branch
docker
documentation
duplicate
enhancement
feature
help wanted
i18n/l10n
invalid
legacy motionEye
meta
motion
motionEyeOS
notourproblem
python update
question
question
security
troubleshooting
wontfix
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/motioneye#2466
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @hpicelli on GitHub (Dec 12, 2023).
Hi there,
I'm facing this problem.
In a recorded video (all videos have this issue), it plays one second, freeze for 3 seconds, then plays normal until the end.
I'm using mp4 (h264) now, but tested avi (mpeg4) and the problem persists on all formats i've tested.
Check attached video.
motionEye Version: 0.43.0
Motion Version: 4.5.1
OS Version: Linux 6.1.0-13-686-pae (Debian 12 32bit)
*Using 32bit OS because i'ts a old machine. This issue is only on 0.43.0, 0.42 runs ok.
Best regards,
Henrique
https://github.com/motioneye-project/motioneye/assets/3333923/72af2417-4b63-44bf-b9bd-77ae739b1e78
@scott-vincent commented on GitHub (Dec 29, 2023):
I have the same problem where first 3 seconds of every recorded video is frozen. Running on Raspberry Pi 5 with 64-bit OS.
@guaycuru commented on GitHub (Jan 29, 2024):
I have the same problem. I thought it was the encoder using too much cpu but changing the codec makes no difference
@bnhnbnhn commented on GitHub (May 24, 2024):
I also have the same problem. Is it possible to downgrade to version 0.42.1 under dietpi?
@hpicelli commented on GitHub (May 24, 2024):
I think that is a issue on 0.43.
I'll reinstall using 0.42.
This is really annoying.
On Fri, May 24, 2024, 10:15 bnhnbnhn @.***> wrote:
@Marijn0 commented on GitHub (Jun 29, 2024):
Maybe this has something to do with the pre_capture value:
https://motion-project.github.io/4.5.1/motion_config.html#pre_capture
Can someone who is experiencing this issue set the 'Captured Before' in motionEye to 0 and see if it makes a difference?
@MichaIng commented on GitHub (Jun 30, 2024):
Indeed,
pre_captureis set to 1 (second) by default. Not sure whether it can take 3 seconds to process this 1 second though. At least worth an attempt. Can be changed in motionEye UI.EDIT: Also strange, while there should be 1 second of still frames at the beginning of the recording, it is not. Or the number of changed frames of the 1st second is not above the threshold, and would be missing without
pre_capture🤔.@hpicelli commented on GitHub (Jul 1, 2024):
The "captured before" and the "captured after" are defined in frames, not
seconds. Any tip? Here "motion gap" is defined to 5 seconds, "Captured
Before" and "Captured After" are defined to 10 frames, and the "Minimum
Motion Frames" are defined to 10 frames.
See attached image.
Best regards.
Henrique
[image: image.png]
On Sun, Jun 30, 2024 at 9:14 AM MichaIng @.***> wrote:
@Marijn0 commented on GitHub (Jul 1, 2024):
@hpicelli
What type of camera did you use?
Did you upgrade motioneye to 0.43.0 from 0.42 or a fresh installation?
@MichaIng commented on GitHub (Jul 3, 2024):
Oh right. Please assign "0" to "captured before", to see if it plays a role at all. "captured after" and "motion gap" do not matter in this regards.
Images cannot be posted when you answer via email.
@Marijn0 commented on GitHub (Jul 3, 2024):
Even if you have set pre_capture=0 there is probably still a buffer:
https://motion-project.github.io/4.5.1/motion_config.html#minimum_motion_frames
But even if this were the problem, it would be more down to motion 🤔
@MichaIng commented on GitHub (Jul 3, 2024):
But that section of the docs at least does not state that one will miss frames until the buffer has been processed. I am not sure how motion handles this internally, so worth a try to disable pre-capture, where this is mentioned explicitly. But if it does not help, also setting minimum motion frames to "1" could be tested. motionEye sets this to 20 by default, but can be adjusted in web UI as well.
@hpicelli commented on GitHub (Jul 4, 2024):
Hi.
Fresh 0.43.0. Upgraded to 0.43.1b2 yesterday. Same issue.
Cameras are generic. In 0.42 does't have this problem.
@Marijn0 commented on GitHub (Jul 4, 2024):
@hpicelli
Have you tried assigning 0 to captured before??
And 1 to minimum motion frames??
And if this doesn't solve the problem, please also try turning on Movie Passthrough!
https://github.com/Motion-Project/motion/discussions/1494#discussioncomment-2354084 🤔
@hpicelli commented on GitHub (Jul 4, 2024):
Hi folks.
capture before set to 0: the problem stills (@MichaIng informed that maybe the 0 = 20 (default by motion))
capture before set to 1: the problem stills
Both options tested after system reboot.
@Marijn0
@hpicelli commented on GitHub (Jul 4, 2024):
@Marijn0
Activating the button still causes the same problem.
No changes so far have changed the problem at all.
To ensure this, the system is restarted with every change made.
@MichaIng commented on GitHub (Feb 12, 2026):
Checking some open issues: @hpicelli did you try to set "minimum motion frames" to 1? You said "capture before set to 1: the problem stills", probably a typo?