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 ???...

daemon on
process_id_file /var/run/motion/motion.pid 
setup_mode off
videodevice /dev/video0
v4l2_palette 8
input 0
norm 0
frequency 0
rotate 0
width 640
height 384
framerate 5
auto_brightness off
brightness 0
contrast 155
saturation 255
threshold 400
threshold_tune off
noise_level 32
noise_tune on
despeckle EeeddDl
mask_file /usr/local/etc/motion/utile/mask2.pgm
lightswitch 99
minimum_motion_frames 2
pre_capture 0
post_capture 0
gap 10
max_mpeg_time 0
output_all off
output_normal first
output_motion off
quality 100
ppm off
ffmpeg_cap_new on
ffmpeg_video_codec msmpeg4
snapshot_interval 3600
locate on
text_right %d.%m.%Y\n%T\n%D_%q_%N
text_double on
target_dir /mnt/hda4/bucatarie/cam1
snapshot_filename snapshot_last
jpeg_filename jpeg_picture_%d.%m.%Y_%H.%M.%S
movie_filename movie_motion_%d.%m.%Y_%H.%M.%S
timelapse_filename timelapse_motion_%d.%m.%Y_%H.%M.%S
webcam_port 8081
webcam_quality 100
webcam_motion off
webcam_maxrate 1
webcam_localhost on
webcam_limit 0
control_port 8080
control_localhost on
control_html_output on
quiet off
on_event_start mpg123 /usr/local/etc/motion/utile/door3_1.mp3
on_event_end /usr/local/etc/motion/utile/up_poze1.txt
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

Environment

Motion version:	3.2.11
ffmpeg version:	SVN-r15375
Shared libraries:	ffmpeg
Server OS:	Slax Linux / 2.6.24.5 kernel

-- FlorinAnton - 12 Jul 2009

Follow up

Florin , did you reproduce in trunk also ?

-- AngelCarpintero - 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...

-- FlorinAnton - 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?

-- TheOtherBug - 20 Jul 2009

---

- Seems that this patch is involved (in locked pixels) : http://www.lavrsen.dk/foswiki/bin/view/Motion/SmarterReferenceFramePatch

-- FlorinAnton - 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 :

ACCEPT_STATIC_OBJECT_TIME 0

-- AngelCarpintero - 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...

-- FlorinAnton - 25 Jul 2009

---

Fix record

- 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...

-- FlorinAnton - 11 Feb 2010