Is there a bug with the Seerr integration?

[Nipal33]

Environment

• Moonfin Plugin (Moonbase): v1.9.1.0
• Jellyfin Server: 10.11.x, installed via swizzin
• Moonfin for Android: v2.2.0
• Reverse proxy chain: Nginx Proxy Manager (public) → swizzin's internal Nginx → Jellyfin (default port)
• Jellyfin "Base URL" networking setting: /jellyfin

Symptom

In the Moonfin Android app, under Settings, the Seerr integration shows:

"Unavailable because server plugin Seerr support is disabled"

This is despite having enabled Seerr in the Jellyfin admin panel (Dashboard → Plugins → Moonfin) with a valid, reachable URL.

Troubleshooting done so far

1. Reverse proxy path forwarding — confirmed working correctly at both proxy layers. Tested /Moonfin/Ping both locally on the Jellyfin host and through the public domain; both return identical, consistent responses (a 401 without auth, as expected, with allow: GET on a HEAD request). The /Moonfin/ paths are reaching the plugin correctly through the full reverse proxy chain.

2. Server-side Seerr config — confirmed correct. Calling /Moonfin/Ping with a valid Jellyfin API token returns:

   {
     "Installed": true,
     "Version": "1.9.1.0",
     "SettingsSyncEnabled": false,
     "ServerName": "Jellyfin",
     "JellyseerrEnabled": true,
     "JellyseerrUrl": "https://myjellyseerrserveur.mydomain.com",
     "MdblistAvailable": false,
     "TmdbAvailable": false,
     "DefaultSettings": { ... }
   }

So the server plugin genuinely has Seerr enabled with the correct URL. This isn't a config-not-saved issue — I restarted Jellyfin after saving, and logged out/back into the Moonfin app, with no change.

3. Jellyfin logs — no errors around the Seerr config save.

Possible root cause: JSON key casing mismatch

Note the casing in the actual /Moonfin/Ping response above: PascalCase (JellyseerrEnabled, JellyseerrUrl, Installed, etc.).

Every documented example of this endpoint's schema I could find — including the plugin's own README and third-party reimplementations — uses camelCase:

{ "installed": true, "version": "1.0.0.0", "settingsSyncEnabled": true, "serverName": "Jellyfin", "jellyseerrEnabled": true, "jellyseerrUrl": "https://jellyseerr.example.com" }

If the Moonfin client does case-sensitive JSON parsing (typical for Dart/Flutter with generated model classes), it would never find jellyseerrEnabled in a PascalCase response, default it to false/null, and show the "server plugin Seerr support is disabled" message — even though the server is correctly configured. This would line up exactly with what I'm seeing.

I don't know if this is:

• A genuine bug in my client (1.9.1.0) e.g., a controller endpoint returning raw System.Text.Json output without the app's configured camelCase naming policy applied, or
• Specific to something about my setup (though I can't identify what, given the response is otherwise complete and correct)

Question

Is this a known issue, or something specific to my environment? Happy to provide more logs/config if useful — I have a fairly unusual double reverse-proxy setup (NPM + swizzin's internal Nginx) but have ruled that out as the cause since the request path and server-side config are both confirmed correct — the discrepancy seems to be purely in the response body's key casing.
Also, in the plugin in Jellyfin, the "Enable Seerr" is the only option checked for now.

Thanks for your help !

[RadicalMuffinMan]

This has all been fixed for plugin v2.0.0 and Moonfin-Core 2.3.0 all releasing this week

[outbackwebsitedesign]

Just tested on plugin v2.0.0.0 / Moonfin-Core 2.3.0 (fresh reinstall today, not an old cached version), the top-level /Moonfin/Ping fields are still PascalCase (Installed, Version, SeerrEnabled, JellyseerrEnabled, JellyseerrUrl).

Interestingly, the fix does seem to have landed partially — the nested DefaultSettings object now correctly uses camelCase (mdblistEnabled, showShuffleButton, etc). So it looks like the settings model serialization got fixed, but the Ping controller's top-level response object didn't get the same treatment.

Confirmed via authenticated curl from two separate devices on the same LAN, response is identical both times:

{"Installed":true,"Version":"2.0.0.0","SeerrEnabled":true,"JellyseerrEnabled":true,...,"DefaultSettings":{"mdblistEnabled":false,"showShuffleButton":false,...}}

Seerr auth/SSO itself works fine (confirmed via /Moonfin/Jellyseerr/Login and /Status), so this is purely the client failing to parse the top-level PascalCase keys on Ping — matches the original theory in this thread. Happy to provide full curl output or test a build if it'd help narrow down the controller.

[RadicalMuffinMan]

Thanks for the detailed testing. Quick heads up though, the casing itself isn't the mechanism. The client runs every Ping field through a helper that tries camelCase and then falls back to the PascalCase key, so SeerrEnabled gets read as seerrEnabled regardless. That fallback is in the 2.3.0 build you're already on, so a PascalCase Ping alone would not trip the "disabled" banner.

[outbackwebsitedesign]

Good to know! Not sure why it won't work then.... But definitely doesn't!

[ArneNaessens]

Same issue here:
Android Moofin app v2.3.0
Moonfin plugin 2.0.0.0
Jellyfin version: 10.11.10
Seer version: 3.3.0

Getting the same Unavailable because server plugin Seerr support is disabled error on my phone whilst address is filled in and checkbox is enabled.