No torrents found - qBittorrent

[kingp0dd]

Environment

Docker

Version

v0.10.0

Describe the problem

I can't seem to find the logs to know why it's not working. I checked the documentation if there are configurations for the Torrent Module but I also can't find it.

I just get the following status in the module box: No torrents found

Additional info

No response

Please tick the boxes

• [X] You've read the docs
• [X] You've checked for duplicate issues
• [X] You've tried to debug yourself

[ajnart]

Did you enable "Hide completed torrents " by any chance ?

[kingp0dd]

It is disabled. I also have an ongoing download :( The qbittorrent service shows green though:

[ajnart]

It is disabled. I also have an ongoing download :( The qbittorrent service shows green though:

Weird. Can you show me the logs of the network request for the download module (in developer console) should happen every second

[javijuji]

Same issue here.

Failed to load resource: the server responded with a status of 401 (Unauthorized) 777-11150e74696d08e7.js:1 Error while fetching torrents Object[[Prototype]]: Object (anonymous) @ 777-11150e74696d08e7.js:1

If I go to http://your-ip/api/modules/torrents

I get {"statusCode":405,"message":"Method not allowed"}

The actual qBittorrent connection is working since disabling CSRF connections but the torrent tracker still doesnt work

[ajnart]

Same issue here.

Failed to load resource: the server responded with a status of 401 (Unauthorized) 777-11150e74696d08e7.js:1 Error while fetching torrents Object[[Prototype]]: Object (anonymous) @ 777-11150e74696d08e7.js:1

If I go to http://your-ip/api/modules/torrents

I get {"statusCode":405,"message":"Method not allowed"}

The actual qBittorrent connection is working since disabling CSRF connections but the torrent tracker still doesnt work

Could you show me the logs of the request from the network panel ? It's weird that you would do a method that is not allowed

[javijuji]

Request URL: http://192.168.1.50:7575/api/modules/torrents Request Method: POST Status Code: 401 Unauthorized Remote Address: 192.168.1.50:7575 Referrer Policy: strict-origin-when-cross-origin

Failed to load resource: the server responded with a status of 404 (Not Found) api.github.com/repos/ajnart/homarr/releases/latest:1 Failed to load resource: the server responded with a status of 403 () _app-c331164f2ecf68da.js:1 POST http://192.168.1.50:7575/api/modules/torrents 401 (Unauthorized) (anonymous) @ _app-c331164f2ecf68da.js:1 e.exports @ _app-c331164f2ecf68da.js:1 e.exports @ _app-c331164f2ecf68da.js:1 f.request @ _app-c331164f2ecf68da.js:1 (anonymous) @ _app-c331164f2ecf68da.js:1 (anonymous) @ _app-c331164f2ecf68da.js:1 (anonymous) @ 777-11150e74696d08e7.js:1 777-11150e74696d08e7.js:1 Error while fetching torrents {} (anonymous) @ 777-11150e74696d08e7.js:1 Promise.catch (async) (anonymous) @ 777-11150e74696d08e7.js:1

[PrzemekSkw]

I also don't see torrents. I add 3 modules: Deluge, Deluge-VPN and Qbittorrent-VPN and have no torrent found. I don't have any option to disable downloaded torrents. I see error messege about torrents when starting Homarr dashboard but it dissapear very fast. Docker logs shows only that:

docker-compose logs
Attaching to homarr
homarr    | Listening on port 7575
homarr    | warn  - using beta Middleware (not covered by semver) - https://nextjs.org/docs/messages/beta-middleware
homarr    | react-i18next:: You will need to pass in an i18next instance by using initReactI18next

I add dash. and see there's also invisible network tab. Download and Upload speed also always 0 kb/s.

Regards.

[ajnart]

Sorry, I still couldn't replicate your issue. Could you contract me on discord and give me some kind of access to your homarr instance so that I can debug it ?

[wiston81]

I have same issue. How can i help to solve?

[yeeahnick]

Same issue here as well.

[manuel-rw]

Can you try if this issue also occurs on the dev image?

WARNING: dev is an experimental branch and a backup is highly recommended. We do not recommend it for daily use, as it might be unstable

[miguelccoelho]

@ajnart I think I found the general issue, and it's the same in QBT, Sonarr or Radarr, and I will make myself available for you to test this. Essentially: DNS name translation. If I have a service configured with an IP address, everything will work fine. As soon as I switch to name translation, it breaks down.

I have the same behavior as in https://github.com/ajnart/homarr/issues/538

@manuel-rw might as well ping you too, as you seem to be working around here too. :)

[manuel-rw]

Thanks for pining me! Ajnart is currently quite busy and I will respond instead for now. It would be awesome if all people in this thread and also #538 could confirm this.

How do I test if I am being affected of this issue?

1. Copy the hostname from your service URL
2. Paste it to "On click URL"
3. Replace your service URL with the internal IPv4 URL
4. Check if it works. If it does now, you are most likely affected.

An example:

I honestly don't know any reason, why this might be the case though. Under the hood, we use the API wrappers of https://github.com/scttcper. These use https://github.com/sindresorhus/got for sending requests to the clients.

We also use https://github.com/axios/axios for some other modules.

It would be really interesting to see, if there is anything going wrong with name resolution. If a timeout happens, this could also explain #515

EDIT: I just remembered, that #551 was a thing. Perhaps we're causing a massive overflow of DNS requests, until a firewall, router or security device blocks the requests? I sadly don't have the time for this, but perhaps somebody could sniff around with Wireshark and check if this is the case? Currently very busy for 0.11 - sorry

[yeeahnick]

Out of nowhere mine just started populating without me changing anything. I browsed to Homarr on my mobile device and noticed it was working, I then came back to my computer (using Edge browser) and the graph refreshed and is now showing my downloads. Very strange...

[miguelccoelho]

It would be really interesting to see, if there is anything going wrong with name resolution. If a timeout happens, this could also explain #515

EDIT: I just remembered, that #551 was a thing. Perhaps we're causing a massive overflow of DNS requests, until a firewall, router or security device blocks the requests? I sadly don't have the time for this, but perhaps somebody could sniff around with Wireshark and check if this is the case? Currently very busy for 0.11 - sorry

Not sure if it's a timeout thing, TBH. I can say that looking at the preview message that comes back when using name resolution, it doesn't strike me as a timeout thing: {message: "getaddrinfo ENOTFOUND sonarr.rabbit", name: "Error",…}

But like you, I don't know how those wrappers work behind the scenes. I do have a Pi Hole serving my network, so at least I wouldn't discard it. There is another point though. If the system keeps on requesting name translation, without a caching mechanism... It's a baaaad idea. That much is clear to me. Whether those wrappers have something like that or not... No clue.

But like you mentioned, as soon as I have things configured as you described, it all works perfectly. So one thing is for sure: name resolution is the issue. I know that it's not a critical thing, but name resolution is a big boon for networks. In my case, I'm using specific IP addresses for certain services, so having name resolution is a life saver for me. Of course, using the IP is a workaround I can deal with, but if at some point I decide to change the IPs behind those names (it has happened before), I'll have to reconfigure Homarr. Not breaking, but annoying. Still, on my side, I can confirm that this works for me.

[miguelccoelho]

@manuel-rw just to maybe get some more proof of the name resolution as part of several issues (whether it's flooding, network blocking, or even something not being properly translated), let me point out more issues that have the same base. Do note, I'm not pressuring or anything, just want to centralize some information for later reference:

https://github.com/ajnart/homarr/issues/496 In https://github.com/ajnart/homarr/issues/496#issuecomment-1354707159 the user mentions that as soon as it has name resolution with Nginx, it starts failing.

https://github.com/ajnart/homarr/issues/480 Already a duplicate of this one

https://github.com/ajnart/homarr/issues/538 As I mentioned there, I've had the same issue as seen here.

And then, the two potential issues you mentioned. Not sure I have the time to go sniff the network, but if I have that time, I'll post something here.

[ajnart]

@manuel-rw just to maybe get some more proof of the name resolution as part of several issues (whether it's flooding, network blocking, or even something not being properly translated), let me point out more issues that have the same base. Do note, I'm not pressuring or anything, just want to centralize some information for later reference:

496 In #496 (comment) the user mentions that as soon as it has name resolution with Nginx, it starts failing.

480 Already a duplicate of this one

538 As I mentioned there, I've had the same issue as seen here.

And then, the two potential issues you mentioned. Not sure I have the time to go sniff the network, but if I have that time, I'll post something here.

Thank you very much for your investigation, we'll look into it

[manuel-rw]

Not sure if it's a timeout thing, TBH.

You wouldn't see in the browser if your DNS resolution would fail.

{message: "getaddrinfo ENOTFOUND sonarr.rabbit", name: "Error",…}

This just indicates that the host was not found or connection was rejected. I really suspect that we do not cache properly which might explain the unusual and unstable behaviour.

Not breaking, but annoying

I disagree. This issue seems to be quite breaking for some people, especially since multiple components of Homarr seem to be affected.

let me point out more issues that have the same base

Amazing, thank you!

We probably won't fix this issue in 0.11 though. We're making the last polish before releasing, but I can focus more on this issue here afterwards. Anyhow, thank you everyone here for your engagement and effort - I'm sure we'll figure it out :)

[manuel-rw]

I dug around on Google and it seems like axios does not have a cache at all? https://github.com/axios/axios/issues/1878

You can use an intercepter though to add such behaviour:

https://www.npmjs.com/package/axios-cached-dns-resolve

[manuel-rw]

One thing that confuses me is, that got seems to have a caching system in place: https://github.com/sindresorhus/got/blob/e24b89669931b36530219b9f49965d07da25a7e6/package.json#L50

I've had it happen multiple times, that my PiHole notified me, that there were too many requests being sent - not sure if this is being caused by Homarr though.

[manuel-rw]

One thing that would actually interest me is, if how many of you are accessing Homarr with a domain. Since we know that axios does not cache, requests like these could be a serious problem:

https://github.com/ajnart/homarr/blob/ba6a3df2b599f88a3a9883b28f0c7e6bc293c74c/src/modules/torrents/TorrentsModule.tsx#L63-L87

[ajnart]

One thing that confuses me is, that got seems to have a caching system in place: https://github.com/sindresorhus/got/blob/e24b89669931b36530219b9f49965d07da25a7e6/package.json#L50

I've had it happen multiple times, that my PiHole notified me, that there were too many requests being sent - not sure if this is being caused by Homarr though.

I mean how hard is it to switch to something that has caching ? Also @manuel-rw we need singleton for Api-wrapped stuff, this might enable caching. Or we can try to swap to sockets. My biggest dream would be to have SQLite database that contains all possible intégration data and then we bind components to data, with like an observer

[miguelccoelho]

Ok, now is the part where I have to say a "mea culpa" on part of this issue. I have been able to solve it, and this may be an issue for other users as well. I'm very sorry for making you guys sweat over this, but I'm hoping this can be useful in the future for similar failures

I am using Unraid as the server where this is being used. I've been fighting issues with networking on Unraid, when using 3 network interfaces. A long lost solution I had, at a point, was to use the google servers as the DNS configuration of those interfaces. And that was the root cause of the Name Resolution part.

Once I changed that, downed all interfaces but one, and restarted Unraid, proper local Name Resolution started working, as I was now pointing correctly to my Pi-Hole. Even the scenario where I'm doing a more complex routing with reverse proxying (Pi-hole -> Nginx with HTTPS -> Vaultwarden). All working now.

That will not, however, solve the polling part you have been discussing.

One thing that would actually interest me is, if how many of you are accessing Homarr with a domain. Since we know that axios does not cache, requests like these could be a serious problem:

Well, I can say I am using a domain. My PiHole has several name translations, one of the is homarr.rabbit. Never seen if there are issues with flooding on the Pi though.

[manuel-rw]

I've been fighting issues with networking on Unraid, when using 3 network interfaces. A long lost solution I had, at a point, was to use the google servers as the DNS configuration of those interfaces. And that was the root cause of the Name Resolution part.

Interesting... So perhaps Homarr is not the issue, but maybe Docker and it's DNS resolution? Can somebody else confirm this? I sadly don't have the time as I try to keep up with all bug reports an issues of 0.11

[miguelccoelho]

Sorry @manuel-rw for never answering this. The issue was a mix of Unraid's Docker and the DNS I had setup, indeed. The best I can offer, is that ever since I've fixed a few things (like setting some options to allow the docker networks to better communicate with the outside), I've stopped having most issues.

I've gone as far as to now being able to have a PiHole, that redirects certain names to Nginx Proxy Manager, and have it return the IP and port, which essentially lets me have names that give me access to the full service. And yes, they are configured with those names in Homarr. Not sure this helps this specific case though.

If anyone else is having issues with that, I can definitely try to help, but I'm not constantly active here. @kingp0dd maybe if you add more info on your network setup, I could try to help.

[Meierschlumpf]

Is this still an issue?

[miguelccoelho]

No, this has been solved I believe. The owner hasn't returned here, and I was able to solve this by making changes on Unraid's network and DNS resolution. You can close this @Meierschlumpf

EDIT: I'll also leave a note here, for anyone using Unraid (it may be useful for another Docker usage, perhaps...) that may relate to this and other issues on homarr. When the Docker daemon comes up, whatever network configuration is available at the moment is what the docks will use. This has given me issues on Nginx Proxy Manager, specifically on my reverse proxy / DNS resolution. If anyone is facing an issue like this, make sure to at least confirm your network configuration, and restart docker.