Send Motion-user mailing list submissions to
motion-user@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
motion-user-requ...@lists.sourceforge.net
You can reach the person managing the list at
motion-user-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: Negative impact on wifi connectivity (Damian)
2. Re: Negative impact on wifi connectivity (MrDave)
3. mail (somebody)
4. Re: Negative impact on wifi connectivity (Adam Goryachev)
5. Re: Negative impact on wifi connectivity (Damian)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Oct 2020 22:03:40 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <11f6af23-cfab-ad56-3399-fc3df7d5d...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed
I was about to prepare a pull request that would introduce a configuration
choice whether to pause streaming in between frames
based on below snippet, but then realized that this option would be
v4l2-specific. Is this discouraged?
> However I now know that the issue actually is about VIDIOC_STREAMON being
> active continuously. My primary use case is
> "snapshot_interval 5", so I tried the following based on Debian buster
> (release-4.1.1):
>
>> diff --git a/video_v4l2.c b/video_v4l2.c
>> index 5be8d6e..4dcab92 100644
>> --- a/video_v4l2.c
>> +++ b/video_v4l2.c
>> @@ -882,0 +883,9 @@ static int v4l2_capture(struct context *cnt, struct
>> video_dev *viddev, unsigned
>> +
>> +??? enum v4l2_buf_type type;
>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> +??? if (xioctl(vid_source, VIDIOC_STREAMON, &type) == -1) {
>> +??????? MOTION_LOG(ERR, TYPE_VIDEO, SHOW_ERRNO
>> +??????????? ,"Error re-starting stream. VIDIOC_STREAMON");
>> +??????? return -1;
>> +??? }
>> +
>> @@ -924,0 +934,3 @@ static int v4l2_capture(struct context *cnt, struct
>> video_dev *viddev, unsigned
>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> +??? xioctl(vid_source, VIDIOC_STREAMOFF, &type);
>> +
> This yields a more stable wifi network while providing the same image quality
> (i.e. better than fswebcam). I think it also reduced
> the cpu load. The "Tx excessive retries" counter goes up slowly, probably
> counting the packets that should have been transmitted
> during STREAMON and STREAMOFF. Motion still has an impact on the smoothness
> of the ssh session which I could probably improve more
> by setting a higher snapshot_interval.
------------------------------
Message: 2
Date: Wed, 28 Oct 2020 15:12:21 -0600
From: MrDave <motionmrd...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <4567caac-c18c-ef05-67b2-763617ef3...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I believe the main concern would be that this issue or the configuration
option would be unique and only applicable to you rather than a wider
audience.? This isn't something that has been observed or reported in
the years I've been associated with the project.
On 10/28/2020 3:03 PM, Damian via Motion-user wrote:
> I was about to prepare a pull request that would introduce a
> configuration choice whether to pause streaming in between frames
> based on below snippet, but then realized that this option would be
> v4l2-specific. Is this discouraged?
>
>> However I now know that the issue actually is about VIDIOC_STREAMON
>> being active continuously. My primary use case is "snapshot_interval
>> 5", so I tried the following based on Debian buster (release-4.1.1):
>>
>>> diff --git a/video_v4l2.c b/video_v4l2.c
>>> index 5be8d6e..4dcab92 100644
>>> --- a/video_v4l2.c
>>> +++ b/video_v4l2.c
>>> @@ -882,0 +883,9 @@ static int v4l2_capture(struct context *cnt,
>>> struct video_dev *viddev, unsigned
>>> +
>>> +??? enum v4l2_buf_type type;
>>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> +??? if (xioctl(vid_source, VIDIOC_STREAMON, &type) == -1) {
>>> +??????? MOTION_LOG(ERR, TYPE_VIDEO, SHOW_ERRNO
>>> +??????????? ,"Error re-starting stream. VIDIOC_STREAMON");
>>> +??????? return -1;
>>> +??? }
>>> +
>>> @@ -924,0 +934,3 @@ static int v4l2_capture(struct context *cnt,
>>> struct video_dev *viddev, unsigned
>>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> +??? xioctl(vid_source, VIDIOC_STREAMOFF, &type);
>>> +
>> This yields a more stable wifi network while providing the same image
>> quality (i.e. better than fswebcam). I think it also reduced the cpu
>> load. The "Tx excessive retries" counter goes up slowly, probably
>> counting the packets that should have been transmitted during
>> STREAMON and STREAMOFF. Motion still has an impact on the smoothness
>> of the ssh session which I could probably improve more by setting a
>> higher snapshot_interval.
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
------------------------------
Message: 3
Date: Wed, 28 Oct 2020 17:45:05 -0600
From: somebody <for...@n0sq.tech>
To: motion-user@lists.sourceforge.net
Subject: [Motion-user] mail
Message-ID: <79ad59e1-422e-1885-5a06-91af23696...@n0sq.tech>
Content-Type: text/plain; charset=utf-8
How do I specify a different SMTP server for sending alerts?
------------------------------
Message: 4
Date: Thu, 29 Oct 2020 11:06:21 +1100
From: Adam Goryachev <mailingli...@websitemanagers.com.au>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID:
<3bc1cd3e-e923-1317-f435-d9b82c6d5...@websitemanagers.com.au>
Content-Type: text/plain; charset=utf-8; format=flowed
This entire issue still appears to me as though it is simply a power
issue. You could solve this by using a USB powered hub, or a better
power supply for the RPi. It sounds like the USB camera requires more
power when you are actively receiving the video stream (OR, the
raspberry pi is drawing more power when receiving/processing the video
stream) and this is causing the WiFi to fail (lack of power), ultimately
resulting in your issue.
I guess if you can't fix the problem (power) then you could use the
below as a kludge, but you might also want to be careful if this lack of
power might also cause other issues (SD card corruption would probably
be the worst).
Of course, it's not confirmed, but all the information I've seen on the
issue to date suggests this to be the most likely problem.
Regards,
Adam
On 29/10/20 08:03, Damian via Motion-user wrote:
> I was about to prepare a pull request that would introduce a
> configuration choice whether to pause streaming in between frames
> based on below snippet, but then realized that this option would be
> v4l2-specific. Is this discouraged?
>
>> However I now know that the issue actually is about VIDIOC_STREAMON
>> being active continuously. My primary use case is "snapshot_interval
>> 5", so I tried the following based on Debian buster (release-4.1.1):
>>
>>> diff --git a/video_v4l2.c b/video_v4l2.c
>>> index 5be8d6e..4dcab92 100644
>>> --- a/video_v4l2.c
>>> +++ b/video_v4l2.c
>>> @@ -882,0 +883,9 @@ static int v4l2_capture(struct context *cnt,
>>> struct video_dev *viddev, unsigned
>>> +
>>> +??? enum v4l2_buf_type type;
>>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> +??? if (xioctl(vid_source, VIDIOC_STREAMON, &type) == -1) {
>>> +??????? MOTION_LOG(ERR, TYPE_VIDEO, SHOW_ERRNO
>>> +??????????? ,"Error re-starting stream. VIDIOC_STREAMON");
>>> +??????? return -1;
>>> +??? }
>>> +
>>> @@ -924,0 +934,3 @@ static int v4l2_capture(struct context *cnt,
>>> struct video_dev *viddev, unsigned
>>> +??? type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> +??? xioctl(vid_source, VIDIOC_STREAMOFF, &type);
>>> +
>> This yields a more stable wifi network while providing the same image
>> quality (i.e. better than fswebcam). I think it also reduced the cpu
>> load. The "Tx excessive retries" counter goes up slowly, probably
>> counting the packets that should have been transmitted during
>> STREAMON and STREAMOFF. Motion still has an impact on the smoothness
>> of the ssh session which I could probably improve more by setting a
>> higher snapshot_interval.
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
------------------------------
Message: 5
Date: Thu, 29 Oct 2020 08:18:40 +0100
From: Damian <motion-u...@arcsin.de>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Negative impact on wifi connectivity
Message-ID: <26a5c161-d95d-a1f2-fb5e-3c4fad2b2...@arcsin.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
> This entire issue still appears to me as though it is simply a power issue.
> You could solve this by using a USB powered hub, or a
> better power supply for the RPi.
my setup works sufficiently fine now, so it is solved for me.
> It sounds like the USB camera requires more power when you are actively
> receiving the video
> stream (OR, the raspberry pi is drawing more power when receiving/processing
> the video stream) and this is causing the WiFi to
> fail (lack of power), ultimately resulting in your issue.
I ruled out the receiving/processing, it is about changing the camera mode
which then, as you and others suggested, probably
requires more power. That particular model I had trouble with, is designed for
24x7 usage, has infrared and maybe is too much for
a Zero W.
I acquired a simple webcam yesterday to test the code changes and as most
desktop webcams it has an activity LED. With a vanilla
motion, the LED is always on, with the patched motion, the LED blinks once per
snapshot_interval and is off otherwise. So it is
plausible that a blinking, i.e. active camera needs more power than an inactive
one.
> I guess if you can't fix the problem (power) then you could use the below as
> a kludge, but you might also want to be careful if
> this lack of power might also cause other issues (SD card corruption would
> probably be the worst).
Luckily the SD card is mounted read-only most of the time. But I'll keep this
in mind.
Thanks
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 172, Issue 21
********************************************
