NITETIME GOPHER 1.0 - Lake Koshkonong Node

Server: gopher.nitetime.net:70 Selector: /about/radio-technical-overview/

NITETIME.NET GOPHER

INSIDE NITETIME.NET RADIO
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.
[DIR]READ THE OCTOBER 19 STATION DISPATCH
------------------------------------------------------------------
NITETIME.NET // FEATURE EDITION // OCTOBER 18, 2026
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.
[WEB]OPEN THE WEBSITE
[TXT]PLAIN TEXT EDITION
[DIR]RETURN TO NITETIME.NET
___________________________________________________________________
Gophered by Gophernicus/3.1.1 on Ubuntu/22.04 x86_64

SIGNAL ACTIVE // WISCO 608 // Gateway locked to gopher.nitetime.net