(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 and say "use this network for this app".)
The other feature I'd like to see is sequential downloads, but the developers object out of principle so that is never going to come.
The only downside is that @haugene has gone missing for sometime now, as such there are no firm releases. If you want new features/bug fixes, you have to pull dev, which isn't very ideal. Otherwise the maintainers are doing a great job (shout out to @pkishino!)
Within openwrt, I’ve installed WireGuard and OpenVPN for accessing different vpns.
Finally, again in openwrt, I installed the policy based routing package[1]. This package makes it super easy to route all traffic from the transmission container to the VPN network.
There are probably many ways you could do this, but this setup is great for me!
Sounds pretty awesome. I've not dabbled with PBR on home equipment. We did use it in prior employment to force all PCI traffic over a dedicated physical network between datacenters.
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 because people would be sending only specific traffic through them instead of everything.
Coddling users is harmful.
- ip netns add vpnonly # create an empty namespace
- ip netns exec vpnonly wg quick ... # connect to your VPN
later, launch transmission inside this namespace:
- ip netns exec vpnonly transmission
has the nice property that as long as you do that exec step right (or even half right), the failure mode is no connectivity rather than accidentally sending traffic in the clear.
I don't expect torrents to be available for a long time. Only very few people keep the torrent entry in their client alive for long, even though I keep around all the files. This is as opposed to eMule and older systems, where you can download any file in the user's media folder.
This goes against the general cluster inter-peer everybody swaps what they have so far w/out reference to file position for maximising transmission within a swarm design of the torrent protocol.
Start with a default policy of deny and work from there, if you’re only creating rules for allowing traffic explicitly then there’s less possibility for error.
I wish transmission supported mutable torrents (BEP46). It would allow completely re-thinking distribution: grab a torrent of your favorite distribution, and have it auto-update to the latest version.
Or grab a "super-torrent" that lists isos for all known distributions, select the ones you're interested in, and let it update... Of course, that can be used for file-sharing repositories too.
Maybe transmission is not interactive enough for such a use-case (you'd have to ask the user what they want to do when the torrent mutates, and possibly add simple scripting interfaces for more complex heuristics).
That sounds horrible. My own expectation is that if I have a torrent file/magnet link and I download from it, I always get the same content. This is why I commonly keep the magnet link/torrent file around even if I delete the content itself, so if I want the same thing in the future, I just re-download it and I'm 100% it's exactly the same.
This change would break that expectation, for what benefit? This could be implemented as a HTTP call instead, that serves different torrent files, so you can just change whatever serves the torrent file in order to mutate what gets downloaded.
The main benefit is not having to rely on a centralized HTTP server and repository, as well as the associated infrastructure: DNS, TLS, CA, etc. One could host a blog over torrents (more or less what IPFS is doing).
We already have RSS feeds for what you describe (though not supported natively by transmission).
> My own expectation is that if I have a torrent file/magnet link and I download from it, I always get the same content.
That wouldn't change significantly. The mutable torrent content is basically a .torrent that points to whatever the current version is; so just save that instead.
The good thing with mutable torrents (or mutable content in the DHT, as pointed out in another comment) is that instead of the hash (content-addressing) being stored in the DHT, a public key is retrieved. Once you got a torrent ("trust on first use" of sorts), you can verify that the new version is from the same uploader (or at least, one that knows the private key).
I would present it with a new set of checkboxes in the torrent client: "download new versions", then if checked "delete previous version after downloading updated content" and for more granularity "download new files", "download updates to existing files". Of course, for ease of use it would be better to have a historical view. I think the main use-cases would be to archive every intermediate version, or to just grab whatever is latest. There's infinite variations in-between. One thing I would like to stress, and that I didn't point out enough in my original comment is that this goes extremely well with v2 torrents and their de-duplication feature: if the same file exists in multiple versions of the torrent, peers with any version can contribute to the swarm.
It's not as good for deduplication as a rolling hashes could be, but you could host whole distribution repositories with mutable v2 torrents.
You could imagine hierarchically pushing the entire of TPB or whatever into the DHT. And even, each torrent having an `index.html` that renders a page containing links to the rest of the sub-torrents, so that the entire site is hosted in the DHT.
Not necessarily sqlite, that said. It might be useful for openstreetmap tiles/db, or indeed repositories like library genesis, wikidata/wikipedia dumps, etc.
It is not very known but there actually is a transmission-cli for common torrent operations that may come in handy some time.
Wah! Bad news! I like to kick off a download from an SSH shell. Now I have to find out what transmission+remote is.
It's great for keeping downloads going overnight without having to leave all the power-hungry devices powered on.
edit: ok, size is ~4.5M on my Debian, of which transmission-gtk accounts for 3.6. Maybe graph libs are bigger on mac ?
3.5mB is for a Quicklook plugin, so that Torrent files can be previewed in the Finder.
4.5mB is UI 'stuff'. The Cocoa 'nibs' that define the application UI tend to be bigger than comparable GTK XML files.
I remember using some obscure tool before 2010 to intercept these packages and update them. I was in my early teens back then and used it to overreport my upload statistics by something like x2 on some private trackers, so they wouldn't ban me.
The maintainers reject the proposal to block by client ID. But they never consider the second method.
The birthplace of BitThief.
Does it not upload to none Xunlei clients or does it leech Bittorent entirely? I can’t imagine one that is a pure leech could exist without harming BitTorrent
I hope they figure out their maintainer issues.
Cool to see community listed as a feature up there with the tech stuff
That means future improvements are going to be 2x easier and we’ll see the product mature much quicker in the future.
Transmission has a huge market share, particularly in open source circles. Lack of support for the V2 spec has stopped many open source projects from migrating their torrents to the V2 spec, because transmission clients won't work.
Please support and use other open-source torrent clients, because Transmission's long-standing history of going years between updates and their significant market share simply is not healthy.
The first client to support v2 spec was two years ago; same year the libtorrent library that some clients use supported v2: https://torrentfreak.com/biglybt-is-the-first-torrent-client...
But there are no new killer features. I would guess that the extra user headaches from having outdated software not work with new torrents will exceed the benefits of slightly faster downloads and slightly better availability.
Agree that it's been a long time but isn't this V4 release about to speed up development? New cleaner codebase, new contributors, ...
That was done recently in https://github.com/arvidn/libtorrent/pull/4123, merged to master, but hasn't been released yet.
Per the master changelog, that should be soon, I guess... https://github.com/arvidn/libtorrent/blob/master/ChangeLog
It's built on top of WebRTC.
Webtorrent and regular torrents can exist of the same file, but crucially, at least some small percentage of the people in the network have to support both webtorrent and regular torrent to act as a kind of bridge between the two.
If this isn't the case, you might have a webtorrent user who has the file, and a regular torrent user who wants the file, but the two people can't connect to eachother because they're talking different protocols, so the file won't be delivered.
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...
I've been torrenting since the early 2000s and using torrent clients on Mac and Linux for over ten years, and there have been various issues in both Transmission and qBittorrent for as long as I can remember. I'm not sure if rTorrent is better, but lots of people seem to like it.
QBT has a tendency to break on upgrades and then it tries to rename files and do re-checks and all sorts of messy stuff - maybe due to my configuration since I have "append !qB" to incomplete files - but I personally don't think a client should ever rename a file from 'video.mp4' -> 'video.mp4.!qB' unless the checking is complete and it has already determined the file needs to be partially re-downloaded. Also, checking torrents is basically a broken feature since v4.4 - according to a bunch of people on the internet. I'm on the latest version, but going back to a working version could be a nightmare with hundreds of torrents on multiple hard-drives.
I used to use Transmission exclusively but pretty much stopped using it because of the single-threaded limitation. Also, Transmission on linux didn't support categories or labels like the Mac GUI version did, which I required for organization.
I'm not sure how much goes into a Torrent client, though I did read [madreyels]<https://mandreyel.github.io/posts/rust-bittorrent-engine/> post on writing a bittorrent engine in Rust. I'm not saying rust is the answer, but I would welcome a new and improved bittorrent client meeting my requirements in any language if it works better than the existing options.
/media/pi/WD\ Elements on your user@local machin instead of ~/download/torrents.
I hope it's fixed.
https://hub.docker.com/r/picotorrent/server
but last updated 2 years ago, so not sure what's going on there
That would give the distribution platform the idea that what they are doing is OK. In this case, just download it and don't pay for it, if they are not actually providing you of any service. Vote with your wallet.
For me, streaming services for music is no-go. It is not about money, it is about control.
I prefer to listen only albums (not playlists, tracks, sets, mixes, etc), and I prefer to choose masterings & presses. Yes, Spotify has whole King Crimson catalog, but which masterings/remasterings among many? I don't know, Spotify doesn't provide this information and can change material at any moment without notification. Also all streaming services has stupid regional limitations (and I'm in process of transitioning from sanctioned country to "normal" one, good luck to use streaming services in this situation), and could remove whole catalog on whim due to some problems with label.
If I can buy music in ownable format (which means mostly "if it is presented at bandcamp"), I buy it, no problem. If I cannot - I download it. Also, I'm still buy CDs on concerts. Again, it is not about money (I've spent on bandcamp much more than several years of Spotify subscription), it is about owning music I love in exactly form I want.
See, I do have Netflix, Amazon Prime, Disney+ etc. but they each have their own app and even their combined coverage is not complete.
Do you know who has the (almost)complete movie&series coverage? Fmovies. That's where I watch most of my stuff lately, because of convenience. The legal content providers screwed it up again, once more they are not the most convenient way to watch movies and series.
Every now and then Fmovies would not have something, or I would like to watch something immediately after it's premiere and it would take more hours to be added to Fmovies. Sometimes I really like something I would like to keep it and make sure not lose it for re-watch or some movie has such a nice visuals that I need it in the best quality possible.
That's where Transmission comes handy.
Supports AppleTV, Android, Android TV, Roku and Fire TV in the USA.
AppleTV, Android, Roku and FireTV in the UK.
Why have they decided to not support my Shield TV in the UK? Who knows but NowTV has the same limitation so sometimes you have to find alternatives.
Also I can go to rarbg and find whatever I want, whenever I want, without ever needing to check whether this or that service has this or that particular movie. It's like how Netflix used to be, a single directory for all media, only even better due to the aforementioned constant and high bitrate.
There are also other more legit usages of BitTorrent: I use it often to download Linux install images so that the network load is distributed among users and I do not tax excessively the servers.
Where in Europe is it not available on Netflix? Or is it the case of Netflix being unavailable?
> There are also other more legit usages of BitTorrent: I use it often to download Linux install images so that the network load is distributed among users and I do not tax excessively the servers.
Yeah, personally I use it to grab Path of Exile updates. The team release a torrent earlier so that people with bad internet connections can grab it early, it works great.
There are 200,000 movies, and Netflix and others catalogue 2000 of them. If you think of a movie to watch there’s literally 1% chance that it will be available for streaming.
I have almost never watched a movie I seeked out on the streamers. It’s the other way round, the streamers offer me some movies and if I’m interested I watch it. But their catalogues are laughably small. Completely incomparable to the music streaming catalogues which are really vast.
Used it today for some archive.org content
I am once again asking the entertainment industry to charge me literally any price they like per month to have all this in one place permanently.
Boxee was excellent for this, we used their services, and paid for them, but a standardised interface let me watch shows from different networks.
These days they would have to work with Plex but they would never actually cooperate.
That is the reason I use Transmission over anything else.
https://www.addictivetips.com/ubuntu-linux-tips/set-up-qbitt...
Mentioned on homepage, too:
> Remote control through Web user interface, written with AJAX
>> Nearly identical to the regular GUI
Torrents typically don't do more than a few thousand DNS lookups - which isn't much more than a few people browsing the web.
And most of those lookups are just for showing pretty flags and country codes in the UI, and aren't needed anyway.
Linux isos are frequently pointed out as a use-case. I've seen it used for distributing neural network weights recently (stable diffusion and others). Rainbow tables and password lists too: https://freerainbowtables.com/
I have used it to efficiently distribute big files (disk images) over hundreds of computers in LANs. Computers on local switches can exchange data with each other, and computers can come and go on the network.
For instance, if you're in the infrastructure group in a company, and you need to distribute VM images around the place, it's great.
Over 10 years ago I've worked on a very custom BitTorrent-related application for an ISP. Roughly, it was a piece of software that acted like caching proxy but for torrents, intended to lower upstream congestion. Legal questions aside, it was a success - but, anyway, back to Transmission.
I needed a very custom client, and libtransmission was (in my personal opinion) hand-down the sanest and powerful option. I liked the design of the API, how there are only a minimum number of hoops to "just" get a torrent running, and yet how one can gradually expand. Honestly I don't remember any details beyond the overall impressions - it was very long time ago - but I liked it. And what I remember is that one of the features I valued was that it was written in C - because I wanted to use it from Python. I mean, C ABIs are generally quite significantly easier to work with in any language that has FFI, compared to C++ ABIs.
CFFI had improved since then, of course, and I haven't looked into v4 library at all so maybe they have an interface without any C++ nuances... But in general, the point is that libraries written in C are typically easier to interface with.
