I have done a couple of temperature measuring projects with different
PIs (a Pi3 and a Pi Zero W) and am quite familiar with running them
headless via VNC.

I thought I would try my hand with a camera on a PI zero W and having
got the basics sorted have installed the "motion" package and was
starting to play with that.

but now when running headless initial attempts to access the machine via
VNC result in

VNC Server is not currently listening for cloud connections

I discovered by chance that if I leave it long enough it does eventually
come up and having done some testing by trying to access every 30
seconds from boot I can not get access at 11 minutes but can at 11
minutes 30 seconds.


If I connect the pi to a display via the HDMI port and keyboard/mouse
via USB, the machine boots in about a minute or two, VNC starts and I
can log in from my remote machine, straight away.

I have done quite a bit of googling and did find this page https://www.raspberrypi.org/documentation/configuration/screensaver.md

but setting consoleblank to 60 did not improve matters.

I have tried @reboot vncserver start in crontab with no effect.

I have uninstalled the motion package but still no improvement

Does anyone have any idea where I should look?

Thanks

--
Chris B (News)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Chris B" <news@salis.co.uk> wrote in message news:sa09rd$i6d$1@dont-email.me...

I have done a couple of temperature measuring projects with different PIs
(a Pi3 and a Pi Zero W) and am quite familiar with running them headless
via VNC.

I thought I would try my hand with a camera on a PI zero W and having got
the basics sorted have installed the "motion" package and was starting to play with that.

but now when running headless initial attempts to access the machine via
VNC result in

VNC Server is not currently listening for cloud connections

I discovered by chance that if I leave it long enough it does eventually
come up and having done some testing by trying to access every 30 seconds from boot I can not get access at 11 minutes but can at 11 minutes 30 seconds.

If I connect the pi to a display via the HDMI port and keyboard/mouse via USB, the machine boots in about a minute or two, VNC starts and I can log
in from my remote machine, straight away.

I have done quite a bit of googling and did find this page https://www.raspberrypi.org/documentation/configuration/screensaver.md

but setting consoleblank to 60 did not improve matters.

I have tried @reboot vncserver start in crontab with no effect.

I have uninstalled the motion package but still no improvement

Does anyone have any idea where I should look?

Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to a
Pi4.

I found that the following lines in /boot/config.txt solved it for me:

hdmi_force_hotplug=1 # allow Pi to boot with no monitor connected
hdmi_group=2
hdmi_mode=82 # force 1920x1080x60 even though monitor can’t be
auto-detected

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 11/06/2021 21:22, NY wrote:

"Chris B" <news@salis.co.uk> wrote in message news:sa09rd$i6d$1@dont-email.me...

I have done a couple of temperature measuring projects with different
PIs (a Pi3 and a Pi Zero W) and am quite familiar with running them
headless via VNC.

I thought I would try my hand with a camera on a PI zero W and having
got the basics sorted have installed the "motion" package and was
starting to play with that.

but now when running headless initial attempts to access the machine
via VNC result in

VNC Server is not currently listening for cloud connections

I discovered by chance that if I leave it long enough it does
eventually come up and having done some testing by trying to access
every 30 seconds from boot I can not get access at 11 minutes but can
at 11 minutes 30 seconds.


If I connect the pi to a display via the HDMI port and keyboard/mouse
via USB, the machine boots in about a minute or two, VNC starts and I
can log in from my remote machine, straight away.

I have done quite a bit of googling and did find this page
https://www.raspberrypi.org/documentation/configuration/screensaver.md

but setting consoleblank to 60 did not improve matters.

I have tried @reboot vncserver start in crontab with no effect.

I have uninstalled the motion package but still no improvement

Does anyone have any idea where I should look?

Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to
a Pi4.

I found that the following lines in /boot/config.txt solved it for me:

    hdmi_force_hotplug=1    # allow Pi to boot with no monitor connected
    hdmi_group=2
    hdmi_mode=82        # force 1920x1080x60 even though monitor can’t
be auto-detected

Thanks for the suggestions which I have now had time to look into.
The first two lines were already set in my /boot/config.txt

The third line was hdmi_mode=16. I changed it to 82 and although this
had a major effect on the VNC display it did not reduce the VNC access
time which remains at in excess of 10 minutes from reboot

Regards

--
Chris B (News)
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"NY" <me@privacy.invalid> wrote in message
news:sa20ke$2kp$1@dont-email.me...

