Movie search returns no results while series search works as expected about doplarr HOT 18 CLOSED

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.

from doplarr.

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)
`

from doplarr.

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

from doplarr.

@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.

from doplarr.

@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.

from doplarr.

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.

from doplarr.

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

from doplarr.

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.

from doplarr.

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

from doplarr.

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.

from doplarr.

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.

from doplarr.

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.

from doplarr.

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.

from doplarr.

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

from doplarr.

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.

from doplarr.

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.

from doplarr.

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

from doplarr.

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.

from doplarr.