Transmission 4.0.0 beta 1(github.com) |
Transmission 4.0.0 beta 1(github.com) |
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.
Also, why would you have a DNS quota? I guess some DNS blocker service like NextDNS? Either pay them the money, put a local cache on your torrent client (or use a pihole with blocklists), or have the machine with the torrent client use another DNS server.
In terms of actual features, Transmission is more lightweight. It doesn't support super-seeding, broadcatching, native SOCKS support and doesn't have built-in search engine integration.
If you want to go that route you might as well use Deluge, which is built on the same libtorrent library, has a proper daemon-client architecture with fully featured native clients for all major platforms.
This is true but for me this is a disadvantage. qBitTorrent allows to fine-tune a lot of settings. Not as many as Tixati but still.
Here is the libtorrent code that does it for every peer:
https://github.com/arvidn/libtorrent/blob/8786d17e59c90aee2c...
(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).
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.
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, ...
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 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.
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
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...
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.
$ transmission-remote -a one.torrent two.torrentI really don't follow you there
I suppose they removed bittorrent's weirdness of allowing chunks to overlap multiple files. That was the original sin that caused all this
So presumably in a similar manner as https://github.com/phiresky/sql.js-httpvfs you could map SQLite pages to leaf torrents too and get the chunking you are looking for.
You can create a fork and implement the feature or pay someone to implement it for you. That's the wonderful benefit of free software.
Just so you know (and stop using that phrase), there is no way scientifically or otherwise, to attribute the effect of non-sales to a feature, a service or anything else.
Your opinion on the matter just never shows up during product decisions, planning or analysis.
Your "vote" just doesn't exist.
Maybe the terminology is wrong, but I don't find the concept of "don't pay for what you cannot/won't use" wrong.
In a general sense, any video content where the bitrate is lower than the typical users upload bitrate could work for a webtorrent only swarm of 'regular' users who aren't going to do anything special for network health.
Let's say I have a movie I want to let other people stream with their browser. I am obligated to use some javascript horror webtorrent-compatible client. If I already have a seedbox running transmission I simply cannot use that for this purpose, which is a shame
The actual .torrent file is the same for both, so it already has support there.
> Or in being to transparently talk to web clients from transmission
This. Currently if all peers who have the data of a torrent are webtorrent clients, then transmission won't be able to download that file.
Most importantly, the webtorrent ecosystem is still small, and browser-based webtorrent-only clients suffer because frequently they can't get the file data they need because all the other peers only talk the original-torrent protocol.
If it supported these as a transport mechanism, transmission would be able to communicate with torrent clients that run in the browser, making the potential number of peers much higher (both for swarms that are mostly in-browser, and for those that have a majority of traditional clients). It would be very useful for seeding peertube videos from transmission, for instance, which was the quoted use-case.
The important part is to keep track of what's happening with your own connection to others, not what other peers are doing.
99%+ of the time any pair of peers has unidirectional traffic. The situation where two clients will have incomplete torrents and are exchanging data with each other is rare, like the first few hours after a brand new torrent hits the network.
Another interesting example of people embracing the pirate image was British submarines in WW1. The First Sea Lord of the day saw them as ungentlemanly and called for all German submarine crews to be hanged as pirates, this outburst birthed the tradition that a British submarine returning home after successfully sinking an enemy vessel flies the jolly roger! The last time this occurred was after the 1982 Falklands War, I believe HMS Conqueror to this day remains the only nuclear submarine to have engaged an enemy ship with torpedos.
pirate (n.)
Meaning "one who takes another's work without permission" first recorded 1701; sense of "unlicensed radio broadcaster" (generally transmitting from a ship outside territorial waters) is from 1913.
pirate (v.)
"to rob on the high seas; commit piracy upon," 1570s, from pirate (n.). By 1706 as "appropriate and reproduce the literary or artistic work of another without right or permission; infringe on the copyright of another."
-- https://www.etymonline.com/word/pirate
sadly it doesn't explain the how of the word coming about.
"The term "piracy" is used by record companies to demonize sharing and cooperation by equating them to kidnaping, murder and theft." [0]
(Better read it in entirety, if you haven't yet)
Literal pirate parties exist in Somali and prey on nearby shipping lanes.
Torrenting non-free products from unofficial sources is illegal.
The main point of computers is to make things easier for people. Most of us make our livings because computers are very good for that. If most users really had to deeply understand the technologies involved in solving their needs, a lot fewer of us would have jobs and much more time would be wasted by people who were just trying to get something done. So yes, let's absolutely coddle users.
The point of computing is to be a tool to make people more powerful and efficient, an extension of our abilities, able to do more or better.
The point of a tool is to make things easier for people.
Also, youtube just served me an un-skip-able 12 minute add 30 seconds into a video. It was the 3rd add. The thought police is all over the web now. My windos cant download photos from my iphone. My windos is rebooting when it feels like it. The glued in phone battery life is garbage after 2 years. I must have purchased 30 chargers now. My new laptop requires a microsoft account. Google search is not working anymore. Adsense is driving up prices.
Its like trying to get nutrition from MacDonalds. The mc drive is convenient tho. Very easy for users.
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.
"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 assume using a vpn is more secure. That is a wrong assumption.
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 a reason: no nonsense-seeking users. They're the majority. Just let me download my file bro.
But to be more specific with my feedback, it seems a bit silly that Transmission (I'm trying 4.0.0b1 right now) doesn't allow me to specify that it must use "VPN X" (as opposed to "VPN Y", which is also available) for downloads.
I understand that I could mess with namespaces or containers or VMs and probably make that work, but "use Bittorrent client with VPN" is more or less a universal use case and should be straightforward.
I agree with this statement, but what should a user ‘read’ in order to understand this?
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...