"Chris B" <news@salis.co.uk> wrote in message news:sa1n7f$fol$1@dont-email.me...

Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to >>> a Pi4.

I found that the following lines in /boot/config.txt solved it for me:

hdmi_force_hotplug=1 # allow Pi to boot with no monitor
connected
hdmi_group=2
hdmi_mode=82 # force 1920x1080x60 even though monitor can’t >>> be auto-detected

Thanks for the suggestions which I have now had time to look into.
The first two lines were already set in my /boot/config.txt

The third line was hdmi_mode=16. I changed it to 82 and although this
had a major effect on the VNC display it did not reduce the VNC access
time which remains at in excess of 10 minutes from reboot

Hmmm. I wonder what it different about your setup. In my case the Pi
refused to boot, and stuck as a solid (not flickering) green LED. I never thought to leave it to see if it would eventually boot. VNC may be a
slight red herring here, because a Pi ought to be able to boot without any remote connection. What happens if you set up a recurring ping to the Pi: does that start responding any sooner than the > 10 mins that you've found for VNC.

As far as I am aware, the hdmi_force_hotplug=1 is the only parameter which matters as regards ability to boot; the hdmi_mode=82 is there just to make sure what VNC sees a full-resolution display when it connects, rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.

Thinking about this a bit more, I can't see that any software which
auto-starts on your Pi (but which I don't have on mine) would be started
early enough to cause a no/go-go on the booting process. So I wonder if the reason your Pi doesn't respond to VNC is different to the reason mine didn't boot until I added hdmi_force_hotplug=1. Maybe your Pi is booting OK but
Real VNC server isn't starting until after a long timeout. There is probably
a log file somewhere which contains details of all the processes and their time-since-boot (it will be a fictitious time because the Pi will boot with
a semi-random time because it has no real-time clock hardware, and the time will only be corrected when the Pi then syncs with an NTP server),

If you can ping the Pi from long before VNC responds, you could try enabling SSH on the Pi and connecting to it by PuTTY (Windows) or JuiceSSH
(Android) - get those working when the Pi is booted and responding via VNC
(or connected to a monitor) so you know that they normally work, before rebooting and trying with the Pi headless. Those are diagnostic rather than solutions, but at least they help diagnose how far the Pi is getting in its boot process - ie whether it is even leaving the starting blocks.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Andy Burns" <usenet@andyburns.uk> wrote in message news:iijfffFm6ihU1@mid.individual.net...

NY wrote:

As far as I am aware, the hdmi_force_hotplug=1 is the only parameter
which matters as regards ability to boot; the hdmi_mode=82 is there just
to make sure what VNC sees a full-resolution display when it connects,
rather than defaulting to 640x480 or giving a
white-writing-on-black-background error message.

If the config.txt option isn't doing the trick, maybe try a physical hdmi dummy?

<https://thepihut.com/products/hdmi-dummy-plug>

I nearly suggested something like that...

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Chris B" <news@salis.co.uk> wrote in message news:sa1n7f$fol$1@dont-email.me...

Ah, the "headless Pi4 problem". I hit this when I migrated from a Pi3 to
a Pi4.

I found that the following lines in /boot/config.txt solved it for me:

hdmi_force_hotplug=1 # allow Pi to boot with no monitor connected
hdmi_group=2
hdmi_mode=82 # force 1920x1080x60 even though monitor can’t
be auto-detected

Thanks for the suggestions which I have now had time to look into.
The first two lines were already set in my /boot/config.txt

The third line was hdmi_mode=16. I changed it to 82 and although this had
a major effect on the VNC display it did not reduce the VNC access time
which remains at in excess of 10 minutes from reboot

Hmmm. I wonder what it different about your setup. In my case the Pi refused
to boot, and stuck as a solid (not flickering) green LED. I never thought to leave it to see if it would eventually boot. VNC may be a slight red herring here, because a Pi ought to be able to boot without any remote connection.
What happens if you set up a recurring ping to the Pi: does that start responding any sooner than the > 10 mins that you've found for VNC.

As far as I am aware, the hdmi_force_hotplug=1 is the only parameter which matters as regards ability to boot; the hdmi_mode=82 is there just to make
sure what VNC sees a full-resolution display when it connects, rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Chris B wrote:

Does anyone have any idea where I should look?

does SSH access become available before VNC access?

if so, can you see the VNC process, is anything listening on the VNC port?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

NY wrote:

As far as I am aware, the hdmi_force_hotplug=1 is the only parameter
which matters as regards ability to boot; the hdmi_mode=82 is there just
to make sure what VNC sees a full-resolution display when it connects,
rather than defaulting to 640x480 or giving a white-writing-on-black-background error message.

If the config.txt option isn't doing the trick, maybe try a physical
hdmi dummy?

<https://thepihut.com/products/hdmi-dummy-plug>

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 11-06-2021 20:25, Chris B wrote:

I have tried @reboot vncserver start in crontab with no effect.

Use 'sudo raspi-config' to configure VNC, that should be enough. Do not
add another 'vncserver start' somewhere.

I have uninstalled the motion package but still no improvement

Desktop + Motion + VNC sounds a bit much (by which I mean a LOT) for a
Pi Zero.

Does anyone have any idea where I should look?

Start over from scratch: download a fresh image of the latest 32-bit
RaspiOS, burn it to SD card and connect to that.

If running headless, you do need those config.txt settings. Group 1 mode
16 is the same as group 2 mode 82. CEA (group 1) was originally for TV compatible hdmi, DMT (group 2) is for DVI over hdmi to a computer
monitor, but effectively they're the same. If you want sound output over
the physical cable, use a CEA mode. This makes no difference for VNC. I
have this:

hdmi_force_hotplug=1
# 1/16 = CEA 1920x1080 @ 60 Hz
# 1/31 = CEA 1920x1080 @ 50 Hz
# 1/95 = CEA 3840x2160 @ 30 Hz (only for Pi 4)
# 2/69 = DMT 1920x1200 @ 60 Hz
# 2/82 = DMT 1920x1080 @ 60 Hz
hdmi_group=1
hdmi_mode=16

More modes available at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md (scroll down to "hdmi_mode" where they have two enormous tables for CEA
and DMT).

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 12/06/2021 11:14, NY wrote:

Maybe your Pi is booting OK but Real VNC server isn't starting until
after a long timeout.

The timeout is reasonably consistent with a tcp connect failure time


--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"A. Dumas" <alexandre@dumas.fr.invalid> wrote in message news:60c49236$0$22704$e4fe514c@news.xs4all.nl...

If running headless, you do need those config.txt settings. Group 1 mode
16 is the same as group 2 mode 82. CEA (group 1) was originally for TV compatible hdmi, DMT (group 2) is for DVI over hdmi to a computer monitor, but effectively they're the same.

If you want sound output over the physical cable, use a CEA mode. This
makes no difference for VNC. I have this:

Ah!!!!!!!!!

This explains why when I was using 2/82 = DMT 1920x1080 @ 60 Hz, I couldn't
get any sound if I connected the Pi by HDMI cable, having set the Pi to boot headless with

hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=82

I'll change it to

hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=31

Which are the parameters I have for my Pi3 which doesn't need the hdmi_force_hotplug=1 to allow it to boot headlessly. I Couldn't find any reference to the CEA modes or 50 Hz rather than 60 Hz when I was researching for the Pi4 - maybe it is that 50 Hz modes are not offered by raspi_config.

hdmi_force_hotplug=1
# 1/16 = CEA 1920x1080 @ 60 Hz
# 1/31 = CEA 1920x1080 @ 50 Hz
# 1/95 = CEA 3840x2160 @ 30 Hz (only for Pi 4)
# 2/69 = DMT 1920x1200 @ 60 Hz
# 2/82 = DMT 1920x1080 @ 60 Hz
hdmi_group=1
hdmi_mode=16

More modes available at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md (scroll down to "hdmi_mode" where they have two enormous tables for CEA
and DMT).

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:

Chris B wrote:

Does anyone have any idea where I should look?

does SSH access become available before VNC access?

if so, can you see the VNC process, is anything listening on the VNC port?

Apologies if this formats incorrectly but I am away from home at the moment using Google Groups
rather than the more familiar T Bird

I have uninstalled the "motion" package

I rebooted and tried to ping immeadiately

chris@Johns-iMac ~ % ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
ping: sendto: No route to host

{lots of similar lines deleted}

Request timeout for icmp_seq 43
64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms
64 bytes from 192.168.1.22: icmp_seq=46 ttl=64 time=7.650 ms
64 bytes from 192.168.1.22: icmp_seq=47 ttl=64 time=5.090 ms
64 bytes from 192.168.1.22: icmp_seq=48 ttl=64 time=6.026 ms
64 bytes from 192.168.1.22: icmp_seq=49 ttl=64 time=5.279 ms
64 bytes from 192.168.1.22: icmp_seq=50 ttl=64 time=5.696 ms
64 bytes from 192.168.1.22: icmp_seq=51 ttl=64 time=5.697 ms
64 bytes from 192.168.1.22: icmp_seq=52 ttl=64 time=2.083 ms
64 bytes from 192.168.1.22: icmp_seq=53 ttl=64 time=7.380 ms
^C
--- 192.168.1.22 ping statistics ---
54 packets transmitted, 10 packets received, 81.5% packet loss
round-trip min/avg/max/stddev = 2.083/5.799/8.094/1.628 ms

So then I tried to SSH and do a ps aux (results below)

chris@Johns-iMac ~ % ssh pi@192.168.1.22
pi@192.168.1.22's password:
Linux pizero2 4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jun 12 14:55:11 2021
pi@pizero2:~ $ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 5.0 1.6 27024 6052 ? Ss 15:02 0:04 /sbin/init splash
root 2 0.0 0.0 0 0 ? S 15:02 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I 15:02 0:00 [kworker/0:

"Chris B (News)" <cjb200@gmail.com> wrote in message news:a833b994-8d62-490f-9c37-707cfa38a5cdn@googlegroups.com...

On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:

Chris B wrote:

Does anyone have any idea where I should look?

does SSH access become available before VNC access?

if so, can you see the VNC process, is anything listening on the VNC
port?

Apologies if this formats incorrectly but I am away from home at the
moment using Google Groups
rather than the more familiar T Bird

I have uninstalled the "motion" package

I rebooted and tried to ping immeadiately

chris@Johns-iMac ~ % ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
ping: sendto: No route to host

{lots of similar lines deleted}

Request timeout for icmp_seq 43
64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms

...

So then I tried to SSH and do a ps aux (results below)

...

All of this time VNC viewer is responding with
VNC Server is not currently listening for Cloud connections.

Ok. so we've established that the Pi *is* booting - and taking about 43
seconds to start responding to pings - assuming that you started the ping command as you applied power to the Pi to start it booting, and that your
pings are once a second.

And SSH is working OK: its listener process must be starting long before
VNC's starts.


So it's not the failure-to-boot problem of not having an HDMI monitor to detect. But something else is preventing the VNC listener starting when
there's no HDMI device present.



Ah, a thought has just occurred to me. That word "cloud" in "VNC Server is
not currently listening for Cloud connections". There are two ways of establishing a VNC connection. One involves referring to the computer (in
your case, the Pi) by its name, and goes via a central cloud server. The
other is a direct connection by IP address and does not rely on a cloud
server. The default is to use the cloud server: it works for RealVNC server
on *any* platform, even if you have the free rather than paid-for
subscription version of VNC.

The VNC server component that is built into Raspian/RasPiOS is a special
case: even without a paid-for subscription, clients can connect to it
directly by IP address.

At your VNC Viewer client (on your non-Pi computer), try configuring a
direct connection. For the Windows version, to the right of the "VNC
Connect" logo there is a box with the default wording "Enter a VNC Server address of search". Hopefully it's similar for your Mac client. In this box, type the IP address of the Pi. And see whether you can connect any sooner
this way than via the cloud.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

NY wrote:

That word "cloud" in "VNC Server is not currently listening for Cloud connections". There are two ways of establishing a VNC connection.

VNC was always direct (either forward on TCP/5900 or reverse on
TCP/5500) when I was using it, having a rendezvous with a 3rd party
server in the cloud was the teamviewer or anydesk way of doing it (with
pros and cons).

How long does the Pi take to register with this VNC cloud?

<https://help.realvnc.com/hc/en-us/articles/360003474692-Why-is-VNC-Server-not-currently-listening-for-Cloud-connections->
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Andy Burns" <usenet@andyburns.uk> wrote in message news:iik41rFq5upU1@mid.individual.net...

NY wrote:

That word "cloud" in "VNC Server is not currently listening for Cloud
connections". There are two ways of establishing a VNC connection.

VNC was always direct (either forward on TCP/5900 or reverse on TCP/5500) when I was using it, having a rendezvous with a 3rd party server in the
cloud was the teamviewer or anydesk way of doing it (with pros and cons).

In my RealVNC address book I have two entries for my Pis - one using the
normal cloud method (*) and the other using direct connection. And the connection speed reported by VNC is very different: the cloud one is capped
at roughly the upstream (slower) speed of my broadband connection. That does rather suggest that a cloud connection routes data out onto the WAN and then back in again.

I've just connected directly from my Windows PC to one of my Pis, where both computers and the router are Gigabit compatible. In the pull-down menu at
the top of the remote desktop, there is an "i" icon. It reports Connection
Type = Direct TCP and Line speed estimate = 750110 kbits/sec. Having closed that connection and opened one via the cloud to the same Pi, results are Connection Type = Cloud connection to [LAN IP}:50556 and Line speed
estimate = 10560.kbits/sec - and Ookla Speedtest gives my current speed as 29.18 Mbps D and 9.78 Mbps (ie 9780 kbps) U. That suggests that a direct connection is almost full Gigabit speed and cloud speed is similar to
upstream WAN speed.


(*) I only use this if I need to access the Pi from outside my LAN - eg from
my phone or laptop when away from home.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 12/06/2021 15:44, NY wrote:

"Chris B (News)" <cjb200@gmail.com> wrote in message news:a833b994-8d62-490f-9c37-707cfa38a5cdn@googlegroups.com...

On Saturday, 12 June 2021 at 11:13:53 UTC+1, Andy Burns wrote:

Chris B wrote:

Does anyone have any idea where I should look?

does SSH access become available before VNC access?

if so, can you see the VNC process, is anything listening on the VNC
port?

Apologies if this formats incorrectly but I am away from home at the
moment using Google Groups
rather than the more familiar T Bird

I have uninstalled the "motion" package

I rebooted and tried to ping immeadiately

chris@Johns-iMac ~ % ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
ping: sendto: No route to host

{lots of similar lines deleted}

Request timeout for icmp_seq 43
64 bytes from 192.168.1.22: icmp_seq=44 ttl=64 time=8.094 ms
64 bytes from 192.168.1.22: icmp_seq=45 ttl=64 time=4.997 ms

...

So then I tried to SSH and do a ps aux (results below)

...

All of this time VNC viewer is responding with
VNC Server is not currently listening for Cloud connections.

Ok. so we've established that the Pi *is* booting - and taking about 43 seconds to start responding to pings - assuming that you started the
ping command as you applied power to the Pi to start it booting, and
that your pings are once a second.

And SSH is working OK: its listener process must be starting long before VNC's starts.

So it's not the failure-to-boot problem of not having an HDMI monitor to detect. But something else is preventing the VNC listener starting when there's no HDMI device present.

Ah, a thought has just occurred to me. That word "cloud" in "VNC Server
is not currently listening for Cloud connections". There are two ways of establishing a VNC connection. One involves referring to the computer
(in your case, the Pi) by its name, and goes via a central cloud server.
The other is a direct connection by IP address and does not rely on a
cloud server. The default is to use the cloud server: it works for
RealVNC server on *any* platform, even if you have the free rather than paid-for subscription version of VNC.

The VNC server component that is built into Raspian/RasPiOS is a special case: even without a paid-for subscription, clients can connect to it directly by IP address.

At your VNC Viewer client (on your non-Pi computer), try configuring a
direct connection. For the Windows version, to the right of the "VNC
Connect" logo there is a box with the default wording "Enter a VNC
Server address of search". Hopefully it's similar for your Mac client.
In this box, type the IP address of the Pi. And see whether you can
connect any sooner this way than via the cloud.

Just tried that and in the period when the cloud connection is
"VNC Server is not currently listening for Cloud connections."

the direct connection method you suggest gives
"Timed out waiting for a response from the computer"

as soon as the cloud connection is up and running so is the direct method.

Once up and running the CPU usage is very low - usually well below 5%
with the odd spike to 20% or so, so its not as if something else is
using all of the processing power.

I asked myself what is different about this machine and my other 2.
1) This one has the camera interface enabled
2) This one has had the motion package installed and removed.

