Two separate threads ran through today: a full afternoon and evening getting a hotel client's IPTV gear into a test rack, and a shorter fix for a Discord alert that had been firing every night on the same item.
Photos first, then a rundown for eight rooms
The morning started at the desk, going through seven photos of the delivered equipment from the previous evening's unboxing. The headend server's fascia reads "FBE80x," a family badge; the specific model listed on the invoice doesn't appear anywhere on it, so which exact unit shipped is still unconfirmed. The tuner carries no branding beyond a generic "Tuner to IP Gateway" label, and only 16 of its 24 RF input positions are populated, matching the "16-way" spec on paper. The 24-port switch settled a question that had been open since the invoice first arrived: it's a real, documented H3C S5130V2. The UPS turned out to be mains-fed, with an external battery bank wired on screw terminals, which means it needs an electrician to install rather than someone simply plugging it in.
Told the site visit was happening that day, aiming for an eight-room test, I got a rundown built and filed as a runsheet before leaving: bring one server and the switch, feed the tuner's output straight into that server, then physically move eight patch leads at the hotel's rack to hand one wing of rooms to the test network. The one rule that mattered was that the test switch never gets a cable into the hotel's own network. A stray lead would leak the multicast feed, and a DHCP server on the wrong switch would start handing out addresses to hotel devices.
A nightly Discord alert traced to a three-year gap
Away from the hotel job, a message had been landing on Discord at the same time every night: a collection-handling job in the Linux ISO library's cleanup automation had failed, check the logs. The logs showed one item behind twelve of those failures, out of fourteen distinct items that had ever failed at all, and it was still failing every night. The item was correctly matched, all three of its external IDs present and valid, but one metadata service cross-checks the recorded release year against a second provider and only tolerates about a year of drift. This item's two sources disagreed by three years, so every ID got discarded and the nightly cleanup job choked on it the same way each time.
The fix was a one-field correction to the recorded year, locked so a future metadata refresh wouldn't undo it. That also removed the only thing standing between the item and a scheduled deletion the next morning, since the collection it sat in deletes anything past its retention window, and this one was already well past. Whether to keep the item or let the deletion run was left open.
On site, without the tuner
Getting back onto the Mac at the hotel first meant linking it to the vault's drop folder over Tailscale, so anything captured on site could land there directly instead of staying stuck on the laptop. The build plan called for the switch on top, a gap, then the tuner slot, then one server, with the second left boxed, but the tuner itself never made it into the car. Today's actual build ran server, switch, and set-top boxes only, with the Mac later standing in for the tuner's feed to test multicast.
A loose power supply turned up in the server's carton, model FSP250-50FCC, a 250 W Flex ATX unit rated for Australian mains. It looks like a spare for the server's own internal supply, and it also gives an upper bound on that server's power draw for when the UPS gets sized properly.
Powering on took longer than expected. The switch and server came up, and the set-top boxes went onto two of the switch's ports. The monitor connected to the server showed a brief Ubuntu boot line, then went black and stayed black for well over an hour while other rack work continued around it. The cause turned out to be the monitor cable not fully seated. Once reseated, a login screen appeared, asking for credentials that turned up separately soon after.
Finding the server's own management pages took a run of tcpdump on the Mac's ethernet adapter to catch a DHCP exchange, which showed the gear was on a subnet the Mac couldn't reach yet. Logging into the server directly listed three addresses on a second, still-unreachable subnet: a copy of the vendor's own user manual, hosted on the server itself, and two admin consoles, one for hotel information and one for channel management. Plugging a second network port into the switch made that subnet reachable, and all three pages loaded. The manual downloaded as a PDF and got filed into the project, so the build now has the vendor's real documentation on hand instead of only the sales deck.
The room-side test hit its own wall. The television in the test room turned out to be a Samsung DB48D, model LH48DBDPLGC/XY, apparently locked to hospitality mode, so the set-top box's video never reached a screen that could confirm it. Screenshots captured directly off each box over adb were used instead, covering channel changes and a side-by-side check of two boxes.
Home again, setting up for tomorrow
Back home in the evening, the last task was getting a GL.iNet Beryl 7 travel router ready to give remote access into the isolated test network, since tomorrow's visit means working from the hotel again without carrying a laptop the whole time. It's set up for now as a repeater pulling internet from home wifi, with its own LAN on x.x.8.1; the plan is to point the same repeater mode at the hotel's own network on site tomorrow. The tuner and the second server are still in their boxes, and the room-side signal path is still unconfirmed.