[BUG] Can't remove trackers from WebUI

[nicolajkl]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When removing a tracker URL from a torrent nothing happens.
Editing works fine though.

Expected Behavior

The tracker URL should be removed.
According to the issue linked below it should've been resolved in "current master" (3 weeks ago at the time of writing this):
qbittorrent/qBittorrent#22039 (comment)

Which is why I suspect this is an LSCR issue. I tried to look for which version you're using in this container, but wasn't successful in finding that info.

Steps To Reproduce

1. Highlight a torrent
2. Go to the tracker tab in lower half of UI
3. Right click a tracker and click "Remove tracker"
4. Nothing happens

Environment

- OS: Debian Bullseye/Raspberry Pi OS lite 64 bit
- How docker service was installed: apt I think (don't remember/5 years ago or so)

CPU architecture

ARMv8-A

Docker creation

qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - WEBUI_PORT=8080
    volumes:
      - /mnt/usb/config/qbittorent:/config
      - /mnt/usb/media:/media
      - /home/autobrr:/autobrr
    ports:
      - 4900:4900/tcp
      - 4900:4900/udp
      - 8080:8080/tcp
    restart: unless-stopped
    networks: 
      - docker_network

Container logs

No entries in log when trying to remove trackers.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[sizeur]

I have the same problem. In the link you provide "qbittorrent/qBittorrent#22039 (comment)" the comment said the problem is still present in v5.0.3, which is the latest stable version: https://www.qbittorrent.org/news

The version I am using:

So I believe the problem is not from linuxserver but it's from qbitorrent, we have to wait for the next stable release

[taw123]

Per my comment source qBit repo....

qbittorrent/qBittorrent#22039 (comment)

Pro-ported to be fixed in current head but no build since 5.0.3 so only way to pick this up in via linuxserver's docker image is if they have a daily or test build train. Something I am getting to thee point of considering as I don't REALLY want to build myself and can't keep living with the jack I have tons of bogus trackers I need to purge from current torrents and of course can/'tt do that given the bug. Not complaining (1st world problem) :)

[sizeur]

Well, instead of building my own image i rather rollback to 5.0.2...

root@localhost: cat /qbittorrent/docker-compose.yaml
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:5.0.2
[...]
    restart: unless-stopped
    labels:
      - "com.centurylinklabs.watchtower.enable=false" # Prevent watchtower to update container (if needed)
root@localhost:/qbittorrent$ docker-compose down
root@localhost:/qbittorrent$ docker-compose up -d

Tracker can be deleted again without problems, but I need to manually update container in the future :/

[taw123]

Thanks for the suggestion to regress the version. Unfortunately I THINK(?) the 5.0.3 had the Qbit-NOX fix for trash handling of deleted media content (ie ensure that when a Torrent is deleted AND remove media is checked, the ACTUAL files are really removed- from the correct location as Qbit-NOX dosen't support thee trash/recycle folder and for ME even with setting the flag manually in the prefs file is STILL didn't delete the actually file-- again until Qbit fixed the default behavior). I know that was a problem in at least 5.0.1 and thought it was still present in 5.0.2.

That said I did have a variation on your suggestion to regress... I may just regress may container release to 5.0.2, then delete/clean up all my torrent trackers, THEN roll forward to "current". A bit more work than I was hoping to do but not a big deal and would then mean I don't have to remember to pick up 5.0.4 (or whatever actually contains the Tracker WebUI fix.

All that said is there ANYWAY to get an idea when a new RELEASE MIGHT occur? Not a dig, just trying to manage expectations and decide how much hassle to take on myself in addressing the consequences of the WebUI bug. Originally I had thought given previous 5.x release cadence it would be a couple days or even weeks but issue now dates back to mid Dec - with the fix quickly merged in on Dec 28. Again no offense intended against any of thee current devs, just expectation mgt :)

Thanks!

[janusn]

Actually, could we have a feature to ban some trackers from adding? It is a more sensible approach.

Of course, that is not a replacement for removing trackers. Could we have both?

Here is the feature request: Tracker Ban List

[Roxedus]

is there ANYWAY to get an idea when a new RELEASE MIGHT occur?

we are not qbittorent devs. we have no say in its development.

[taw123]

Apologies with all the cross posting I have done btw LinuxServer's repot and Qbit, it's clear I should have asked this in the bit repo issues. Regards.