qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
26.99k stars 3.88k forks source link

Ignore common prefixes from tracker filter list to make it more readable. #19851

Open Pentaphon opened 10 months ago

Pentaphon commented 10 months ago

Suggestion

For example, if the announce URL is tracker.privatesite.org, the only important parts are the top-level and 2nd level domain, so it should be shown only as privatesite.org. Why?

1) It saves space on the tracker filter view panel since the URLs are now all shorter by not showing the rather useless subdomain. 2) It creates a more uniform filter view list since some announce URLs have subdomains and some do not, making it more readable.

Examples of common prefixes you can filter out:

bt for bittorrent t for tracker tk for tracker tr for tracker tracker is commonly used in announce URLs opentracker for URLs using that software open for a shortened version of the above.

This feature was implemented in https://github.com/openscopeproject/TrguiNG/issues/51 if you need a concrete example.

Use case

This is especially useful for private trackers which use all sorts of announce URLs as well as people who add many public announce URLs to their torrents. Especially since the tracker filter list is a very thin column that is easier to read when the list entries are shorter.

Extra info/examples/attachments

No response

stalkerok commented 10 months ago

related https://github.com/qbittorrent/qBittorrent/issues/19035

glassez commented 10 months ago

related #19035

So wouldn't this be a better approach?

glassez commented 10 months ago

It could be implemented using two lists. One contains subdomains to discard, and the other (optional, could be implemented later if really needed) contains a list of hostnames to be excluded from processing.

Pentaphon commented 10 months ago

So wouldn't this be a better approach?

Whatever shortens the list entries to make the list more uniform and readable with the least amount of work is fine by me.

stalkerok commented 10 months ago

I think it is impossible to take into account all subdomains, there are an infinity of them, there is only a small list of popular subdomains of public trackers. In addition, it would be nice to combine different domains or even ip addresses, as I showed in the example, belonging to the same tracker, into one tracker in the list. I would also prefer to ignore the dual subdomains bt02.ipv6 ipv6.tracker tracker1.bt or something completely non-standard (www connect localhost ssl routing) to reduce and combine in their own way. It will be very difficult to automate this.

Or make a setting, including which, everything before the hostname will be ignored, about as it was before, only you will need a list of domains such as .co.uk so that they are displayed correctly.

Pentaphon commented 10 months ago

I think it is impossible to take into account all subdomains, there are an infinity of them, there is only a small list of popular subdomains of public trackers.

Sure, but the community, even a single person can come up with a list of common prefixes to ignore and that would take care of 90% of the entries with unnecessarily long URLs, which is a huge improvement over the existing situation. Over time, we could get that up to 95% or more.

stalkerok commented 10 months ago

Trackers are born and die, this list can be very long. I think it's easier to discard everything contained before the main domain and make a list of domains with which there may be problems.

Pentaphon commented 10 months ago

Trackers are born and die, this list can be very long.

Sure, but they also tend to use many of the same kinds of prefixes when they are born like tk or tracker so just making a list to filter common prefixes would be very effective and not necessarily that long.

stalkerok commented 6 months ago

It looks like it could be implemented through something like tracker aliases, e.g. if given example.com=tracker1.example.com;tracker2.example.com, then they are all counted as example.com.

It could be implemented using two lists. One contains subdomains to discard, and the other (optional, could be implemented later if really needed) contains a list of hostnames to be excluded from processing.

Is there anything else on your mind, how to implement it better? Perhaps a function to group trackers with their own group name? For example, a group can contain even one tracker and while it is minimized we can only see the group name, not the tracker itself. Thus we can set a group name manually for each tracker or group several trackers together. Using the example of categories as an example of what this might look like. 2024-02-24_2050442024-02-24_205220

glassez commented 6 months ago

Perhaps a function to group trackers with their own group name? For example, a group can contain even one tracker and while it is minimized we can only see the group name, not the tracker itself. Thus we can set a group name manually for each tracker or group several trackers together.

The point is still the principle by which to group trackers. And we have the same thing, i.e. either manually set the tracker lists for each group, or automatically group them by some attribute, such as domain.

Pentaphon commented 6 months ago

automatically group them by some attribute, such as domain.

I would say that is the solution, yes. Grouping and filtering out common words would be more than enough to make the tracker list much more readable than it is now.

stalkerok commented 6 months ago

Manual grouping has more functionality and variability than automatic, the only thing is that it may not be to everyone's liking, but I would be more satisfied with this option. Besides, as I already said, one tracker can have trackers on different domains or ip addresses as a tracker, there are even cases when there are different trackers on the same domain but with different subdomains.

Pentaphon commented 3 months ago

Manual grouping has more functionality and variability than automatic, the only thing is that it may not be to everyone's liking, but I would be more satisfied with this option.

We can always do it automatically by default and let the user do manual grouping if automatic doesn't satisfy their needs.