Movie search returns no results while series search works as expected

[wjs018]

Describe the bug Searching for a movie returns no results. Searching for and requesting series works as expected. This is likely a similar issue to #88.

Expected behavior Movie search results should be returned just like happens for series requests.

Logs Please copy out the log in it's entirety, please make sure to hide any potential secrets/API keys - although they should be censored via the logging program.

2022-09-11T01:44:29.039Z ba149cbd8135 INFO [doplarr.interaction-state-machine:28] - Performing search for movie top gun
2022-09-11T01:44:29.310Z ba149cbd8135 FATAL [doplarr.utils:78] -
java.lang.Thread.run Thread.java: 831
java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 630
java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1130
java.util.concurrent.CompletableFuture$AsyncSupply.run CompletableFuture.java: 1769
java.util.concurrent.CompletableFuture.postComplete CompletableFuture.java: 506
java.util.concurrent.CompletableFuture$UniHandle.tryFire CompletableFuture.java: 907
java.util.concurrent.CompletableFuture.uniHandle CompletableFuture.java: 930
jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$1 PlainHttpConnection.java: 205
jdk.internal.net.http.PlainHttpConnection.checkRetryConnect PlainHttpConnection.java: 229
jdk.internal.net.http.PlainHttpConnection.connectAsync PlainHttpConnection.java: 184
java.security.AccessController.doPrivileged AccessController.java: 554
jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$0 PlainHttpConnection.java: 182
sun.nio.ch.SocketChannelImpl.connect SocketChannelImpl.java: 846
sun.nio.ch.SocketChannelImpl.beginConnect SocketChannelImpl.java: 759
sun.nio.ch.SocketChannelImpl.ensureOpen SocketChannelImpl.java: 195
java.nio.channels.ClosedChannelException:
java.net.ConnectException:
java.util.concurrent.CompletionException: java.net.ConnectException

Additional context Doplarr is being run as a docker container inside Unraid. As mentioned above, series requests continue to function as expected and these errors only happen for movie requests. I am using Overseerr instead of radarr/sonarr to manage requests. I have included below the log output for a successful search for a series to compare. The repo I am using is from linuxserver.io

2022-09-11T01:49:26.765Z ba149cbd8135 INFO [doplarr.interaction-state-machine:28] - Performing search for series firefly
2022-09-11T01:49:30.369Z ba149cbd8135 DEBUG [doplarr.core:27] - Received interaction
2022-09-11T01:49:32.394Z ba149cbd8135 DEBUG [doplarr.core:27] - Received interaction
2022-09-11T01:49:32.394Z ba149cbd8135 DEBUG [doplarr.core:27] - Received interaction
2022-09-11T01:49:35.262Z ba149cbd8135 DEBUG [doplarr.core:27] - Received interaction
2022-09-11T01:49:35.262Z ba149cbd8135 DEBUG [doplarr.core:27] - Received interaction

[pellett655]

Same issue here. Currently docker container is only linked up to Overseerr and series lookups work fine.

Error when searching for movie `2022-09-22T14:41:07.690Z 843a614179ce FATAL [doplarr.utils:?] - Exception from HTTP request java.lang.Thread.run Thread.java: 831 ...
clojure.core.async.impl.concurrent/counted-thread-factory/reify/fn concurrent.clj: 29 java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 630 java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1130 ...
doplarr.utils/request-and-process-body/fn utils.clj: 73 clojure.core.async.impl.ioc-macros/run-state-machine-wrapped ioc_macros.clj: 982 clojure.core.async.impl.ioc-macros/run-state-machine ioc_macros.clj: 978 doplarr.utils/request-and-process-body/fn/state-machine--auto-- utils.clj: 73 doplarr.utils/request-and-process-body/fn/state-machine--auto--/fn utils.clj: 75 clojure.core/apply core.clj: 667 ...
doplarr.backends.radarr.impl/GET impl.clj: 9 doplarr.backends.radarr.impl/GET impl.clj: 10 ...
doplarr.utils/http-request utils.clj: 19 doplarr.utils/http-request utils.clj: 25 ...
hato.client/request client.clj: 321 hato.client/request client.clj: 326 hato.middleware/wrap-method/fn middleware.clj: 472 hato.middleware/wrap-nested-params/fn middleware.clj: 689 hato.middleware/wrap-form-params/fn middleware.clj: 538 hato.middleware/wrap-content-type/fn middleware.clj: 300 hato.middleware/wrap-multipart/fn middleware.clj: 709 hato.middleware/wrap-accept-encoding/fn middleware.clj: 339 hato.middleware/wrap-accept/fn middleware.clj: 317 hato.middleware/wrap-exceptions/fn middleware.clj: 160 hato.middleware/wrap-output-coercion/fn middleware.clj: 273 hato.middleware/wrap-decompression/fn middleware.clj: 640 hato.middleware/wrap-url/fn middleware.clj: 553 hato.middleware/url-request middleware.clj: 543 hato.middleware/parse-url middleware.clj: 120 java.net.URL. URL.java: 515 java.net.URL. URL.java: 568 java.net.URL. URL.java: 672 java.net.MalformedURLException: no protocol: /api/v3/movie/lookup

Exception in thread "async-dispatch-1" java.net.MalformedURLException: no protocol: /api/v3/movie/lookup at java.base/java.net.URL.(URL.java:672) at java.base/java.net.URL.(URL.java:568) at java.base/java.net.URL.(URL.java:515) `