So I have disabled the camera interface - no change.
Perhaps 2 has corrupted something somewhere.

It looks like this isn't a quick and easy fix that lots of people know
but I don't so perhaps it is time for the SD card reformat option and
start again from scratch. This time play with the camera without
trying motion. Its all part of the learning experience :-)




--
Chris B (News)
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 12/06/2021 11:14, NY wrote:

Thinking about this a bit more, I can't see that any software which auto-starts on your Pi (but which I don't have on mine) would be started early enough to cause a no/go-go on the booting process.

Could be an excessive amount of time to obtain a DHCP lease. If you use raspi-config to set wait for network at boot, you should see this
happening with an attached display.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 13/06/2021 10:10, druck wrote:

On 12/06/2021 11:14, NY wrote:

Thinking about this a bit more, I can't see that any software which
auto-starts on your Pi (but which I don't have on mine) would be
started early enough to cause a no/go-go on the booting process.

Could be an excessive amount of time to obtain a DHCP lease. If you use raspi-config to set wait for network at boot, you should see this
happening with an attached display.

Ignore that, just read other branch of thread and it seems networking is
up fairly quickly.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Chris B" <news@salis.co.uk> wrote in message news:sa4e87$5d1$1@dont-email.me...

It looks like this isn't a quick and easy fix that lots of people know but
I don't so perhaps it is time for the SD card reformat option and start
again from scratch. This time play with the camera without trying
motion. Its all part of the learning experience :-)

