Known Problems

Changing language

  1. Qt in general allows to change the UI language by adding an entry to the environment variables. Use LANG=language, where language is the Microsoft defined code Windows Language Pack Default Values.
  2. If you prefer to work in the original language (English), then its even easier: Open the installation directory of the app, say C:\Program Files\Transmission, and delete all the files inside the translations directory (or at least the one used in your default locale).

Known bugs on the source

  1. The foreign language problem.  Fixed (locally) since version 2.30b1.  Please report any problems here, because its not supported in Linux, but Transmission-GTK seems to work fine there, also the daemon built on Cygwin seems to work. Fixed in version 2.42 for the configuration directory (path), and torrent files with foreign characters, the fix is in 2.42+(13118).
  2. The “Change session…” panel doesn’t close… some times, Fixed seems to be working fine.
  3. Changing sessions between local and remote carries over the preferences of one into the other… which is bad because my remote session is on Linux, and my local session is on Windows and this last one just created a /var/downloads directory.  The problem is that settings (preferences) are stored in the local settings.json, and its one file, no settings-remote/settings-local… but this isn’t a real problem since the application has a “-g <config dir>” parameter, you just could have several different short-cuts that use a different configuration directory.
  4. Memory leak.  In Windows the application seems to be growing all the time (unless you minimize it), in older versions it was a memory leak, in newer it has improved.  In Linux it has been said in the forum that it was tested and it doesn’t leak… my own test on Linux, long time ago, did show some leaking, slower than the Windows version.  I wouldn’t worry unless you plan to run the application 24/7 for a long time.
  5. Set Location… doesn’t do anything.  Fixed (locally), the change is in the current beta releases (2.30b1 and newer).

Known bugs on the Windows build

  1. Poor performance with huge torrents.  Current tests with a 1.02 TB torrent composed of many files show very poor performance (high CPU use, even if only in one core, slow response, suspect download speed).  A different test with a 295 GB torrent shows acceptable performance; so that gives you an idea of what to expect.  We also found that a good workaround for working with huge torrents is to use transmission-daemon (yes, it runs fine in Windows) with Transmission-Qt as the front-end GUI (because the Web client is unusable due to the large number of files, and the lack of a file tree view).
  2. Unresponsiveness.  Fixed in 2.41+ the lag caused by creating files, by using sparse files (they report the full size but occupy only what has been downloaded).   When a download start the application allocates the files, the bigger the file the larger it takes that allocation and the application becomes unresponsive.  I’m looking for a fix on this.
  3. Crash the first time it is used, after a few (30) seconds.  Workaround: when the Change Session panel opens, with Start Local Session selected, instead of hitting OK hit Cancel. The problem has been found and its fixed (locally) on version 2.30b1.  It is not a bug on Transmission, its on miniupnp (patch sent upstream).
  4. No large file support (MinGW  does have LFS but not in the configure expected ‘header magic’ form).  Fixed on version 2.20 and above.
  5. dbus-daemon loops taking 100% of one CPU (you see 50% CPU if you have 2 cores, 25% if a quad-core).  I’ve seen this occasionally (twice in about 3 months to be exact), just kill the daemon and try again with Transmission by quitting and starting (you don’t have to quit, but file/magnet association will not work without the dbus-daemon).  The bug should be reported to the DBUS project; if you find an official distribution for Windows of that daemon, you could try that (my build is a vanilla build of the original sources… almost vanilla, I some times patch the obvious errors).  Been trying to use the latest release, 1.4.1, 1.4.3, 1.4.6, 1.5.0 but it doesn’t work right: the daemon comes up correctly, but the library doesn’t communicate with it (that bug or inconsistency I did report to DBUS developers).
  6. The uninstaller hangs.  Fixed on latest build of 2.12 .
  7. The uninstaller doesn’t remove anything.  Fixed since 2.something.
  8. Crash reports… none reliable, reproducible, they should start by reading how to report a problem (instructions on the Transmission forum).  The application is only supposed to work on Windows XP or newer.  It has only been tested with XP sp3 (both Home and Professional) and newer (Vista, 7, and 10).  Under Microsoft’s Application Verifier it only crashes when simulating low resources; which probably explain the 2 reports of crashing under a VM (the VM is using a bad configuration, too low on RAM perhaps?), or it could be the case in point 1, where the crash is in the third party library miniupnp and probably was only crashing when there is something in your network that responds to the UPnP query (not only routers have that, my NAS has a media server that responds.)

Known Limitations

  1. Handling of non valid (on Windows) file names.  There are 2 groups of file names that are not valid on Windows, the first is any file name with a “device” name embedded (where device is CON:, LPT:, COM1:, etc.); this is not handled by the application at all.  The second group are file names with invalid characters (” *  : < > ? | \) anywhere in the path; since version 2.60 those torrents are handled by replacing the invalid character with an UTF-16 look alike… which Windows explorer’s font can’t show so all you’ll see is a little square in their place.  Note: this change makes those files different from the original, so they are not compatible with anything that uses the original name.
  2. Handling large torrents.  Large comes in two types: large files, and large number of files.  The first is about sizes, and the application can handle anything the file system can handle.  The second is only a problem with performance, the application has to do too much work to display those large (we’ve tested torrents with more than 64,000 files) lists of files… it is not recommended to use it (or any GUI application, for instance the Web client has the same problem, even worse since it shows a flat list; another more interesting example: Windows Explorer has the same problem trying to show the file list if they are in one directory).  The recommendation for those cases is to use transmission-daemon and transmission-remote.

Known bugs on Qt/MinGW

  1. Program call parameters.  FixedIn Qt some parameters are meant to be for the Qt runtime, -style <something> is one of them and Qt doesn’t handle it right, it does the right thing but it passes one of the parameters to the program, it should “consume” both parameters.
  2. More program call parameters.  MinGW doesn’t handle UTF-16 on the program parameters at all, which is what other programs that execute Transmission pass (i.e. Windows Explorer, Firefox, etc.)  This could be a problem if a .torrent file name has them. Fixed after version 2.72.
  3. Qt’s relative vs. absolute path bug.  One of the parameters you can use with the application is ‘-g config-dir’, and it works fine, except that if the directory is relative, Qt creates config-dir/config-dir as a side effect.

Fixed (locally) means the changes are not in Transmission’s repository.  I usually open a ticket and send my changes, after some time they are accepted, or not.  Some changes are so small and simple that I just fix and don’t open a ticket.

Leave a Reply