How to read FrostWire’s Executable stdout output

Screen Shot 2016-08-29 at 4.13.54 PM

If you sudo lsof -n | grep FrostWire | grep "/dev/null" on a Mac to see where the stdout is going to, you will see that FrostWire’s console output is going to /dev/null, and redirecting a process output in OSX isn’t something at least we could find was easy to do as in Linux, where several developers have created utilities for this purpose.

Luckily, if you run the Mac FrostWire executable manually on your terminal, you will be able to see the stdout output being redirected to your terminal window (e.g. /dev/ttys004)

So simply do the following if you’d like to read the  stdout output.

1. Open Terminal

2. cd /Applications/ (or wherever else you may have dropped the

3. ./FrostWire

Listo! you should now be reading FrostWire’s stdout output.


#CODE libtorrent 1.1.1 released

You can download it from github at:

Changes since the 1.1 release.

* update puff.c for gzip inflation
* add dht_bootstrap_node a setting in settings_pack (and add default)
* make pad-file and symlink support conform to BEP47
* fix piece picker bug that could result in division by zero
* fix value of current_tracker when all tracker failed
* deprecate lt_trackers extension
* remove load_asnum_db and load_country_db from python bindings
* fix crash in session::get_ip_filter when not having set one
* fix filename escaping when repairing torrents with broken web seeds
* fix bug where file_completed_alert would not be posted unless
had been queries by the client
* move files one-by-one when moving storage for a torrent
* fix bug in enum_net() for BSD and Mac
* fix bug in python binding of announce_entry
* fixed bug related to flag_merge_resume_http_seeds flag in
* fixed inverted priority of incoming piece suggestions
* optimize allow-fast logic
* fix issue where FAST extension messages were not used during handshake
* fixed crash on invalid input in http_parser
* upgraded to libtommath 1.0
* fixed parsing of IPv6 endpoint with invalid port character separator
* added limited support for new parameter from BEP 9
* fixed dht stats counters that weren’t being updated
* make sure add_torrent_alert is always posted before other alerts for
the torrent
* fixed peer-class leak when settings per-torrent rate limits
* added a new “preformatted” type to bencode entry variant type
* improved Socks5 support and test coverage
* fix set_settings in python binding
* Added missing alert categories in python binding
* Added dht_get_peers_reply_alert alert in python binding
* fixed updating the node id reported to peers after changing IPs

Arvid Norberg

All of the changes above are already available on our Open Source Java wrapper Jlibtorrent.

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.