Changes in JLibtorrent


JLibtorrent is a Java interface for libtorrent by us, the makers of FrostWire, with it you can develop libtorrent based apps and services with the joy of coding in Java.


On this release we’ve integrated significant updates from libtorrent’s RC_1_1 branch. If your app/service uses jlibtorrent you’ll be ahead of the curve by upgrading to with respect to the majority of bittorrent clients out there that are built in C++, this is the beauty of using jlibtorrent, you’ll always have the safest and fastest bittorrent engine under the hood without compilation and linking nightmares.

- don't perform expensive hash of piece data for logging
- fixed popcnt asm for x86 and gcc/clang
- move storage "file-by-file"
- fix file_completed_alert, it would not be posted unless file_progress had been queries by the client
- fix filename escaping when repairing torrents with broken web seeds
- fix crash in session::get_ip_filter when not having set one
- fix mutable dht_get_item failure when salt is non-empty
- fix range of lsd::cookie
- don't send bitfield to peers whose handshake we haven't fully received yet
- update our id in the rpc manager when it changes
- make local service discovery cookie support not so random numbers
- fix value of current_tracker when all tracker failed
- hack to allow timeout utp sockets that are about to be closed
- fix re-prioritizing a piece while it is downloading
- handle short reads when exporting a file
- make pad-file and symlink support conform to BEP47

Re-release: FrostWire 6.3.3 build 190 for Linux

FrostWire Contributor deivid-rodriguez found issues on the .deb and .rpm installers of FrostWire 6.3.3 build 189 and sent us a fix.

We’ve bumped the build number (as no upcoming changes have been included in this build), and we’ve proceeded to re-release the linux installers on our official website, on and on

FrostWire’s improved Magnet URI support (BEP 0009)


As of FrostWire +6.3.0 for Desktop, and FrostWire +1.7.4 for Android, all FrostWire clients can now interpret the new peer= parameter


Where <peer-address>…

<peer-address>A peer address expressed as hostname:port, ipv4-literal:port or [ipv6-literal]:port. This parameter can be included to initiate a direct metadata transfer between two clients while reducing the need for external peer sources. It should only be included if the client can discover its public IP address and determine its reachability. Note: Since no URI scheme identifier has been allocated for bittorrent xs= is not used for this purpose.

The immediate result of being able to pass and receive this parameter on magnet addresses is that FrostWire will try to include as many ip:port available it can find so that others can connect to your peer, try sharing files on your local Wi-Fi network now, vs doing the same on older networks.

We don’t know if other BitTorrent clients already support this parameter, therefore we suggest that when sharing Magnets from your computer, you tell the other party to use a new version of FrostWire and you’ll have a greater chance of connecting right away.

libtorrent team announces 1.1 release

Arvid Norberg, lead developer of libtorrent, the library FrostWire’s jlibtorrent wraps into has announced today a 1.1 release. In the paragraph’s below Arvid’s words from the BitTorrent developer mailing list.

You can get it here:


Since this major release has been in the works for quite a while, the
changelog is too long to include here. Instead, here are the highlights:

* disk I/O and piece hashing can now be done in multiple threads.

* The internal allocation of alerts is a lot more efficient now, and
requires alerts to be owned by libtorrent. The pop_alerts() function that
returns a container of raw alert pointers are owned by libtorrent and will
be freed by the subsequent call to pop_alerts(). The previous alert popping
functions will still be around when deprecated functions are enabled, but
they will cause more copying and likely have worse performance.

* experimental support for BEP 38 (mutable torrents). Basically this will
attempt to merge torrents that share files.

* there’s a new bdecoder which is a lot quicker than the previous
lazy_bdecode() ( )

* improved shutdown delay by canceling unimportant DNS lookups. (stalled
DNS lookups for tracker announces can cause significant delays when
shutting down).

* verbose logging is now done through alerts (which is possible now since
alerts are a lot more efficient). This means a production build can have
logging enabled at compile time, and enabled on demand when trouble

* SSL over uTP connections is now supported.

* settings of various kinds have moved into the session_settings structure
(proxy settings, listen-interface, protocol encryption). A session can now
be constructed from a session_settings object, allowing for single-phase
initialization. (no more setting settings on the session object right after
constructing it).

* support for part-files. This is still a bit rough on the edges. Files
with priority 0, will have their pieces stored away in a single
consolidated file of partial pieces.

* there’s been countless scalability improvements. It’s possible to seed
tens of thousands, if not hundred of thousands torrents in a single
libtorrent instance. (Just make sure to use efficient APIs when interacting
with such instance, to not make yourself the bottleneck).

* A lot of build configuration defines have been removed or moved out of
public headers (to not affect ABI), as ABI incompatibility caused by
configuration options is a common mistake.

API compatibility:

I’ve tried hard to keep this release API compatible the the 1.0.x series.
If you find a function that behaves differently in 1.1, please file a
ticket on github or bring it up on the mailing list. There are definitely
cases where using deprecated APIs will have worse performance now (because
they’re implemented on top of a new, higher performance, API).

There are some noteworthy exceptions though, that were hard to keep

