Summary
Creating a second profile (for example, one per device) currently produces a blank slate. A partial inheritance mechanism already exists, the "Use Primary Addons" toggle, but plugins, API keys, and all other profile-scoped settings do not follow it. As a result, setting up a new profile requires re-adding every addon, re-entering every API key (TMDB, MDBList, debrid), re-adding plugin repositories, and re-configuring catalogs. For users who want device-specific profiles, the setup cost is high enough that most will just share one profile instead.
Current behavior (0.1.22-alpha, verified against source)
What already works:
- Profiles expose a
usesPrimaryAddons flag, editable in the profile editor ("Use Primary Addons" / "Share the main profile's addon setup instead of managing a separate list").
AddonRepository honors it: resolveEffectiveProfileId() resolves a secondary profile with the flag enabled to profile 1, so the addon list is shared.
What does not:
usesPrimaryPlugins exists in the profile model (ProfilePushPayload) but is never read by PluginRepository, so plugin repos are not inherited. It appears to be an unfinished sibling of the addons feature.- No other profile-scoped state honors the flag: TMDB settings (
TmdbSettingsRepository), MDBList, debrid settings (API key, resolver), home catalog settings, player settings, and per-addon configurations are all keyed per profile via ProfileScopedKey and start empty for a new profile.
- There is no "clone from existing profile" or "duplicate profile" action.
ProfileRepository.createProfile() only accepts name/avatar/flags.
Reproduction: create a new profile on an account whose primary profile has nine addons, plugin repos, a TMDB API key, and a debrid key configured. Switch to the new profile. With "Use Primary Addons" enabled the addons appear; the TMDB key, debrid key, plugin repos, and catalog settings do not, and without the TMDB key TMDB-based scrapers fail silently (all catalog pages carry IMDB ids; Nuvio's id conversion requires the user TMDB key).
Why this matters
Two common setups both hit this:
- One profile per device (TV stays "clean", desktop accumulates history). The profile is the natural unit for this, but inheriting the stack costs a full re-setup.
- Family/kids profiles. Parents curate the primary profile; a kids profile should inherit it and then optionally prune.
In both cases the practical workaround today is sharing a single profile across devices, which mixes watch progress, exactly what profiles exist to prevent.
Proposed options (either alone would close the gap)
Option A: finish the inheritance pattern. The plumbing exists (resolveEffectiveProfileId in AddonRepository is a clean precedent). Apply the same pattern to:
PluginRepository (consume the already-modeled usesPrimaryPlugins flag)- Settings repositories: TMDB, MDBList, debrid, player, home catalogs
Optionally rename/re-scope the toggle to something like "Use primary profile's configuration" so users understand keys follow too. Privacy-sensitive per-profile credentials (e.g. an account's debrid key) would be shared intentionally by the user, which matches the existing single-account trust model.
Option B: profile cloning. Add a "Duplicate from" selector in the profile editor that copies profile-scoped state server-side at creation time. This fits users who want a snapshot (independent copy that then diverges) rather than a live share. It would reuse the existing sync payloads; createProfile() would push cloned scoped data for the new profile index.
A and B compose: inheritance for "follow the main profile", cloning for "start the same, diverge later".
Implementation notes gathered while verifying
ProfileScopedKey.of(baseKey) = "{baseKey}_{activeProfileId}" (core/storage/ProfileScopedKey.kt); it is the single choke point where scoped settings are keyed, so inheritance hooks can live next to it.- The addon fallback behavior is relevant to cloning: on launch, when the server returns an empty addon list for a profile,
AddonRepository.pullFromServer keeps the local list; with a server-side clone, this fallback never triggers.
- Verified against 0.1.22-alpha (commit near current
main at the time of writing); main had no changes to the profile system.
Happy to test any candidate build against a two-device (desktop + Android TV) setup.
Summary
Creating a second profile (for example, one per device) currently produces a blank slate. A partial inheritance mechanism already exists, the "Use Primary Addons" toggle, but plugins, API keys, and all other profile-scoped settings do not follow it. As a result, setting up a new profile requires re-adding every addon, re-entering every API key (TMDB, MDBList, debrid), re-adding plugin repositories, and re-configuring catalogs. For users who want device-specific profiles, the setup cost is high enough that most will just share one profile instead.
Current behavior (0.1.22-alpha, verified against source)
What already works:
usesPrimaryAddonsflag, editable in the profile editor ("Use Primary Addons" / "Share the main profile's addon setup instead of managing a separate list").AddonRepositoryhonors it:resolveEffectiveProfileId()resolves a secondary profile with the flag enabled to profile 1, so the addon list is shared.What does not:
usesPrimaryPluginsexists in the profile model (ProfilePushPayload) but is never read byPluginRepository, so plugin repos are not inherited. It appears to be an unfinished sibling of the addons feature.TmdbSettingsRepository), MDBList, debrid settings (API key, resolver), home catalog settings, player settings, and per-addon configurations are all keyed per profile viaProfileScopedKeyand start empty for a new profile.ProfileRepository.createProfile()only accepts name/avatar/flags.Reproduction: create a new profile on an account whose primary profile has nine addons, plugin repos, a TMDB API key, and a debrid key configured. Switch to the new profile. With "Use Primary Addons" enabled the addons appear; the TMDB key, debrid key, plugin repos, and catalog settings do not, and without the TMDB key TMDB-based scrapers fail silently (all catalog pages carry IMDB ids; Nuvio's id conversion requires the user TMDB key).
Why this matters
Two common setups both hit this:
In both cases the practical workaround today is sharing a single profile across devices, which mixes watch progress, exactly what profiles exist to prevent.
Proposed options (either alone would close the gap)
Option A: finish the inheritance pattern. The plumbing exists (
resolveEffectiveProfileIdinAddonRepositoryis a clean precedent). Apply the same pattern to:PluginRepository(consume the already-modeledusesPrimaryPluginsflag)Optionally rename/re-scope the toggle to something like "Use primary profile's configuration" so users understand keys follow too. Privacy-sensitive per-profile credentials (e.g. an account's debrid key) would be shared intentionally by the user, which matches the existing single-account trust model.
Option B: profile cloning. Add a "Duplicate from" selector in the profile editor that copies profile-scoped state server-side at creation time. This fits users who want a snapshot (independent copy that then diverges) rather than a live share. It would reuse the existing sync payloads;
createProfile()would push cloned scoped data for the new profile index.A and B compose: inheritance for "follow the main profile", cloning for "start the same, diverge later".
Implementation notes gathered while verifying
ProfileScopedKey.of(baseKey)="{baseKey}_{activeProfileId}"(core/storage/ProfileScopedKey.kt); it is the single choke point where scoped settings are keyed, so inheritance hooks can live next to it.AddonRepository.pullFromServerkeeps the local list; with a server-side clone, this fallback never triggers.mainat the time of writing);mainhad no changes to the profile system.Happy to test any candidate build against a two-device (desktop + Android TV) setup.