"Fragments" is unable to connect to transmission-daemon

Support Software & Applications
1

Running the testing flavour

I am no longer able to use the Fragments application. Its been months since I last used it.
On startup it complains it is unable to connect to the transmission-daemon.

I have already tried purging the config folder .config/fragments/

I can see that starting Fragments appears to spawn that daemon but to no avail

# ss -tulpn | grep transmission
udp   UNCONN 0      0                                      0.0.0.0:51413      0.0.0.0:*    users:(("transmission-da",pid=55471,fd=15))                                       
udp   UNCONN 0      0                                      0.0.0.0:6771       0.0.0.0:*    users:(("transmission-da",pid=55471,fd=18))                                       
udp   UNCONN 0      0      [2003:ed:d71f:eb00:5da9:140f:dcae:2531]:51413         [::]:*    users:(("transmission-da",pid=55471,fd=16))                                       
udp   UNCONN 0      0                                         [::]:6771          [::]:*    users:(("transmission-da",pid=55471,fd=19))                                       
tcp   LISTEN 0      128                                    0.0.0.0:9091       0.0.0.0:*    users:(("transmission-da",pid=55471,fd=20))                                       
tcp   LISTEN 0      4096                                   0.0.0.0:51413      0.0.0.0:*    users:(("transmission-da",pid=55471,fd=12))                                       
tcp   LISTEN 0      4096   [2003:ed:d71f:eb00:5da9:140f:dcae:2531]:51413         [::]:*    users:(("transmission-da",pid=55471,fd=13))

I see there are transmisison-daemon.service and transmission.service systemd services. Neither is enabled.
Nothing changes if I start either of these services before starting Fragments, i.e. Fragments is still unable to connect.

Can someone reproduce?

$ pacman -Qs fragments 
local/fragments 3.0.1-3 (gnome-circle)
    BitTorrent client for GNOME
$ pacman -Qs transmission
local/transmission-cli 4.1.0-1
    Fast, easy, and free BitTorrent client (CLI tools, daemon and web client)
2

Without being able to offer any real advice regarding this particular application, fragments is at the same version in all three branches — Stable, Testing and Unstable — but transmission-cli, transmission-qt and transmission-gtk are at a slightly higher version in Unstable.

Stable and Testing have 4.1.0-1 while Unstable has 4.1.1-1, which suggests a bug fix of some sorts. So if this software is important to you, then you might want to switch to the Unstable branch and see whether it works there.

Switching is easy, and reversible (if you use the correct commands). :backhand_index_pointing_down:

sudo pacman-mirrors -a -B unstable && sudo pacman-mirrors -f && sudo pacman -Syyu
3

The issue is apparently caused by fragments trying to connect to the same port as transmission-daemon. This has happened after the recent transmission update, and a bug has been lodged with fragments:

Apparently the transmission-daemon service starts at boot, and fragments starts its own daemon after login. So, after logging in you have to do several steps.

First, kill any running fragments processes which started at login.

Then, stop the transmission-daemon service by running either of the following commands:

To stop the transmission-daemon service just for the session:

systemctl stop transmission-daemon

or, to stop the service and disable it so that it does not start at next boot:

systemctl disable --now transmission-daemon

Note: sudo is not required as systemctl will prompt you for your password via polkit for changes to system services

Then start fragments again.

Another bug report Fragments fails to connect after transmission-cli update to v4.1 also mentions that a recent commit may have resolved the issue. I can’t see how, as the linked commit seems completely unrelated (it is to do with speed). They might mean a change done afterwards.

So, if you prefer to keep the transmission-daemon active, maybe try installing the fragments-git package from the AUR to see if that gets around the issue:

pamac build fragments-git

The AUR (en) - fragments-git page doesn’t show any recent issues in its comments section.

More info about the package:

pamac info fragments-git 
Name                  : fragments-git
Version               : 3.0.0.r12.gd048235-2
Description           : BitTorrent client for GNOME
URL                   : https://gitlab.gnome.org/World/Fragments
Licenses              : GPL3
Repository            : AUR
Groups                : --
Depends On            : gtk4 libadwaita transmission-cli
Optional Dependencies : --
Make Dependencies     : git meson cargo
Check Dependencies    : --
Provides              : fragments
Replaces              : --
Conflicts With        : fragments
Maintainer            : FabioLolix
First Submitted       : Wed 31 Jan 2018 07:41:26
Last Modified         : Thu 25 Apr 2024 20:55:50
Votes                 : 3
Out of Date           : --

