Environment: Jaksta Media Recorder 2026.4.3.34, Windows 11, HLS Downloader = FFMPEG.
Bundled ffmpeg n6.0 (2023-05-29), hlsd.exe 2025.1.31.2. Recording Twitch and Chaturbate via Monitor.
1. FFMPEG mode marks every naturally-ended live recording as Failed
Symptom: When a live stream ends on its own, the recording always shows "Complete (Errors)"
(Failed, status 11), the log ends with "Stream Downloading Failed / Unknown error", and
auto-convert never runs. The file itself is complete and plays fine. Manually stopping a
recording does not have this problem. It happens on both Twitch and Chaturbate.
Evidence: I watched the ffmpeg process directly. It exits with code 0 at the moment the
stream ends, and Jaksta marks it Failed anyway.
Cause: In the Apple HLS downloader, the HLSD branch sets the success flag from the downloader's
exit code (success = false only if hlsd returns non-zero). The FFMPEG branch instead sets
success = false unconditionally and discards ffmpeg's return value. Afterwards, an un-cancelled
recording is only marked Complete if the "fell back from HLSD" flag is set, so a recording in
plain FFMPEG mode can never be marked Complete.
Fix: In the FFMPEG case, set success from ffmpeg's exit code the same way the HLSD case does
(success = (exitCode == 0)). I confirmed locally that with this one change, natural endings
are marked Complete, go through the normal mux-to-MP4 step, and produce a valid MP4.
2. "HLS Mux to" is hidden in FFMPEG mode but still applies to it
The FFMPEG downloader's finishing step reads the "HLS Mux to" setting, but that setting only
appears in the UI when HLSD is selected. If it was ever set to "Leave as RAW", FFMPEG
recordings silently skip the MP4 step, with no visible way to change it while in FFMPEG mode.
Please show it in both modes, or give FFMPEG mode its own setting.
3. HLSD fails on Chaturbate (separate audio/video LL-HLS streams) and deletes the downloaded data
a) Merge fails: HLSD downloads the video and audio playlists correctly into two temp files,
but the files contain only media fragments, without the init segment from #EXT-X-MAP. The
ffmpeg merge then fails, and the temp files are deleted, leaving a 0-byte output. When I
prepended the init segments manually, the same temp files merged into a perfect MP4. Fix:
include the init segment in the output (hlsd side), and never delete the temp files after
a failed merge.
b) "Leave as RAW" deletes everything: with two streams, the muxer logs "muxTo is Raw. No
muxing required." and returns, and the temp files are then deleted without being moved to
the destination. The result is a 0-byte file. Fix: move or rename the temp files to the
destination in RAW mode.
c) Stop leaves the audio downloader running: on Stop, the video hlsd ends but the audio hlsd
keeps downloading, and the recording hangs in "Stopping" until that process is killed. Each
hlsd download appears as two hlsd.exe processes with identical command lines, which suggests
Process.Kill() is only ending the parent. Fix: kill the process tree (taskkill /T, or a
job object).
4. Thumbnails from old recordings appear on new ones
Library IDs are reused after the newest entries are deleted, and thumbnails are keyed by ID
(art.<id>.jpg). A new in-progress recording shows the deleted recording's thumbnail until it
finishes. Deleting an entry also never deletes its thumbnail: I had 236 orphaned thumbnails
for 19 entries. Fix: clear the cached thumbnail when an ID is assigned, or don't reuse IDs, and
delete art files along with their entries.
5. Suggestion: "Download as MPG" re-encodes live
With "Download as MPG" on, every live recording is re-encoded to MPEG-2 in real time
(-vcodec mpeg2video -q:v 2). That's about 1 to 1.6 CPU cores per stream, and files are 3 to 5
times the original stream size (Twitch: around 35-45 Mbps on disk versus a ~6 Mbps source),
then a second lossy encode when converting. With it off, recording is -c copy to .ts, which is
just as crash-safe, keeps the original quality, and uses almost no CPU. Consider making Off
the default.
Also worth knowing: version updates appear to reset HLS settings to their defaults (HLSD,
Download as MPG on) and have twice brought back an obsolete chaturbate.com/FLV Site Specific
entry, which re-breaks Chaturbate recording.
I'm happy to provide logs or test a build.
Sorry, that should have said Version (2026.7.17.35), but 2026.4.3.34 and 2026.1.23.33 are also affected.
Ken Kopin
Environment: Jaksta Media Recorder 2026.4.3.34, Windows 11, HLS Downloader = FFMPEG.
Bundled ffmpeg n6.0 (2023-05-29), hlsd.exe 2025.1.31.2. Recording Twitch and Chaturbate via Monitor.
1. FFMPEG mode marks every naturally-ended live recording as Failed
Symptom: When a live stream ends on its own, the recording always shows "Complete (Errors)"
(Failed, status 11), the log ends with "Stream Downloading Failed / Unknown error", and
auto-convert never runs. The file itself is complete and plays fine. Manually stopping a
recording does not have this problem. It happens on both Twitch and Chaturbate.
Evidence: I watched the ffmpeg process directly. It exits with code 0 at the moment the
stream ends, and Jaksta marks it Failed anyway.
Cause: In the Apple HLS downloader, the HLSD branch sets the success flag from the downloader's
exit code (success = false only if hlsd returns non-zero). The FFMPEG branch instead sets
success = false unconditionally and discards ffmpeg's return value. Afterwards, an un-cancelled
recording is only marked Complete if the "fell back from HLSD" flag is set, so a recording in
plain FFMPEG mode can never be marked Complete.
Fix: In the FFMPEG case, set success from ffmpeg's exit code the same way the HLSD case does
(success = (exitCode == 0)). I confirmed locally that with this one change, natural endings
are marked Complete, go through the normal mux-to-MP4 step, and produce a valid MP4.
2. "HLS Mux to" is hidden in FFMPEG mode but still applies to it
The FFMPEG downloader's finishing step reads the "HLS Mux to" setting, but that setting only
appears in the UI when HLSD is selected. If it was ever set to "Leave as RAW", FFMPEG
recordings silently skip the MP4 step, with no visible way to change it while in FFMPEG mode.
Please show it in both modes, or give FFMPEG mode its own setting.
3. HLSD fails on Chaturbate (separate audio/video LL-HLS streams) and deletes the downloaded data
a) Merge fails: HLSD downloads the video and audio playlists correctly into two temp files,
but the files contain only media fragments, without the init segment from #EXT-X-MAP. The
ffmpeg merge then fails, and the temp files are deleted, leaving a 0-byte output. When I
prepended the init segments manually, the same temp files merged into a perfect MP4. Fix:
include the init segment in the output (hlsd side), and never delete the temp files after
a failed merge.
b) "Leave as RAW" deletes everything: with two streams, the muxer logs "muxTo is Raw. No
muxing required." and returns, and the temp files are then deleted without being moved to
the destination. The result is a 0-byte file. Fix: move or rename the temp files to the
destination in RAW mode.
c) Stop leaves the audio downloader running: on Stop, the video hlsd ends but the audio hlsd
keeps downloading, and the recording hangs in "Stopping" until that process is killed. Each
hlsd download appears as two hlsd.exe processes with identical command lines, which suggests
Process.Kill() is only ending the parent. Fix: kill the process tree (taskkill /T, or a
job object).
4. Thumbnails from old recordings appear on new ones
Library IDs are reused after the newest entries are deleted, and thumbnails are keyed by ID
(art.<id>.jpg). A new in-progress recording shows the deleted recording's thumbnail until it
finishes. Deleting an entry also never deletes its thumbnail: I had 236 orphaned thumbnails
for 19 entries. Fix: clear the cached thumbnail when an ID is assigned, or don't reuse IDs, and
delete art files along with their entries.
5. Suggestion: "Download as MPG" re-encodes live
With "Download as MPG" on, every live recording is re-encoded to MPEG-2 in real time
(-vcodec mpeg2video -q:v 2). That's about 1 to 1.6 CPU cores per stream, and files are 3 to 5
times the original stream size (Twitch: around 35-45 Mbps on disk versus a ~6 Mbps source),
then a second lossy encode when converting. With it off, recording is -c copy to .ts, which is
just as crash-safe, keeps the original quality, and uses almost no CPU. Consider making Off
the default.
Also worth knowing: version updates appear to reset HLS settings to their defaults (HLSD,
Download as MPG on) and have twice brought back an obsolete chaturbate.com/FLV Site Specific
entry, which re-breaks Chaturbate recording.
I'm happy to provide logs or test a build.