AndroidDiscoverDataSource duplicated catalog+genre resolution logic
in Kotlin instead of calling discoverSelectionPlan, the same shared
Rust function fluxa-desktop already relies on for this. Route Android
through it too: one implementation for both platforms, and it's more
robust than the Kotlin version since it treats whichever extra a
catalog lists first as the filterable dimension generically, not just
one literally named "genre".
Add DiscoverCatalogOption.extras (carrying each raw catalog extra:
name/options/default/isRequired) and CatalogExtra.default, both
needed for the plan call and previously missing from the addon
manifest models entirely -- the actual bug hunted down across this
and the two preceding core commits was that "default" was dropped at
manifest-parse time in Rust, so no amount of Kotlin plumbing could
have surfaced it.
Catalogs with requiresGenre now pre-select defaultGenre (falling back
to the first available option) instead of leaving the dropdown
looking unselected while discover() silently ran without a genre --
results were already coming back filtered by the addon's own
server-side fallback, but the UI gave no indication why.
The genre dropdown never appeared because loadDiscoverCatalogFilters
-- the only call that fetches real per-catalog genre data -- was
unreachable: the fast local catalog-options path resolved a
catalogKey on almost every call and returned early before ever
reaching it.
Fetch genres in the background right after applying the selected
catalog and kicking off results (matching the existing behavior for
that part exactly, so catalog selection stays instant), instead of
gating catalog selection behind the fetch. Guards on catalogKey
rather than full filter-object equality, since genre/type selections
made while the fetch is in flight shouldn't invalidate it.
MainActivity kept its own currentDestination alongside FluxaAppHost's
internal appState.uiState.destination, with only a one-way sync
(external -> internal). Any purely-internal navigation (bottom nav
taps, "switch profiles" from Settings) moved appState's destination
without MainActivity's copy ever finding out. If a later external
navigation call (e.g. profile selection completing) happened to name
a destination MainActivity's stale copy already equaled, it was
treated as a no-op and silently dropped -- reproducible by going
Settings -> Switch profiles -> tapping a profile, which then did
nothing.
Add a callback that mirrors appState's destination back out to
MainActivity whenever it changes internally, and guard the existing
external->internal effect so it only re-applies on a genuine change
(avoiding a reset loop that would otherwise wipe editingProfile/
selectedDetail/etc. on every round trip).
Also account for showProfilePickerSettings in the screen transition
key, which was missing and left the profile picker settings screen
keyed identically to whatever destination was active underneath it.
Avatar packs were a one-time snapshot from when they were added, so
new images the repo owner pushed later never showed up. Add a
per-pack refresh button in Profile Picker Settings, and re-run
discovery for every saved pack's repository once when the app starts.
Let users customize the "who's watching" screen: add GitHub-hosted
avatar packs to pick profile pictures from, and set a background
image behind the profile grid. The Rust side (GitHub URL/tree/manifest
parsing and validation) already existed in fluxa_core but was never
wired to Kotlin; this adds the FFI wrappers, an OkHttp-driven GitHub
crawl, a small global picker-settings store, and the new/updated
Compose screens. Android only for now — iOS/desktop keep compiling via
default no-op ProfilePersistence methods.
StreamDiscoveryUseCase now bails out early on a null execution plan
instead of relying on per-field null-safe calls. HomeParentsGuideCoordinator
now imports ImdbApiService from its current package.
Notification title now shows the actual episode/show title with the
release kind as subtext, and season/episode text is generated per case
(episode with title, episode without, season-only) instead of one
generic template. Calendar artwork now prefers the episode-specific
poster before falling back to show-level artwork.
Reworks the player's settings sidebar and input controls, adjusts the
sidebar shell layout, and wires the updated sidebars into the playback
surface and screen content.
Surfaces which item is currently being imported (index/total/title)
under each import step on both mobile and TV auth screens, with a
checkmark for completed steps.
- AddonRepository: cache meta detail lookups with in-flight de-dup, and
race addons instead of fanning out to all of them unconditionally,
cutting redundant requests to slow/duplicate addon instances.
- HomeCatalogFeedCoordinator: publish each background catalog row as it
arrives instead of waiting for a whole batch, and support cancelling
in-flight remaining-catalog loads.
- HomeBillboardRuntime: add a pause for rotation/prefetch/trailer work.
- HomeViewModel: pause Home's background billboard/catalog work when
Discover becomes active so it stops competing for the same addons.
- AndroidDiscoverDataSource: skip redundant addon-list recomputation on
catalog-only filter changes, and move card mapping off the main thread.
- FluxaHeadlessEffectRunner/FluxaHeadlessAppRuntime: narrow the runtime
mutex to only guard Rust engine calls, not the network effects they
trigger, so one screen's dispatch can no longer block another's for
the duration of a slow effect chain.
- NetworkModule: raise the shared OkHttp dispatcher's per-host/total
request ceilings.
Add a topNavigationBar appearance toggle that, on TV and non-compact tablet
widths, moves the navigation destinations into a horizontal bar across the top
instead of the TV sidebar, tablet rail, or bottom bar. Thread the flag through
the settings contract, the Android and Apple settings data sources, the user
profile, and both language files, and render the shared FluxaTopNavBar with
focus restoration on TV.
checkSharedUiBoundary was failing on master because the July 17 move of
player overlays into shared/commonMain kept imports of data/player domain
types (Meta, Stream, Video, IntroTimestamps, UserProfile, Chapter,
MediaTrack, TorrentStreamStatus, TrailerCue). Relocate the plain value
types into the shared-safe com.fluxa.app.shared.feature.player package,
and replace the remaining domain-object usages with small UI models
(StreamSourceUiModel, SkipSegmentUiModel, NextEpisodePreviewUiModel)
mapped at the Android call sites. Also drops the dead, UserProfile-only
QuickSettingsSidebar/TrackSidebar composables that had no callers.
Addons now only manages Stremio addons. CloudStream3 repo/plugin state
and the Android-only Nuvio scraper settings screen both move into a new
shared KMP feature (feature/plugins) with a real Android data source
combining PluginRepositoryManager and PluginManager, and an iOS stub
data source pending a follow-up Swift implementation.
Scrapers are now grouped under their owning repository instead of two
separate flat lists, and the screen reuses AddonStoreScreen's visual
language (icon-circle back button, bordered repo cards, icon buttons)
instead of its own bespoke plain-text styling. Adds a refreshRepository
action reusing the existing re-fetch dispatch.
Wire executePluginScraper's updated scraper_id/scraper_settings_json
params through FluxaCoreUniFfi and PluginRepositoryManager, add
getSettingsLayout() to fetch and parse a scraper's onSettings() field
layout into small UI models, and add a gear-icon-triggered bottom
sheet (PluginScraperSettingsSheet) rendering header/info/text/select/
toggle fields, matching Nuvio's real settings schema.
PluginRepositoryManager's headless engine instance was in-memory only, so
installed plugin repositories and disabled/configured scrapers vanished
on every process restart. Now persists repository URLs and per-scraper
enabled/settings overrides to SharedPreferences, and replays them as
headless actions on startup (relying on the Rust-side fix that makes a
repository re-fetch preserve existing overrides instead of resetting to
manifest defaults).
Also adds updateScraperSettings(), used by the persistence replay and by
the upcoming per-scraper settings UI.
fluxa_core already emitted these for plugin-sourced streams, but Gson
silently dropped them since Stream had no matching properties. Renamed
the existing getHeaders() to resolveHeaders() to avoid a JVM signature
clash with the new headers property, and merged it into the raw
behaviorHints-derived headers.
Implements PluginHttpClient over OkHttp with SSRF guarding (PluginNetGuard),
wires the FetchPluginManifest effect, adds PluginRepositoryManager for
repository/scraper state, folds plugin-scraper streams into
StreamDiscoveryUseCase, and adds a Plugins settings screen.
fluxa-core's plugin-js-engine feature now generates rquickjs FFI
bindings via bindgen instead of relying on prebuilt binding files,
since rquickjs-sys ships none for any Android target. Export
LIBCLANG_PATH (from the NDK's own libclang) and
BINDGEN_EXTRA_CLANG_ARGS (NDK sysroot, matching clang resource-dir,
and the concrete clang target triple) alongside the existing
CC/AR/linker env vars in each buildFluxaCore<Abi> task, so bindgen
resolves Android headers instead of falling back to the host's.
StremioAddonManifestClient, StremioAddonResourceClient, and the trailer
effect in FluxaAndroidHeadlessEnvironment each hand-rolled the same
Request.Builder -> execute -> read status/body -> catch pattern. One
shared executor now backs all three call sites.
New setting under Settings > Appearance > Home Screen: when enabled,
Continue Watching items whose next episode/season hasn't released yet
move into their own Upcoming row instead of sitting in Continue
Watching with nothing to resume.
Classification runs async per up-next series item (no active playback
progress): HomeContinueWatchingCoordinator resolves the specific
lastVideoId episode via the existing getSeasonEpisodes fetch, checks
its release date through the new isEpisodeReleased FFI call, and
caches the result by id:lastVideoId. Once known, it triggers a
dynamic-rows refresh so the split applies without blocking the
initial Home paint.
HomeCatalogFeedCoordinator/HomeDynamicRowsCoordinator partition the
Continue Watching list into continue_watching/upcoming HomeCategory
rows via the new isUpcoming lambda, gated by
UserProfile.upcomingRowEnabled (resolved through the Rust safe-prefs
struct like every other appearance toggle). HomeCategoryPolicy's
isContinueWatchingCategory()-gated behavior (card layout, action-row
treatment, title passthrough) now also covers the upcoming row so it
renders with the same horizontal episode-card treatment.
androidFluxaPlatformServices was only built for DeviceType.Mobile, but
AppRoutesHost always force-unwraps it, so the TV build crashed with an
NPE on every launch.
New opt-in Appearance toggle (default off), mirroring how amoledMode
is wired through UserProfile and both settings data sources. Enabling
it swaps the nav bar's flat fill for a translucent frosted surface
with a soft top-light gradient and a hairline glass-edge border.
Both sources fed the same skip-segments pipeline and were always
toggled together in practice, so collapse them into a single
useSkipSegments flag on SettingsPlaybackUiModel. Both the Android and
Apple settings data sources still write/read the two underlying
useIntroDb/useAniSkip flags in lockstep, so the merge stays UI-level
and existing profiles keep working.
imdbapi.dev moved its base URL; also drops the now-dead
ImdbApiService.create() factory since HomeViewModel already gets its
instance through Hilt DI in NetworkModule.
Adds contentWarningsEnabled to the playback settings model, defaulting
to true, and gates both the parents-guide fetch and the overlay
display in PlayerScreen behind it.
Adds trailerUrl to DetailUiState and DetailUiModel so the detail
screen's data source can pass the resolved trailer through, and
adds the missing HeroPageChanged branch to CatalogHomeStore's
no-op action list.
Home Screen and Detail Screen settings now split into dedicated
sub-pages (Hero Banner, Continue Watching, Navigation for Home;
Hero Banner, Episodes for Detail) instead of one long mixed page,
so a specific setting is reachable by name instead of scrolling.
Also removes the dead "Trailer on Hero" toggle in Detail Screen
settings, which persisted a value but was never read by any
consuming code — it just duplicated the real "Trailer on Detail
Hero" setting and caused exactly this kind of navigation confusion.
MkvChapterFetcher's fixed prefix scan missed Chapters on releases where
it sits past the first Cluster (e.g. large embedded attachments pushing
it ~10MB in on one observed torrent release). Wire up the new
parseMkvChaptersAtOffsetNative bridge and the seekOffset the Rust
parser now reports: when Chapters isn't in the initial head fetch,
follow the SeekHead-derived offset with one small targeted range fetch
instead. Shrink the initial fetch from a 4MB prefix guess down to 64KB
now that it only needs to cover the (always compact, near-the-front)
SeekHead rather than hoping Chapters itself falls within it.
Add unitTests.isReturnDefaultValues so android.util.Log calls in
Robolectric-less JVM unit tests don't throw, and a regression test
covering the SeekHead follow-up path end to end.
- Route YouTube trailer resolution through the shared headless engine
(headless_engine/trailer.rs) instead of a hand-rolled Innertube client
in TrailerResolver, mirroring what fluxa-desktop already does. Wire
the two HTTP effect kinds (fetchYoutubeTrailerWatchConfig/Player) as a
generic passthrough in FluxaAndroidHeadlessEnvironment.
- Wire HeroTrailerVideoSurface's ExoPlayer through
TrailerResolver.mediaDataSourceFactory() so trailer playback actually
gets the browser UA + Range header YouTube's CDN requires — this was
the root cause of the black-screen hero trailer.
- Fix AndroidCatalogHomeDataSource pinning the active billboard movie to
index 0 of heroItems on every index change, which desynced the pager's
page index from item identity and made forward swipes visually snap
back to the previous item.
- Hide synopsis/metadata/play button and shrink the logo while a hero
trailer plays, soften the bottom scrim so it doesn't black out most of
the video, and add trailer subtitles (selection/normalize/parse) via
the same fluxa-core functions fluxa-desktop uses, rendered as a
position-synced overlay above the shrunk logo.
MkvChapterFetcher sent bare stream headers instead of routing through
StreamRequestPolicy (default User-Agent, referer), which many origins
require to respond to a Range request at all — unlike mpv, which always
gets proper headers. Also bail out instead of buffering an unbounded
body when a server ignores the Range header and returns 200 with the
full file.
Add MkvChapterFetcherTest using MockWebServer, exercising the real path
end-to-end (headers, 206 handling, JNI EBML parsing) on the JVM without
an emulator.
LibraryItem never declared removed/_mtime so those fields were
silently dropped by Gson before Rust ever saw them, even though
library_state.rs already worked on raw JSON and could have used them.
Adds the fields, StremioRepository.getLibraryWatchlistWithTimestamps,
and wires it into the same mergeWatchlist reconciliation the other
providers use -- but pull-only (reconcileWatchlistPullOnly), not the
full push-capable path.
Deliberately not pushing local watchlist changes to Stremio: that
would need a "toggle membership" write that preserves whatever
progress/state fields already exist on the remote item (a
read-modify-write), which isn't built and isn't safe to guess at
without being able to verify Stremio's actual datastore PUT semantics
(full-replace vs partial-patch) against a live account.
The AniList GraphQL query only ever fetched status: CURRENT, so the
watchlist-add push added in the AniList phase had nothing to
reconcile against on the next sync -- pushed items would just get
re-pushed or silently diverge. Drops the CURRENT-only filter (Rust's
anilist_entries_to_sync already builds a timestamped watchlist array
from PLANNING entries, just needed the query to actually fetch them)
and wires it through the same mergeWatchlist reconciliation Trakt
uses. Generalizes reconcileTraktWatchlist -> reconcileWatchlist since
the logic is fully provider-agnostic.
Simkl mark-watched push existed but nothing was ever pulled back --
marking an episode watched on simkl.com never reached Fluxa. Simkl's
sync/all-items already returns per-episode watched_at when fetched
with extended=full (already the default), just unused until now.
Adds getSimklWatchedEpisodesWithTimestamps (watching+completed status,
shows+anime types) and generalizes the Trakt watched-episode
reconciliation (reconcileTraktWatched -> reconcileWatchedEpisodes)
since the merge logic and push path are provider-agnostic -- both
Trakt and Simkl now call the same function.
Simkl's sync/all-items endpoint has no "added to list" timestamp
(last_watched_at is watch-history, not list-membership, and is null
for plantowatch items) so a real timestamp merge like Trakt's isn't
possible without risking local removals being silently undone by a
fabricated timestamp. Per explicit decision: items on Simkl's
plantowatch list are treated as authoritative and always restored
locally each sync, overriding any local removal tombstone. Removing
something from Simkl's own list doesn't remove it locally -- that
would need a persisted prior-snapshot to detect, out of scope here.
Trakt's watched-state pull only ever wrote into the external mirror
table for display; local watched_episodes and Trakt's remote state
were never compared or reconciled, so un-marking an episode locally
never propagated and remote-only watched episodes never landed
locally. Trakt's watched-shows response already carries per-episode
last_watched_at, just unused until now.
Adds getWatchedEpisodesWithTimestamps (parses last_watched_at),
global (not per-series) local watched-episode/removal snapshot
queries, and reuses the mergeWatched core_invoke method (Phase 1) to
decide push vs. apply per composite episode id, mirroring the
watchlist reconciliation pattern.
StremioRepository.savePlaybackProgress was fire-and-forget on the
calling coroutine at both call sites (HomePlaybackController and the
writePlaybackProgress headless effect) — an app kill mid-request
silently dropped the push with no retry, unlike Trakt/Simkl scrobble
and Nuvio's progress push which are all worker-backed.
Adds StremioPlaybackProgressPushWorker on the ProviderSyncPushWorker
base, keyed by profileId+contentId same as Nuvio's so rapid saves
coalesce via ExistingWorkPolicy.REPLACE. savePlaybackProgress now
returns Boolean instead of swallowing failure, since the worker needs
to know whether to retry.
TraktScrobbleWorker, SimklScrobbleWorker, and NuvioPlaybackProgressPushWorker
had hand-copied WorkManager boilerplate: identical Constraints/backoff
policy, enqueueUniqueWork wiring, and profile-lookup/failure-bookkeeping
against ProfileManager. Behavior-preserving refactor onto a common base
so the next durable workers (Stremio, Simkl watchlist, AniList) don't
duplicate it a fourth and fifth time.
Trakt's watchlist pull previously fed only a live, un-timestamped,
display-only union in HomeLibraryCoordinator/AndroidLibraryDataSource
(distinctBy id, recomputed on every emission, never persisted or
pushed back). This wires it into the Phase 0/1 groundwork instead:
- TraktSyncItem now parses listed_at, exposed via
TraktSyncClient.getWatchlistWithListedAt / TraktRepository
- ExternalSyncMergeBridge wraps the mergeWatchlistTimestamped
core_invoke call for Kotlin callers
- WatchlistManager gains a local membership snapshot (active entries +
removal tombstones) and applyRemoteWatchlistAdd
- HomeLibraryCoordinator.load() now reconciles Trakt's remote
watchlist against the local one after each fetch: items the merge
says are locally newer get pushed via the existing
ExternalSyncPushCoordinator.pushWatchlist, items remote is newer on
get applied into the local watchlist_entries table
Simkl and Stremio are follow-up work — their fetch shapes differ
(Simkl has no true watchlist endpoint, Stremio's is a unified
datastore blob) and need separate integration passes.
Both only ever read id/type/seasonsCount from the 39-field Meta model,
in violation of the leaf-UI-gets-narrow-models rule in CLAUDE.md.
Adds seasonsCount to the existing PlayerContentUiModel (already
computed once via meta.toPlayerContentUiModel() at the top of
PlayerScreenContent) and threads that through instead.
The other Player files that take a Meta parameter (PlayerLoadingEffects,
PlayerTrackMemoryEffects, PlayerPipAndEpisodes, etc.) are LaunchedEffect
wrappers that hand Meta straight to ViewModel/repository calls for
persistence and scrobbling — that's the "effects/coordinators" layer
CLAUDE.md explicitly allows to hold domain objects, not a violation.
Adds a per-profile continue-watching source preference (Fluxa/Stremio/
Nuvio/Trakt/Simkl/AniList), a background worker to push playback
progress to Nuvio instead of pushing inline, dedup of mark-watched
pushes against already-watched episodes, and general Nuvio account
import/merge fixes.
