Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transmission 4.0.0 beta 1

github.com

Post reply on HN
Print view View original

211–220 of 262 posts

Re: Transmission 4.0.0 beta 1

#211

Post by zaik »

denton-scratch wrote: post #109
xpressvideoz wrote: post #101

Earlier quoted context omitted.

FYI, transmission-cli is considered deprecated by the Transmission developers. Using both transmission-daemon and transmission-remote is the recommended approach. Actually, transmission-cli uses transmission-daemon internally and they share the same configuration. transmission-cli is still useful for one-off downloads, but I still prefer the recommended way because I'd like to seed older torrents some more time.

> transmission-cli is considered deprecated Wah! Bad news! I like to kick off a download from an SSH shell. Now I have to find out what transmission+remote is.

You can still do that

   $ transmission-remote -a one.torrent two.torrent

Re: Transmission 4.0.0 beta 1

#212

Post by zaik »

netheril96 wrote: post #127
hrbf wrote: post #32

Earlier quoted context omitted.

It’s probably impossible to track that with any meaningful precision. Historically it’s the (central) tracker that implements the bookkeeping.

It’s quite easy to block Xunlei. First, they identify themselves in the connection. Second, no matter how much you upload to them, they always report zero progress. The maintainers reject the proposal to block by client ID. But they never consider the second method.

Both methods can be circumvented quite easily and it will happen, if Transmission were to implement this. It's a cat and mouse game you can't win.

Re: Transmission 4.0.0 beta 1

#213

Post by singlow »

captainmuon wrote: post #112

Good to see it being in active development. But the one feature I'm waiting for is a network whitelist. For example, it should never connect over my home or office network, but only via anonymous VPN. (Edit: I know you can do this already with firewall rules, or containers, but I don't trust myself to not make a mistake. Ideally this should be part of the OS. You should be able to right-click somewhere in the window…

Set http_proxy environment variable to a socks proxy that goes through the vpn. Some vpn clients offer a socksproxy built in. That way if the vpn is not connected the proxy address is dead.

Re: Transmission 4.0.0 beta 1

#215

Post by netheril96 »

zaik wrote: post #212
netheril96 wrote: post #127

Earlier quoted context omitted.

It’s quite easy to block Xunlei. First, they identify themselves in the connection. Second, no matter how much you upload to them, they always report zero progress. The maintainers reject the proposal to block by client ID. But they never consider the second method.

Both methods can be circumvented quite easily and it will happen, if Transmission were to implement this. It's a cat and mouse game you can't win.

Ad blocking is a cat and mouse game. Anti censorship is a cat and mouse game. Anti fraud is a cat and mouse game. Anti spam is a cat and mouse game. I don’t see people giving up so easily on those problems.

Re: Transmission 4.0.0 beta 1

#217

Post by newaccount74 »

vorpalhex wrote: post #192
anderspitman wrote: post #187

Earlier quoted context omitted.

Agreed. Users shouldn't have to understand firewall rules, containers, VMs, or even VPNs in order to tunnel traffic for a specific app through a (more) trusted third party. We need an open protocol for establishing tunnel/VPN connections. Apps implement the protocol, which lets you enter your tunnel provider and go through a quick OAuth flow to establish a tunnel. This would be a big win for VPN providers as well bec…

Users should understand how to use their computer. Asking users to comprehend a firewall or a vpn (if using a vpn) is not unreasonable. Coddling users is harmful.

This isn't about coddling users, it's about not reinventing the wheel.

Sure you could spend hours reading pf man pages. But maybe it would be better use of time if one person figures out how to do it, writes code to do it automatically, and shares that with other people so they can spend more time watching all the movies they download instead of configuring their bit torrent client.

Re: Transmission 4.0.0 beta 1

#218

Post by remram »

xd1936 wrote: post #207
remram wrote: post #185

Earlier quoted context omitted.

Which clients do have support for webtorrent?

Many! https://webtorrent.io/faq Notable ones include Libtorrent[1], Peertube[2], and their own Webtorrent Desktop[3]. 1. https://github.com/arvidn/libtorrent/issues/223 2. https://peertube-viewer.com/posts/2021-02-20-peertube-viewer... 3. https://webtorrent.io/desktop/

I meant torrent client programs, not libraries or websites.

Re: Transmission 4.0.0 beta 1

#219

Post by newaccount74 »

ByThyGrace wrote: post #206
vorpalhex wrote: post #201

Earlier quoted context omitted.

"Hey why are my torrent downloads running super slow?" "Oh, well, your torrent client decided to automatically use your vpn because it saw one running and somebody decided that was the right behavior because they thought you were dumb." Users have preferences. Users can read. Let them learn and sort it out. Don't ruin a simple program with tarred assumptions of what is correct for users. Prefer simplicity. Also don't…

I don't have a horse in this race, but I think you're presuming simplicity where there is none. A bittorrent client, even in CLI form, is not simple software at all. Have you ever taken a look at the myriad of available settings? Most GUI clients have a sort of "wizard" that helps you pick acceptable connection parameters. This feature alone has a truckload of assumptions coded in. And that kind of feature exists for…

It also makes sense that the developer chooses parameters. They are probably the person with the most detailed knowledge of the problem, they are probably the person who knows best what the parameters should be.

It baffles my mind when developers just expect users to tweak low level settings. Sure, it's good if stuff is configurable, but it should work correctly out of the box. Like, you spent days or weeks working on this feature, don't expect your users to do the same...

Re: Transmission 4.0.0 beta 1

#220

Post by talideon »

Macha wrote: post #30
ksec wrote: post #27

My biggest problem with BT / Transmission is that they dont work well with DNS Ad blocking solution. As the BT client will quickly swamp and use up all available DNS quota for torrents. I am wondering if anyone has a solution to that?

I can't say I've noticed this, and I'm a little surprised DNS gets much use in bittorrent at all, is the client doing rDNS on peers or something?

Essentially, yes. It's basically looking up the PTR records. If you look at the UI, you'll see them listed in the peer list.
Post reply on HN