OCTOBER 19, 2026 UPDATE: The October 18 article below preserves the earlier Kick-to-radio relay architecture. Today's operating reports replace that path with listener-triggered workstation MP3 encoding at 48 kHz stereo, 320 kb/s, passed through the server to Icecast without another encode. Public samples decoded successfully, and idle capture shutdown was reported after the ninety-second reconnect grace. The metadata system remains separate; exact alignment with the new audio path has not been measured. Read the October 19 station dispatch for the updated account. Latest dispatch: /about/station-update-2026-10-19/article.txt ------------------------------------------------------------------------ INSIDE NITETIME.NET RADIO: ONE BROADCAST, SEVERAL CAREFULLY CONNECTED SYSTEMS A technical field guide to the live radio stream at radio.nitetime.net (https://radio.nitetime.net/) NITETIME.NET Radio is designed to feel like a radio station: a receiver, a tuning dial, a live program display, and one button that brings the broadcast into the room. Behind that interface is a compact chain of streaming and metadata services. The important architectural choice is that the player is a new listening surface for the station that already exists. It is not a second radio station, a duplicate encoder, or a new program scheduler. The public player lives at https://radio.nitetime.net/. Its audio is the established NITETIME stream, delivered through the existing https://nitetime.net/live.mp3 route and through the new host's matching /live.mp3 route. Both public URLs reach the same Icecast mount. Listeners can keep using the original URL, existing bookmarks, and compatible players; the standalone host adds a dedicated radio experience without replacing the original distribution path. FROM BROADCAST TO LISTENER The audio path begins with the live Kick broadcast. On the server, the existing relay retrieves Kick's live HLS presentation, selects an audio-bearing variant, downloads its MPEG-TS segments, and passes the audio to FFmpeg. FFmpeg encodes stereo MP3 at 128 kilobits per second. The relay publishes that encoded stream to the local Icecast server's /live.mp3 mount. Icecast is bound to loopback, so the public listener does not connect directly to its administration interface or depend on an exposed Icecast port. Nginx provides the public HTTPS entry point. Its /live.mp3 locations proxy the existing Icecast mount, disable response buffering for the continuous stream, and pass through the listener's Icy-MetaData request header. When a compatible player requests ICY metadata, Icecast advertises an interval (icy-metaint) and inserts the current StreamTitle into the audio response at those boundaries. Ordinary MP3 clients can still request the audio without displaying metadata. The same encoded source feeds either URL; adding radio.nitetime.net did not add another Kick fetcher, FFmpeg process, Icecast mount, or encoder. This distinction matters operationally. The relay is already the owner of the Icecast mount. A second publisher must not be started against that mount casually: Icecast accepts one source publisher for a mount at a time. The standalone page is a listener and metadata consumer; it does not publish audio. TWO DELIVERY PATHS, ONE PROGRAM EVENT Audio and display information travel through separate but coordinated paths. Audio is continuous MP3 from Icecast. Now Playing information is a small JSON document served by the metadata sidecar at 127.0.0.1:8769. Nginx exposes that data as GET /now-playing.json on the radio host and as the existing GET /api/now-playing.json route used by the atlas. The public read route does not need the source's signing key or bearer credential. On the broadcast workstation, an independent publisher observes actual playout state and the active PLAYING rundown entry. It uses the item's actual start time rather than announcing an item merely because it is next in a queue. It can classify the available program states as music, commercial, weather, DJRC, or station, and attach a title, optional artist, and approved first-party artwork where those fields exist. Timed scene cues, including mapped weather and commercial transitions, can produce their own events when the source timeline defines them. A single unsegmented cue cannot truthfully provide finer-grained transitions than the source itself contains. The workstation signs each event using Ed25519. The signature covers the exact UTF-8 JSON request body, so any change to the body invalidates the signature. The server verifies the signature with the installed public key before accepting the event. The private signing key remains on the workstation; it is not part of the website, the public player, or shared documentation. The HTTP event submission is a separate authenticated write path from the public read-only JSON feed. Accepted events are held for approximately twelve seconds before publication. This delay is intended to bring the title closer to what a listener hears after the source, Kick HLS segments, extraction, encoding, Icecast, and player buffers have each introduced some delay. Two observed transitions -- a station promotion and the next music item -- reached public JSON and ICY about 12.015 and 12.324 seconds after their source timestamps. Those measurements support the configured hold as a practical starting point; they do not prove frame- or waveform-perfect alignment for every listener. Kick segment timing and each phone, browser, car stereo, and network buffer can vary. Exact heard-audio alignment remains a separate measurement rather than a promise made by the interface. If valid events stop for fifteen minutes after a specific item is active, the metadata service returns to the station identity. The sidecar also reasserts the current ICY title periodically so a reconnecting source does not silently lose the display title. The metadata service, Icecast, nginx, and the Kick relay are separate operational components; metadata updates do not need to restart the audio relay, the station schedule, OBS, or the stream. WHAT THE STANDALONE PLAYER DOES The page is a static HTML, CSS, and JavaScript receiver served by the existing nginx virtual host for radio.nitetime.net. It uses the HTML audio element with src="/live.mp3"; playback is initiated by the listener, which satisfies mobile browser gesture requirements and avoids unexpectedly starting sound. The interface offers play/pause, mute, a remembered volume setting, a UTC clock, a direct MP3 link, and a copy-link action. On phones, the receiver fills the viewport and includes a phone-only Add to Home Screen or install affordance. In landscape orientation, its CSS moves to an edge-to-edge receiver layout. The page links back to the main NITETIME.NET site. The page requests Now Playing JSON independently of the audio stream. It refreshes quickly, avoids overlapping polls, retains the last good event during a short service error, and eventually falls back to station identity when the metadata source has gone stale. The page maps the event type to the receiver's program selector: MUSIC, DJRC, WEATHER, BREAK, or STATION. The visible title and artist update with the feed; opaque generated DJRC filenames are displayed as "DJRC Announcement" so implementation identifiers do not become program copy. A known older forecast label also receives a narrow weather display compatibility mapping. The document title changes with the broadcast. Where supported, the browser Media Session API exposes the current program title, artist/station name, album/program context, and artwork to operating-system media controls. This is how a phone lock screen can show the broadcast information even while another app is in front. The logo is used as station artwork when no per-track cover art is supplied. The owner verified the title in a car display and saw the logo on the phone lock screen. That proves behavior on those particular devices; cars differ, and the owner's car showed a music-note placeholder instead of cover art. The page cannot make a receiving car support artwork if the phone/car combination does not relay it. URLS, TLS, AND OPERATIONS The canonical page is https://radio.nitetime.net/, served from /var/www/nitetime-radio-standalone/. Its nginx configuration is /etc/nginx/sites-available/radio.nitetime.net, with the normal enabled symlink. HTTP redirects to HTTPS. The existing certificate and renewal process cover the radio hostname. https://nitetime.net/radio and its slash form redirect to the standalone host, while https://nitetime.net/live.mp3 remains an audio endpoint. The main homepage links to the player from its radio announcement, programming block, and service grid. The page and its styles, script, PWA manifest, and icons are static files. There is no player-specific application daemon or database. Nginx proxies the stream and the JSON endpoint to the already-running local services. The source-publishing credential, Icecast password, and private signing key are deliberately outside the website and are never published in article material. A guarded deployment utility keeps backups and separates UI publication from TLS/vhost changes; routine player copy or CSS changes do not require restarting the audio pipeline. WHAT IS -- AND IS NOT -- LIVE The MP3 itself is the existing continuous feed. The current title, category, artist when available, and station artwork are separate descriptive metadata. ICY-capable players receive StreamTitle; the website uses JSON plus Media Session metadata. A phone's lock screen and a Bluetooth car stereo may render those fields differently. The integration does not claim that each song has individual album artwork, that every vehicle supports cover art, or that a title change is synchronized to the millisecond with every buffered listener. It does not publish listener counts, listener locations, or fabricated program transitions. Its goal is narrower and useful: read the actual current playout item, deliver an authenticated and delayed metadata event, and present it consistently across the radio page, supported phone controls, and ICY-aware stream listeners while leaving the established sound path intact. Technical source: NITETIME server service documentation and production route configuration, plus the workstation's reported source publisher and transition checks. Service details are described at the level needed to explain the system; secrets and internal credentials are intentionally omitted.