github swapplications/uhf-server-dist 2.2.0

5 hours ago

New: recordings that survive bad streams

  • Recordings no longer fail when the stream drops. If the source stops sending data, closes the connection or returns an error, the server restarts ffmpeg and continues into the same recording, up to ten times per programme, with a growing pause between attempts. A short gap is marked where this happened, and the apps are notified the first time a recording recovers.
  • Late starts and resumes. A recording whose start time passed while the server was down (or that was in progress when the server stopped) now records what is left of the programme instead of being marked as missed. The part captured before a restart is kept.
  • Gentler stops. ffmpeg is now asked to finish cleanly, so the last seconds of a recording are kept and the playlist is always complete.
  • Every recording folder now contains an ffmpeg.log with the exact command line and output of each attempt (capped at 5 MB). Attach it to bug reports.

New: save each recording as a single file

  • A new option, --single-file-recordings (SINGLE_FILE_RECORDINGS=true for Docker, or "Save each recording as a single file" in the desktop app settings), merges the segments of a finished recording into one index.ts file. The playlist is kept and points at that file, so playback in the apps, in the browser, casting and downloads work exactly as before. The merge briefly needs twice the recording's space on disk, which is why it is optional. Existing recordings are left as they are.

Fixes

  • Recordings in progress could not be watched with ffmpeg 7.1 or newer: segments without a file extension were rejected. They play again, from the start, while still recording.
  • Playlist connection limits are now reported as such. When a recording fails because the account's simultaneous connections are all in use (typically a device still playing a channel from that playlist), the recording says so, in the apps, in the web app and in the push notification, instead of a bare "ffmpeg exited with code 8".
  • Streams that resume with a different timestamp base after a drop (the playlist restarted its stream) produced a playlist that players refused, with a target duration of several hours and a 26-hour timeline. The offending segment is now detected and dropped when the recording is finalised, the dates are corrected, and such a recording can no longer be mistaken for complete before the programme ends.
  • Recurring series: when the first occurrence of a series was created while its programme was already on air, the shortened duration was repeated for every following occurrence. The series now repeats the slot that was asked for.

Don't miss a new uhf-server-dist release

NewReleases is sending notifications on new releases.