Most of today went on the hotel IPTV job. It started with chasing a contractor for answers and ended at home with the evening's captures turned into a topology map. A download queue full of fakes and a batch of journal posts fitted in around it.
Catching the blog up
Just after midnight I caught up on the journals I'd missed for 28 September to 1 October. Going back over them turned up a wrong power-brick wattage in an older post, which now says 180 W everywhere.
In the afternoon I published them. Nine posts from 16 September to 1 October went through a staging folder so the titles of older live posts couldn't be overwritten, then got committed, pushed and checked live. All nine returned 200. The blog had been stuck on 24 September and now has 61 posts.
Asking the contractor, then picking up the phone
The hotel's outside network contractor replied to my questions with no technical content at all. Their account manager only wanted to know whether they should answer questions or come on site, and either way it would be billed. I started on a written reply, then rang them instead.
The person I spoke to wasn't technical. Mapping the network would be billable, the contractor doesn't have access to all the equipment, and the hotel's existing TV network is already in use. I asked for read-only access so I could map it and confirm it all myself.
Read-only access to the hotel's Wi-Fi and switch controller came through at 16:32, and I went through it without changing anything. The existing TV network reaches the room ports and runs its own DHCP, which clashes with the IPTV plan. Each room has one Ethernet port behind the wall-mounted TV. Firewall and core switch logins arrived at 17:01, and I set myself a rule straight away: the core switch logins are admin-level, so read-only commands only and nothing gets changed. I wrote up a handoff for the site session and drove over.
A queue full of fake releases
Before that, late in the afternoon, I looked at why Sonarr wasn't grabbing point releases properly, even when I picked them by hand. The queue was clogged with fakes: normal-looking names with Windows executables or .zipx archives inside instead of the image. Sonarr can't import them, so they sat there forever, and Sonarr then turned down real releases because the queue already met the cutoff.
I'd seen the same problem on 21 September and never cleared it. It had grown from 17 fakes to 31 in a 33-item queue. I cleared the queue. Every fake came from the same three indexers, and I deprioritised them rather than switch them off. Priority only breaks ties, though, so a fake that's the only match can still get grabbed.
So I added a queue sweeper that runs every 30 minutes across Sonarr and Radarr. It flags executable payloads, removes them from the torrent client and the seedbox, blocklists the release and kicks off a re-search. If it finds more than 25 fakes in one run it does nothing and errors out. I checked the tests by deliberately breaking the matching to prove they could fail. The first real run caught another fake that had been grabbed after my clear-out. Nothing monitors the sweeper yet.
I also filled out another rolling release from a smaller mirror. Three more point releases imported, which makes 17 of 40. About ten more exist but fall just under the size minimum, and the first eleven aren't on any indexer at all.
On site
I got there at 17:38 and plugged the Mac in through a USB Ethernet adapter, on its own macOS network location. The first core switch's web interface let me in. SSH didn't, and that turned out to be me mistyping my login.
The second core took about half an hour. The Mac kept sending traffic out over Wi-Fi instead of the cable, and the return path was asymmetric. Moving to a port on the management network fixed it. After that I logged into the firewall read-only.
I had two things wrong going in: which device was acting as multicast querier for the TV network, and my assumption that nothing on that network used multicast at all. The real numbers said otherwise. There's plenty of spare bandwidth, with core-to-core around 3% and the building uplinks between 0 and 10%. One core port is a ready-made spare uplink. The querier sits in the wrong building, so a lot of TV traffic crosses the network for nothing, and fixing that is a firm requirement for the new VLAN.
I decided the IPTV system gets its own VLAN so the changes can go in stages. I'd also thought about connecting my remote-access travel router to the hotel core, then shelved it until I've done more research, because I don't want to make a mistake on someone else's network. I put a small TP-Link LS105G unmanaged switch behind the travel router instead and reconfigured the router around it. Every piece of the IPTV equipment is now reachable remotely, and I got my first successful SSH login to the second TV switch. One login looked like it had hung, but the Terminal tab was just stuck in raw mode after screen.
Before leaving I documented everything in as much detail as I could, since I wouldn't be back the next day. At 21:28 I logged out of everything and headed home.
The topology map
From home at 21:41 I went through the controller once more: 8 switches, 48 access points and about 280 clients. Then I built a topology map of the whole hotel from the day's captures, which came to 92 devices and 100 links.
A second pass checked 36 facts against the raw captures and found 4 wrong and 3 unsupported, and all seven got fixed. Only 9 of the 100 rooms can be tied to a switch port so far, so the offline click-through HTML page has a room-to-port recorder to fill in on site. There are three versions: the offline page, an internal map and a client copy. The client versions use the real device names instead of my internal nicknames. A spot check caught a few names joined with slashes that had slipped through, and those got fixed too.
Still open
At the hotel, room-to-port mapping sits at 9 of 100, and moving the querier and building the new VLAN still need a staged plan. The queue sweeper has no monitor, so if it stops I won't find out. And at 5am the automated update review flagged a Proxmox kernel update on one node as "ask" instead of applying it, so that one is waiting on me.