gLiveView is only gathering information it can see on the running machine using linux tools available. You can also use these tools and look in the logs on the running machine. For example, when the block producer is still syncing it won’t be doing it’s slot leader checks but when fully synced these will start happening.
As far as I am aware, each relay has no idea whether the other node it is directly connected to is another relay or a block producer. Each is simply a node that can supply blocks.
The 0 incoming connections on your block producer indicates your relays were not initiating connections to it or at least these connection attempts were not getting through to it. If the only thing you changed was to restart these relays and there were no changes to your block producer, firewall, dns, or network routing, then maybe your relays didn’t “like” your block producer for some reason because it wasn’t synced for so long and the P2P mechanism labelled it “untrusted” so they refused to connect??? I don’t know, but it seems odd.
Did the block producer try to establish connections to the relays from it’s end? You could look through the logs on the block producer at the time to see if there were attempts by it to connect out to your relays.
On my block producer I see logs like this:
Sep 12 00:29:53 bp1 cardano-node[2664962]: [bp1:cardano.node.LocalRootPeers:Info:586] [2023-09-11 14:29:53.21 UTC] TraceLocalRootResult (DomainAccessPoint {dapDomain = "relays.terminada.io", dapPortNumber = 2700}) [(x.x.x.x,3600),(x.x.x.x,3600),(x.x.x.x,3600),(x.x.x.x,3600)]
Sep 12 00:29:53 bp1 cardano-node[2664962]: [bp1:cardano.node.LocalRootPeers:Info:586] [2023-09-11 14:29:53.21 UTC] TraceLocalRootGroups [(6,fromList [(x.x.x.x:2700,DoNotAdvertisePeer),(x.x.x.x:2700,DoNotAdvertisePeer),(x.x.x.x:2700,DoNotAdvertisePeer),(x.x.x.x:2700,DoNotAdvertisePeer)])]
Sep 12 00:29:53 bp1 cardano-node[2664962]: [bp1:cardano.node.LocalRootPeers:Info:586] [2023-09-11 14:29:53.21 UTC] TraceLocalRootDNSMap (fromList [(DomainAccessPoint {dapDomain = "relays.terminada.io", dapPortNumber = 2700},[x.x.x.x:2700,x.x.x.x:2700,x.x.x.x:2700,x.x.x.x:2700])])
Sep 12 00:29:53 bp1 cardano-node[2664962]: [bp1:cardano.node.LocalRootPeers:Info:586] [2023-09-11 14:29:53.21 UTC] TraceLocalRootWaiting (DomainAccessPoint {dapDomain = "relays.terminada.io", dapPortNumber = 2700}) 3600s
Note that the x.x.x.x values were all valid IP addresses which I changed to protect the innocent before pasting. 
I see similar logs on my relays for setting up connections the other way.
I just looked at one of my relays to see what sort of errors it logs about peer connections and I see messages like this:
Sep 12 07:21:58 relay1 cardano-node[984262]: [relay1:cardano.node.PeerSelectionActions:Error:99235] [2023-09-11 21:21:58.37 UTC] PeerStatusChangeFailure (HotToCold (ConnectionId {localAddress = 172.27.0.7:2700, remoteAddress = 13.228.77.95:1338})) (ApplicationFailure [MiniProtocolException {mpeMiniProtocolNumber = MiniProtocolNum 2, mpeMiniProtocolException = MuxError (MuxShutdown (Just (MuxIOException Network.Socket.recvBuf: resource vanished (Connection reset by peer)))) "(recv errored)"}])
Sep 12 07:21:58 relay1 cardano-node[984262]: [relay1:cardano.node.PeerSelectionActions:Error:99235] [2023-09-11 21:21:58.37 UTC] PeerMonitoringError (ConnectionId {localAddress = 172.27.0.7:2700, remoteAddress = 13.228.77.95:1338}) (MiniProtocolExceptions [MiniProtocolException {mpeMiniProtocolNumber = MiniProtocolNum 2, mpeMiniProtocolException = MuxError (MuxShutdown (Just (MuxIOException Network.Socket.recvBuf: resource vanished (Connection reset by peer)))) "(recv errored)"}])
So it looks like that peer went off-line or something. The “resource vanished” message seems to indicate that the tcp connection got closed by the other end.
There is so much useful logging done by the cardano-node software. It might be worthwhile looking for similar messages about errors in your logs during the time your blocks weren’t getting out, because you might not have fully fixed your problem yet.
Another thing I see in the relay logs is this message:
Sep 12 07:45:37 relay1 cardano-node[984262]: [relay1:cardano.node.ConnectionManager:Info:626] [2023-09-11 21:45:37.24 UTC] TrConnectionManagerCounters (ConnectionManagerCounters {fullDuplexConns = 1, duplexConns = 29, unidirectionalConns = 42, inboundConns = 22, outboundConns = 50})
I don’t actually understand the difference between “fullDuplex” and “Duplex” in this P2P mechanism. If anyone does, please let me know.
I assume this “fullDuplexConns = 1” is the connection between my relay and my block producer as this is the only accessPoint listed under localRoots in the relay’s topology file. In other words, I think that because each end point (relay, bp) is trying to set up a connection with each other then this is upgraded to “fullDuplex” by the P2P mechanism. (Maybe?) On the other hand, I think the “duplexConns = 29” might represent connections set up by outside relays into my relay, or connections from my relay out to other relays, which then agree on a duplex upgrade.
You could look for similar “ConnectionManager:Info” logs to see if you are now seeing “fullDuplex” connections between your relay and block producer.
If you figure out anything, let me know. IOG have really built some robust mission critical beast here but the complexity is mind blowing.