Closed TheRaven500 closed 9 months ago
Log added. The Log is from my wildcam. Here you can download the video: Test-Video1 As you can see, the video stutters extremely when motion is detected. The same happens (but a bit less extreme) on the i7. Hope i can also get a log. By the way, it doesn't matter whether the movement is recognized by the image change or whether it is triggered externally via http webinterface command (i have a PiR connected which triggers the motion if an animal passes the camera). Additional information: This is a Raspberry Pi Zero2W. If motion is triggered cpu reaches about 70% of load. So this can not be the problem i think. Here you can see the cpu-load: CPU-Load I also tried with codec mp4 and mpeg4 but result is always the same.
Could you try to set:
pre_capture 0 post_capture 0
And test again (attach new log and new test movie)?
Thank you very much for response. Have done this and it looks good so far! Here is the log: motion2.log And here the video: Test-Video2 BTW: I have deliberately moved the output folder to /tmp to make sure that it is not due to the slow microsd card. I will now try only with post_capture and look what happens. Edit: With "post_capture 120" it looks also good. It seems it has something to do with "pre_capture". Test-Video3 Edit2: I played around with "pre_capture". With a value of "5" it has a very small (barely noticeable) lag, with "10" it lags more and much more with a value of "30". So it looks like is has something to do with the value of pre_capture. The higher the value, the more it lags.
Closing per the edit comments.
Why have you closed this bug? What is the solution?
As per your comment, it is because of the pre_capture and the lack of power of a PI.
Edit:
It is also very clearly documented in the guide to not specify large values for pre_capture
or the result will be lags in the resulting videos.
No, it also happens on a intel i7. So i don't think it is a pi problem. Looks like something with pre_capter is wrong. Post_capture works fine. I try to verify this.
Sorry for late response, i am very busy ATM. It happens also on i7-6700 (Quad-Core @3.4Ghz) with RTSP camera. Interesting is that it has also a very small lag with "pre_capture 0". But if i raise "pre_capture" to 120 the lag grows. This is a combined installation (motion 4.6.0 with motioneye 0.43 python3), because of this i try to switch to motion only to be sure it is NOT a motioneye problem. Hope i find time soon to do this. :-) Edit: Ok, i have tested it and as expected it happens also with motion only. Connected 1 network rtsp camera with fullHD 1920x1080. Without pre_capture: Log1.txt Test-Video: https://bigbang.ddns.me/index.php/s/iYFXk3GtS6PTmsy With pre_capture: Log2.txt Test-Video: https://bigbang.ddns.me/index.php/s/WHSzDaisatZfJ5E As you can see it has a lag between motion and trigger. No clue why. But it happens on Rapsberry with dietpi and also on i7 with 8GB of Ram and Debian12 with different cameras (mmal and rtsp).
Oh, closed and won't fix :disappointed: I still think something is wrong, but can also be a config problem. As soon the trigger kicks in it has a short lag. Here is another video of two playing cats: Cat-Video As you can see it stutters from time to time. In this case not really a problem, bit if a thief runs very fast it can be that he can pass the camera without being filmed. BTW: I have edited my previous post to provide more info.
When I was trying to solve another problem, I stumbled across something that might relate to this problem: Only now I realized that I might have a config problem. I am confused by the documentation: https://motion-project.github.io/motion_config.html#pre_capture Until now I thought that “pre_capture” and “post_capture” were identical. In other words, it must be specified in “fps”. So if I have a camera with 20fps and I want 3s I have to set the value to 60. But if I understand the documentation correctly, “post_capture” is specified in seconds and not in fps. Is that correct?
Did you read the guide?
No
What is the base version number of Motion being used?
4.6.x
What was the install method?
Installed via package tool
What is base architecture?
Other
What is the distro being used?
Other
Disto version number
Different Distros (Debian 12 and Dietpi)
Camera type(s) being used?
Other
Describe the issue/problem and steps to reproduce
I use motion (standalone) and in combination with motioneye. This on different platforms. My Wild-Cameras run on RaspberryPi (Dietpi, ARM64) and my Video-Server runs on x86 (Debian 12, Intel Core i7). I have direct attached USB-Cameras, MMAL Cameras and Network-Cameras over RTSP (UDP and TCP). And all of them have the same Problem: The Video runs smooth until motion is detected. Then it drops some frames (about 1s) and runs smooth again. I tried so many things, but never found a solution. I am not sure if it affects motion or ffmpeg. I think (but not sure) it goes more worse on newer versions of motion (and/or maybe ffmpeg?). I also wanted to try "motion plus" to see if it is better, but unfortunately i can't get it running on my Pi because it has Bookworm on it and there are only bullseye arm64 downloads available. First i thought it is a RaspberryPi-Problem (because of low resources) but my Core i7 has the same Problem. Does this happen only to me or is someone else with this problem? BTW: I have already been able to record four thieves. So i really love this useful software! I would appreciate any tips on how to solve this problem.
Motion log output at log_level 8