wget of still images not working the first time with current Motioneye

[Eric Koester]

For the last 3 years, I've been running MotioneyeOS (from June 6, 2020) in a Raspberry Pi Zero W with a RPi camera module attached via the CSI camera connector.
motionEye Version 0.42.1
Motion Version 4.2.2+gitUNKNOWN
OS Version motionEyeOS 20200606

I've been using a simple bash script run by a CRON job entry to capture images, for my weewx weather station page.  This is the line in the script that does the capture:

wget http://192.168.7.90/picture/1/current/ -O /home/weewx/public_html/images/webcam.jpg

It only calls for an image 1 time.

Doing this has worked great, once per minute, for 3 years.

(Note, that with MotioneyeOS you don't need the port :8765 notation in your wget call.)

This week, I loaded some other Raspberry Pi Zero boards (with attached RPi camera modules) loaded with 32-bit Bullseye RaspianOS from July 2024. 
motionEye Version 0.43.1b2
Motion Version 4.7.0
OS Version Raspbian 11

I got Motioneye working in Bullseye and thought I had working Raspberry Pi cameras that were working as well as my 2020 vintage MotioneyeOS RaspberryPi cameras.  Nope!

I found that the same wget command line I was using with the MotioneyeOS RPi cameras, does NOT work the same with the current Motioneye release running inside Bullseye RaspbianOS.

I found that the wget command doesn't grab a valid image from Motioneye, UNLESS you call wget, wait 2 seconds, and then call wget AGAIN!

It's like Motioneye puts the camera to sleep and it takes 2 wget calls to wake it up and get a valid image??

By experimenting, I found that calling wget 2 times with a 2 second delay between calls, wakes up the camera and obtains a valid image

wget http://192.168.7.91:8765/picture/1/current/ -O /home/weewx/public_html/images/webcam.jpg

sleep 2

wget http://192.168.7.91:8765/picture/1/current/ -O /home/weewx/public_html/images/webcam.jpg

Why is it now necessary to call wget 2 times to get a valid image from the camera with the latest release of Motioneye?

Is the current Motioneye putting the camera module to sleep and 2 wget calls are necessary to wake it up?

Is there a setting that will keep Motioneye from putting the camera to sleep?

[StarbaseSSD]

You should post this over at https://github.com/motioneye-project/motioneye/issues as the new devs that are responsible for 0.43.xxx do not follow this forum.

[Eric Koester]

Ok, I posted over in the motioneye-project Issues tab.

Hopefully this is a known issue and has a known fix.

I wonder if the standard 32-bit version of the Bullseye Raspberry Pi OS (with desktop) could be too much of a load for a Raspberry Pi Zero W, and it's not keeping up to wget requests in real time??

How much lighter of a load do you suppose the MotioneyeOS is in comparison?
Should I try a stripped down version of Raspberry Pi OS Bullseye and see if that helps?

[StarbaseSSD]

MotionEyeOS was a VERY stripped down with just enough OS to run it. It uses busybox for it's main OS functions, runs only the services it needs, and no desktop support. It makes RPiOS Lite look like bloatware. I have tested Buster & BullsEye Lite versions with 0.42.1 and it worked fine as either a hub (connecting to IP cameras) or running a single USB or MMAL (CSI) camera on the PiZeroW.

[Eric Koester]

I just loaded an SD card with the Lite version of Bullseye Raspberry Pi OS (no desktop) and then loaded Motioneye (Python3 version).
motionEye Version 0.43.1b2
Motion Version 4.5.1
OS Version Raspbian 11 (RPiOS Lite)

Motioneye responds the exact same way to the wget - delivers a 0 byte .jpg if I only call wget 1 time.

I still have to call wget 2 times in order to get a valid .jpg file.

192.168.7.91 = webcam3.jpg got called 2 times by wget.

192.168.7.92 = webcam4.jpg got called 1 time by wget.

Since Motioneye is doing the same thing in both the Standard and the Lite versions of Raspberry Pi OS, it looks like the RaspberryPi Zero W is not being overloaded by Raspberry Pi OS.

It's something Motioneye is doing.

[StarbaseSSD]

I'll be happy to check in the AM tomorrow.

RPiZeroW, 8GB card, RPiOS Bullsey Lite, CSI camera, MotionEye 0.43.1b2. Should have something to report around 10a, or so. If I have time, I will also test iterations of Buster Lite, and Bullseye Lite with 0.42.1.

[StarbaseSSD]

Sorry, got up a bit late. Currently installing motionEye 0.43.1b2 on Bullseye lite on PiZeroW & PiCam. Will update you shortly...

[StarbaseSSD]

Wow. Bullseye, PiZeroW, and my CSI Camera do NOT get along, at least with motionEye 0.43.1b2 & motion 4.5.1. I am going to try with motionEye 0.42.1 on Bullseye to see if anything else is changed...

[Eric Koester]

I had similar troubles at first with Bullseye RPiOS Lite, RPiZeroW and the RPi camera.

When I selected the camera (as an V4L2 Camera), the image was gray and it had an error message in the image.

I found that I needed to reboot the OS after getting Motioneye installed with the pip command.

THEN I was able to add the camera (as an V4L2 Camera) and it worked normally.

The thing I'm seeing from watching the Motioneye GUI in a web browser, is that the camera image appears to time out and go off after about 1 minute, if you don't click on it with your mouse pointer, to "keep it awake".

I think that is the issue that is causing the wget command to be issued 2 times, to get an image.

The first wget wakes up the camera.  The second wget acquires a valid .jpg.

[Eric Koester]

Here's what it looks like in the web GUI when the camera image is "asleep".

If I click on the image area, it wakes up and is active agian.

[StarbaseSSD]

Interesting. I have never noticed anything like that in 0.42.1. I would think that is a 'bug' in 0.43.1b2. I doubt if it is a 'power' issue, as I have never seen any 'power savings' settings for CSI in RPiOS...

[Eric Koester]

Hummm.  Maybe roll back to 42.1?

I would guess that's the version that is in the last 2020 version of MotioneyeOS?

pip install --upgrade motioneye==0.42.1

--
You received this message because you are subscribed to a topic in the Google Groups "motioneye" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/motioneye/-iWuFIEI8Hk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to motioneye+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/motioneye/98af5514-1b74-4364-ad34-8495150c9f17n%40googlegroups.com.

[Eric Koester]

Were you able to duplicate the lack of .jpg delivery with the issue of a single wget command?

[Eric Koester]

Well, rolling back to an earlier version does NOT work.  

It broke the working Motioneye install.

It wouldn't even run the web gui!

I tried to upgrade back to 0.43.1b2.  

The web gui mostly works, but its still broken to some extent.

Did anyone know that trying to roll back to an earlier version would break everything?

[StarbaseSSD]

Due to the way the systems run (0.42.1 is Python 2.7 dependent, 0.43.1b2 is Python 3 dependent) and the support of CSI cameras changed drastically between RPiOS 10, 11, and 12, no, you can't really 'roll it back'. That is why I always start with a clean install of the OS, then focus on the install appropriate for the OS. My recent testing works for RPiOS 10 and 0.42.1, mostly works for RPiOS 11 and 0.42.1 or 0.42.1b2, and RPiOS 12 only seems to work consistently for 0.43.1b2, but with issues for CSI & USB. I believe a lot of issues are related to the Python camera support. IP cameras seem to work across all versions. BTW, I've also tested with Debian 10, 11, and 12 on x86 and ARM HW and have noted the same results.

[Eric Koester]

My main interest in exploring the latest Motioneye software is to find a way to get usable nighttime images, by lengthening the exposure time to brighten each image.

I'm finding that there seems to be more problems with the current versions of software that Motioneye runs inside than there was with MotioneyeOS from 2020.

I'm not sure how to narrow down the cause of the apparent sleeping state of the camera and frame grab function using wget?

That degraded functionality is annoying but can be worked around by calling for a camera frame using 2 or more wget calls.

During my testing of the latest software releases, I have discovered that the RPi camera software has taken steps backwards.

There seems to be less functionality with the V4L driver compared to the MAL camera driver.

Auto exposure does not work above resolutions of around 800x600 pixels.

Is there any evidence this is being looked and worked on?

Eric

[StarbaseSSD]

The particular functionality changes are due to the way the OS was/is being changed by the RPiOS people. I would contact them via the RPiOS support teams or maybe put a request in on the motion forums. The ability to add manual commands is still in motionEye, so if you can figure out what motion/v4l needs to give you the functions you want, we can help add them in...