Jellifyn url returns http://undefined:undefinedundefined

[AQMpolyface]

Description

hiya, i have the latest docker jellyseer install, and the jellifyn url does not get returned correctly.

2025-11-13T12:20:33.981Z [error][Auth]: The provided Jellyfin is invalid or the server is not reachable. {"error":"INVALID_URL","status":404,"hostname":"http://undefined:undefinedundefined"}

i still have my jellifyn settings in settings.json.

Is there a migration i need to run on the settings? I first installed jellyseer in august. and i have not really checked up on it in like ~3 month.

Thanks in advance!

Version

Jellyseerr 2.7.3

Steps to Reproduce

no clue :3

Screenshots

No response

Logs

2025-11-13T12:20:33.981Z [error][Auth]: The provided Jellyfin is invalid or the server is not reachable. {"error":"INVALID_URL","status":404,"hostname":"http://undefined:undefinedundefined"}

Platform

desktop

Database

SQLite (default)

Device

desktop

Operating System

Linux

Browser

firefox

Additional Context

No response

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[github-actions]

👋 @AQMpolyface, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with Seerr.

• Discord

[AQMpolyface]

Okay thanks a lot! sorry for adding an issue. Thanks for the swift response

[NiklasRosenstein]

I think this might be a bug because https://docs.seerr.dev/migration-guide says

Whether you come from Overseerr or Jellyseerr, you don't need to perform any manual migration steps, your instance will automatically be migrated to Seerr.

I've upgraded from Jellyseerr to Seerr and since am getting the same error. So it would seem the migration was not as friction-less as indicated by the documentation.

I do see a settings.old.json and settings.json and I presume that settings.old.json was created during the upgrade, although I have no way to confirm that. The only difference is

Details

/app/config $ diff -u settings.old.json settings.json
--- settings.old.json
+++ settings.json
@@ -19,20 +19,20 @@
    }
   },
   "hideAvailable": false,
-  "hideBlacklisted": false,
   "localLogin": false,
   "mediaServerLogin": true,
   "newPlexLogin": true,
   "discoverRegion": "",
   "streamingRegion": "DE",
   "originalLanguage": "",
-  "blacklistedTags": "",
-  "blacklistedTagsLimit": 50,
   "mediaServerType": 2,
   "partialRequestsEnabled": true,
   "enableSpecialEpisodes": true,
   "locale": "de",
-  "youtubeUrl": ""
+  "youtubeUrl": "",
+  "hideBlocklisted": false,
+  "blocklistedTags": "",
+  "blocklistedTagsLimit": 50
  },
  "plex": {
   "name": "",
@@ -246,7 +246,7 @@
   "image-cache-cleanup": {
    "schedule": "0 0 5 * * *"
   },
-  "process-blacklisted-tags": {
+  "process-blocklisted-tags": {
    "schedule": "0 30 1 */7 * *"
   }
  },
@@ -264,5 +264,9 @@
    "bypassFilter": "",
    "bypassLocalAddresses": true
   }
- }
+ },
+ "migrations": [
+  "0007_migrate_arr_tags",
+  "0008_migrate_blacklist_to_blocklist"
+ ]
 }
\ No newline at end of file

FWIW deleting the settings.json and setting up the configuration again in the web was easy enough.

[fallenbagel]

I think this might be a bug because https://docs.seerr.dev/migration-guide says

Whether you come from Overseerr or Jellyseerr, you don't need to perform any manual migration steps, your instance will automatically be migrated to Seerr.

I've upgraded from Jellyseerr to Seerr and since am getting the same error. So it would seem the migration was not as friction-less as indicated by the documentation.

I do see a settings.old.json and settings.json and I presume that settings.old.json was created during the upgrade, although I have no way to confirm that. The only difference is

Details

/app/config $ diff -u settings.old.json settings.json
--- settings.old.json
+++ settings.json
@@ -19,20 +19,20 @@
    }
   },
   "hideAvailable": false,
-  "hideBlacklisted": false,
   "localLogin": false,
   "mediaServerLogin": true,
   "newPlexLogin": true,
   "discoverRegion": "",
   "streamingRegion": "DE",
   "originalLanguage": "",
-  "blacklistedTags": "",
-  "blacklistedTagsLimit": 50,
   "mediaServerType": 2,
   "partialRequestsEnabled": true,
   "enableSpecialEpisodes": true,
   "locale": "de",
-  "youtubeUrl": ""
+  "youtubeUrl": "",
+  "hideBlocklisted": false,
+  "blocklistedTags": "",
+  "blocklistedTagsLimit": 50
  },
  "plex": {
   "name": "",
@@ -246,7 +246,7 @@
   "image-cache-cleanup": {
    "schedule": "0 0 5 * * *"
   },
-  "process-blacklisted-tags": {
+  "process-blocklisted-tags": {
    "schedule": "0 30 1 */7 * *"
   }
  },
@@ -264,5 +264,9 @@
    "bypassFilter": "",
    "bypassLocalAddresses": true
   }
- }
+ },
+ "migrations": [
+  "0007_migrate_arr_tags",
+  "0008_migrate_blacklist_to_blocklist"
+ ]
 }
\ No newline at end of file

FWIW deleting the settings.json and setting up the configuration again in the web was easy enough.

This is not a migration bug. Migration only occurs in seerr when users come from Overseerr to Seerr anr is seamless for 99.99% of users that require it. And to be clear, there is no migration for Jellyseerr (Jellyfin/Emby) users because Seerr is literally Jellyseerr rebranded. Upgrading to Seerr for Jellyseerr users is the same as pulling a new image. The only reason we provide a "migration" guide is because the image setup differs (e.g. permissions), but there is no internal migration for config or database. The internal settings.json migration only exists for users coming from Overseerr.

Also, settings.old.json is a write corruption safeguard and it has nothing to do with migration. It was introduced in Jellyseerr years ago.

This issue was originally reported against Jellyseerr, not Seerr, and has intermittently affected fewer than 5 people across both projects. It's caused by the settings JSON not loading properly into memory, which can be due to external factors too, most commonly Seerr not being able to read settings.json at startup. A restart resolves it every time.

We have not been able to reproduce this in testing. Although it's a rare edge case with a simple fix (restart, or regenerate settings.json) we'd love to find the root cause but without a way to reproduce it, there's not much we can act on.

As mentioned, this has nothing to do with the Jellyseerr/Overseerr → Seerr migration.