feat(offline): play downloaded video, and drain the offline sync queue (0.4.6)
🏗️ Build and Test JellyTau / Run Tests (push) Successful in 20m34s
Publish Documentation / Build & publish docs to gitea-pages (push) Successful in 6m6s
Traceability Validation / Check Requirement Traces (push) Successful in 18s
Build & Release / Run Tests (push) Successful in 20m26s
🏗️ Build and Test JellyTau / Android Compile Check (push) Successful in 10m3s
Build & Release / Build Linux (push) Successful in 37m59s
Build & Release / Build Windows (push) Successful in 23m0s
Build & Release / Build Android (push) Successful in 40m26s
Build & Release / Create Release (push) Successful in 1m20s

Bundles this session's work plus the concurrent search/offline/player changes.
Every gate passes on the combined tree: 885 frontend tests, 610 Rust tests,
clippy clean, boundary clean, trace coverage 86%.

Offline video playback — four separate defects, each of which alone stopped it:

  DR-133  A completed download's file_path is already absolute (the worker
          rewrites it on completion), but the player rooted it a second time and
          handed the webview /data/user/0/app//data/user/0/app/videos/x.mp4.
  DR-134  The asset protocol was never enabled: no protocol-asset feature and no
          assetProtocol config, so convertFileSrc produced URLs nothing answered.
          Also silently defeated the cached-thumbnail path, which fails soft to
          the server copy and hid it whenever the server was reachable.
  DR-137  Tauri's asset protocol answers a range-less request by reading the
          whole file into memory, and only advertises Accept-Ranges from inside
          its range branch, so the first request never learns ranges exist.
          Chromium gave up with PIPELINE_ERROR_READ after ~31s. Local media is
          now served by a loopback HTTP server: bounded 4 MiB chunks streamed
          from the file handle, every response length-delimited, and a range-less
          request answered with one chunk rather than the file. Confined by a
          per-session token and to the app data directory, because loopback is
          shared between apps on Android.
  DR-138  Release builds set usesCleartextTraffic=false, so Android rejected the
          request to that server before any I/O. A network-security-config
          exempts 127.0.0.1 only; a remote server must still be HTTPS.

Downloads:

  DR-135  download_item never records media_type and the reconnect resolver read
          that NULL as 'audio', so a movie queued from a media card had its URL
          resolved by get_audio_stream_url and completed as an audio-only
          transcode. The item's own type now decides.
  DR-136  Rows already downloaded that way are requeued on reconnect, since
          prevention alone leaves them reading "downloaded" and still unplayable.

Known limitation: a download taken at `original` quality is a byte copy of the
source, so it can be any container. One such file is an AVI holding XVID, which
the webview cannot play in any case — the media server serves it correctly and
Chromium refuses it. That needs either a transcoded download preset or the
native ExoPlayer surface work, and is not addressed here.

Also fixes two ID collisions between concurrent work: DR-143 defined twice
(search vs offline gate) and UT-131 defined twice (Episode Focus hero vs channel
cap). The search requirement is now DR-147 and the channel-cap test UT-141, with
their code references and matrix rows updated.
This commit is contained in:
2026-08-09 16:38:07 +02:00
parent 7b531a40be
commit 1b70926c36
58 changed files with 8130 additions and 2347 deletions
+29 -15
View File
@@ -2,7 +2,9 @@
//!
//! The sync queue stores mutations (favorites, playback progress, etc.)
//! that need to be synced to the Jellyfin server when connectivity is restored.
//! TRACES: UR-002, UR-017, UR-025 | DR-014
//! Draining it lives in `sync_drain` (DR-131); this module is the storage and
//! read side the UI lists from (DR-132).
//! TRACES: UR-002, UR-017, UR-025 | DR-014, DR-131, DR-132
use serde::{Deserialize, Serialize};
use std::sync::Arc;
@@ -24,6 +26,12 @@ pub struct SyncQueueItem {
pub retry_count: i32,
pub created_at: Option<String>,
pub error_message: Option<String>,
/// Cached title of the item the operation is about, when the catalog knows
/// it. Resolved here rather than by a per-row frontend fetch — the queue
/// list is otherwise a wall of opaque ids.
///
/// TRACES: UR-025 | DR-132
pub item_name: Option<String>,
}
/// Queue a mutation for sync to server
@@ -74,20 +82,20 @@ pub async fn sync_get_pending(
Arc::new(database.service())
};
let sql = if let Some(l) = limit {
format!(
"SELECT id, user_id, operation, item_id, payload, status, retry_count, created_at, error_message
FROM sync_queue
WHERE user_id = ? AND status IN ('pending', 'failed')
ORDER BY created_at ASC
LIMIT {}",
l
)
} else {
"SELECT id, user_id, operation, item_id, payload, status, retry_count, created_at, error_message
FROM sync_queue
WHERE user_id = ? AND status IN ('pending', 'failed')
ORDER BY created_at ASC".to_string()
// The `items` join names the queued item where the catalog has it; a row for
// an item that was never cached still lists, with a null name.
// `abandoned` rows (DR-131 gave up on them) are excluded here for the same
// reason they are excluded from the count — they are no longer waiting.
const SELECT: &str = "SELECT q.id, q.user_id, q.operation, q.item_id, q.payload, q.status,
COALESCE(q.retry_count, 0), q.created_at, q.error_message, i.name
FROM sync_queue q
LEFT JOIN items i ON i.id = q.item_id
WHERE q.user_id = ? AND q.status IN ('pending', 'failed')
ORDER BY q.created_at ASC, q.id ASC";
let sql = match limit {
Some(l) => format!("{} LIMIT {}", SELECT, l),
None => SELECT.to_string(),
};
let query = Query::with_params(sql, vec![QueryParam::String(user_id)]);
@@ -104,6 +112,7 @@ pub async fn sync_get_pending(
retry_count: row.get(6)?,
created_at: row.get(7)?,
error_message: row.get(8)?,
item_name: row.get(9)?,
})
})
.await
@@ -256,6 +265,7 @@ mod tests {
retry_count: 0,
created_at: Some("2024-02-14T08:00:00Z".to_string()),
error_message: None,
item_name: None,
};
// Should serialize successfully
@@ -280,6 +290,7 @@ mod tests {
retry_count: 3,
created_at: Some("2024-02-14T07:00:00Z".to_string()),
error_message: Some("Connection timeout".to_string()),
item_name: None,
};
let json = serde_json::to_string(&item).unwrap();
@@ -300,6 +311,7 @@ mod tests {
retry_count: 0,
created_at: None,
error_message: None,
item_name: None,
};
let json = serde_json::to_string(&item).unwrap();
@@ -323,6 +335,7 @@ mod tests {
retry_count: 0,
created_at: None,
error_message: None,
item_name: None,
};
let json = serde_json::to_string(&item).unwrap();
@@ -363,6 +376,7 @@ mod tests {
retry_count: 0,
created_at: None,
error_message: None,
item_name: None,
};
// Simulate retries