Webcams not working after .34 update

[archived]

After .34 update my webcams stopped working.

If I look at running processes motions seems active, but no picture nor movie are saved.

In /home/cameras there are no new directories, and the existing ones were last modified yesterday immediately before reboot.
On orbiters I can see a fixed picture, reporting date/time of yesterday before reboot.

It sounds like motion may be running, but it is anyway not giving any output.

Could this be related to motion wrapper changes that have been introduced with .34?

If so, how can I have my webcams get to work?

Regards
Marco

[archived]

After .34 update my webcams stopped working.

If I look at running processes motions seems active, but no picture nor movie are saved.

In /home/cameras there are no new directories, and the existing ones were last modified yesterday immediately before reboot.
On orbiters I can see a fixed picture, reporting date/time of yesterday before reboot.

It sounds like motion may be running, but it is anyway not giving any output.

Could this be related to motion wrapper changes that have been introduced with .34?

If so, how can I have my webcams get to work?

Regards
Marco

Hi,

I've sent motion wrapper changes  to Aaron two days ago, so they didn't get into release yet...

Similar situation happens quite often with me. One is when motion goes into motion <defunct> state if one of video drivers shuts down, or maybe one of your devices doesn't initaliaze properly. Surely not nice feature - I always thought that motion will run other threads without problem, but if one dies, they all die....

Few things to check :
- logs from motion wrapper
- running motion by hand (type 'motion')
- running motion wrapper from command line

If you come up with more info, I can look at it..

Regards,

Rob.

[archived]

After .34 update my webcams stopped working.

If I look at running processes motions seems active, but no picture nor movie are saved.

In /home/cameras there are no new directories, and the existing ones were last modified yesterday immediately before reboot.
On orbiters I can see a fixed picture, reporting date/time of yesterday before reboot.

It sounds like motion may be running, but it is anyway not giving any output.

Could this be related to motion wrapper changes that have been introduced with .34?

If so, how can I have my webcams get to work?

Regards
Marco

Hi,

I've sent motion wrapper changes  to Aaron two days ago, so they didn't get into release yet (and I don't know when this will happen - guys are
busy). But maybe some additional parameters are already added to camera devices - so maybe this breaks things - although additional parameters shouldn't do this...

Similar situation happens quite often with me. One is when motion goes into motion <defunct> state if one of video drivers shuts down, or maybe one of your devices doesn't initaliaze properly. Surely not nice feature - I always thought that motion will run other threads without problem, but if one dies, they all die....

Few things to check :
- logs from motion wrapper
- running motion by hand (type 'motion')
- running motion wrapper from command line

If you come up with more info, I can look at it.. Sorry I cannot provide any more info, cause I run enhanced motion wrapper binary all the time...

Regards,

Rob.

[archived]

Hi Rob and thanks for your reply.

I also have some situation (not really often, actually) when motion process goes into <defunct> state. This is when I unplug one of the webcam and  I forget to plug it back, but this was not the case.

So the first thing that I made was to check process status and to run motion by hand, and system was saying that /dev/videoX was already open.
According to this I deduced that motion should have been running, but according to pluto log no picture was saved.

It ended up that I rebooted the system (for the third time in 2 days) and now everything is working again.

This is not the first time that upon an upgrade I have to reboot the system several times before everything goes back to work. It looks like the upgrade is applied in several steps, but I don't know whether this is normal behaviour or not.

Thanks anyway. I'm looking forward to see and test your changes to Motion wrapper (maybe in .35?)

Regards
Marco

[archived]

Hi Rob and thanks for your reply.

I also have some situation (not really often, actually) when motion process goes into <defunct> state. This is when I unplug one of the webcam and  I forget to plug it back, but this was not the case.

So the first thing that I made was to check process status and to run motion by hand, and system was saying that /dev/videoX was already open.
According to this I deduced that motion should have been running, but according to pluto log no picture was saved.

It ended up that I rebooted the system (for the third time in 2 days) and now everything is working again.

This is not the first time that upon an upgrade I have to reboot the system several times before everything goes back to work. It looks like the upgrade is applied in several steps, but I don't know whether this is normal behaviour or not.

I had similar problems, particularly with lirc on one of my diskless MD. While I was banging my head, few reboots solved problem... For motion I always thought that this is problem cause I replace regular motion-wrapper with custom compiled one, but obviously it happens also in 'stock'
system...

Thanks anyway. I'm looking forward to see and test your changes to Motion wrapper (maybe in .35?)

Regards
Marco

I can send modified source to you also, if you want...
Regards,

Rob.