Skip to content

Round-trip Seerr discover sliders in homeSections - #286

Closed
selmant wants to merge 6 commits into
Moonfin-Client:masterfrom
selmant:feat/seerr-slider-home-kind
Closed

selmant wants to merge 6 commits into
Moonfin-Client:masterfrom
selmant:feat/seerr-slider-home-kind

Conversation

@selmant

@selmant selmant commented Sep 12, 2026

Copy link
Copy Markdown

Pull Request

Summary

Supersedes draft #280. Companion client: Moonfin-Core #1520, which replaces closed Moonfin-Core #1407.

Persist Seerr discover sliders in homeSections as kind: seerrSlider (sliderId / sliderType) instead of a plugin type table. List any discover type n >= 1 (stock 1–12 and admin custom 13+). Unknown types stay displayable; Core decides what to fetch. One-shot migrate rewrites stored seerr_trending / seerr_shortcuts (and the other deleted seerr_* home types) into sliders, including homeRowOrder-only profiles so those rows are not dropped. Foreseerr is not in this PR.

The Jellyfin Seerr home-layout tab only treats Seerr slider rows as Seerr, matching Emby, so Radarr/Sonarr calendars stay off that tab.

Related Issues

Type of Change

  • Bug fix
  • New feature
  • Refactor
  • Performance improvement
  • API / endpoint change
  • Settings schema change
  • Documentation update
  • Build/CI change
  • Other (describe):

Area

  • Settings sync / profiles
  • Admin defaults / config page
  • Ratings (MDBList / TMDB)
  • Notifications / Push (FCM / relay)
  • Seerr integration
  • Games / Emulators
  • Custom home rows
  • Web Client (Go to Moonfin-Core repo)
  • Other / shared

Changes Made

  • Additive sliderId / sliderType on home section config for Jellyfin and Emby.
  • Admin JS round-trips discover sliders as kind: seerrSlider without a type enum. Unbound rows (sliderType only) keep a stable key.
  • List any discover slider with type >= 1. Shortcuts are a Moonfin-only candidate (sliderId: shortcuts), not a DiscoverSliderType.
  • One-shot MigrateSeerrHomeSections on load/save: rewrite deleted seerr_* types, unbind leftover legacy: ids, and convert homeRowOrder seerr_* names into homeSections sliders instead of deleting them.
  • Derive homeRowOrder from builtin sections only (skip seerr_slider).
  • Jellyfin Seerr tab uses the same Seerr-only rule as Emby (no Radarr/Sonarr there).

Client Impact

Does this need matching changes in a client repo (Core, Smart-TV, Roku)?

  • No client changes needed
  • Companion client PR(s) required, linked here: Persist Seerr discover sliders as Home kind seerrSlider Moonfin-Core#1520
  • New setting keys added. List each key and confirm it matches the client key exactly, including casing:
    • sliderId (string)
    • sliderType (int)
    • kind: seerrSlider on homeSections entries
    • type: seerr_slider wire type for those entries

Compatibility

  • Change to the settings profile is additive only, no renamed or removed properties
  • New properties use the same type the client sends (a client bool maps to bool?, an int to int?)
  • Migration added for any renamed or removed settings
  • Older clients still work, unknown fields are ignored and no keys were removed

The deleted seerr_* builtin names are rewritten to sliders on load/save. Older clients that ignore kind: seerrSlider still round-trip the extra fields.

Testing

Describe how this change was tested.

  • Built the plugin and deployed to a Jellyfin server
  • Verified against a live client (which one: Moonfin-Core Linux desktop on feat/seerr-slider-home-kind)
  • Manual testing completed
  • Not tested (explain why):

Test Steps

  1. Open Dashboard → Moonbase → Home layout / Seerr and confirm discover sliders list (types 1–12 and 13+), plus Seerr Browse.
  2. Enable a slider, save, and confirm homeSections stores kind: seerrSlider with sliderId / sliderType.
  3. Load a profile that still has seerr_trending in homeSections or only in homeRowOrder. Confirm it becomes a slider and is not dropped.
  4. Confirm Radarr/Sonarr rows do not appear on the Jellyfin Seerr tab.
  5. Confirm a Moonfin client on Core #1520 can show enabled slider rows on Home.

