First real run throws fault "feign.RetryableException"

[rickardfransson]

Hi! So, at last I managed to get a DRY run to run without any faults. Even leaving-soon got created and found by EMBY.

I thought. Why not, so I disabled dry run and instantly got thrown with this in logs:

https://pastebin.com/VERq1NgM

Of course, script stops and doesnt get executed after this fault.

I´ve double checked API key, and also made sure authentication for Sonarr is disabled.

Need som help here, Sonarr works if I turn on dry run..

[Schaka]

You put sonarr as localhost. Localhost is the docker container - Janitorr.

Something is redirecting the client too. Might be some setup you have that tries to force https - but I don't know. It would seem that during dry-run, Sonarr work because it's using limited API access.

If I had to guess, you either changed something else in your config or you've set up something on top of sonarr that does the redirect on delete.

Which sonarr version are you on? Maybe the old sonarr v3 does something else.

[rickardfransson]

Tried putting Sonarr and Radarr as localhost but that didnt do the trick. DRY run still works with localhost.

The only thing i now i got is nginx. Got that setup by a good friend. I really dont now if that can be troublesome.

Sonarr is on the lastest version, updated today, AFTER I saw this fault. So it didnt work with an old V4 or a new V4 Sonarr.

This is my config now: logging: level: com.github.schaka: TRACE server: port: 8978

File system access (same mapping as Sonarr, Radarr and Jellyfin) is required to delete TV shows by season and create "Leaving Soon" collections in Jellyfin

Currently, Jellyfin does not support an easy way to add only a few seasons or movies to a collection, we need access to temporary symlinks

Additionally, checks to prevent deletion on currently still seeding media currently require file system access as well

file-system: access: true validate-seeding: true # validates seeding by checking if the original file exists and skips deletion - turning this off will send a delete to the *arrs even if a torrent may still be active leaving-soon-dir: "/home/rickardfransson/Media" # The directory that's known to Janitorr - this will contain new folders with symlinks to your media library for "Leaving Soon" media-server-leaving-soon-dir: "/home/rickardfransson/Media/" # This is the directory Jellyfin/Emby will be told it can find the "Leaving Soon" library, in case its mapped differently from-scratch: true # Clean up entire "Leaving Soon" directory and rebuild from scratch - this can help with clearing orphaned data - turning this off can save resources (less writes to drive) free-space-check-dir: "/" # This is the default directory Janitorr uses to check how much space is left on your drives. By default, it checks the entire root - you may point it at a specific folder

application: dry-run: false whole-tv-show: false # activating this will treat as a whole show as recently download/watched from a single episode, rather than that episode's season - shows will be deleted as a whole whole-show-seeding-check: false # Turning this off, disables the seeding check entirely if whole-tv-show is enabled. Activating this check will keep a whole TV show if any season is still seeding (requires file access). leaving-soon: 14d # 14 days before a movie is deleted, it gets added to a "Leaving Soon" type collection (i.e. movies that are 76 to 89 days old) exclusion-tag: "janitorr_keep" # Set this tag to your movies or TV shows in the *arrs to exclude media from being cleaned up

media-deletion: enabled: true movie-expiration:

Percentage of free disk space to expiration time - if the highest given number is not reached, nothing will be deleted

  # If filesystem access is not given, disk percentage can't be determined. As a result, Janitorr will always choose the largest expiration time.
  65: 30d # 1 month - if a movie's files on your system are older than this, they will be deleted
  70: 30d # 2 months
  80: 90d # 3 months
season-expiration:
  60: 15d # 15 days
  65: 20d # 20 days - if a season's files on your system are older than this, they will be deleted
  70: 60d # 2 months
  80: 120d # 4 months

tag-based-deletion: enabled: true minimum-free-disk-percent: 100 schedules:

• tag: 5 - demo expiration: 30d

• tag: 10 - demo expiration: 7d

  episode-deletion: # This ignores Jellystat. Only grab history matters. It also doesn't clean up Jellyfin. There is NO seeding check either. enabled: true tag: janitorr_daily # Shows tagged with this will have all episodes of their LATEST season deleted by the below thresholds max-episodes: 10 # maximum (latest) episodes of this season to keep max-age: 30d # Maximum age to keep any episode at all - even the last 10 episodes would expire after 30 days in this example

clients: sonarr: enabled: true url: "http://localhost:8989" api-key: "XXXXXXXXXXXXX" delete-empty-shows: true # If a show that was "touched" by Janitorr contains no files and has no monitored seasons at all, it will get deleted as part of orphan cleanup radarr: enabled: true url: "http://localhost:7878" api-key: "XXXXXXXXXXXX"

You can only choose one out of Jellyfin or Emby.

User login is only needed if deletion is enabled.

jellyfin: enabled: false url: "http://localhost:8096" api-key: "XXXXXXXXXXXX" username: Janitorr password: janitorr delete: true # Jellyfin setup is required for JellyStat. However, if you don't want Janitorr to send delete requests to the Jellyfin API, disable it here

You can only choose one out of Jellyfin or Emby. Emby support is secondary.

