Issue with using nzbhydra2 with Mylar about nzbhydra2 HOT 28 CLOSED

That was fixed two days ago. Are you sure you're running the latest version?

from nzbhydra2.

Yes running version v1.0.14

from nzbhydra2.

Can't really explain that. It should work... Wait for the next release.

from nzbhydra2.

1.0.15 is out, try that one.

from nzbhydra2.

Should be fixed now.

from nzbhydra2.

hi,
im now seeing a search by mylar yet it doesn't download the result. i dont know if i should send this to mylar.

from nzbhydra2.

There's no port there

from nzbhydra2.

And ffs, post your debug infos like it says in the issue template.

from nzbhydra2.

apologise
here is the debug.
i use nginx to reverse proxy which works with all my other programs. all use http://
nzbhydra-debuginfos-2018-01-11-18-47.zip
12.0.0.1/nzbhydra, exepct for lazylibrarian which uses https://mydomain.com/nzbhydra

trying both on mylar cause the same error.

from nzbhydra2.

Here's how I interpret Mylar's log:

Mylar accesses Hydra at https://127.0.0.1/nzbhydra/... to search but finds a download that links to http://127.0.0.1:5075/nzbhydra/.... Note the difference in scheme. I guess that could cause problems.

Try setting the external URL to https://127.0.0.1/nzbhydra/ (in Hydra's main config section).

from nzbhydra2.

I'll probably disable the XSRF protection in the next version because it only causes problems and is rarely needed.

from nzbhydra2.

added the url but still getting the same error

from nzbhydra2.

I'm gonna suggest using your reverse proxy harder. I have mine setup so that sub.domain.com points at my external ip via real DNS. But inside my network, my router points sub.domain.com to the server's internal ip. That way, I can just use that everywhere. This could fix your issue because now you can point everything at https://sub.domain.com/nzbhydra2 (or whatever) and everything will just "work". Magically. Hopefully.

from nzbhydra2.

With lazylibrarian I have to use https://mydomain.com/nzbhydra which works fine. Trying this in Mylar comes up with the same errror as using http://127.0.0.1/nzbhydra (this is used by sonarr and radarr)

from nzbhydra2.

Does your mydomain.com work correctly internally? With routers and port forwards and stuff, it can be a little weird to get working. I assume it does, since LL is working. I've never added Hydra to either, let me try now and see what it does.

Edit: It turns out both Mylar and LL were using my old NZBHydra, so I've switched them to the new. I see a search query go through fine from LL to NZBHydra. The Mylar queries make it through too, but I don't have anything good to search for and nothing is found. :/

from nzbhydra2.

'LL works fine searches and results are sent to nzbget.
Mylar again searches but I get the error you see in my third post.
When I look into NZBHydra search history and run it again it pull results.

from nzbhydra2.

hi,
i updated to the latest version v1.0.16 and i’m still seeing the following error

here are the debug logs
nzbhydra-debuginfos-2018-01-12-14-53.zip

I’ve made connect with @evilhero to see if he could assist from a Mylar point of view.

from nzbhydra2.

from nzbhydra2.

It does at the search level - the problem is that it's getting some kind of response from the 127.0.0.1/nzbhydra and is returning the retrieved headers response. So there's no error per-se from the response (there might be an error code, it doesn't trap that), but the response being retrieved doesn't contain the nzb.

Has nzbhydra2 changed the returning nzb url so that it doesn't have a 'searchresultid' anymore ? (that's what Mylar looks for to distinguish hydra from newznab queries in the past - it looks like the nzb trying to be retrieved above is just using the id field now)

from nzbhydra2.

@phairplay What you get in the browser when you call http://127.0.0.1:5075/nzbhydra/getnzb/api/4065993004411482480?apikey=MYAPI ?

@evilhero Why does Mylar need to distinguish between newznab and Hydra? No, there's not searchresultid parameter anymore. I was not aware there were any programs that handled Hydra differently (or needed to do so in the first place).

from nzbhydra2.

I can see errors in the log that indicate that some tool is trying to make an API call with the parameter t=7030 which doesn't make sense. Mylar seems to make queries using that category. Could that be related?

from nzbhydra2.

Ahhh... Sorry, I'm blind.

http://127.0.0.1/nzbhydra/api?apikey=MYAPI&t=get&id=3 is not a a valid NZB URL. The ID would need to look like the one in http://127.0.0.1:5075/nzbhydra/getnzb/api/4065993004411482480?apikey=MYAPI (in that case 4065993004411482480).

Why does Mylar use that ID?

from nzbhydra2.

It doesn't need to distinguish normally - but at some point (can't recall exactly when), the returning of the searchresultid was only occuring with nzbhydra, so I had to make an exception for the return call to be handled properly. Probably why it was trying to use the id of 3 instead of the other id.

If it's no longer needed, I can remove the searchresultid check and it should be able to retrieve it normally provided @phairplay can figure out his reverse proxy stuff.

from nzbhydra2.

Weird, it seems to work with all the other tools. If you need my support let me know.

from nzbhydra2.

No worries - this is all because I thought it'd be a good idea to allow for dynamic API replacement within the existing API download calls because of some edge case.

So Mylar basically just stores the id and then dynamically generates the url from the other info. Turns out to be more of a PITA than anything else - so now's the excuse for me to just remove that stuff entirely. I'll have this pushed out within the hour for @phairplay to try...

from nzbhydra2.

Hi guys,
Many thanks for taking the time to review this, I’ll report back ASAP

from nzbhydra2.

Winner winner chicken dinner.....
Thank you so much guys, I really appreciate it.

David

from nzbhydra2.

Great to hear.

from nzbhydra2.