ARTICLE2026.06.09

SavePoint v1.47.1 Release Notes

Savepoint FM
5 MIN READ179 VIEWS[ANNOUNCEMENTS][CHANGELOGS]
SavePoint v1.47.1 Release Notes
ARTICLE SUMMARY 5 MIN READ

Member-owned live segments arrive: station members can fully operate their own scheduled blocks directly from OBS or any RTMP-capable broadcasting software, with every connected channel switching to the member's live feed for the duration of their segment.

We are proud to introduce member-owned live segments in SavePoint v1.47.1. Station members can now fully operate their own scheduled blocks directly from OBS or any broadcasting software that supports live streaming. Each member receives a dedicated connection key tied to their assigned slot, allowing them to tunnel directly into the station when their segment begins. Every connected channel automatically switches to the member's live feed for the duration of the block, then returns to station programming when the segment ends or the broadcast disconnects. Members never need server access or file uploads, and they retain full control over their own scenes, microphones, playlists, overlays, and production workflow.

What's New

Member-owned live segments

This is the groundbreaking change. Any station member assigned to a scheduled segment can connect a live stream straight into that segment from their own streaming rig. They keep their own audio setup, their own OBS scene, their own microphone, their own playlist. The station never touches their content. They just need a connection key, the station's ingest URL, and a scheduled slot.

When a member goes live, the station automatically swaps every connected channel (Discord, YouTube, Mixcloud, Kick, Twitch, and the in-browser player) over to the member's feed. When the segment ends or the member disconnects, the station picks the air back up automatically, either with the regular schedule or a configured standby. Listeners hear a smooth handoff, not dead air.

Two types of connection keys are available. Per-segment keys authorize a member only during their scheduled window. Station-level master keys let the station owner take the air for any reason at any time. The dashboard shows the active slot, the member's connection state, and what listeners will hear if the broadcast drops mid-segment.

Station Settings RTMP tab, top card: the RTMP ingest server status, configurable port, per-station production hostname override, and the relay-segment toggle table for enabling or disabling RTMP on each scheduled segment.
Station Settings RTMP tab, bottom card: the Station Master RTMP Keys panel where station owners reveal, copy, rotate, or revoke a master connection key per station.
Per-segment RTMP relay panel on the segment detail page, showing the OBS-ready ingest URL, the masked per-segment connection key, and the controls a member uses to roll or revoke their own key.

Shared Stations: Multiple Members, One Station

A station can now be co-operated by multiple members on a single schedule. Each member holds their own scheduled segments without locking out the others. When one member's slot ends and the next member's slot begins, the station hands the air over cleanly. The station owner keeps a master-key override that reclaims the air for emergencies, drop-ins, or just because.

Member dashboard view of a shared station, showing the station header, stats cards, and the My RTMP Streams card listing the member's assigned segment with a masked stream key and OBS setup instructions. Admin nav items are hidden because the user is not a super admin.

Public Now Playing Source Feed

External widgets, "Now Playing" displays, and third-party integrations now get a public feed that tells them which source is actually on air at any moment. The Now Playing API response gained three additive top-level fields covering the three states a station can be in: the regular schedule, a member-owned segment, or an owner takeover. Existing integrations keep working unchanged.

Logging improvements

A new Export All Logs button on the Logging Settings page bundles every component log, the current logging configuration, and the broadcast observability counters into a single zip download, replacing the previous workflow of sshing into the server and tarring directories by hand. The same page also exposes the broadcast engine's internal warning thresholds, so operators can raise them on noisy hosts or lower them on quiet production hosts.

Issues addressed

  • Kick and Twitch chat connections were stalling on "OAuth not configured" errors or routing to broken redirects because per-station credentials and the token exchange were not threading the station ID through every step. The OAuth flow has been corrected, and chat connections now authorize cleanly across all stations.
  • When a chat OAuth token quietly expired in the background, the channel card stayed green and operators could go days without realizing their chat had stopped working. Channel cards now flip to an amber warning with a Re-connect action the moment the refresh fails, so the problem is visible immediately instead of hiding behind a healthy-looking status.
  • On Electron (Windows), starting a Discord broadcast took roughly ninety seconds because the audio path was falling through an HLS buffer proxy that added significant cold-start delay. The Windows path now uses the local HLS server directly, cutting go-live time to about five seconds.

Under the Hood: Broadcast Pipeline Refactor

Everything above is held up by a quieter change. The five channels (Discord, YouTube, Mixcloud, Kick, Twitch) and the in-browser player now read from a single shared stream produced by one master process, instead of each running their own encoder. This is what makes member-owned segment streaming possible in real time without each channel falling out of sync. It also means a hiccup on one channel can no longer drag the others down, and the server does noticeably less work.

Updating

Download the latest desktop build from the download page, or use in-app update if you are already running an Electron build. Server deployments pick up the new pipeline on first boot after pull, and database migrations apply automatically. If you intend to use member-owned segments or the owner master-key on a production host, read the RTMP Relay setup guide for the one-time hosting setup and the per-segment connection-key workflow.

SECTION_BREAK

Have questions? Check out our documentation or reach out to our support team.

Share

Discussion

Loading...

Loading comments...

Back to Blog179 views