[thedinz]

Reported this to the DEV directly the other night, curious, are you guys using the nightly build?

[wjs018]

@thedinz I use the linuxserver.io docker image (dockerfile here). I am not a dev, but it looks like it pulls the latest release from the releases page which is currently v3.6.0

Based on the logs from @pellett655 it looks like the api url for movie searches might not be correct for Overseerr.

[thedinz]

@thedinz I use the linuxserver.io docker image (dockerfile here). I am not a dev, but it looks like it pulls the latest release from the releases page which is currently v3.6.0

Based on the logs from @pellett655 it looks like the api url for movie searches might not be correct for Overseerr.

I also am using the LSIO version but the nightly build, have talked to others who say its working fine so just wondering if its build specific or what. Either way hope its resolved soon.

[kiranshila]

Yeah this is super strange. I use the lsio containers for radarr/sonarr/overseerr and just updated and have yet to run into any problems.

The log from no protocol: /api/v3/movie/lookup means that it's trying to use radarr directly for some reason and is failing because there is no URL.

[kiranshila]

Are all of y'all using unraid? Perhaps something changed in how they use environment variables.

[thedinz]

Are all of y'all using unraid? Perhaps something changed in how they use environment variables.

I am yes, and that problay is it, i have asked around and everyone keeps testing their instace and saying it works, except us here, i assume what we have in common is unraid. Although, i have not updated the unraid OS anytime recently that would cause this.

[thedinz]

Yeah this is super strange. I use the lsio containers for radarr/sonarr/overseerr and just updated and have yet to run into any problems.

The log from no protocol: /api/v3/movie/lookup means that it's trying to use radarr directly for some reason and is failing because there is no URL.

This is what you said my system was doing also when i sent logs via discord

[wjs018]

Thank you @kiranshila, knowing that it was trying to use radarr rather than overseerr helped me crack the case on this one. Below I have written out how I diagnosed the issue and the resolution.

Diagnosis

Like you suspected, I was also using Unraid as the host OS. So, I thought that I should force an update of the docker image and then see what the actual docker command being run was. For those in the future that might see this thread, to force an update to a docker image in Unraid, you go to your docker tab, switch to advanced mode at the top and then hit the force update button to the right of the docker image name. I have included the (edited for clarity and to protect personal info) docker command that was run below:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d 
  --name='doplarr' 
  --net='bridge' 
  -e TZ="America/New_York" 
  -e HOST_OS="Unraid" 
  -e 'DISCORD__TOKEN'='discord_token_here' 
  -e 'OVERSEERR__API'='api_key_here' 
  -e 'OVERSEERR__URL'='my_url_here' 
  -e 'DISCORD__MAX_RESULTS'='25' 
  -e 'DISCORD__REQUESTED_MSG_STYLE'=':plain' 
  -e 'PARTIAL_SEASONS'='true' 
  -e 'LOG_LEVEL'=':debug' 
  -e 'OVERSEERR__DEFAULT_ID'='your_user_id_here' 
  -e 'RADARR__API'='radarr__api' 
  -e 'RADARR__URL'='http://localhost:7878' 
  -e 'SONARR__API'='sonarr__api' 
  -e 'SONARR__URL'='http://localhost:8989' 
  -e 'SONARR__QUALITY_PROFILE'='' 
  -e 'RADARR__QUALITY_PROFILE'='' 
  -e 'SONARR__ROOTFOLDER'='' 
  -e 'RADARR__ROOTFOLDER'='' 
  -e 'SONARR__LANGUAGE_PROFILE'='' 
  -e 'JAVA_OPTS'='' 
  -e 'PUID'='99' 
  -e 'PGID'='100' 
  -e 'UMASK'='022' 
  -v '/mnt/user/appdata/doplarr':'/config':'rw'

I remembered seeing on the docs page for configuration that overseerr and radarr/sonarr were mutually exclusive and only one or the other should be set up. So, in the past I remember removing all the environment variables for radarr/sonarr. However, looking at the docker command being run, and then going in to edit the environmental variables in Unraid, I found they were back, filled with default values. This led me to a relatively simple resolution:

Resolution

All you need to do to fix this issue is to edit the docker container within Unraid and hit the remove button next to all the radarr/sonarr variables. This will only leave the Overseerr variables when the docker container is run again. I have included the new docker run command below after I removed the offending entries:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d 
  --name='doplarr' 
  --net='bridge' 
  -e TZ="America/New_York" 
  -e HOST_OS="Unraid" 
  -e 'DISCORD__TOKEN'='discord_token_here' 
  -e 'OVERSEERR__API'='api_key_here' 
  -e 'OVERSEERR__URL'='my_url_here' 
  -e 'DISCORD__MAX_RESULTS'='25' 
  -e 'DISCORD__REQUESTED_MSG_STYLE'=':plain' 
  -e 'PARTIAL_SEASONS'='true' 
  -e 'LOG_LEVEL'=':debug' 
  -e 'OVERSEERR__DEFAULT_ID'='your_user_id_here' 
  -e 'JAVA_OPTS'='' 
  -e 'PUID'='99' 
  -e 'PGID'='100' 
  -e 'UMASK'='022' 
  -v '/mnt/user/appdata/doplarr':'/config':'rw'

See? No pesky radarr/sonarr environment variables anymore. This resolved the movie search issue for me. I suspect that the radarr/sonarr variables got added back to the docker image after an update to the image from linuxserver.io's side, though I don't really know how to pinpoint that as the cause.

@kiranshila I will close this issue as I have resolved things on my end. However, there is one thing I don't really understand. I don't know why Doplarr was fine using Overseerr for series and ignoring Sonarr, but tried using Radarr instead of Overseerr for movies. I think it would make more logical sense to default to one or the other for both cases of series and movies, but that is just my two cents as a user and not a dev.

[kiranshila]

Sick!

I don't know why Doplarr was fine using Overseerr for series and ignoring Sonarr, but tried using Radarr instead of Overseerr for movies

I think it has to do with the fact that I store everything in a hash map, and the order in which they were checked is not defined. That's why I was saying one should have one or the other. It's still kinda an open issue how I should check that they are actually mutually exclusive.

[wjs018]

Thanks for the info! Like I said in my post it is clearly spelled out in the docs that one or the other should be used, so I don't think it is a big deal. It just made things harder to diagnose the root cause in this (very specific) instance.

[thedinz]

This DID NOT resolve the issue for me, glad it worked for you but i dont think we can consider the issue closed.

Edit: I even tried installing the HOTIO version of radarr, i do not know that its anything LSIO has done.

[pellett655]

Removing the extra parameters from the docker container when using overseerr resolved the issue for me.

[thedinz]

I also got mine fixed but my process was different, i did what was suggested here and removed the sonarr/radarr parameters from unraid and hit apply, still was doing the same thing.

I noticed in the config folder was a config.edn file now even though this file isnt used when you run in unraid I found that removing the sonarr/radarr parameters from this file is what solved it for me.

[kiranshila]

It should not even be looking at the config file. The dockerfile that I provide doesn't have the arguments to include it. Whoever packaged the docker stuff made a mistake.

[thedinz]

It should not even be looking at the config file. The dockerfile that I provide doesn't have the arguments to include it. Whoever packaged the docker stuff made a mistake.

Its even weirder to me because that file was blank, i mean the arguments were there but they were blank, for instance (not looking at the file now just from memory so might not be exact)

radarr_api = ""

So the section was there but it was blank, simply removing the line from the file altogether fixed it for me.

[kiranshila]

I need to get a patch together that looks both at the existence of the variable as well as checking against the empty string

[kiranshila]

Alright, the latest release should've fixed dealing with random empty strings making their way into the config. If any of you all are still having this issue, please try with the latest release.