Screenshots (if applicable)

Checklist

  • Code builds successfully
  • Code follows project style and conventions
  • No unnecessary commented-out code
  • No new warnings introduced
  • Any new setting keys match the client-side keys exactly

Made with Cursor

selmant and others added 5 commits September 12, 2026 16:40
…e table

Persist sliderId and sliderType, keep disabled stubs, and only emit builtins in homeRowOrder so Moonbase does not strip slider identity.

Co-authored-by: Cursor <cursoragent@cursor.com>
Match Emby: only types that start with seerr_ belong there. Rename isSeerrCustomSliderType to isSeerrSliderType.

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Stop listing deleted seerr_* builtins in the layout editor. Rewrite saved profiles on load/save so those type strings become seerr_slider rows.

Co-authored-by: Cursor <cursoragent@cursor.com>
Turn leftover seerr_* order names into homeSections instead of dropping them, and list any discover type n >= 1.

Co-authored-by: Cursor <cursoragent@cursor.com>
@github-actions

github-actions Bot commented Sep 22, 2026 •

Copy link
Copy Markdown

Build Successful

Both plugins compiled against .NET 8, and both test suites passed.

Property Value
Commit ee8163f
Jellyfin ABI 10.10.0.0
Emby version 2.2.0.0
Workflow Build #436

…y layout when migrating Seerr rows into homeSections and to label stock Seerr sliders by name in the home layout editor
@selmant

selmant commented Sep 28, 2026

Copy link
Copy Markdown
Author

I didn’t realize when I started implementing this that the change would require coordinated updates across so many clients/components and would need this much care to avoid breaking existing behavior.

Would you prefer that I reconsider the architecture and try to make the change completely additive/non-destructive instead? I think I may be able to keep the existing behavior/schema intact and add the new slider support alongside it, with a couple of compatibility workarounds where needed.

It might be a little less clean internally, but if it avoids requiring immediate changes across Core, Smart-TV, Roku, etc., that may be the better trade-off. Let me know what you think before I go further with the current approach.

@RadicalMuffinMan

Copy link
Copy Markdown
Contributor

I didn’t realize when I started implementing this that the change would require coordinated updates across so many clients/components and would need this much care to avoid breaking existing behavior.

Welcome to my world

@selmant

selmant commented Sep 30, 2026

Copy link
Copy Markdown
Author

I went back and redid this so it's purely additive. I'll close this PR and Moonfin-Client/Moonfin-Core#1520 in favour of Moonfin-Client/Moonfin-Core#1709, and nothing needs to change here, in Smart-TV or in Roku.

What changed:

  • The seerr_* built-in row types are untouched, and there's no migration.
  • An admin-created Seerr slider on Home is stored in the existing kind: pluginDynamic shape with pluginSource: "seerr". The slider id goes in pluginSection and its type in pluginAdditionalData.
  • The plugin already stores those entries as-is and leaves pluginDynamic out of homeRowOrder. The admin layout editor keeps them, labelled by pluginDisplayText.
  • Smart-TV (homeLayout.js passthrough) and Roku (ApplyHomeSections → PickedRowFromSection returns invalid → passthrough) already send unknown pluginDynamic sources back unchanged.
  • The one client that dropped them was older Core builds. New Core keeps a local slider row when an incoming layout is missing it, the same way custom rows are already kept.

So there's nothing to reimplement on Smart-TV or Roku. Sorry for the churn this caused on your side.

@selmant selmant closed this Sep 30, 2026
@RadicalMuffinMan

Copy link
Copy Markdown
Contributor

Hey bud don't think I'm ignoring the PRs, last release had enough changes baked in and I didn't want to add on more for testing and the upcoming one I'd mostly just for bug fixes, after 2.6.1 I plan to look at more PRs and feature requests

@selmant

selmant commented Sep 30, 2026

Copy link
Copy Markdown
Author

Not at all! I actually found a much better way to implement this in the meantime 😄 It’s pretty close to my first implementation, but with a cleaner approach, and we probably won’t need any changes to the Plugin at all:

Moonfin-Client/Moonfin-Core#1709

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants