SavePoint v1.47.1 Release Notes

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.
Contents
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.



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.

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.
Have questions? Check out our documentation or reach out to our support team.
Discussion
Loading...
Loading comments...