Derive a playable magnet URI from a stream's infoHash/sources (or
detect an existing magnet/torrent URL) via stream_magnet_link, and
let the offline-download planner accept torrent-sourced streams
instead of rejecting them outright.
The append-to-discover.results step only ran when initial_paging was
active (the internal multi-catalog merge sequence used on first load).
A manual, user-triggered discoverPageRequested dispatch (e.g. infinite
scroll load-more for the single currently-selected catalog) resets
initial_paging to empty in dispatch_discover_page, so its page results
landed only in discover.paging.items and were silently dropped from
discover.results. The recursive dispatch_next_initial_page call stays
gated on initial_paging so the merge-flow behavior is unchanged.
Kotlin's readDiscoverCatalogFilters effect now returns a contentTypes
list (distinct catalog types found across installed addons, e.g.
movie/series/anime), but the effect completion flows back through the
engine's own discover state before Kotlin ever sees it again. Added
content_types to DiscoverState and store it in the completion handler
for readDiscoverCatalogFilters, preserving it across a fresh discover
dispatch the same way catalogs/genres already are.
Lets the platform feed a scraper's getStreams() output straight into
the existing detailStreamsAppended merge path instead of needing a
parallel stream-ranking system for plugin-sourced streams.
Quality/size/provider/seeders/peers ride along in Stream's extra map
since they don't have first-class fields.
Adds a plugins domain to the headless engine (mirrors settings.rs/
offline.rs): pluginRepositoryAddRequested dispatches FetchPluginManifest,
completion upserts the repository and replaces its scrapers; remove and
per-scraper enable/disable are pure local edits. Reuses the existing
addon_store::normalize_plugin_repository_url helper for the URL.
Also fixes EffectKind::from_str missing the executePlugin/
fetchPluginManifest arms added in the previous commit (silently made
those effects undispatchable — completion always fell through as an
unrecognized type) and backfills the as_str/from_str roundtrip test's
variant list, which is supposed to catch exactly that.
ExecutePlugin (actually running scraper JS) is still a no-op in the
engine — that's the native QuickJS runtime work from the desktop-side
spike, not yet connected here.
Mirrors Nuvio's PluginManifest/PluginManifestScraper and the
parseJsonResults normalization from PluginRuntime.kt: validates
manifests (name/version/non-empty scrapers) and tolerantly parses a
plugin's raw getStreams() output (string-or-object url, blank
filtering) into typed results. Exposed via ffi.rs as
pluginManifestParse/pluginStreamResultsParse, and adds
ExecutePlugin/FetchPluginManifest to the effect vocabulary (not yet
wired to an engine completion flow — no-op for now).
A late-resolving refresh from a superseded home load could clobber
continue_watching state written by a newer load, since only the
readHomeBootstrap arm checked the generation counter.
fluxa-desktop was reimplementing several pieces of business logic in
TypeScript instead of delegating to fluxa-core: Trakt/Simkl "similar
titles" response mapping, search/discover source merging, addon HTTP
retry/concurrency/race policy, AnimeSkip episode matching, continue-
watching week partitioning, library merge diffing, and cast/director
link classification. Adds the corresponding pure functions here and
exposes them over ffi so the shell just calls into core and executes.
Phase 0 of the fluxa-android KMP/CMP migration needs an xcframework +
Swift UniFFI bindings for fluxa_core. Adds an "ios" feature (full-api +
uniffi-bindings, no jni/dolby_vision, mirroring the existing "desktop"
feature), a staticlib crate-type for xcframework embedding, a
[bindings.swift] uniffi.toml section, and a macOS-only build script
that produces FluxaCore.xcframework for aarch64-apple-ios and
aarch64-apple-ios-sim.
Verified on Linux: `cargo check --target aarch64-apple-ios --features
ios` and the aarch64-apple-ios-sim equivalent both compile cleanly, so
the crate itself has no Android/JNI-only code leaking into the iOS
feature set. Actual linking/xcframework packaging needs a Mac with
Xcode — untested here.
Resolves trailer video/audio URLs through the engine's effect system
(watch-page config fetch, then player API), pairing the best AVC1
video with the best audio track. Uses the ANDROID_VR client instead
of plain ANDROID since ANDROID-issued CDN URLs are capped to serving
only the first ~8.8MB of a video regardless of request strategy.
Supports fluxa-desktop's synthetic TMDB metadata addon: a static
manifest (catalog + meta resources only, no stream), a genre-name-to-id
catalog URL builder (popular/discover/search, skip mapped to TMDB's
page param), a rich meta mapper that prefers a resolved imdb id and
picks a title logo from TMDB's /images response, and an episode-list
mapper with still_path thumbnails.
merge_progress_meta_json only fell back to the existing value when the
incoming field was JSON null, but an empty string (what a progress
write produces when no metadata addon can resolve artwork) counted as
present and permanently overwrote the good value already on disk.
Treat empty strings the same as null so removing addons temporarily
can't permanently poison a continue-watching entry's artwork.
Discover only ever fetched the first page (typically 20-50 items) of a
catalog and had no way to request more. Add a discoverPageRequested
action, a fetchDiscoverPage effect, and a dedicated DiscoverPaging
generation key so an in-flight "load more" fetch can't clobber a fresh
query (or vice versa) when the user changes catalog/genre mid-fetch.
The catalog picker showed "AddonName | Instance: Catalog Name" instead
of just the catalog name, which is redundant once the addon is already
selected via the type/catalog flow.
anime catalogs were collapsed into "series" during type normalization,
but discover_catalog_options_json compared the raw requested type
against the normalized catalog type, so selecting an "Anime" tab never
matched any catalog. Give anime its own bucket and normalize both
sides of the comparison the same way.
Derives skip segments from anime-skip.com's point-in-time timestamps
by pairing each recognized-type timestamp with the next one, unlike
AniSkip/IntroDB which already provide start/end intervals.
Adds detail.failedAddons, populated from the fetchDetailStreams
completion payload, distinct from availableAddons so a permanently
failed addon (exhausted retries, bad response, etc.) can be shown to
the user as a failure rather than looking identical to "no streams".
Re-requesting streams for the same episode while a fetch is already
running used to bump the generation counter and orphan any addon
results still on the way, so a duplicate click could make a fully
valid addon result silently disappear. Now a duplicate request for the
same content is ignored while one is already in flight, and the
generation is only advanced when the request actually targets
different content.
detailStreamsAppended merged partial addon results as soon as they
arrived, gated only on is_loading_streams. Switching episodes quickly
resets that flag's data but not fast enough to stop a slower addon
response for the previous episode from landing in the new episode's
list. Tag the append with the request generation and drop it if the
active generation has since moved on.
select_next_episode_stream_json picked a stream by bingeGroup equality
(which Torrentio derives from the torrent infoHash alone, so every file
in a season-pack torrent shares one), falling back to the first stream
in the list with no title/filename check either way. A duplicate or
mis-scoped addon entry could win and play the wrong episode.
resolve_next_episode_json's released_only flag was backwards
(released_only || is_episode_released instead of !released_only ||
...), so the "raw next episode" and "released-only next episode"
call sites got each other's behavior. Also add debug timing around
torrent server teardown/bootstrap to help diagnose slow episode
transitions.
The stat-polling "get" action registered a magnet without narrowing
rqbit's only_files to the target index, so progress/readiness could be
driven by unrelated files in the torrent. That let isPlayableEnough
report true before the actual file had any data, handing mpv a stream
URL that wasn't ready yet (Sentry RUST-4). Also re-scope on repeat
lookups of an already-known link so switching files on a shared magnet
(season packs) doesn't keep the first file's scope.
torrent_status_info_json (isPlayableEnough/statusKey/bufferProgress)
existed unreachable from any binding — no ffi.rs arm called it. It's
exactly the policy fluxa-desktop needs to decide when a torrent stream
is actually safe to hand to the player.
is_loading only covered the results fetch, so the frontend had no way
to tell "catalogs still loading" apart from "no catalogs available",
causing a false empty state while addon catalogs were still in flight.
Excluding a catalog entirely whenever it didn't declare genre as a supported
extra was too strict: once genre filtering actually started reaching the
core (previous commit), any user whose installed addons don't declare genre
support at all got zero catalogs and "No content found." Instead, only skip
sending the genre query param to catalogs that don't support it — they still
contribute their normal item list, which then goes through the existing
post-fetch genre filter in discover_sort_plan_json (checks each item's own
genres tag), so mismatched items still get filtered out without starving
the catalog list entirely.
Also switched to the canonical, case-insensitive catalog_supports_extra in
addon_protocol.rs instead of the ad-hoc case-sensitive duplicate added
earlier, matching the pattern already used by search_plan.rs.
Discover was sending genre=X to every installed catalog regardless of
whether its manifest declared genre as a supported extra. Addons commonly
ignore unsupported extras and return their default/unfiltered list, so
picking e.g. "Animation" pulled in unrelated items from catalogs (Action,
Sport, ...) that don't actually support genre filtering.
Episode auto-advance (playerLoadStreamsRequested) was fully decoupled
from progress saving: nothing in the core persisted the outgoing
episode's position/metadata before switching, so it relied entirely on
the host remembering to fire a separate savePlaybackProgressRequested
dispatch first. If the host missed that or the app was killed in the
gap between the two dispatches, the last watched position (and its
season/episode metadata) for the finished episode was lost.
playerLoadStreamsRequested now accepts an optional outgoingProgress
payload; when present and the video id is actually changing,
dispatch_load_streams emits a writePlaybackProgress effect for the
outgoing video in the same response as the stream-load effects, so a
single host dispatch covers both.
lastEpisodeSeason and lastEpisodeNumber were only taken from the
incoming write when the video changed, with no fallback to the
existing value, same flaw as 54e5fff fixed for name/thumbnail. If
an auto-advanced episode's metadata was incomplete, this nulled out
season/number on the continue-watching record, which downstream
consumers then displayed as "Season 0".
lastEpisodeName and lastEpisodeThumbnail were only taken from the
incoming write when the video changed, with no fallback to the
existing value (unlike continueWatchingPoster/Background). If an
auto-advanced episode's metadata was incomplete, this nulled out a
previously-good title/thumbnail on the continue-watching card.
dispatch_load now also fires RefreshContinueWatching alongside
ReadHomeBootstrap, so continueWatching badges (new episode / up next)
can arrive and update state independently instead of only ever coming
from bootstrap.
Note: fluxa-desktop's readHomeBootstrap still computes badges inline
via refreshReleasedContinueWatching, so home load doesn't yet get
faster from this alone — it currently just computes badges twice.
Realizing the perf win needs a follow-up to drop that inline call and
rely solely on the parallel refresh effect.
"anime" is a virtual content-type bucket in Discover that doesn't map
to Stremio's native movie/series type field, so items from
anime-flagged catalogs were being dropped when their underlying type
didn't literally equal "anime". Treat it like the empty-filter case.
