Python3 (again) and Bullseye

411 views
Skip to first unread message

Rolf Pedersen

unread,
Nov 12, 2021, 10:32:51 AM11/12/21
to motioneye

Howdy,
I've been using Calin Crissan's formidable softwares, motioneye and motioneyeos, for some years.  I've got 6 or 8 pis and probably started with motioneyeos on Pi ZeroW.  I've since migrated up to Pi 4 8G (just ordered a Pi Zero2W) and have come to use some Debian-ish image with motioneye installed on it for my installations method.

As I'm able to upgrade the software on these devices with apt, I do so.  However, I note that the latest Debian release, Bullseye, has erased Python2, moved completely to Python3, AIUI.  Just posting a heads-up/RFI since Bullseye would, therefore, be out-of-bounds for the simple motioneye installations I, possibly others, have come to know and love.
Thanks,
Rolf

StarbaseSSD

unread,
Nov 12, 2021, 10:39:21 AM11/12/21
to motioneye
Have you tried either of these instruction sets?
RaspberryPiOS just came out with their version of RaspiOS 11 Bullseye (10/30/2011)
and I was able to set up the correct instructions for getting Python2, pip2,
and the rest working for motionEye.
Ditto for Debian 11 Bullseye on other hardware.
Please feel free to try them.

Rolf Pedersen

unread,
Nov 12, 2021, 11:56:37 AM11/12/21
to moti...@googlegroups.com

I did not know they were there!

That's very helpful, thanks, and hopeful, IMO, in light of this:

   There will be a warning that python 2.7 and pip2 are outdated and will not be updated
   This is normal and to be expected, as Python 2.7 is beyond EOL, as is pip2.
   When motionEye is updated to Python3, these messages will go away.

meaning affirmation from the source of ongoing development of motioneye for Python3.

Now, I *do* feel free to see what damage I can do, thanks again!
Rolf

--
You received this message because you are subscribed to the Google Groups "motioneye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motioneye+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/motioneye/29d21989-183c-4d08-825f-0a66a37de219n%40googlegroups.com.

StarbaseSSD

unread,
Nov 13, 2021, 3:40:41 PM11/13/21
to motioneye
Any results?

Rolf Pedersen

unread,
Nov 13, 2021, 4:16:20 PM11/13/21
to moti...@googlegroups.com

My plan is to try it with a new setup on my Pi Zero2W, due next week.  I'll update!

Rolf Pedersen

unread,
Nov 26, 2021, 11:49:20 AM11/26/21
to moti...@googlegroups.com

Howdy,

The Zero2W showed up and I wanted to use it with a new Eyoyo portable HD monitor, which required getting some HDMI adapters.  Today was the first opportunity after that to try with Bullseye. 

First, I tried the Debian nightly, raspi_1_bullseye.img.xz from 20211124 burned to an unused, on-the-shelf 256  GB SanDisk Ultra A1 XC 1 microSD card with Etcher.  I wrote 'ssh' to /boot and put a working  wpa_supplicant.conf into /etc/wpa_supplicant/.  It booted only to the rainbow screen and the brief green led activity stopped.  I let it set for some time and tried the same process with the 'tested' 20210823_raspi_1_bullseye.img.xz from Debian downloads.  That got no further. 

Then, I got the bright idea to use the Ubuntu file for Pi Imager, imager_1.6.2_amd64.deb, converted it to an rpm with `alien', and installed that with urpmi.  This program has the option to configure wifi and ssh, a few other options before burning the image, which I thought would workaround my fumbling manual attempts:  https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/

That booted to the new desktop.  I had a logitech keyboard/mouse dongle connected to the Zero2W OTG micro USB port via unpowered hub and ssh was working on my Magiea 8 desktop in konsole.  I followed https://github.com/ccrisan/motioneye/wiki/Install-on-Raspbian-Bullseye to install motioneye.  When completed, motioneye would not start.  An error explained the directory /var/lib/motioneye did not exist, so I created it and motioneye started.  Probably, I inadvertently skipped the step during instructions as subsequent installations by this method did not have this error.  I added the working configuration backup for the 4 cameras on my LAN and was able to access them at [url]:8765.

The Zero2W has 4 cores but only 512MB memory.  Something was not optimal as `motion' was consuming 250% - 350% cpu, load average was ranging up to around 6, down to just over 4.  All 100MB swap got used and ssh became unresponsive.  There are maybe tweaks for swap but my next move is to go back to Buster:  Debian Buster with Raspberry Pi Desktop Release date: January 11th 2021, 2021-01-11-raspios-buster-i386.iso, verified with sha256sum, burned to card with Pi Imager.



This was the result for several repeated attempts with different readers, different cards.  I tried with Etcher, no customization step, but could not make the manual modifications in /boot as the filesystem reported as RO, not writeable, several attempts, several configurations of reader, burning app, and card.