Ignore the Last Modified date. AUR -git packages will always build the latest version/commits in the Git repository

2 Likes
4

Thank you for your suggestions.

As mentioned in my inital post,
I see there are transmisison-daemon.service and transmission.service systemd services. Neither is enabled.
those daemons are not running. So there is no IPv4 port conflict happening.

Building fragments-git from AUR fails

Fragments/meson.build:1:0: ERROR: Could not invoke sanity check executable: [Errno 13] Permission denied: '/var/cache/private/pamac/fragments-git/src/build/meson-private/rusttest.exe'.

So I headed to flathub.org and got me the flatpak version.

Startup fails

 DEBUG transmission_gobject::client::imp           > Connect to http://127.0.0.1:9091/transmission/rpc ...
 DEBUG transmission_client::client                 > Received status code 409, resend request.
 ERROR transmission_client::client                 > Unable to parse json: arguments (arguments: invalid type: floating point `100.0`, expected i32 at line 1 column 1982)

The last line indicates a type mismatch, which apparentlgy got fixed upstream 4 weeks ago, but did not make it into any release nor the flatpak.

It appears fragments remains unusable until a new release makes it to flathub or Manjaro. It is an upstream issue, tough.

1 Like
5

No issues building it on my Testing branch machine. This is the end of the build & install process:

==> Tidying install...
  -> Removing libtool files...
  -> Removing static library files...
  -> Purging unwanted files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> WARNING: Package contains reference to $srcdir
usr/bin/fragments
==> Creating package "fragments-git"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: fragments-git 3.0.1.r356.g6469a4e-1 (Sun 01 Mar 2026 09:30:29)
==> Cleaning up...

Checking keyring...                                                                                                [1/1]
Checking integrity...                                                                                              [1/1]
Loading packages files...                                                                                          [1/1]
Checking file conflicts...                                                                                         [1/1]
Checking available disk space...                                                                                   [1/1]
Installing fragments-git (3.0.1.r356.g6469a4e-1)...                                                                [1/1]
Running post-transaction hooks...
Arming ConditionNeedsUpdate...                                                                                     [1/4]
Compiling GSettings XML schema files...                                                                            [2/4]
Updating icon theme caches...                                                                                      [3/4]
Updating the desktop file MIME type cache...                                                                       [4/4]
Transaction successfully finished.

As we’re both on Testing branch (according to your profile), I’m not sure why it would not build on your machine.

After installing fragments I rebooted to ensure any related services (transmission-daemon & fragments) start at boot or login. I noticed that both transmission services were still inactive, so I installed & started transmission-qt, thinking that maybe I needed to run it first to activate the services. I was able to start fragments successfully.

Anyway, now that I had started both applications, I closed them down & rebooted again. Still no issues running fragments. I can even run both fragments & transmission-qt at the same time:

I noticed that both defaulted to using port 51413 for incoming connections, and both had no issues when I tested the connection via their preferences:

The only thing I didn’t try was to download an actual torrent on either. But at least I have been able to confirm that fragments-git does build on a Manjaro testing branch system using the pamac build fragments-git command, and it seems to run normally without any clash with transmission.

Something important I just noticed when looking in the fragments settings file (~/.config/fragments/settings.json) is that the rpc-port is 9091. That port is only active if Remote Access is enabled for fragments via the Settings → General tab. Remote access was disabled by default when I started fragments, so if you have Remote Access set up for fragments, try disabling it.

If you can’t disable remote access via the GUI, then it can be done by opening the ~/.config/fragments/settings.json file in a text editor and changing the "rpc-whitelist": line to:

"rpc-whitelist": "127.0.0.1,::1",

Make sure fragments is closed when you make the edit. Once you’ve saved the file, see if fragments now opens.

Finally, I noticed that my newly-installed transmission-qt also had remote access disabled by default. If you are not using remote access (which can used for viewing torrent progress in your web browser, among other things), then you might want to switch it off via the “Remote” section in Transmission’s preferences.

1 Like
6

fragments-git from AUR just build successfully. No idea what went wrong the first time.

I was able to download a torrent.

2 Likes
7

Does this mean you have a solution?

9

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.