While the internal SSD is dead (#684/#686), we tried to at least get the YouTube live stream working. It does not go live: YouTube Studio shows No data.
Configured and verified via the Pearl API (driven remotely over cluster exec from turbo-pancake-76):
- Channel 2 (Live Stream) encoder healthy: state started, nosignal 0, bitrate ~6.2 Mbps. The dead SSD does NOT affect streaming (streaming is encoder->network, RAM only; only recording uses disk).
- Publisher configured to rtmp://a.rtmp.youtube.com/live2 with the correct stream key. Tried the alternate key and RTMPS on 443 too: identical result.
- Publisher stays in state starting with Frequent stream reconnections; never reaches started.
Root mechanism (proven): the Pearl transmits almost nothing. eth0 TX counter moved ~50 bytes over 10s while the encoder ran at 6.2 Mbps (a real stream would add ~7 MB). So the outbound RTMP data is not leaving the Pearl.
Network comparison:
- Pearl eth0: IP 11.0.6.76, gateway 11.0.0.1, DNS 8.8.8.8, /20, link 1Gbps up.
- Mac mini turbo-pancake-76 (11.0.5.207) uses the SAME gateway 11.0.0.1 and completes a full TLS handshake to a.rtmps.youtube.com:443 (verify code 0), reaches 8.8.8.8:53, resolves YouTube. So the venue path to YouTube works from 11.0.5.x.
Conclusion: the Pearl (11.0.6.76) has no working internet egress, while a host on the same gateway in the 11.0.5.x range does. Most likely the venue firewall/switch isolates the Pearl port / AV subnet (11.0.6.x) from internet egress. This is a venue network (Citymesh) matter, not a Pearl or key fault.
Next steps:
- On-site: plug a laptop into the Pearl's switch port and test internet. If the laptop also cannot reach the internet on that port, it is the switch port/VLAN (Citymesh). If it can, the fault is Pearl-side.
- Fix: have Citymesh allow 11.0.6.76 outbound to YouTube ingest (TCP 1935 and 443) and DNS, or move the Pearl to a port/subnet with internet egress (e.g. the 11.0.5.x general network the Mac uses).
- The Pearl is left configured with the correct key on standard RTMP and started, so it will go live automatically once egress is restored.
Contacts: cederik@experiencenet.com, tom_nijs@telenet.be, valere@cloudseven.be
Contingency + new lead: this is now tracked with a dedicated network-investigation sub-ticket #688. Lead from Tom: yesterday he changed the Pearl default gateway from 0.0.0.0 to 8.8.8.8 to make streaming work; it failed again today after the reboots, which points to the gateway/route reverting on reboot. Detail and next steps in #688.