Then, I ran Etcher, using the recommended image, Bullseye with desktop, no configuration step at Ctrl-Shift-X and pre-wifi configuration by putting ssh and wpa_supplicant.conf in /boot on an old, generic 32GB card.  That ran, I was able to restore the backup configuration, all cameras were displayed, but Zero2W wasn't up to the task:


Then, I went semi-conservative, burning motioneyeos-raspberrypi-dev20201026.img.xz to the 32GB card with Pi Imager, attempting the configuration step, which failed to find a startup script on the filesystem.  I'm beginning to think Pi Imager works for only a certain set of OS images.  I re-plugged the card, added the modifications to /boot, and booted to the rainbow screen.  Maybe the Pi Imager manipulations are at fault?  Re-try with Etcher, manual edits...
Rainbow screen.

Next up, motioneyeos-raspberrypi-20200606.img.xz, Etcher, 32GB card, manual pre-configuration.  During this step, I saw that I was able to see contents of the /boot partition in the file browser, sudo cp wpa_supplicant.conf and sudo touch ssh, there, see those files in the browser, but the partition was not mounted.  I refreshed and files were not there.  Good chance my previous rainbow screens happened this way.  I mounted, sudoed, and verified writes, then booted to Rainbow Screen, no green LED illumination at all.  Back to the newer card; maybe I'm wearing 'em out!

Newer card, different reader, Etcher, motioneyeos-raspberrypi-20200606.img, manual configuration, verified write.
Rainbow Screen.  No green LED activity.  Leaving for 5-6 minutes.  No change.  Tried different power adapter, unplugged USB hub, same results.

My first Pi0W is set up in a case with pi camera, SD card, booting to a USB key and that works.  I took the latest burned card of this experiment, partially took the case apart, exchanged SD cards, and removed the USB bootable key.  The HDMI connector wouldn't seat with the case blocking full insertion.  I booted, the green LED was blinking rapidly, and I could connect to an ssh login prompt.  I failed to login as pi, forgetting there is only root/admin on motioneyeos.  I loosened the board enough to plug HDMI, booted again, and saw boot complete to a login prompt on the mini-monitor.  I could see in my desktop browser that the pi camera had been automatically added to motioneye.  I could move forward with this card in Pi0W.  I must have missed whether or what image of Buster-era will work on Pi02W.

For S&G, I put the known working SD card from Pi0W into Pi02W, attached OTG USB hub with Logitech dongle and bootable USB key, attached HDMI, then let 'er rip.  It booted to the pi@pi0w prompt, the hostname for that machine, and informed me rfkill was blocking Wi-Fi.  I could run raspbi-config to unblock, as advised, but this shows Pi02W is working and I think I'll put things back together as was, then try to see what can be done to get Buster on Pi02W.

Thanks,
Rolf

StarbaseSSD

