BiglyBT is a feature filled, open source, ad-free, BitTorrent client | Hacker News Reader

BiglyBT is a feature filled, open source, ad-free, BitTorrent client

biglybt.com

98 pointsgjvc68 comments

One feature I really liked in BiglyBT is the ability to download the same file from 2 or more "forked" torrents. For example some pirate groups "pirate" the releases of other pirate groups by just renaming their files, adding some meta info and publishing a new torrent. This causes a split in the seeders and peers as these different torrents form separate torrent swarms, while all are downloading the same file(s). BiglyBT can "merge" these torrent swarms to download the common files from 2 or more torrents.

Wish it wasn't based on Java though - seems so 90's to have to install a framework first (JRE) to run something (and then having to worry about keeping it updated for security).

New BitTorrent 2 protocol supports this nativly if I recall correctly the standard was recently confirmed now trackers and uploaders need to implement it

Why would I use this over Transmission or qBittorrent?

I'd like to know this, too. What sets it apart? I'm especially curious about performance, because both Deluge and qBittorrent chug a little bit on my machine when I have too many torrents listed.

You can limit qBittorrent pretty nicely with a cgroup if you're on Linux. It won't crash and won't lose much performance.

I'm forcing it to use between 75 and 125MB and it doesn't complain.

Note: I'm using "nox" variant as a user service and control via a web browser.

Qbittorrent recently introduced sql based resume file it is advanced option in beta I see an improvement with about 1000 torrent. Though for 1000+ torrents most people recommend rtorrent.

Or picotorrent https://github.com/picotorrent/picotorrent

From the Features page, looks like the main differentiator is social and content features:

* Tag Discovery to discover what other users have tagged content with. This can be very helpful before deciding to download the content.

* Decentralized ratings and comments. You can view them before the torrent is added to BiglyBT.

* Decentralized public and anonymous chats with default channels for individual torrents, tags, subscriptions, and trackers

* Media Playback

* Media Conversion (Transcoding)

* UPnP Media Server and DLNA support, allowing devices to connect and browse your content, and allowing BiglyBT to send content directly to devices.

https://www.biglybt.com/features.php

how does the anonymous chat work? wont you be able to see the ips from the peers?

It could theoretically route your chat messages through other peers so nobody knows if you wrote the message or you're forwarding it for someone else.

Such a scheme seems open to spam by design. I don't think there's any way to handle spam/moderation in a fully anonymous decentralised network.

> I don't think there's any way to handle spam/moderation in a fully anonymous decentralised network.

Surely you could have small bayesian engines running in each client, and coordinate ratings through DHT. It would still have the issue of somebody potentially abusing such engine to effectively DDOS certain types of messages (e.g. mentioning a certain party), but you could try and fight that with modern consensus techniques from the cryptocurrency world.

> Surely you could have small bayesian engines running in each client,

If each client has a copy of the filter, then so does the spammer. The spammer can use that to craft spam the filter doesn't catch.

The lack of filter availability doesn't stop spammers bypassing even Google's uber-filters, so it's not much of an argument really. The arm race is what it is. The point is having a system that can react fast enough to remove the spam from most systems once it is identified.

> The point is having a system that can react fast enough to remove the spam from most systems once it is identified.

Then you need a system for distributing filter updates, and preventing the spammers from distributing bogus filter updates. Isn't this basically just the same problem as before?

That's why I said that injecting some modern consensus-finding strategies could be an idea.

Reminds me of https://notabug.io/ which makes you sacrifice some CPU in order to vote.

There's also an Android app:

BiglyBT, Torrent-Downloader (ad free, open source torrenting for phones, tablets, Chromebooks & Android TV) - https://f-droid.org/packages/com.biglybt.android.client

A bittorrent client is a cpu-intensive application... why would I want to use a java application for this?!

Could it be that only the UI is in Java? I’m on mobile, I did not check sources, but that would be reasonable.

It's mostly Java, GitHub reports 99.1% of the source is Java, with tiny sprinkles of C++ (0.5%), C (0.2%), Objective-C++ (0.1%) and Objective-C (0.1%).

You're missing the second half of your reasoning here. Why would Java applications be unsuitable for something CPU intensive? It matters more how you build your program than what technology you use, as long as you use the right data structures and algorithms, Java is as suitable for CPU intensive tasks as any other language.

For what it's worth, a BitTorrent client will (usually) be more limited by network and disk I/O than by your CPU, as those tend to be the bottleneck when it comes to transferring large amount of data/large amount of small packets (DHT).

One of the best ever BT clients was Azureus (later Vuze), and it was indeed a Java app. It hammered the disk like it was nobody else's business.

Bigly is actually a vuze fork

I remember back in Kazaa/LimeWire/WinMX day, Azureus was a powerful beastly BT client. It is a massive beast that took my computer to fully load Azureus in 10 minutes. And that was the only powerful BT client at the time and people hate it because it is powerful but it is CPU intensive. BitComet, BitLord, FlashGet couldn't hold a candle against Azureus. Until qBittorrent, uTorrent and Transmission popped up few years after Azureus initial release. What a time to be alive back then.

