[Other] Transmission

[Anuskuss]

问题描述 - Issue Description

I understand that after #382 Transmission is considered deprecated and when compared to something like v6.0.2 the latest version doesn't do anything. But is it really that much of a support burden? If I set up my Transmission to restart once a day (so it can get the latest blocklist) that would work perfectly fine for me. I know that means that some blocked peers will continue downloading (unless you manually merge transmission/transmission#7167) but I think that's better than nothing. And while the advanced anti-leeching features are great (hopefully transmission/transmission#7172 will help in that regard) I don't really need them. So can you please restore the ability to populate the blocklist and just let the user know that they have to restart Transmission manually?

额外信息 - Addition Information

No response

检查清单 - Check list

• 这不是一个错误 （BUG） (This is not an bug/error)
• PeerBanHelper 已更新到最新版本，非最新版本不接受任何错误反馈，任何非最新版本的 Issue 将被 立 刻 关 闭，不会有人给您提供任何支持 (I'm running the latest version of PBH that can be found in Github Relases, non-latest release won't receive any support)
• 我已检查过 PBH 文档（特别是常见问题），且即使使用了搜索也没有找到与此有关的内容 (This not a question/or the question that not listed in README's FAQ or PBH WIKI)
• 我同意遵守 PBH-BTN 包容性条约，不发布 “嘲讽、骂战、引战、开盒（有时也称为人肉搜索）、人身攻击、仇恨、暴力、侮辱性言辞、违法违规、黑灰产、危害国家安全、实施或帮助他人实施电信犯罪” 等内容。并已知晓如果仍旧发布了这些内容，我的账号将立刻从包括但不限于 PBH-BTN 组织、社交软件中封禁。所有主题、内容都将被立刻删除或折叠，撤销、删除和收回您所做出的一切贡献，并封禁 BTN 网络的中账号权限、排除您所提交的所有数据。在您违反相关规则时，PBH-BTN 将会将您的注册、登录、和最近访问的 IP 地址、电子邮件地址、以及其它可能追踪您或将您去匿名化的信息从定期删除转为永不删除，并在任何国家或地区的政府、公安机关或有关部门需要时无通知的提供这些数据。 (I agree to abide by the PBH-BTN Inclusivity Pact by not posting content such as “taunting, name-calling, war-mongering, open-boxing (sometimes referred to as mansplaining), personal attacks, hatred, violence, insulting language, illegal activities, black and grey business, endangering national security, and committing or assisting others in committing telecommunication crimes”. I am aware that if I continue to post such content, my account will be immediately banned from organizations including but not limited to PBH-BTN, social software. All topics and content will be immediately deleted or collapsed, all contributions will be revoked, deleted and retracted, and you will be banned from the BTN network and all data you have submitted will be excluded. In the event of a violation of these rules, PBH-BTN will delete your registration, login, and most recent IP address, email address, and any other information that may be used to track you or de-anonymize you from regular to permanent deletion, and will make this data available to the government, public security, or other relevant authorities without notice if they request it, no matter what country or region.)

[Ghost-chu]

The code for the Transmission feature is still in the PeerBanHelper codebase, but it has been disabled and not updated for more than six months due to the issues we mentioned, and we don't expect to maintain support for Transmission in the future.
However, you can indeed re-enable it manually before it is completely removed.

You can follow the documentation to manually re-enable and manually add the configuration (it is disabled in the WebUI so edit the file is necessary).

https://pbh-btn.github.io/pbh-docs/docs/downloader/Transmission#%E9%87%8D%E5%90%AF%E7%94%A8%E8%A2%AB%E7%A6%81%E7%94%A8%E7%9A%84-transmission

I'd love to restore active support for Transmission, but it's going to be hard to do that until Transmission makes changes.

[Anuskuss]

Okay thanks for the link, that indeed made it work. And it also populated blocklist-url although I'm wondering how often that will happen?

So the warning says

Warning: Use Transmission Adapter is discourage. Frequent starting and stopping of torrents on seeds that are often subject to bans can result in frequent updates to the tracker server, indirectly triggering DoS attacks. This increases the load on the tracker server and may lead to your IP address being banned by the tracker. We encourage you to migrate to other downloaders whenever possible.

How can I disable this "Frequent starting and stopping" (if it's not already disabled) so I can just restart Transmission once a day myself? (I also found a bug when ignore-private is set to true but since you don't officially support Transmission anymore I'm not going to ask you for a fix.)

[Ghost-chu]

Okay thanks for the link, that indeed made it work. And it also populated blocklist-url although I'm wondering how often that will happen?

So the warning says

Warning: Use Transmission Adapter is discourage. Frequent starting and stopping of torrents on seeds that are often subject to bans can result in frequent updates to the tracker server, indirectly triggering DoS attacks. This increases the load on the tracker server and may lead to your IP address being banned by the tracker. We encourage you to migrate to other downloaders whenever possible.

How can I disable this "Frequent starting and stopping" (if it's not already disabled) so I can just restart Transmission once a day myself? (I also found a bug when ignore-private is set to true but since you don't officially support Transmission anymore I'm not going to ask you for a fix.)

This is actually one of the problems we're having, PeerBanHelper is designed to disconnect immediately after a block, and if it doesn't disconnect, it tries again and again. Each repeated ban is also logged as a banning operation thus polluting the statistics.
I would suggest that you could use BTN-Collected-Rules as we are constantly updating it with data from BTN and it works just fine. Transmission 3.0+ should read this rule set without any problems.

Of course the best option is always to switch to another supported downloader.

[Anuskuss]

I would suggest that you could use BTN-Collected-Rules

This seems like a fair compromise but then you're really forced to restart Transmission yourself. Would you consider undeprecating Transmission and removing the "stop-and-start" workaround once transmission/transmission#7167 is merged? Or maybe add a restart_torrent option in the config that defaults to true which a user then can manually disable? I already build my own Transmission with a few unmerged patches so it would be easy to apply 7167 myself. I know that Transmission has been stuck in limbo for a few months but I really think we can make this work.

Of course the best option is always to switch to another supported downloader.

I tested the big 3 (Transmission, qBittorrent, Deluge) many many years ago and for me the clear winner was Transmission for servers (low CPU/memory usage, better headless) and qBittorrent for desktops (more features, better speeds). Back then qbittorrent-nox was quite bad and you didn't have have a good remote GUI but maybe that has improved since then? Anyway I have hundreds of torrents in Transmission and I really don't wanna switch unless I have to. I'll consider qBittorrent once Transmission officially dies but until then I hope we can make this work. The dev of 7167 said that blocklist-update will trigger a blocklist refresh and 7167 will let you kick blocked peers so I think it's possible to make Transmission a first-class citizen again.

P.S. Is there any way to change the loglevel? My systemd service/journal is flooded with Java nonsense and I would really like to only see warnings and errors there (the rest can go into /etc/peerbanhelper/logs/latest.log). I'm doing java -jar PeerBanHelper.jar | grep --line-buffered -v '\(/\||-\)INFO\|^ ' but there's got to be a better way.

[Anuskuss]

Also don't forget about the ability to just straight up block peers through iptables which means that you wouldn't have to use Transmission's blocklist at all (the rules apply immediately). Is this already trackable without running into the "repeated ban is also logged as a banning operation" situation?

[Ghost-chu]

I would suggest that you could use BTN-Collected-Rules

This seems like a fair compromise but then you're really forced to restart Transmission yourself. Would you consider undeprecating Transmission and removing the "stop-and-start" workaround once transmission/transmission#7167 is merged? Or maybe add a restart_torrent option in the config that defaults to true which a user then can manually disable? I already build my own Transmission with a few unmerged patches so it would be easy to apply 7167 myself. I know that Transmission has been stuck in limbo for a few months but I really think we can make this work.

Of course the best option is always to switch to another supported downloader.

I tested the big 3 (Transmission, qBittorrent, Deluge) many many years ago and for me the clear winner was Transmission for servers (low CPU/memory usage, better headless) and qBittorrent for desktops (more features, better speeds). Back then qbittorrent-nox was quite bad and you didn't have have a good remote GUI but maybe that has improved since then? Anyway I have hundreds of torrents in Transmission and I really don't wanna switch unless I have to. I'll consider qBittorrent once Transmission officially dies but until then I hope we can make this work. The dev of 7167 said that blocklist-update will trigger a blocklist refresh and 7167 will let you kick blocked peers so I think it's possible to make Transmission a first-class citizen again.

P.S. Is there any way to change the loglevel? My systemd service/journal is flooded with Java nonsense and I would really like to only see warnings and errors there (the rest can go into /etc/peerbanhelper/logs/latest.log). I'm doing java -jar PeerBanHelper.jar | grep --line-buffered -v '\(/\||-\)INFO\|^ ' but there's got to be a better way.

Hi I want to know which one deploy method that you have to use to setup PBH? The .sh script or .deb package or something else?

[Ghost-chu]

Also don't forget about the ability to just straight up block peers through iptables which means that you wouldn't have to use Transmission's blocklist at all (the rules apply immediately). Is this already trackable without running into the "repeated ban is also logged as a banning operation" situation?

This works for Linux systems, but there doesn't seem to be a better way for Windows.
I've tried operating the firewall but it doesn't work well, especially since sometimes the number of IPs blocked reaches the upper limit of a single rule.

Another important reason is that I don't think I should have PeerBanHelper running under root or Adninistrator privilege levels, whereas operating the firewall obviously requires elevated privileges.

[Anuskuss]

Hi I want to know which one deploy method that you have to use to setup PBH? The .sh script or .deb package or something else?

The .deb package.

This works for Linux systems, but there doesn't seem to be a better way for Windows.

I don't know about Windows but that's why I was asking for a restart_torrent option. So the user can decide for themself if they want PBH to restart the torrent, or either restart the client or use a firewall instead.

Another important reason is that I don't think I should have PeerBanHelper running under root

In Linux land it already runs as user peerbanhelper. For use with iptables you'd also need at least CAP_NET_RAW and CAP_NET_ADMIN (haven't tested).

[Ghost-chu]

The .deb package.

@Gaojianli Can you redirect stdout/stderr to a file in /var/log for .deb packaging?

I don't know about Windows but that's why I was asking for a restart_torrent option. So the user can decide for themself if they want PBH to restart the torrent, or either restart the client or use a firewall instead.

If Transmission can merge that PR, we can actually not restart Torrent but just update the blocklist url.

[Ghost-chu]

For what it's worth, our community members have created a tool that can proxy the Transmission API and the System Firewall API and convert them to the qBittorrent API and provide it to PeerBanHelper or any other program that needs the qBittorrent API (although it's not yet complete) if you're interested.You can check it out at: https://github.com/azicen/transmission-proxy

Disclaimer: This project is not affiliated with PeerBanHelper, PBH-BTN or me.

[Anuskuss]

Can you redirect stdout/stderr to a file in /var/log for .deb packaging?

The full log is already being recorded in /etc/peerbanhelper/logs/latest.log so the only thing that would make sense it to set StandardOutput=null. But I need a filtered log in systemd so I can quickly check for problems (e.g. systemctl status peerbanhelper).

If Transmission can merge that PR, we can actually not restart Torrent but just update the blocklist url.

Transmission could merge that PR but it's release cycle is currently stuck. So the merged PR could sit in master for months and nobody would benefit. A restart_torrent option would fix it today but I guess the code would be dead once Transmission 4.0.7/4.1 releases so I understand why you're maybe opposed to that. It's your call after all.

[Anuskuss]

our community members have created a tool that can proxy the Transmission API and the System Firewall API and convert them to the qBittorrent API

That sounds really interesting but I hope we can make it work with the tools we have available now.

[Anuskuss]

I saw that you disabled the logs completely now but I still wanna see them when I do systemctl status peerbanhelper so instead I just turned on the loglevel (#698). There are still a bunch of useless lines like

22:25:01,641 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.5.12

but it's better than before.

Edit: The loglevels seem a bit arbitrary, no? Because why aren't these INFOs?

Nov 06 22:53:24 java[4097459]: [22:53:24] [virtual-13334/ERROR]: The Peer being blocked is in the block list: BanMetadata(context=com.ghostchu.peerbanhelper.module.impl.rule.IPBlackRuleList, banAt=1730930004819, unbanAt=1731189204819, banForDisconnect=false, rule=TranslationComponent{key='all-in-one', params=[]}, description=TranslationComponent{key='MODULE_IBL_MATCH_IP_RULE', params=[all-in-one, ###]})
Nov 06 22:53:24 java[4097459]: [22:53:24] [virtual-13334/WARN]: [Repair] PeerBanHelper scheduled full banlist re-sync with downloaders

[Ghost-chu]

The loglevels seem a bit arbitrary, no? Because why aren't these INFOs?

This warning should not be triggered under normal circumstances, as indicated when the PBH reports the problem:

1. BanList update failed
2. Downloader disconnect Peer lagging
3. user manually changed BanList

Reapplying the full list is a fix, but it sometimes doesn't always work, especially since some qBittorrent occasionally stops processing the BanList while it is running, and the user must be instructed that when a large number of WARNs and ERRORs recur, there must be some kind of problem.

[Anuskuss]

Ah okay, I misunderstood then: The error happens because the peer is already blocked but the client is still connecting to it. I guess I'll merge transmission/transmission#7167 myself and see if it still happens.

Edit: Seems like merging 7167 is not possible using 4.0.5/4.0.6 as base because too many changes happend since then. I'm not comfortable running master because I'm sure new bugs were introduced since the last stable so I'm resorting to StandardOutput=null and RuntimeMaxSec=1d for now.

[azicen]

For what it's worth, our community members have created a tool that can proxy the Transmission API and the System Firewall API and convert them to the qBittorrent API and provide it to PeerBanHelper or any other program that needs the qBittorrent API (although it's not yet complete) if you're interested.You can check it out at: https://github.com/azicen/transmission-proxy无论如何，我们的社区成员创建了一个工具，可以代理传输 API 和系统防火墙 API，并将它们转换为 qBittorrent API，并将其提供给 PeerBanHelper 或任何其他需要 qBittorrent API 的程序（尽管尚未完成） ）如果您感兴趣。您可以查看：https: //github.com/azicen/transmission-proxy

Disclaimer: This project is not affiliated with PeerBanHelper, PBH-BTN or me.免责声明：该项目与 PeerBanHelper、PBH-BTN 或我无关。

在我尝试构建这个工具来正常使用 Transmission 时遇到了问题，即使通过防火墙中断连接，Transmission 也不会立刻更新数据快照。这会引起 PBH 的不满，尝试通过更多的 api 校验客户端数据并更新所有 banlist，这回增大 Transmission 客户端的负担，导致 Transmission 性能下降。

结论就是，即使使用防火墙拦截，也无法达到一个可用的预期，我认为还是需要 Transmission 解决阻断问题。

When I attempted to build this tool for normal use of Transmission, I encountered issues where Transmission does not immediately update the data snapshot even when the connection is interrupted through the firewall. This can cause dissatisfaction with PBH, as it tries to validate client data through more API checks and update all banlists, which increases the load on the Transmission client, leading to a decline in Transmission's performance.

The conclusion is that even with the use of a firewall to intercept, it is not possible to achieve a usable expectation. I believe that it is still necessary to use Transmission to BanList issue.

[cdowen]

Seems like merging 7167 is not possible using 4.0.5/4.0.6 as base because too many changes happend since then.

I tried backporting the fix to previous stable, but 4.0.6 lacks many utilities. Updating blocklist via rpc and getting blocklist from url are not in the codebase yet. To make it work, one need to place the updated blocklist in daemon folder and call transmission-remote to update.

Transmission release has been stuck for too long. For now I think using master is acceptable.

[Anuskuss]

Thanks for trying. I'm not sure if I wanna give master a go. The whole v4 line has not been great, it's always 1 step forwards 2 steps back. I wish they would just release a new minor version so many people can test it. Buidling master myself (and spoofing the version to the whitelisted v4.0.5) unfortunately bears the risk of getting me banned (from private trackers).

[Anuskuss]

so I'm resorting to StandardOutput=null and RuntimeMaxSec=1d for now.

I initially did this because I would quite often run into these pause/unpause loops because Transmission would (somehow) miss the blocklist update which results in a 100s of torrents (even my private ones because the ignore-private is currently broken) getting paused every 2 minutes (my update interval is 1 minute). I did try transmission-remote --blocklist-update but that didn't work and I'm not sure if transmission/transmission#7167 would even help in this case because to me it feels like Transmission just fails to load new rules (after some time?) altogether.

Anyway I just realized that Transmission has the ability to reload via SIGHUP so instead of killing my daemon once a day I'll just reload it every hour or so. Doing it like that results in 0 downtime.

Would it be possible to get that functionality into PBH? So whenever

[Repair] PeerBanHelper scheduled full banlist re-sync with downloaders

appears it should just reload Transmission instead of pausing/unpausing the torrents endlessly. At the very least I think there should be a safeguard to prevent this scenario altogether as it will never end (unless the user restarts the client) and just waste resources (on your machine and on the tracker).

[Anuskuss]

Transmission seems to be broken in v7.2. I don't expect you to fix it or even care so I'll be staying on v7.1.5 (until Transmission finally releases a new version).

Log

[00:33:28] [main/WARN]: PeerBanHelper SQLite Connection Pool - keepaliveTime is greater than or equal to maxLifetime, disabling it.
[00:33:29] [main/WARN]: [Restricted] Due to Transmission's RPC-API limitations, the PeerId blacklist function and the excessive download module of ProgressCheatBlocker are unavailable
[00:33:29] [main/WARN]: Warning: Use Transmission Adapter is discourage. Frequent starting and stopping of torrents on seeds that are often subject to bans can result in frequent updates to the tracker server, indirectly triggering DoS attacks. This increases the load on the tracker server and may lead to your IP address being banned by the tracker. We encourage you to migrate to other downloaders whenever possible. https://github.com/PBH-BTN/PeerBanHelper/issues/382
[00:33:33] [virtual-507/ERROR]: Failed to execute module Progress Cheat Blocker, please report to PeerBanHelper developer
java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()" because the return value of "cordelia.rpc.types.Torrents.getSizeWhenDone()" is null
	at com.ghostchu.peerbanhelper.downloader.impl.transmission.TRTorrent.getCompletedSize(TRTorrent.java:45)
	at com.ghostchu.peerbanhelper.module.impl.rule.ProgressCheatBlocker.shouldBanPeer(ProgressCheatBlocker.java:232)
	at com.ghostchu.peerbanhelper.PeerBanHelperServer.checkBan(PeerBanHelperServer.java:847)
	at com.ghostchu.peerbanhelper.PeerBanHelperServer.lambda$checkBans$23(PeerBanHelperServer.java:639)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.lang.VirtualThread.run(Unknown Source)
[00:33:33] [virtual-914/ERROR]: An exception occurred while ban Peer, specific Peer unable to ban, Please report these information to PeerBanHelper developer
java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()" because the return value of "cordelia.rpc.types.Torrents.getSizeWhenDone()" is null
	at com.ghostchu.peerbanhelper.downloader.impl.transmission.TRTorrent.getCompletedSize(TRTorrent.java:45)
	at com.ghostchu.peerbanhelper.wrapper.TorrentWrapper.<init>(TorrentWrapper.java:24)
	at com.ghostchu.peerbanhelper.wrapper.PeerMetadata.<init>(PeerMetadata.java:26)
	at com.ghostchu.peerbanhelper.wrapper.BanMetadata.<init>(BanMetadata.java:25)
	at com.ghostchu.peerbanhelper.PeerBanHelperServer.lambda$banWave$10(PeerBanHelperServer.java:570)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.lang.VirtualThread.run(Unknown Source)

[Ghost-chu]

Transmission seems to be broken in v7.2. I don't expect you to fix it or even care so I'll be staying on v7.1.5 (until Transmission finally releases a new version).

Log

Transmission code still exists in the repository, because we still want to restore support for Transmission.
But since Transmission has not merged transmission/transmission#7167, it is actually very unusable. Therefore, none of our test volunteers test commits related to Transmission.

I just completed a fix for this issue, but I haven't tested it yet.

[Anuskuss]

Thanks, 3e1803a fixed it indeed.

But since Transmission has not merged

Yeah I'm also thinking about switching clients because Transmission seems to be close to death but who knows, maybe it can make a comeback.