BUG: Locked pixels
From time to time, in Motion v. 3.2.11, I experience some extended events that are located and recorded due to the fact that after objects that produced the event are passed away from my mask zone, some pixels remains "locked" and the value of threshold remain also higher and of course motion are detected, located and recorded, even the subject has passed away from my mask zone.
It is involved here locate feature or reference frame algorythm ???...
on_event_start mpg123 /usr/local/etc/motion/utile/door3_1.mp3
on_picture_save /usr/local/etc/motion/utile/create_jpg_link1.sh %f
on_motion_detected mpg123 /usr/local/etc/motion/utile/door1_1.mp3
| Motion version:
| ffmpeg version:
| Shared libraries:
| Server OS:
|| Slax Linux / 184.108.40.206 kernel
- 12 Jul 2009
Florin , did you reproduce in trunk also ?
- 15 Jul 2009
- Well, this strange behavior occurs certainly in Motion v. 3.2.11... O.K., from now, I will make thoroughly tests with trunk version of Motion and will inform you. Certainly this will take some time...
- 15 Jul 2009
May i ask if this error is about that some times the recording is extended to the gap time, even when the motion is over?
If so i have seen this also after the upgrade to 3.2.11. I don't use any mask files or other fancy stuff, just from time to time see recordings continue after the motion defently is below threshold.
I think i also have this error now http://www.lavrsen.dk/foswiki/bin/view/Motion/BugReport2008x09x28x002613
, giving now and then recordings of a few images where the buttom and up is just gray with timestamp.
After trying to catch up on what changed the last years i would suspect the buffer handling there, as i understand, have changed in the later versions. could that be possible? - is there any easy way to compile without this buffer change, if there is any?
- 20 Jul 2009
- Seems that this patch is involved (in locked pixels) : http://www.lavrsen.dk/foswiki/bin/view/Motion/SmarterReferenceFramePatch
- 21 Jul 2009
You can try to play with some values defined in :
alg_update_reference_frame() ( alg.c : 1082 )
#define ACCEPT_STATIC_OBJECT_TIME 10 #define EXCLUDE_LEVEL_PERCENT 20
You can exclude those ghost setting :
- 25 Jul 2009
- Well, running with Motion trunk - r456 and adding the same above motion.conf settings, I also experience the same present bug : randomly locked pixels after motion has been detected... O.K. , now I will make a downgrade to Motion v.3.2.11. and I will try to hack alg.c file with recommended values...
- 25 Jul 2009
- YES, "bug" fixed... NOW, (for me, at least) Motion is working O.K...
- Well, for Motion v. 3.2.11, go to file alg.c (line #1082 ) and change ACCEPT_STATIC_OBJECT_TIME 10 to ACCEPT_STATIC_OBJECT_TIME 1 , then recompile Motion and now you will have "locked pixels" for 1 second and not for 10 seconds, after motion is detected...
- 11 Feb 2010