Yes, that's how I rationalised it when I had to reinstall my Pi: once
because something catastrophic happened between a clean shutdown and a clean startup (no power cuts at that time), so the Pi failed very early in the
boot process; secondly when I bought a Pi4 and migrated software from the
Pi3; thirdly because an update on the Pi4 invoked by sudo apt update
followed by sudo apt full-upgrade caused a program (or a device driver) to misbehave (the Pi was running TVHeadend as a video recorder; after the
upgrade recordings from the satellite decoder started intermittently experiencing massive numbers of data errors, as if the satellite signal had become badly degraded by noise). I will not be installing any updates on the
Pi - especially ones which update the kernel.

Luckily I made detailed notes of all the customisations I made as I was
doing the first reinstallation (Pi wouldn't boot) and was able to refer to those to make sure I carried out the same stages (with appropriate modifications when going from Pi3 to Pi4) for initial installation and then
the reinstallation (duff satellite tuner driver).


In your case, I'd get VNC server working early in the build process, and
prove that it works, and then retry it periodically as new software is installed, to find out what provokes it. Maybe also take an image of the SD card before each significant new installation so you can roll back to just before, rather than having to go right back to the beginning.

That reminds me: it's probably about time I updated the SD images of my Pis
as rollback insurance, so I roll back to as late a state as possible rather than to how they were several months ago.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"druck" <news@druck.org.uk> wrote in message
news:sa4i5t$prj$2@dont-email.me...

On 13/06/2021 10:10, druck wrote:

On 12/06/2021 11:14, NY wrote:

Thinking about this a bit more, I can't see that any software which
auto-starts on your Pi (but which I don't have on mine) would be started >>> early enough to cause a no/go-go on the booting process.

Could be an excessive amount of time to obtain a DHCP lease. If you use
raspi-config to set wait for network at boot, you should see this
happening with an attached display.

Ignore that, just read other branch of thread and it seems networking is
up fairly quickly.

LOL. I was just about to point that out, but you got there first.

Another off-the-wall suggestion to the OP (you may already have tried this). What happens if you boot up headless and then some time in the expected 10 minute delay plug the monitor in? Does that immediately allow VNC to accept connections?
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 13/06/2021 11:00, NY wrote:

"Chris B" <news@salis.co.uk> wrote in message news:sa4e87$5d1$1@dont-email.me...

It looks like this isn't a quick and easy fix that lots of people know
but I don't so perhaps it is time for the SD card reformat option and
start again from scratch.   This time play with the camera without
trying motion.   Its all part of the learning experience  :-)

That reminds me: it's probably about time I updated the SD images of my
Pis as rollback insurance, so I roll back to as late a state as possible rather than to how they were several months ago.

Thanks to you (and others) for suggestions and help, it is much
appreciated. I have now returned to a fully serviceable PiZero with a
camera connection.

The comment about SD card backups is noted and from now forwards will be carried out before major changes.




--
Chris B (News)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 14 Jun 2021 09:55:43 +0100, Chris B wrote:

The comment about SD card backups is noted and from now forwards will be carried out before major changes.

You may like to take a look at the 'rsync' backup package if you're not
already using it. Its fast because, rather than taking a full backup, it
brings the backup into line with the current state of play on your live
system, adding/deleting/replacing files and directories as needed to
capture each current machine state.

I have a pair of 1GB WD Essential USB drives which are kept offline and
used alternatively to do a weekly backup of all my systems (3x Linux x86
and (currently) one RPi), so I always have last week's set of backups
offline in a fire safe while the two week old backup disk is being
updated to capture the current system states.


--
Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)