* Instead of using boost.intrusive_ptr<> for torrent_info objects,
boost.shared_ptr<> is used. (this is a step in the direction of adopting

* the storage_interface has changed, to support multi-threaded disk I/O.

* the declarations of some functions and classes have been factored out
into their own header files. You may find yourself having to include some
new headers.

Deprecated features:

* deprecated adding torrents by URL. This feature introduced a lot of
complexity and does not fit well at the libtorrent layer. It’s often easier
for a client to download a .torrent file anyway, and then add it to

* sparse-regions feature was removed. This was a feature that attempted to
keep the number of extents per file low, to circumvent a bug in early
versions of vista.

* deprecated RSS feeds. The API for RSS feeds was awkward and did not fit
well with libtorrent. It’s likely easier for clients to use a separate RSS
feed library.

* deprecated lazy_bdecode and lazy_entry, as it’s been replaced by
bdecode() and bdecode_node.

* deprecated time functions in favor of using boost.chrono.

* compact file allocation was removed (it was deprecated in 1.0 iirc)

* deprecated explicit cache feature

* deprecated resolve-countries feature (not in scope of libtorrent, can
easily be done by client)

* deprecated set_tracker_login() (to use basic auth with http trackers).

* deprecated session_status, cache_status and session::status() (use
post_session_stats() instead)

What is a torrent?

FrostWire utilizes torrents to accomplish peer to peer file sharing. There seems to be a lot of confusion on what a torrent is and how it is used.

First, let’s consider how files are organized and accessed. Any file can be considered as a string of bytes, starting at one and going to the end of the file. In most files systems, data can be read and written to a specific point in the file by using the character number, which can be expressed in many ways, but that’s not your problem. If you want character 10, ask the file system to give you character 10, and you don’t care how that happened.

You can think of torrents as two basic types: File torrents and Folder torrents. A file torrent names one file and only one file. If you wanted to obtain an album of 20 songs, you’d have to use 20 different torrents, if you used file torrents.

A folder torrent describes all of the data in a folder, which can include sub-folders. If an album of 20 songs is contained in one folder, that one torrent will allow you to obtain that entire album. Some torrents can contain a primary folder containing sub-folders, each containing many files. Torrents containing over a thousand files are NOT uncommon.

Even with a folder torrent, there is provision to select specific files and exclude others from the download process. This can vary from program to program. For FrostWire, its fairly easy and covered in many help articles.

The key is that a torrent is NOT the data that you want. It is a description of the data you want. Torrents are created by torrent programs. They organized the data into chunks and provide a data map of the file structure, based on those chunks, so that data matching the torrent description can be read and written, randomly, from the disk.

Because the data can be read and written randomly you can send to and receive from multiple people at one time. This means that the data describe by a torrent MUST be and remain unchanged on the disk, once the torrent is made. If the data is changed, it will invalidate the torrent and cause errors, which the system will catch and attempt to deal with, usually by disabling the offending torrent.

Each torrent can be identified by a unique hash total of the data layout. The hash description is not so large as to be difficult to handle, but is large enough to make generation of the same hash from different data almost impossible.

The hash is considered a unique identifier for each torrent and is the mechanism that torrent programs use to exchange information about who has what torrent.

Here are some facts.
A torrent contains NO data from the files it describes. It only contains a mapping of the way the data is organized on disk.

A torrent has NO information about who has the file described. If someone decides to share files from a torrent, the torrent program will advertise the hash, and those looking for that file will be so informed.

New FrostWire Plus (1.6.5) for Android released

Download FrostWire Plus 1.6.5 for Android now

This release makes FrostWire for Android compatible with the new Android 6 Marshmallow release. Now when FrostWire starts up for the first time, Android 6 users will be explicitely asked to let FrostWire have disk access to media files.
This is only asked once and this annoyance is there thanks to your friends at Google.
As a result FrostWire will no longer crash on startup on Android 6 devices.

Integration with search engines such as SoundCloud, TPB, BTJunkie, Torlock and TPB has been fixed.

A very annoying usability bug on which searches would appear never end has finally been fixed, we had users waiting for searches to end for over 12 hours!!! when all they had to do was click on other search result tabs to notice that the search had ended, but this was completely our fault.

Multiple rare crash fixes on the music player will continue to make the app more stable as we continue reach new lower records on daily crash reports.

Fixes a bug where FrostWire wouldn’t know how to open finished .apk files from the “Transfers” screen.

New .APK search result icon

Apk search results icon is now an Android head, many users would think the former gear icon represented “settings”, our bad. Thanks for the feedback.

Let’s grow the community!

There’s a new “Keep In Touch” dialog after the installation wizard, we’d like to grow our community, many people think FrostWire is dead, but we never left, thanks media.

New: Copy Magnet, Copy InfoHash

We’ve added a couple of advanced torrent actions for users that may want to know the infohash of a torrent, or who may want to share the magnet link of a torrent with a friend for sharing content.

New “Help” menu entry

Updated Spanish, Polish, Croatian translations.

FrostWire 6.15 brings back 32bit compatibility to Linux

The new FrostWire 6.1.5 installer for Linux is a universal architecture binary.


The installer is now a bit bigger since we include 2 copies of our C++ native libraries, one for 32bit another one for 64bit intel cpus.

FrostWire will automatically pick up your architecture and use the right DLL.

We highly recommend you run the latest version of Oracle’s Java Runtime 1.8, preferrably the one for your CPU.