v4.4.1
Release v4.4.1 (2025-12-10)
Quick Links:
π API documentation
-
β― Demo
-
π Migration guide from v3
:mag: Overview
This is a very small patch release we're doing because of a v4.4.0 regression that seemed to impact some applications in various ways.
We did not include new features to ensure this patch release is as stable as possible.
Changelog
Bug fixes
- Fix v4.4.0 regression where the RxPlayer might base itself on the previous content's position [#1758]
- Add resilience to DRM fallback when position is not yet known instead of triggering
MEDIA_TIME_NOT_FOUNDerror [#1755]
Issue when loading several contents without stopping
The v4.4.0 regression this release fixes, brought with the ability of seeking while the RxPlayer hasn't yet loaded the content, led to an internal RxPlayer issue where for a very brief chunk of time it relied on the position from a potential previous content while running its logic for a new content.
Yet because we've built the RxPlayer to be resilient, that issue did not have any effect for most applications.
After a few weeks, one of canal+ application started seeing MEDIA_TIME_NOT_FOUND errors only in multithreaded scenarios and only under a set of time-related conditions. We saw the issue, brought a fix, but thought that it was sufficiently rare, only under the "experimental" MULTI_THREAD feature and had many work-arounds (stopping a content between loads, disabling the MediaKeySession cache etc.) so we thought the impact was limited.
Yet last week, another application had an "infinite loading" issue, linked to the same root cause.
Note that in any case, calling stop before calling loadVideo again totally fixes the issue (as our internal position tracking is reset when a content is stopped).
Anyway, we decided to release the fix in its own patch release on top of v4.4.0 so it can just work as expected under the more efficient strategy of calling loadVideo without stopping first.
We also added resilience to our handling of a position that seems not-right to avoid seeing MEDIA_TIME_NOT_FOUND errors even in similar future scenarios, handling minor, recoverable, state discrepancies gracefully instead.