expressvpn issue? about alpine-qbittorrent-openvpn HOT 14 CLOSED

Looks like the pipeline job failed...?

from alpine-qbittorrent-openvpn.

Looks like it started up ok. Will do some more testing. The only thing that looked odd in the log this time was:

[cont-init.d] 02-setup-openvpn: exited 0.
[cont-init.d] 03-setup-iptables: executing... 
sh: missing ]
/var/run/s6/etc/cont-init.d/03-setup-iptables: line 27: -z: not found
[cont-init.d] 03-setup-iptables: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

from alpine-qbittorrent-openvpn.

Yep, I've included a fallback default value in case the config does not have a protocol (fallback to udp) or is missing a port (fallback to 1194), these changes are in ac5d7d0 once the pipeline is finished could you pull the new image and let me know if everything works?

from alpine-qbittorrent-openvpn.

whoops, this should be fixed after this pipeline hehe https://gitlab.com/guillaumedsde/alpine-qbittorrent-openvpn/-/pipelines/157797418

from alpine-qbittorrent-openvpn.

Hmm, maybe it's not actually working. I was getting odd segfaults from qbittorrent-nox when porting over an existing config from markusmcnugen/qbittorrentvpn:latest (seemed to happen when the client tried to check fast-resume data), so I tried starting with a clean config, I checked logs, looked like the VPN was up, etc. Opened the webui and went to search - search plugins - check for updates, and the log started throwing a bunch of these:

QIODevice::read (QProcess): device not open
Could not parse Nova search engine capabilities, msg:  
QIODevice::read (QProcess): device not open

(qBittorrent was unable to pull the plugin list and just stalls when trying)

from alpine-qbittorrent-openvpn.

Looks like it started up ok. Will do some more testing. The only thing that looked odd in the log this time was:

[cont-init.d] 02-setup-openvpn: exited 0.
[cont-init.d] 03-setup-iptables: executing... 
sh: missing ]
/var/run/s6/etc/cont-init.d/03-setup-iptables: line 27: -z: not found
[cont-init.d] 03-setup-iptables: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

weird my container didn't have this issue. In any case I know where this is from, the latest commit fixes these issues along with making shell script variable expansion more reliable.

from alpine-qbittorrent-openvpn.

Hmm, maybe it's not actually working. I was getting odd segfaults from qbittorrent-nox when porting over an existing config from markusmcnugen/qbittorrentvpn:latest (seemed to happen when the client tried to check fast-resume data), so I tried starting with a clean config, I checked logs, looked like the VPN was up, etc. Opened the webui and went to search - search plugins - check for updates, and the log started throwing a bunch of these:

QIODevice::read (QProcess): device not open
Could not parse Nova search engine capabilities, msg:  
QIODevice::read (QProcess): device not open

(qBittorrent was unable to pull the plugin list and just stalls when trying)

yeah from memory, the search engine requires python which isnt installed here , I'm looking into this

from alpine-qbittorrent-openvpn.

Yeah that's the issue, python isn't installed, I've set the CI to build an image tagged python (automatic builds are enabled for this tag).

Once this CI pipeline is done (and if it is sucessful ;) ) you can pull guillaumedsde/alpine-qbittorrent-openvpn:python and you should be able to add search engines, let me know how that goes

from alpine-qbittorrent-openvpn.

Failed again :P (the pipeline, that is)

from alpine-qbittorrent-openvpn.

damn hehe those multi architecture builds are not meant for gitlab CI.... (computationally expensive).

I've fixed it (again) the image is built at: guillaumedsde/alpine-qbittorrent-openvpn:python

from alpine-qbittorrent-openvpn.

Ok, switched to new image and cleared all settings. Search can pull down plugins now, but with that working, I think we're back to exposing some oddities that I was originally seeing:

• Search results for the same term from the same engines are showing only a small fraction compared to the same client running on markusmcnugen or on a windows test machine (also behind VPN).
• A torrent with 57 seeds only shows 11 seeds on these builds and appears to be stuck 'downloading metadata' indefinitely. The same operations on markusmcnugen with the same settings behave as expected.
• Importing existing settings from markusmcnugen (on the same version of qBittorrent) appears to try to continue downloading the existing test torrent, but throws segfaults every time the client tries to check fast-resume data.

...so I can't put my finger on it, but something is getting in the way of the traffic somehow.

from alpine-qbittorrent-openvpn.

hum...

• so regarding the first issue, could so post here the logs for qbittorrent, if you've mounted the container's config directory they should be (inside the container) at /config/qBittorrent/data/logs/ (probably have a glance at them, they might contain sensitive information, I'm not sure).
• regarding your second point, it appears that MarkusMcNugen/docker-qBittorrentvpn implements port forwarding (as far as I can tell, not through the VPN tunnel) does your VPN provider support this? If it does and it is enabled (you can check with https://canyouseeme.org/) , it is possible that if port forwarding is enabled you might connect to more peers. Also, did you try both clients at roughly the same time (peers could have disconnected in between the two tests)?
• This is also curious, technically, this version of qBittorrent is built with musl instead of glib (although that probably isnt the reason for the segfault), the answer to this might also be found in the qbittorrent logs

from alpine-qbittorrent-openvpn.

Yeah that's the issue, python isn't installed, I've set the CI to build an image tagged python (automatic builds are enabled for this tag).

Once this CI pipeline is done (and if it is sucessful ;) ) you can pull guillaumedsde/alpine-qbittorrent-openvpn:python and you should be able to add search engines, let me know how that goes

I've documented the python variant of the image in the README in commit f828216

from alpine-qbittorrent-openvpn.

Seems like the issue is resolved? feel free to reopen if that's not the case :)

from alpine-qbittorrent-openvpn.