Motion_Wrapper fails to acquire images (produces grey images) [SOLVED]

[Avner]

Hi,

I want to operate a webcam in a Core only (no MD) in a lmce-1004.
I had problems in the past to run Motion_Wrapper in a Hybrid environment but solved it by changing the following lines in /etc/init.d/motion (see http://forum.linuxmce.org/index.php/topic,13292.0.html) from

Code: [Select]

if start-stop-daemon --start --oknodo --exec $DAEMON -b --chuid motion ; thento:

Code: [Select]

if LDPRELOAD=/usr/lib/libv4l/v4l1compat.so start-stop-daemon --start --oknodo --exec $DAEMON -b --chuid root ; then
I now have the same setting in a Core only (no MD) environment.
Motion_Wrapper fails to acquire images. The images fail to acquire - the image files are grey 640x480.
The related processes that run are:

Code: [Select]

dcerouter_1035867:~# ps aux | grep -i motion
root      9675  0.0  0.0   3036  1096 ?        Ss   08:07   0:00 /usr/bin/SCREEN -d -m -S Motion_Wrapper33 /usr/pluto/bin/Spawn_Device.sh 33 localhost Motion_Wrapper
root      9677  0.0  0.0   3120  1632 pts/20   Ss+  08:07   0:00 /bin/bash /usr/pluto/bin/Spawn_Device.sh 33 localhost Motion_Wrapper
root      9742  0.0  0.1  69788  3016 pts/20   Sl+  08:07   0:00 /usr/pluto/bin/Motion_Wrapper -d 33 -r localhost -l /var/log/pluto/33_Motion_Wrapper.log
root      9749  2.4  0.1  15408  2588 pts/20   Sl+  08:08   0:11 [motion]

I tried to invoke the same Motion_Wrapper related command, i.e.

Code: [Select]

/usr/pluto/bin/Motion_Wrapper -d 33 -r localhost -l /var/log/pluto/33_Motion_Wrapper.log
from the command line. In this case, the frames are acquired succesfully - I get image files 352x292.

I cannot understand why the same Motion_Wrapper command fails when executed via lmce but succeeds when executed the command line.

Also can someone explain the command /usr/bin/SCREEN ? I cannot find such executable but all the respawning services have this associated SCREEN command.

Regards,
Avner

[Marie.O]

Why do you run motion wrapper?

no idea why the screen bin is shown as SCREEN in the process list. We do use the regular screen.

[Avner]

posde, Motion_Wrapper runs by default and manages the utility motion to acquire images from the webcam.
Because it fails to acquire the images I ran the same Motion_Wrapper command from the command line and there it succeeds.

[Marie.O]

posde, Motion_Wrapper runs by default and manages the utility motion to acquire images from the webcam.

Motion_Wrapper is nothing that runs by default on a LinuxMCE system. It only runs when you install the Motion_Wrapper device (can't remember the exact name nor the DT number).

I have webcams on my system, and do not have Motion_Wrapper running on my core:

Code: [Select]

dcerouter_112602:~# ps ax|grep motion -i
 5054 pts/15   S+     0:00 grep motion -i


[Avner]

My camera is a USB camera (Logitec QuickCam Express). The camera is connected through usb to my core. I followed the instructions in http://wiki.linuxmce.org/index.php/USB_Surveillance_Camera to install the usb camera, which instructs to create a motion wrapper device.

[Marie.O]

For USB cameras you are correct. You talked about webcams, which my two brain cells associated with an *IP* webcam.

[WhateverFits]

For some weird reason screen always shows up as SCREEN in the process list. This is not LinuxMCE specific.

My first, last, and only guess is permissions. Who is the original task running as? I can imagine a scenario where the capture thread does not have permissions to access the USB camera.

[mkbrown69]

For some weird reason screen always shows up as SCREEN in the process list. This is not LinuxMCE specific.

Might be a Debian/Ubuntu thing... on my core, I get this

Code: [Select]

ps -ef |grep SCREEN | wc -l
22
On my Debian KVM host, I have the same SCREEN process, with a PPID of 1, for the screen session I have running their for admin purposes.  I'll have to check it out on some SLES and CentOS boxes at work... Got me curious...

Edit:  It's a screen thing... does the same thing on CentOS. 

Code: [Select]

# ps -ef | grep -i screen
root      5850  2146  0 17:57 pts/0    00:00:00 screen
root      5851  5850  0 17:57 ?        00:00:00 SCREEN
root      5863  5852  0 17:57 pts/1    00:00:00 grep -i screen

/Mike

[WhateverFits]

Yeah, that looks like it is running as root so it should have permissions. Do a ps and look for the motion executables and check who they are running as. That's odd.

I've seen screen show up as SCREEN for a while now but I first noticed it on LinuxMCE since it makes such heavy use of screen. Very strange.

[Avner]

My first, last, and only guess is permissions. Who is the original task running as? I can imagine a scenario where the capture thread does not have permissions to access the USB camera.

I think you are right in that the problem has to do something with permissions.
Notice, however that I changed the uid inside /etc/init.d/motion from motion to root so I expect no permission issues

Yeah, that looks like it is running as root so it should have permissions. Do a ps and look for the motion executables and check who they are running as. That's odd.

When I do ps and look for the motion executables, I get the following list with user root. That is why I also ran the same Motion_Wrapper executable from the command line as root (where it succeeded).

Code: [Select]

dcerouter_1035867:~# ps aux | grep -i motion
root      9675  0.0  0.0   3036  1096 ?        Ss   08:07   0:00 /usr/bin/SCREEN -d -m -S Motion_Wrapper33 /usr/pluto/bin/Spawn_Device.sh 33 localhost Motion_Wrapper
root      9677  0.0  0.0   3120  1632 pts/20   Ss+  08:07   0:00 /bin/bash /usr/pluto/bin/Spawn_Device.sh 33 localhost Motion_Wrapper
root      9742  0.0  0.1  69788  3016 pts/20   Sl+  08:07   0:00 /usr/pluto/bin/Motion_Wrapper -d 33 -r localhost -l /var/log/pluto/33_Motion_Wrapper.log
root      9749  2.4  0.1  15408  2588 pts/20   Sl+  08:08   0:11 [motion]
I am trying to resolve the problem by tracking the log messages.
When I run Motion_Wrapper from the command line, the correct output images have image size of 352x292, and I see log messages such as:

Code: [Select]

[1] Adjusting resolution from 640x480 to 352x292.I think that these are messages written to stdout by the motion process.

When running via lmce the (grey) incorrect output image is 640x480 - probably the resizing does not happen.
So I want to track the log messages when Motion_Wrapper is ran via lmce.
How can I see these messages, when Motion_Wrapper is running via the lmce mechanism?
(I added related log levels to /etc/pluto.conf (17 LV_CAMERA, 35 LV_DEBUG), but the messages still don't show up in /var/log/pluto/33_Motion_Wrapper.log)

Thanks,
Avner

[Avner]

OK, I found the problem.

To debug the problem, I did the following:
1. Removed Motion_Wrapper (33) from the list of running services in /usr/pluto/locks/pluto_spawned_local_devices.txt
2. Invoke screen in a non "detached" mode (i.e. without the parameters "-d -m") so I can see the messages

Code: [Select]

screen -S Motion_Wrapper33 /usr/pluto/bin/Spawn_Device.sh 33 localhost Motion_Wrapper
From the log messages I realized that the environment variable LD_PRELOAD was not set.
The executable motion needs to run with the environment variable LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so in order to acquire the images properly.
When running Motion_Wrapper through the lmce mechanism, it is invoked via screen which fails to pass the environment variable.
(Motion_Wrapper was successful when executed manually from the command line, because the environment variable in the terminal session was set properly)

The solution is to set the environment variable in .screenrc as follows:

Code: [Select]

dcerouter_1035867:~# cat ~/.screenrc
setenv LD_PRELOAD "/usr/lib/libv4l/v4l1compat.so"
Now I'm getting correct images.

[WhateverFits]

Ahhh!! Good debugging!