After version 0.41.4 armbian crash during play recordings

[rickoh6w-cloud]

After version 0.41.4 armbian crash during play recorder.
The Armbian CPU usage keeps rising during playback, and eventually, the system crashes.

[matteius]

I noticed something similar in general and had pushed up a fix for it, and cut a release when I saw your report -- please rechceck 0.41.13

[rickoh6w-cloud]

Version 0.41.13 cpu normal but, can't play recorder.

[rizkybs70]

I noticed something similar in general and had pushed up a fix for it, and cut a release when I saw your report -- please rechceck 0.41.13

Evidence :
https://jam.dev/c/c76d0696-209c-4cdc-8f4d-f336d0203b8b

[matteius]

I believe addressed in just released 0.41.14

[matteius]

The playback regression came from the automatic HEVC conversion path. The recording files are still MP4s; MP4 is the container, and the video inside can be H.264 or H.265/HEVC.

a95eb355 made the playback endpoint convert every HEVC recording to H.264 before serving it, without checking whether the requesting browser could play the original. A cache miss required decoding and re-encoding the entire clip. Concurrent playback requests could launch duplicate FFmpeg processes with large default thread/buffer allocations, explaining the CPU and memory failure mode reported here.

The subsequent OOM fix limited FFmpeg threads/buffering and serialized conversions. That reduced resource use but left playback waiting for a full conversion; requests waiting inside the shared HTTP pool could also delay unrelated APIs. Moving conversion to a background worker removed that HTTP bottleneck, but I preserved the unconditional conversion policy, so the timeline could still spend a long time displaying “Preparing.” That was the wrong default. The separate timeline CI failures were outdated test mocks; correcting those did not address this user-visible delay.

The final fix is 4196b94f, pushed to main:

• Recording, timeline, and investigation players load the original immediately. The normal playback endpoint serves the original with byte-range support and does no codec probing or transcoding.
• Only a browser decode/unsupported-format error triggers a compatibility copy. Network errors and cancelled loads do not start a conversion. Fallback is attempted once, retains the single-worker/thread limits, and stops polling when the user closes playback or changes recordings.
• Timeline regression coverage now uses an actual decodable MP4 with range responses and verifies seeking and playback, rather than only checking the assigned media URL.

Validation: 8 playback-handler C cases, 15 JavaScript playback cases, and 18 browser regression cases passed locally. An HTTP check confirmed that native HEVC playback returns the original bytes and byte ranges without launching FFmpeg. Browsers that cannot decode a recording's original codec can still take time to prepare the fallback; browsers that can decode it no longer incur that conversion. This fix is on main and requires a build containing the commit above; it was not included in the earlier 0.41.14 release mentioned in this thread.

[rickoh6w-cloud]

Preparing recording for playback… can't play recorder.

[rizkybs70]

New updates performance after 0.41.14 : https://jam.dev/c/f244533a-30ca-4305-b275-f2072821fd33
It's still not as smooth as expected in the previous version

Here is a basic overview of the performance figures for version 0.41.4 : https://jam.dev/c/dfe09ebf-5906-4e4d-b48c-151276ce9c34

For the notes :
My deployment under docker, my camera HEVC

[rickoh6w-cloud]

Released 0.41.14 not work

Back again to Released 0.41.4

[rizkybs70]

The playback regression came from the automatic HEVC conversion path. The recording files are still MP4s; MP4 is the container, and the video inside can be H.264 or H.265/HEVC.

a95eb355 made the playback endpoint convert every HEVC recording to H.264 before serving it, without checking whether the requesting browser could play the original. A cache miss required decoding and re-encoding the entire clip. Concurrent playback requests could launch duplicate FFmpeg processes with large default thread/buffer allocations, explaining the CPU and memory failure mode reported here.

The subsequent OOM fix limited FFmpeg threads/buffering and serialized conversions. That reduced resource use but left playback waiting for a full conversion; requests waiting inside the shared HTTP pool could also delay unrelated APIs. Moving conversion to a background worker removed that HTTP bottleneck, but I preserved the unconditional conversion policy, so the timeline could still spend a long time displaying “Preparing.” That was the wrong default. The separate timeline CI failures were outdated test mocks; correcting those did not address this user-visible delay.

The final fix is 4196b94f, pushed to main:

• Recording, timeline, and investigation players load the original immediately. The normal playback endpoint serves the original with byte-range support and does no codec probing or transcoding.
• Only a browser decode/unsupported-format error triggers a compatibility copy. Network errors and cancelled loads do not start a conversion. Fallback is attempted once, retains the single-worker/thread limits, and stops polling when the user closes playback or changes recordings.
• Timeline regression coverage now uses an actual decodable MP4 with range responses and verifies seeking and playback, rather than only checking the assigned media URL.

Validation: 8 playback-handler C cases, 15 JavaScript playback cases, and 18 browser regression cases passed locally. An HTTP check confirmed that native HEVC playback returns the original bytes and byte ranges without launching FFmpeg. Browsers that cannot decode a recording's original codec can still take time to prepare the fallback; browsers that can decode it no longer incur that conversion. This fix is on main and requires a build containing the commit above; it was not included in the earlier 0.41.14 release mentioned in this thread.

So far, the performance v 0.41.15 has been just as stable as in version 0.41.4; I’ll test it further. If I run into any issues, I’ll let you know.