[BUG] - Sonarr panel not working since updating to Sonarr v4.x

[jeremysherriff]

Describe the bug
Sonarr panel does not show Enhanced content. Test button fails.
Reference: linuxserver/Heimdall#1266

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Application List'
2. Click on 'Edit' icon for Sonarr
3. Check/edit configuration in Config section
4. Click 'Test'
5. See error:

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Version info (please complete the following information):

• Heimdall: 2.6.1
• Any browser
• App: Sonarr
• Version of remote application App tries to use: 4.0.5.1710

Additional context
This may be due to increased Auth requirements for Sonarr: see https://wiki.servarr.com/sonarr/faq-v4#forced-authentication

[mvdkleijn]

I will need more information that this.

1. Any errors in the Heimdall logs?
2. How did you configure your Sonarr authentication? (basic, forms, etc)

[jeremysherriff]

I have solved my problem, it was to do with very stale old copies of the Enhanced App code.
I could not figure out a way to refresh the downloaded code from inside Heimdall - the files stayed with the original modified date no matter what I did.

Eventually I gave up, deleted the config/www/SupportedApps directory, and cloned this git repo as SupportedApps.
Sonarr worked perfectly immediately.

To answer your specific questions;

• No errors in any Heimdall logs, but looking at the logs available to view I could not figure out what logs would be relevant to this sort of issue anyway. The PHP code does not appear to be logged anywhere? And given the real issue (stale zip) - where would the zip download/unpack process be logged to?
• Sonarr is configured with External auth (I use a WAF with auth for remote connectivity) and has Disable auth for local addresses set.

I am tempted to close this issue but I suspect the root cause (stale Enhanced Apps code) is a potential problem for others, and likely explains the original issue (linuxserver/Heimdall#1266). I feel that my solution to the issue (cloning the git repo) is not the "right" solution either.

I use the linuxserver/docker-Heimdall docker image, and do not set the GUID and PUID - all directories and files are therefore owned by 911:911. I first set up Heimdall using this docker image around 2 years ago, so my issue may be caused by changes to the SupportedApps download process as that has changed quite extensively.

If I remove the config/www/SupportedApps directory and then start the docker container, a small number (between 2 and 15, varies each time) of SupportedApps subdirectories are created. I cannot edit existing Enhanced Apps because the blade PHP file is missing (expected, sort of) but if I created a new one the results vary - sometimes the zip file downloads but does not unzip, other times the zip downloads and unzips.

The Update Apps list button does not appear to refresh the existing Enhanced Apps zips/contents - is it intended to? At what point should a new zip be downloaded and unpacked? How are the EnhancedApps versioned and updated?

If I start a completely new Heimdall instance (new empty config directory) I see config/www/SupportedApps is empty, and then correctly populates with latest code when I create a new panel. The obvious answer is that the permissions are different between the original vs new config directory; they are, but the original location is more permissive (drwxrwxr-x vs drwxr-xr-x, same owner and group of 911:911).

Not sure how to proceed - in theory my issue is resolved but it appears that something is not working correctly?

[mvdkleijn]

A quick (and probably too brief) reply between appointments: I am a maintainer of the Heimdall-Apps repository. This only carries the actual app files.

It specifically does not contain any update logic etc. That is part of the main Heimdall repo. When I have a little more time I can look into the details of updates (never did that before since it wasn't relevant) however...

other than making a PR on the main repo, I can't change anything there.

Just an attempt at making sure I'm clear on my position and giving an honest and transparent reply. 😁

[jeremysherriff]

Yeah I fully understand, and it makes me suspect my issues are edge-case otherwise you likely would have had to get across the update logic before now. I have retained the original SupportedApps directory in order to refer back to if needed, although outside of owner:group and permissions I'm not sure what would be useful - but it's there.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[jeremysherriff]

Methinks the Stalebot doesn't actually close things, just threatens to do so 😄

[mvdkleijn]

Methinks the Stalebot doesn't actually close things, just threatens to do so 😄

Yeah, I didn't stick it in there... I'll see if I can rip it out. It's just annoying.