User login is only needed if deletion is enabled.

emby: enabled: true url: "http://127.0.0.1:8096" api-key: "XXXXXXXXXXXXXX" username: Janitorr password: janitorr delete: true # Emby setup is required for JellyStat. However, if you don't want Janitorr to send delete requests to the Emby API, disable it here jellyseerr: enabled: true url: "http://127.0.0.1:5055" api-key: "XXXXXXXXXXXX" match-server: false # Enable if you have several Radarr/Sonarr instances set up in Jellyseerr. Janitorr will match them by the host+port supplied in their respective config settings. jellystat: enabled: true whole-tv-show: false # Enabling this will make Jellystat consider TV shows as a whole if any episode of any season has been watched url: "http://127.0.0.1:3000" api-key: "XXXXXXXXXXXX"

[Schaka]

Again, localhost will not work. localhost is INSIDE the Janitorr container.

If you somehow managed to set it up where it does (whatever your friend did), where localhost works and points towards your host system from within the container, then you still somehow have the routing fucked up. It could be that your friend isn't allowing the PUT method. But I don't know.

The log file shows that Sonarr answers with a redirect. I don't know why it redirects. Post a log from a dry run to prove that it works.

Read your radarr/sonarr logs and see why they would redirect. I don't believe.

Here's the request that just returns a status code for redirect:

cannot retry due to redirection, in streaming mode executing PUT http://127.0.0.1:8989/api/v3/series/35

[rickardfransson]

oops. Sorry. Misunderstood regarding localhost. During first run without dry run I used 127.0.0.1:ports .

Now im using localhost (my bad)

Attaching logs from dry run. This dry run IS using localhost. Not IP-adress. logs janitorr.txt

Ive checked logs from sonarr. It only shows deleting the first series for a couple of seconds when the script runs. After that, nothing more of interest.

[Schaka]

I'm leaning towards whoever set up nginx for you fucked up forwarding the PUT method properly and now redirects. localhost and 127.0.0.1 are the same.

I bet if you try to unmonitor a season in Sonarr it's fucked too.

[rickardfransson]

OK. It looks like dav_methods in nginx isnt configurated. Will have a look at that this wekeend.

if its ok for you, please keep this ticket open a few days..

[Schaka]

You can respond to the closed issue. However, it's not a problem with Janitorr whatsoever, so I'll close it (AGAIN!). There are well over 100 users to the best of my knowledge, including myself, who don't have these problems.

Sonarr/Radarr should not redirect any requests and the fact that it works for all the GET requests in the dry run but now for anything that isn't dry (PUT, DELETE, etc) tells me what I need to know.

I'm honestly not even sure how you managed to put a reverse proxy between local interaction of a container with its host when accessing ports directly.

Fix your setup, maybe respond here when you have. But stop creating issues that are NOT relevant to Janitorr. Read the error messages.

[rickardfransson]

Just stopping by..

Seems your right. Have observed the errorlogs and it haults exactly the moment Janitorrs going to unmonitor in Sonarr.

I have tried to shutdown nginx completely, re run Janitorr but the same problem occurs. Tried different adresses in config, both https and one different port for https. Tried developer branch.

Debug in Sonarr tells me this the exact moment Janitorr throws a fault when unmonitoring.

Seems like I probably need to ditch this program. Mostly because i feel that everytime I post something I get a bad respons back. Its not easy for me to either read the faults in Janitorr OR to now if its my environment or a BUG in Janitorr.

To bad. Really liked this script....

[Schaka]

You seem to be the only user that's constantly messing up the setup. After the first 5 tickets, I was getting really sick of it. Especially with essentially nothing to go on, not full log file, terrible formatting, etc. Leaving me to play a guessing game.

As you can see here, the request Janitorr sends is entirely valid. I don't know what you have done that causes PUT API calls to result in a redirect. You've set it up and I've told you the solution is to fix the redirect.

Maybe you've enabled SSL and it somehow tries to redirect to https? God knows. I certainly don't.

I don't want to "fix" this by following redirects. I should not have to. If a direct happens, temporary or not, it should result in an error so I can fix Janitorr calling the wrong URL. However, there is no wrong URL being called here.

If you manage to fix your setup (not around Janitorr, but in general), and you find an actual bug in Janitorr, I am more than happy to fix it. I've pretty much implemented every bug fix and feature request within a week whenever someone has made a legitimate request. You can check the issue tracker.

If basic functionality, like a PUT request to Sonarr doesn't work and 100s of users have no problem running it, then the problem is your setup. I didn't set up your server. So I have to literally guess what could even be wrong.

Maybe this thread can put you on the right path:

https://www.reddit.com/r/LunaSeaApp/comments/106fgz2/http_302_error_with_radarr_sonarr/

https://www.reddit.com/r/LunaSeaApp/comments/vmzmq1/sonarr_and_radarr_shows_information_but_dont/

https://www.reddit.com/r/sonarr/comments/17m3j5b/sonarr_v_redirecting_to_https_but_radarr_v4_is_not/