• v0.6.0 8e98e1c37a

    JellyTau v0.6.0
    🏗️ Build and Test JellyTau / Run Tests (push) Successful in 22m57s
    Publish Documentation / Build & publish docs to gitea-pages (push) Successful in 5m50s
    Traceability Validation / Check Requirement Traces (push) Successful in 24s
    Build & Release / Run Tests (push) Successful in 7m21s
    🏗️ Build and Test JellyTau / Android Compile Check (push) Successful in 10m3s
    Build & Release / Build Linux (push) Successful in 20m32s
    Build & Release / Build Windows (push) Successful in 14m29s
    Build & Release / Build Android (push) Successful in 31m5s
    Build & Release / Create Release (push) Successful in 12s
    Stable

    dtourolle released this 2026-08-16 19:24:34 +00:00 | 102 commits to master since this release

    🐛 Fixes

    • Android native video actually shows a picture. It shipped once as audio
      with no picture
      and was reverted with the compositing named as the suspect
      (DR-172). The compositing was not at fault; five independent defects sat
      between ExoPlayer and the screen, each able to produce that symptom alone. The
      app shell painted over the video surface through a CSS rule targeting
      [data-app-shell], an attribute no component had ever set in any commit
      (DR-185). The poster/title card had no way to lift on a path that renders no
      <video> element, so a black card covered the surface for the whole session
      (DR-182). The JavaScript bridges were installed by a 500 ms tree walk that
      raced the page load — and lost permanently when it lost, because the
      re-injection guard then declined to retry — so setTransparent(true) could
      never arrive (DR-183). The SurfaceView was never detached, leaking one per
      video and leaving picture-in-picture's gate stuck open (DR-184). Verified on a
      device: logcat now carries WebView transparent = true and
      Marking media ready with video on screen, the pair the original
      investigation went looking for and could not find.
      (UR-003, UR-004, UR-041 → DR-182, DR-183, DR-184, DR-185)

    • Play and pause reach the player that is actually rendering. Transport did
      nothing on the native video path — from the on-screen tap, from the control
      bar, and from a direct command invocation — while seek and skip kept working,
      because those decide elsewhere. Rust routes play/pause to the webview <video>
      whenever it believes one is active, and the player route mirrored element state
      into that belief unconditionally, including from a ten-second progress
      interval. So on the native path the frontend re-declared every ten seconds that
      an element was playing when none existed, and every intent was emitted at
      something that was not there. The mirror now lives where useHtml5Element is
      known. This also explains the flashing transport controls, since they key off
      the play state that was being contradicted on every tick.
      (UR-005, UR-003 → DR-193, DR-195)

    • The player's controls hide themselves on a touchscreen. The auto-hide timer
      was armed only from mousemove, which a touch device never fires, so the
      control bar stayed over the video for the whole film. It is now armed on entry
      and on every touch, and pinned open while paused, seeking, or with a menu open.
      (UR-003, UR-066 → DR-189)

    • The system bars go away with the player. Immersive mode had exactly one
      caller — the fullscreen button — so opening a video left the status and
      navigation bars painted over it until the user pressed a control most never
      press. (UR-066, UR-003 → DR-187)

    🔬 Internal

    • Native video presents through a TextureView rather than a SurfaceView. A
      SurfaceView renders on its own layer outside the app window and punches a
      transparent region through it, and Android's own graphics documentation warns
      that overlays do not composite reliably above one. (UR-003, UR-004 → DR-192)

    • Native Android video remains opt-in, and is not yet the default. Turning it
      on surfaced a further unverified path: returning from background audio is
      implemented only for the webview element, so playback stays dead on the native
      path (DR-190, proposed). Rotation still needs device confirmation (DR-194).
      (UR-003 → DR-188)

    Downloads

    Platform File
    Android jellytau-release.apk — sideload or adb install
    Windows (portable) jellytau.exe
    Linux (Debian/Ubuntu) jellytau_0.6.0_amd64.debsudo dpkg -i
    Windows jellytau_0.6.0_x64-setup.exe (NSIS installer)

    Report a problem: https://gitea.tourolle.paris/dtourolle/jellytau/issues

    Downloads