Transmission 4.0 is now official will be implemented here?

[spupuz]

Transmission 4.0 is now official will be implemented here?

[emk2203]

You beat me to ask this by six minutes.

A little more info from the release notes:

For example, a stress test of starting transmission-daemon with 25,000 torrents is almost entirely IO-bound, using 50% fewer CPU cycles and 70% fewer memory allocations than Transmission 3.00.

The remote control GUIs (transmission-qt and transmission-web) now use the RPC API "table" mode, resulting in smaller payloads / less bandwidth use.

RPC payloads are now compressed using libdeflate, a "heavily optimized [library that is] significantly faster than the zlib library."

Upgrading to Transmission 4 isn't just about chasing the number, but a noticeable improvement for low-power clients which are most likely the devices of choice. I mean, who wants to have his gaming rig run 24/7 to torrent?

[pkishino]

We’ve been running the beta on the beta branch here and I’m been using it since day one without much problems. Let me trigger a rebuild on it using the release and then let’s see when it can be properly released

[spupuz]

haugene/transmission-openvpn:dev i'm using the dev docker does this is already in transmission 4.0?

[pkishino]

It is on the :beta branch.. the release just finished building

[spupuz]

so i can try it?

[ksurl]

wow it's 619mb

[spupuz]

i have used the docker image beta tag how can i check the transmission version?

[spupuz]

ok i checked the version is 4.0, does this tag will get more updates or better to stay on dev tag?

[pkishino]

do a new pull of :beta and it should be the newest version..

[theythem9973]

First and foremost - great project; thank you to all contributors. This is what got me to finally peek / mess around with docker.

Now, onto business. While I'm super excited about v4.0, I'm also concerned that a lot of trackers haven't necessarily whitelisted it yet and that may take some time on their side to roll out.

As such, I have some naive questions (that if I was better with docker, I'd probably already know):

1. Within a docker compose file, I have a version: '2', does that link to all the "images" including Transmission 3.0? If not, then what's the implication of that number? It's such a whole number that I find it hard to believe that it corresponds to a release number (and any associated bug fixes that happen).
2. I cloned the repo and am working out of that. In theory, if I never do another pull, will I still be with Transmission 3.0 or is it possible underneath the hood with respect to docker that I can somehow get Transmission 4.0 when it's pushed? I wanted to say latter, since the images aren't "stored" on github.
3. Lastly, if there's a strong push to 4.0 and the last two points don't mitigate me getting the 4.0 change, is there any thoughts of creating a feature on whether we can use 3.0 vs. 4.0?

Basically, my point of confusion is between github work (e.g., scripts) and "docker images" work (which is stored on dockerhub?) and the interaction between the two.

Thanks!

[ksurl]

Version 2 is the docker compose version spec. If you are running the latest docker version, compose spec is implied and no longer needed (it would be 3).

You can stay on transmission 3 as long as you don't update the docker image. You dont need to clone the repo to run the container. All you need is the compose file.

When 4.0 goes into stable on the main image (out of beta tag) it will be in the release notes. So as long as you don't autoupdate and read the changes before you update manually you shouldnt be caught off guard

[theythem9973]

Thanks for the clarification @ksurl!

Follow up.

In my docker compose file, I have this:

 transmission:
  image: haugene/transmission-openvpn

Is it the case that,

1. Upon first loading, it will pull the image and keep it at that version unless I intentionally do a docker update/pull?
2. Is this where I can also specify specific tagged versions (either to downgrade or upgrade)?

Thanks again!

[ksurl]

Thats correct.

[theythem9973]

Thanks @ksurl for taking time on educating me on non-project related docker 101, heh.

[julien-vu]

Hi, does someone here could use transmission 3 with radarr (absolute path issue) and does transmission 4 fixes this issue? I don't know if I should try the beta branch

[pkishino]

What issue? Been using this container for years..2.x,3.x and now 4.0 and never issues with arr apps

[julien-vu]

I am talking about the infamous
Remote download client transmission places downloads in radarr but this is not a valid LinuxMusl path. Review your remote path mappings and download client settings.

Manual is fine, automatic does not work

[pkishino]

Hmm, have you correctly set your remote path mappings then? I have and it works fine.. anyway. This isn’t really a container issue but transmission/radarr.. so better check on those repos for accurate response