BUMP!
qBittorrent is still broken in -current.
Again, to repeat: it has been tested on multiple machines, on multiple
ISPs/internet networks, on multiple trackers, etc.
TL;DR: qBittorrent stalls - stops torrenting, after some time, on most if not
all torrents.
If I recall correctly some do not even start.
Peers seems to just drop off until 0.
Works perfectly fine on FreeBSD but FreeBSD sucks but also no I2P support on
it.
The rest of details is in the thread (read arhive, below is incomplete).
I do not command anyone to do anything, it is just sad to see this decent
project - program, not work on OpenBSD.
I am in no health condition do jack sh1!t about it, sadly.
All I can do is try and help in finding the problem.
We still do not know if it is a qBittorrent issue or a OpenBSD issue.
Does OpenBSD have some throttling for openfiles or something like that unless
like ran as root? IDK
Thanks
On Thu, Oct 24, 2024 at 06:14:15PM +0000, Anon Loli wrote:
> On Sat, Oct 19, 2024 at 12:46:00PM +0000, Anon Loli wrote:
> > On Wed, Oct 09, 2024 at 04:57:26PM +0000, Anon Loli wrote:
> > > On Wed, Oct 09, 2024 at 12:08:53AM +0000, Lucas Gabriel Vuotto wrote:
> > > > On Tue, Oct 08, 2024 at 09:17:43PM GMT, Anon Loli wrote:
> > > > > Interesting question!
> > > > > For the clearnet torrenting I tried the default /etc/pf.conf before, and it
> > > > > exhibits said behavior.. no idea if the rtables have anything to do with this
> > > > > and if they somehow change >> by default <<, but I will give it a try!
> > > >
> > > > Then it's most surely not the case. Creating and using a different
> > > > rtable(4) is an admin decision. If this your own platform and not a
> > > > shared host, then most likely you're using rtable 0.
> > > >
> > > > This doubt can be easily cleared by sharing the full output of `netstat
> > > > -R` and `id -R`. They look something like this:
> > > >
> > > > $ netstat -R
> > > > Rdomain 0
> > > > Interfaces: lo0 enc0 sec0 tap0 tap1 veb0 vport0 pflog0
> > > > Routing table: 0
> > > >
> > > > Rdomain 1
> > > > Interfaces: iwx0 em0 lo1
> > > > Routing table: 1
> > > >
> > > > Rdomain 2
> > > > Interfaces: wg2 lo2
> > > > Routing table: 2
> > > >
> > > > $ id -R
> > > > 0
> > > >
> > > >
> > > > > I will be testing the setup with what the manual for rtable(4) provides:
> > > > > > route -T0 exec /usr/local/bin/qbittorrent
> > > >
> > > > In most scenarios and setups, rtable 0 is the default and that command
> > > > has no effect. As said, `id -R` will clear this up.
> > >
> > > Well... fuck.
> > > There goes my hope, out of the window. Can you see it?
> > >
> > > What now?
> > > I got a littel bit more info on this main bug.
> > >
> > > After some time, if there have even be any peers, they disconnect, seemingly
> > > all at once.
> > > This happens from after 10 minuts, up to like 1 hour sometimes.
> > > I think that peers drop off slowly until all of my torrents are dead.
> > > Slow in this case would be 1 every few dozen seconds.
> > > By "drop", I mean drop off the Peers list.
> > >
> > > But then, also seemingly... a little bit of traffic comes back for a short and
> > > slow while, then also disapears.
> > >
> > > Here's a stupid graph that I manually made attached as "qb-bug".
> >
> > I not only tested on another computer, but also on a new drive.
> >
> > The BOTH issues persist.
> > The restarting downloaded progress might be just from using (p)kill on
> > qbittorrent and that somehow makes it unstable.
> >
> > The issue of poor variable or non-existent speed might also be there for other
> > networking-heavy programs, meaning it might not even be qbittorrent-specific.
> > Again, everything points to something on OpenBSD...
> > I have tried on:
> > - different computers
> > - different disks
> > - different network
> > - different ways to access the network: wired/wireless
> >
> > *it has to be* something in OpenBSD.
> > What the fu can do that, since OpenBSD aims to be very good when it comes to
> > networking - some ISPs use OpenBSD for networking.
> >
> > I do not mean to shit on OpenBSD or developers, but everything points to this..
> > What else can it be? What user error?
> > Actually maybe I'm onto something... it might even be user error after all?
> >
> > Perhps it could be this:
> > both of the computer I tested on were low-end, and I tried increasing the max
> > number of connections which seemingly decreased the time before the big
> > no-speed bug occured, meaning it occured way faster.
> >
> > Perhaps it's something related to some limit like openfiles?
> > I did have openfiles increased on both machines.
> > And if I recall correctly, I was warned of increasing the limit and also
> > arguing as to why the limit is that low by default and wether or not a
> > automatic utility for extracting the maximum limit for openfiles and similar.
> >
> > Again, time will tell, I will decrease the limit to what I think was the
> > original one shown at-boot.
> >
> > While I'm at it: I forgot where I can find the information printed at-boot
> > that's similar to dmesg?
> > I tried grepping the entire /var/ for openfiles, but I can't find it...
> > I'd like to know.
>
>
> Nope... the default 7030 seems to not change anything, really.
> I am out of ideas and it sucks that there is no --verbose option!
>
> Why do peers keep on expiring?
> Do they become unreachable? HOW
>
> I also tried changing the port, it did nothing.
> What's interesting is that it like opens up a liiiiiiiittle bit and then closes
> back up... what the bug can make for that behavior?
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system, NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
PGP fingerprint: AE35FC867EAB1A7450E5CCA27630FFBD6BB466B8
AE35 FC86 7EAB 1A74 50E5 CCA2 7630 FFBD 6BB4 66B8
<anonloli@autistici.org>
No comments:
Post a Comment