thrroow

Okay finally figured it out. I had another semi-broken eth port connected that I used as a fallback in the past. For some strange reason during my upgrades, the eth0 switched which mac address it was mapped to. Swapping those in network settings fixed the issue.

Alright. I will break out the compressed air and some more CAT6 cables and keep trying things. The reason I was suspicious this was something else is the switch it is directly connected says 10G (as do lights on both sides of the connection) Also tried it in a different 1Gbps switch and it said negotiated to 1Gbps too (while still 100Mb in UNRAID)

eth0 looks more accurate, thanks. Still doesn't solve the problem. I fear it's something in the BIOS, which has been quite the pain in the past. Settings for eth0: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on Port: Twisted Pair PHYAD: 0 Transceiver: internal MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes

Did a small overhaul today and added some more drives and swapped around some SATA connections. Added a PCIe for 4 more SATA ports and removed a 4x1Gb networking card (I wasn't using it for anything). I turn the server back on and start clearing the drives, all is well. No problems at all. I notice web traffic seems slow in/out of the server and check the dashboard -- sure enough it says `eth0100 Mbps, full duplex, mtu 1500`. I thought it was the cable that became unseated but I tried other cables. I also checked my switch via lights & in software and both confirm the link speed is 10Gb. I feel like I am missing something obvious, but I am not sure what else to check. How can the link speed be 10Gb on the hardware, but only show 100Mb in unraid? I have the GA-7PESH2 motherboard and am using the builtin 10Gb Intel networking. Never had this problem until this upgrade. Here's the latest syslog, no mention of failing to negotiate at 1 or 10Gb before this Apr 15 21:52:57 Tower root: Verifying package rclone-2022.01.20-bundle.txz. Apr 15 21:52:57 Tower root: Installing package rclone-2022.01.20-bundle.txz: Apr 15 21:52:57 Tower root: PACKAGE DESCRIPTION: Apr 15 21:52:57 Tower root: Package rclone-2022.01.20-bundle.txz installed. Apr 15 21:52:57 Tower root: plugin: running: anonymous Apr 15 21:52:59 Tower kernel: ixgbe 0000:05:00.0 eth0: NIC Link is Up 100 Mbps, Flow Control: RX/TX Apr 15 21:52:59 Tower kernel: br0: port 1(eth0) entered blocking state Apr 15 21:52:59 Tower kernel: br0: port 1(eth0) entered forwarding state Apr 15 21:53:00 Tower ntpd[1939]: Listen normally on 2 br0 192.168.1.99:123 Apr 15 21:53:00 Tower ntpd[1939]: new interface(s) found: waking up resolver Apr 15 21:53:02 Tower root: Local rclone binary up-to-date ifconfig: br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.99 netmask 255.255.255.0 broadcast 0.0.0.0 ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet) RX packets 3848501 bytes 5309227708 (4.9 GiB) RX errors 0 dropped 939 overruns 0 frame 0 TX packets 1790718 bytes 571169498 (544.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ethtool: ethtool br0 Settings for br0: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Unknown! (255) Auto-negotiation: off Port: Other PHYAD: 0 Transceiver: internal Link detected: yes

I have upgraded to 6.9.0-rc1 and the new Nvidia drivers to keep hardware transcoding. For some reason a certain patch doesn't work, but I don't really need more than several streams at once, so no big deal. However, if I'm transcoding 3 streams, and someone goes to try and use a 4th one, it just constantly buffers / is just a black frame. Is this expected behavior? I would imagine Plex would realize that the card is at the transcode limit and fallback to CPU?

wow that careless of me. Thanks for the headsup, changed credentials.

I've got a weird problem. After months of running fine and me not touching anything, rtorrent suddently stopped being able to be used by web interface. When I would click anything it would just say error. When I add a torrent it would fail. HOWEVER, sonarr/radarr/etc still could use it fine, so I never bothered fixing it. Now weeks later it won't boot at all. So I deleted the container, used a blank config folder - the only thing I kept is the wireguard folder. Both the old and new containers now just hang on "loading" and never even let me see the GUI. No response from sonarr/radarr. I'm not sure what else to try, I would assume deleting the container and remaking with a whole new data folder should remove almost anything I could have done to it?

It's started and stopped happening to me, at seemingly random intervals.

I actually used to have this problem, then it went away for months, now it's back. No significant hardware changes in that time.

I was in the middle of uploading several screenshots when I saw that the container volume mapping was /data/ (as it had been), but the within qbittorrent the /data/ location had changed to /downloads/. After changing it back to /data and restarting it, it now works! When or how did those settings get changed within qbittorrent? I definitely didn't touch any of those settings.

I misunderstood your question. Yes both those paths are the same in each docker, and I have all identical settings (even ports). I ran one, tried to download, stopped it, started the other, and tried the same download. And again, no paths or settings of any kind have changed in months. Another odd thing I noticed, is that sometimes public trackers work slowly (like RARBG ~400kbps). But trackers that should be faster (iptorrents, xspeeds, ubuntu, etc.) don't work at all. Also tested all of these on both docker containers and on a PC using the same VPN connection. In all cases it's only this particular docker that won't download. I was talking about deleting the container files, e.g., anything pulled down from the docker repository or any container data. Or might that not help?

No, both containers were changed to be exactly the same, including container mounted paths, settings, etc. Also, as others have mentioned, these setups used to work just fine. All of a sudden stopped working even though I haven't even opened up the webUI in months. I just noticed radarr/sonarr downloads were stacking up. Double checked with a manual Ubuntu torrent to make sure it wasn't a tracker or VPN issue. Is there a way to delete all container info etc. so that all of it will be re-downloaded? I can try that too.

I didn't change the folders it was pointing to, however, the other qbitvpn docker I downloaded and tried were also pointed at the same folders with no problems. I also made sure to use the exact same ovpn credential file between the two instances. I get around 40 to 60MB/s on my VPN, so it's definitely not overhead or losses. The one thing I didn't try was to get rid of the torrent backup folder because I'd rather switch clients than stop seeding hundreds of torrents.

Also having the same issues as everyone else with the very slow speeds that soonafter just reach 0kbps. I tried installing the other qbittorrentVPN and copied my appdata and torrents to it - same issues. I then deleted all the config/logs/etc - everything BUT the torrents I was downloading and restarted it. This worked and behaved normally. I tried to copy the same thing to binhex-qbittorrentvpn but it didn't help, still slow speeds with everything else being identical. I guess I'm switching dockers for the time being since they're basically identical, except one works

In terms of featureset, this is my favorite torrent client so far. But after a few minutes of use, it becomes painfully slow. Setup with just a normal config using a VPN (PIA). Saving to download directory which is downloading to a cache drive first. Dual xeon CPU, and never high CPU usage detected. Any troubleshooting ideas?