The great thing with Azureus is if you could download bits of content somewhere else you could copy them in and it would take that into account.

This was quite handy for a big torrent of music videos back in the day with not enough seeders.

Is this a Vuze fork? Last time I remember using Azureus, it was a bloated slow mess.

Azureus - not heard that word in over at least 15 years or so. Thanks for the trip down memory lane!

> Two long-time developers of the Vuze BitTorrent client, formerly known as Azureus, have launched a new client. BiglyBT emerges at a time when Vuze development has stalled. The developers promise to take the project forward while removing all advertising and other annoyances.

It's a full-on Vuze fork

BiglyBT is the cleanest and easiest Android torrent client that I have used.

Just trying it now - I don't know how I've missed this application before, but someones been keeping it quiet :)

doesn't it kill your battery?

This one of the few bittorrent clients available for Android

BiglyBT is awesome, it supports Bittorrent v2, stream merging and also includes its own media server so you can stream videos while they are downloading.

The interface is a little slowish but extremely customisable.

It's a real power-users client with every feature imaginable.

You can increase the heap size and various cache sizes, which will greatly increase performance. Turn on advanced mode and search around the settings.

I've been using f-droid for a long time. Does the play store advertises when an app has advertisements? Is it possible to search the play store for ad-free apps? Is is possible to search the play store and filter the results by license?

The play store shows a badge on apps with ads, but I don't remember if you can filter on it.

You cannot filter apps based on ads, with the official Play Store app.

It is nice to have some competition and so thank you to the developer, but I see no reason to use this compared to qBittorrent, Transmission, aria2, etc.

This one seems to be a lightweight Vuze fork. The differential is that it should have most of the Vuze features, which are not necessarily available for the programs you mentioned. Swarm Merging, for example, seems to be exclusive to Vuze. I've never used it though, so I don't know how appealing that is.

BiglyBT is the new name for Azureus. It’s older than qBittorrent and Transmission. The reason people use it over those alternatives is that those alternatives didn’t even exist when they started using it, and they haven’t offered any features since to make switching worthwhile.

> they haven’t offered any features since to make switching worthwhile.

Ish. The main advantage of newer clients were simplicity and nimbleness: Azureus/Vuze was a bit heavy on memory, at a time when this mattered more than today. After the Vuze renaming, it also went down a dark ad-filled path that did it no favours, to be honest. So a lot of people moved away.

It does not seem to support WebRTC peers, a pity.

I don’t understand why thats bad.

https://github.com/webtorrent/webtorrent/issues/1654#issueco...

qbittorrent-nox-static (go with 4.3.9 for now, 4.4.1 still has a memory leak) is the way to go, IMO, on a linux server.

Absolutely love this on my Android mobile!!!

Personally I prefer LibreTorrent for mobile

https://github.com/proninyaroslav/libretorrent

Tixati is the best client out there

It's fast, and has all the features needed

For desktop and gray area torrenting I've not found anything better than qbittorrent

* webclient with separation of LAN/WAN password requirements

* interface kill switch

* handle hundreds of torrents (more than that I would go for rtorrent)

* Updated often

* built in search plugins.

* not bloated

* primarily written in c++

Few days back only I got a malware notification while updating it.

False positives happen all the time when developers forget to scan and (automatically) provide signatures to AV vendors before releasing.

Man clicking on the release blog post was a mistake. Tumblr straight up hijacks the return button and you can’t go back. On mobile that is.

> Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

https://news.ycombinator.com/newsguidelines.html

Yes. Ignore the issue and move on

My bad.

right click on the back button and go back to where you want to go :)

Thanks, I'll avoid clicking through. I appreciate the warning.

Can I tell it to always "Download in sequential order" and "Download first and last pieces first"? I can set it in qBittorrent, but theres no option to remember for next torrents, forcing me to select those manually everytime. The issue has been brought up but was rejected with reasoning "If everyone would do that, the health of torrents, especially fresh ones, would degrade drastically", completely ignoring that some people usually download torrents where seed/peer ratio is above 100, and it doesnt affect the health of the torrent in the slightest.

The solution here seems obvious, switch to random downloading if the seed/peer ratio is under some number.

It frustrates me how indifferent some authors are to the user, though I guess I can't complain too much for a free product. I usually just fork them.

In the scenario you describe, the response of the author still applies. It may frustrate you, but that doesn't change the reality.

Some systems are more appropriate than just those options, but it requires player cooperation.

For instance on Android, NOVA Video Player supports torrent streaming. Or btplay from https://github.com/johang/btfs .

The way they work is better for the network, because it asks only for the N next MB from current position to be available ASAP, but the rest can be downloaded randomly to help the network like a standard client would do.

This is excellent implementation. Just today, when I was waiting to download 500 MB zip to extract 16 MB exe I needed I was thinking why all files aren't streamed everywhere.

> Installer for Linux, BSD, etc

> Requires GTK and java-headless

Reply on news.ycombinator.com