unread,
Nov 26, 2021, 12:13:40 PM11/26/21
to motioneye
Thank you for the very thorough testing. I appreciate it.
The Pi motionEyeOS image motioneyeos-raspberrypi-20200606.img should not work. The PiZeroW2 has a different SoC and wifi chip, and the images are very chipset specific. dev20201026 shouldn't work either for the same reason. The Pi3 image _could_ work, but for the wifi chip there.
I'm surprised that the RPiOS image isn't working for Buster, as the 'official' Bullseye image is dated around the release date of PiZeroW2, and it would seem strange to me that they (RPiFoundation) would have released a board in development without using the then current OS (Buster), unless their intent was to put a flag on it saying PiZeroW2 only works with Bullseye.
(I won't bring up all the other issues that Bullseye has, like unable to use PiCamera/Raspistill & RaspiVid (removed) in favor of libcamera. Lack of Python 2 or 3 PiCam funtions. Removal of GTK2 and other graphic utilities in use for more than a decade in the student development environment, and on and on... Breaking many apps like motion & motionEye and quite a few HAM radio apps... or maybe I just did...)




Rolf Pedersen

unread,
Nov 26, 2021, 3:51:44 PM11/26/21
to moti...@googlegroups.com

Thanks for the info.  I found Daniel-Muszkiet saying this:

Which Pi? PiZeroW or PiZeroW2? You should be using this for PiZeroW and this for PiZeroW2 I do not use balena etcher for imaging, I prefer Win32DiskImager.

here:  https://gitmemory.com/starbasessd and went to the suggested page:  https://github.com/jawsper/motioneyeos/releases/tag/20211113 to get motioneyeos-raspberrypi3.img.gz

I burned that to the large, newer card with Etcher, seeking the best performance.  I did the manual pre-configuration and booted to a working system.  However, when I tried to restore the settings backup from my Pi48g running 4 rtsp cameras quite well, it did not complete.  There was an error for 'no /etc/motioneye directory' and a core dump.  I tried writing the directory to the card in a reader, even in the apparent overlay area, but it did not survive the boot.  So I re-imaged and added the cameras one-by-one at [url]:8765.  They display as desired in a 2x2 grid but only show up for about 5 seconds, once in a while, two at a time.  The time overlay shows the correct minute but the seconds increment only by one, if at all, during the brief display.  The crossed camera image is what displays most of the time.

The measurements with top, uptime, and free do not appear problematic (screenies below).  Since the Pi48g is displaying these cameras all the time, I turned it off in case it was too much load on the cameras but no help.  Using a bash script posted by Crisan, IIRC, the temp of the board, in open air, shows 51.5 after about an hour of running.  Maybe it's a wifi issue?  I connect to the 2.4GHz radio as with other machines on the LAN which have no bottlenecks.

As busy as I've seen, usually quieter:


Help, Mr. Wizard, Help!  I don't want to be an early adopter anymore! 😉

Thanks.

--
You received this message because you are subscribed to the Google Groups "motioneye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motioneye+...@googlegroups.com.

StarbaseSSD

unread,
Nov 26, 2021, 4:26:30 PM11/26/21
to motioneye
Twas my post to Daniel you posted above, concerning setting up a PiZeroW2 (he wasn't clear which device he was trying to use), and which image to use.
I don't have a PiZero2W to test with, otherwise I'd be all over it.
There are all kinds of issues, with all kinds of things related to Buster on PiZero2W, motionEyeOS on PiZero2W, Bullseye and PiCams and apps for cameras in general, and on and on.
Until I can get one to test / write up, and with the confusion abounding as to what does and doesn't work, I'm going to say:
Not supported by the official images of motionEyeOS, and RPiOS Bullseye is not supported for motionEye.
Motion later than version 4.3.2 (per motion -project) on Bullseye not supported.
Until a new image is issued and / or a PiZero2W is acquired for testing, please understand that some of the issues are beyond our control.

StarbaseSSD

unread,
Nov 27, 2021, 12:31:56 PM11/27/21
to motioneye
Found another reason to not like Bullseye... They killed OMXPlayer (and deprecated it, along with a bunch of needed files) killing my attempts to add the Fast Network Camera functionality (including Display to HDMI) using Lite (or even lighter) without going all the way back to motionEyeOS... It's VERY frustrating...

Rolf Pedersen

unread,
Nov 27, 2021, 8:38:50 PM11/27/21
to moti...@googlegroups.com

Today, I made several attempts to install Raspbian images from here:  https://downloads.raspberrypi.org/ e.g.
2021-05-07-raspios-buster-arm64  and 32-bit Buster, IIRC, lost track.  Many attempts with different burning programs and procedures all resulted in Rainbow Screen, nothing further.  At one point, I found that repeatedly pushing the microSD card into the slot of one of the cheap readers seems to have dislodged the contacts into the interior, causing me to think that maybe all the previous failures were related to faulty hardware (Etcher and Pi Imager verify the burns, N.B.).  I tried once more with a different reader but same result.

Then, I moved over to 2021-10-30-raspios-bullseye-armhf, the 32-bit version.  I was pretty hungry for success.  I didn't touch it with pre-configuration as I had an attached monitor/hub/mouse/keyboard and it booted normally.  I added ssh and installed motioneye from the github instructions referenced in another thread.  I believe I might have experienced the inability of Buster images to support Pi02W

When I added the 4-camera configuration from my successfully running Pi48g, all four came up in :8765 on my PC monitor for a few moments.  htop looked about like this:

Very soon, the brief displays of only one or two cameras, as described in the other thread, began happening.  It seemed like the software was crashing and attempting to restore itself, with htop looking like this:

I proceeded to disable all but one of the rtsp cameras in the :8765 web gui but it and ssh were pretty unresponsive.  I rebooted a couple of times to get the handle.  Finally, one camera displays fairly well, keeping up with the clock, generally, but with occasional lags of a second or three I don't notice on the 8G Pi running 4 cameras.  htop looks like this:


There are a couple of scripts I've borrowed from Crisan and elsewhere that I put in /usr/[local]/bin, one of which I call 'throttle':

root@raspberrypi02w:/home/pi# throttle
frequency(48)=1000002000
frequency(1)=400000000
temp=64.5'C
throttled=0x0
volt=1.2125V
root@raspberrypi02w:/home/pi#

The interpretation of 0x0 for 'throttled' is that there has been no under-voltage situation, no throttling.  The temperature is pretty high, verified by the other script, "hot", but it seems to be caused by the connected USB hub, which gets very warm, as USB things are known to do.  When I disconnect it, it drops back down

root@raspberrypi02w:/tmp# hot
CPU Temp=48.3
root@raspberrypi02w:/tmp#

and it goes back up when I connect it

root@raspberrypi02w:/home/pi# hot
CPU Temp=62.8
root@raspberrypi02w:/home/pi#

The Pi is just hanging from connected cables in air over my desk and this observation is consistent over a small number of trials.

I'd say limited RAM is the big drawback of Pi02w for multi-camera operations.  I think the swap file could be made larger, I've heard of making swap on attached flash memory, and software optimizations will probably improve performance.  From what I've seen of the experiences of others and those of my own, it would be more practical to buy a more powerful SBC, already proven for my current application.  I've another single 5V IR-cut camera remote surveillance installation with line voltage adapter, power bank backup, 5V mifi that has been miraculously reliable for more than a year and three-quarters (I spent 6 months developing and testing at home).  The Pi02w might have some application for me like that but it remains to be seen if it will be more than a White Elephant.

All in all, I'd say this motioneye stuff is pretty amazing.
Thanks for your work!
Rolf


On 11/26/21 09:13, StarbaseSSD wrote:
--
You received this message because you are subscribed to the Google Groups "motioneye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motioneye+...@googlegroups.com.

StarbaseSSD

unread,
Nov 28, 2021, 12:54:55 AM11/28/21
to motioneye
Out of curiosity, when installing motion, are you disabling the daemon?
systemctl stop motion
systemctl disable motion
motionEye starts its own copies when needed.
I think you've noticed the lack of RAM (especially as compared to the Pi3Bs and 4Bs) that could be a detriment to the use of motionEye for anything but a single camera like a PiZeroW.
You might consider (if your cameras supports 2 resolutions) movie passthrough and https://github.com/ccrisan/motioneye/issues/880 to reduce cpu workload.
I can't find specifics on throttling for the PiZero2W but I wouldn't be surprised that they didn't change trip points and indicators there, too, like they did with Pi4s from previous Pis. I start getting 'flakey' behavior at 60`C on the Pi4s even though. (soft limit)

Rolf Pedersen

unread,
Nov 28, 2021, 5:10:21 AM11/28/21
to moti...@googlegroups.com
Yes, following the instructions to the letter.

 systemctl stop motion
 systemctl disable motion

Currently booted headless:
pi@raspberrypi02w:~ $ sudo systemctl status motion
● motion.service - Motion detection video capture daemon
     Loaded: loaded (/lib/systemd/system/motion.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:motion(1)
pi@raspberrypi02w:~ $
With only one of the cameras enabled:



pi@raspberrypi02w:~ $ throttle
frequency(48)=1000000000
frequency(1)=400000000
temp=56.9'C
throttled=0x0
volt=1.2063V
pi@raspberrypi02w:~ $
Curiously, opening a tab of Chrome to :8765 on my PC seems to cause the temperature to go up.  It's been rising for the 5 or 8 minutes since I opened it:
pi@raspberrypi02w:~ $ throttle
frequency(48)=1000000000
frequency(1)=400000000
temp=65.5'C
throttled=0x0
volt=1.2063V
pi@raspberrypi02w:~ $
A-a-a-n-n-d, camera feed lost, ssh unresponsive, Pi02w appears to be crashed.  To be clear, only power connected, no OTG USB, no HDMI.  FWIW,
pi@pi48g:~ $ cat `which throttle`
vcgencmd measure_clock arm; vcgencmd measure_clock core; vcgencmd measure_temp; vcgencmd get_throttled; vcgencmd measure_volts core
pi@pi48g:~ $
-copied from good ol' Pi48g, 4 cameras continuously displaying to 4 monitors on the bridge of the Enterprise:
pi@pi48g:~ $ uptime
 02:02:37 up 1 day, 14:20,  2 users,  load average: 1.80, 1.66, 1.61
pi@pi48g:~ $

IDK whether viewing the web page over LAN could increase work for the CPU enough to crash pi.  Doesn't seem likely.  ISTR load average became over 1 but less than 2 with it open and memory/swap was not nearly saturated.  It sure snuck up on me.  Maybe a flaw in this pi.

I picked up the pi to plug the keyboard radio dongle and one ssh session to it disconnected with 'broken pipe'.  The green status LED flickered, so kernel must be running.  The other session with 'htop' is still frozen and "ssh: connect to host raspberrypi02w port 22: No route to host" repeatedly.  Time for Magic Keys!
...That didn't work so I plugged a wired USB keyboard and lights flickered in response to Alt-SysRq+R,S,E,I,U,B then:
pi@raspberrypi02w:~ $ uptime
 01:55:34 up 4 min,  4 users,  load average: 0.74, 0.77, 0.38
pi@raspberrypi02w:~ $
My camera settings are pretty modest; I'll look into those nuances some other time.  This is enough for me, tonight.  Signing off.  Thanks.
Reply all
Reply to author
Forward
0 new messages