Release of version 4.0 #1936
Replies: 25 comments 70 replies
-
|
Good day, I can't access the Web UI ( Container spams the following message: |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps something here: #1452 ? But if it was fine in 3.7.1…hmm |
Beta Was this translation helpful? Give feedback.
-
|
I switched to the Caddy and can try again. In the meantime I'm using 3.7.1, but am happy to run any tests you may need. |
Beta Was this translation helpful? Give feedback.
-
|
Ah damn. The fix I provided here #1936 (reply in thread) broke this. I didn't think long enough on that one 🤔 Let me have a look 🧐 |
Beta Was this translation helpful? Give feedback.
-
|
New fix committed. Try now @kirill-solovev ? 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
Everything works now and GUI is also accessible. |
Beta Was this translation helpful? Give feedback.
-
|
After migrating my docker container to latest version, I lost every existing torrents. What is the migration process to migrate to version 4.0? |
Beta Was this translation helpful? Give feedback.
-
|
what is your config? how are you setting /data & /config ? |
Beta Was this translation helpful? Give feedback.
-
actually, you're right, config is not persisted. I have to try that before. |
Beta Was this translation helpful? Give feedback.
-
|
I've got a question: I read in another thread that you rolled back from transmission 3 to version 2 because of stability issues. Is it still the case in this version? |
Beta Was this translation helpful? Give feedback.
-
|
Let's continue this discussion here: #1937 |
Beta Was this translation helpful? Give feedback.
-
|
Similar issue to gchaperyout. Transmission updated overnight (using Watchtower) and when I woke up this morning it looked like it started re-downloading all of my torrents from scratch. This isn't good as that hard drive is almost full now. Is it too late to revert to the last version and save everything, or has the ball been rolling too long now? Is not mounting /config the issue? I only mounted /data, and Transmission just made its config within that folder, it looks like - the "transmission-home" folder. |
Beta Was this translation helpful? Give feedback.
-
|
I deleted my last comment as I think that was wrong. Total torrent count seems about the same as before - not entirely sure - but it's re-downloading everything and filling up the drive. I'm wondering if the previously-downloaded torrent data still exists in the "completed" folder, and then Transmission starts re-downloading a duplicate, which may eventually overwrite the data in "completed"? But in the meantime, you have duplicate data in both "completed" and "incomplete"? |
Beta Was this translation helpful? Give feedback.
-
|
I rolled back to 3.7.1 and my torrent list looks good again, but there are still those remnant data in the incomplete folder taking up a lot of hard drive space. I'll now need to reconcile that by comparing what's in the incomplete folder to what's actually incomplete (still downloading) in Transmission, in order to figure out what can be safely deleted. |
Beta Was this translation helpful? Give feedback.
-
|
Let's continue this discussion here: #1937 |
Beta Was this translation helpful? Give feedback.
-
|
I am following the guide to move from Synology to Portainer to fix the crashing issue caused by admin rights (#1839) on Synology devices when I start the stack using either latest or developer using compose the logs show ` Creating TUN device /dev/net/tun Using OpenVPN provider: IPVANISH Running with VPN_CONFIG_SOURCE auto Provider IPVANISH has a bundled setup script. Defaulting to internal config Executing setup script for ipvanish Downloading OpenVPN config bundle configs.zip into temporary file /tmp/tmp.vl2AfFqcxX Extract OpenVPN config bundle into /etc/openvpn/ipvanish 3 servers found in OPENVPN_CONFIG, ipvanish-UK-Manchester-man-c12 chosen randomly Starting OpenVPN using config ipvanish-UK-Manchester-man-c12.ovpn Modifying /etc/openvpn/ipvanish/ipvanish-UK-Manchester-man-c12.ovpn for best behaviour in this container Modification: Point auth-user-pass option to the username/password file Modification: Change ca certificate path Modification: Change ping options Setting OpenVPN credentials... adding route to local network 172.16.0.0/24 via 172.17.0.1 dev eth0 Sat Sep 4 14:28:09 2021 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6 Options error: --ca fails with 'ca.ipvanish.com.crt': No such file or directory (errno=2) Options error: Please correct these errors. this then causes a start loop and the container will not load. I rolled back to 3.7 and the container starts up fine. Any ideas? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry its broken again for ipvanish Options error: --ca fails with 'ca.ipvanish.com.crt': No such file or directory (errno=2) |
Beta Was this translation helpful? Give feedback.
-
|
Yeeeeah. That was a silly mistake 🙈 My regex is hopefully correct but I forgot to add back the -i option (in-place) after testing locally so the change was not written to file. Here we go again: 8f0a92a 🤞 Now let's see if it actually works 😄 |
Beta Was this translation helpful? Give feedback.
-
|
yep that seems to work for me anyway |
Beta Was this translation helpful? Give feedback.
-
|
Works for me too, 3rd time was the charm 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Morning - Since the upgrade in the last few days I now get this with IPVANISH. Appears to get stuck in a loop. I've destroyed the doscker and completely started again but still get the same results on my Raspberry Pi. Thanks, Stuart Starting container with revision: 901c0d2 |
Beta Was this translation helpful? Give feedback.
-
|
Something between the initial 4.0 release (which Watchtower grabbed) and subseqent commits has caused it to append the path to the CA certificate twice: I'm going to have a dig around the see if anything stands out as the cause... |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure this commit causes the regression: Pulling |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hmm, I believe I fixed that a week or two ago..
…On Sun, Sep 5, 2021 at 7:27 DavidFair ***@***.***> wrote:
Something between the initial 4.0 release (which Watchtower grabbed) and
subseqent commits has caused it to append the path to the CA certificate
twice:
transmission | Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.QHUy9aicNO
transmission | Extracting configs to /tmp/tmp.G9BKC9IsKp
transmission | Found configs for MULLVAD in /tmp/tmp.G9BKC9IsKp/vpn-configs-contrib-main/openvpn/mullvad, will replace current content in /etc/openvpn/mullvad
transmission | Cleanup: deleting /tmp/tmp.QHUy9aicNO and /tmp/tmp.G9BKC9IsKp
transmission | Starting OpenVPN using config gb_all.ovpn
transmission | Modifying /etc/openvpn/mullvad/gb_all.ovpn for best behaviour in this container
transmission | Modification: Point auth-user-pass option to the username/password file
transmission | Modification: Change ca certificate path
transmission | Modification: Change ping options
transmission | Setting OpenVPN credentials...
transmission | adding route to local network 192.168.1.0/16 via 172.19.0.1 dev eth0
transmission | Error: Invalid prefix for given prefix length.
transmission | Options error: --ca fails with '/etc/openvpn/mullvad//etc/openvpn/mullvad/ca.crt': No such file or directory (errno=2)
transmission | Options error: Please correct these errors.
transmission | Use --help for more information.
I'm going to have a dig around the see if anything stands out as the
cause...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7OFYVDTNPGL54TLN4Z5SLUAKMLRANCNFSM5DNE3JAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
If this is for my one above, just stopped/rm'd/pulled the latest version and it's still falling over the same 😕 |
Beta Was this translation helpful? Give feedback.
-
|
I broke it 5 hours ago, just committed what I believe to be a fix. 3aa8daa |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, for a smooth brain like me, what’s the best practise to get this talking to the new VPN provider repo? Should there be a shared mount or does one need to manually copy things over? |
Beta Was this translation helpful? Give feedback.
-
|
There's some info on running with your own provider files here: https://haugene.github.io/docker-transmission-openvpn/supported-providers/ Hopefully that has the answers you're looking for. |
Beta Was this translation helpful? Give feedback.
-
|
the new VPN repo is automatically used by this release.. no more vpn configs stored in this repo, all has been moved over to https://github.com/haugene/vpn-configs-contrib |
Beta Was this translation helpful? Give feedback.
-
|
Noted with thanks, so if everything is working in the VPN repo, then this 4.0 release talks to it automatically and everything works. So far 4.0 has been super smooth, thanks for all your work |
Beta Was this translation helpful? Give feedback.
-
|
Excuse me, but why Transmission version got downgraded from 3.0 to 2.94? I am running |
Beta Was this translation helpful? Give feedback.
-
|
See this thread: #1937 The short answer is that we downgraded deliberately because of specific issues, but also because we want to be explicit that this image will prioritize stability over being on the latest versions. If you have any questions after reading through it feel free to join the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Since upgraded to 4.0, I deleted some of the torrents in my list but after restarting the container, those deleted torrents re-appeared and transmission was downloading them and re-verifying all other torrents again (my container was already upgraded to 4.0 so this shouldn't be happening). Those deleted torrents were added before the upgrade, and newly added torrents were not affected. I haven't changed any configs. |
Beta Was this translation helpful? Give feedback.
-
|
that is an expected break that we should have mentioned in the notes.. this is due to change in hashing between the versions.. |
Beta Was this translation helpful? Give feedback.
-
|
I'm aware of the hashing problem. But in my situation, all the torrents have been re-verified, but once the container restarted, it starts to verify everything again. |
Beta Was this translation helpful? Give feedback.
-
|
yeah..I can only suggest to remove the torrents, restart, then re-add the |
Beta Was this translation helpful? Give feedback.
-
|
Please add this to the notes, due to some Synology updates and consequent reboots I've now downloaded A TON of files 3 times.. |
Beta Was this translation helpful? Give feedback.
-
|
or you can do as in the other discussion, add a line to upgrade your
transmission in the startup script
On Mon, Sep 6, 2021 at 10:15 AM Patrick Kishino ***@***.***>
wrote:
… yeah..I can only suggest to remove the torrents, restart, then re-add the
torrents and let them re-verify
On Mon, Sep 6, 2021 at 10:08 AM ThaiN ***@***.***> wrote:
> I'm aware of the hashing problem. But in my situation, all the torrents
> have been re-verified, but once the container restarted, it starts to
> verify everything again.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1936 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AA7OFYVVYZF4G42RZO43I5TUAQIBVANCNFSM5DNE3JAQ>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
|
Beta Was this translation helpful? Give feedback.
-
|
This is probably the dumbest question, but I have to ask: I pulled haugene/transmission-openvpn:latest and didn't notice anything different. How can I check to see if I'm actually on 4.0? |
Beta Was this translation helpful? Give feedback.
-
|
Purge old image since you most certain used latest tag last time. Now when you try to initiate a new container from latest tag docker find a local version matchning so it wont download from docker hub. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I see that Transmission is now version 2.94, rather than the version 3 is was before, so I know that it actually updated, but is there no where else where you can check the version of the overall container? Somewhere that says it's version 4.0? |
Beta Was this translation helpful? Give feedback.
-
|
well, if you use latest then it won't show..it should show a hash in the logs that you can compare to docker hub.. |
Beta Was this translation helpful? Give feedback.
-
|
Much better respons time now when downloading big files. Great work love this project! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the excellent work on this project! Today, after updating pulling the image for 4.0, my container can't start properly, likely due to my use of the AirVPN provider? It worked on the 3.x images without a problems, properly configured folders and volumes and .ovpn file etc. What would be the recommended steps/process to migrate my AirVPN setup to this new 4.0 image? Here are the docker logs: |
Beta Was this translation helpful? Give feedback.
-
|
have you got a ca.crt file inside your custom directory ? seems you don't |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, this got me looking too. Thing is, all the files are there and the config worked earlier on the old version. It seems however when inspecting my default.ovpn file (for AirVPN) that for some reason the opening quotation mark |
Beta Was this translation helpful? Give feedback.
-
|
@haugene yeah , the ca substitution still has some quirks..I'll take a look tomorrow perhaps |
Beta Was this translation helpful? Give feedback.
-
|
Hi team, First of all... THANK YOU for the amazing work that you do!!! I love your container! I've got an issue with the 4.0 version that I don't have when I did the rollback to 3.7.1. I'm running it on a Synology DSM 7.0, changed of course in Portainer the "NET_ADMIN" to True (else even on 3.7.1 the container doesn't work). The issue was nothing was downloading but logs looked ok... So I've checked on Portainer and the container appeared as "unhealthy". I've then searched into the issues raised here and found this one: docker keeps saying that container is 'unhealty' #1582. So I've done a I then tried on a terminal I've tried multiple things, like changing the port, rebuilding the container but nothing worked. The only thing was to use the 3.7.1 version and... it worked. Thank you for your help and support! |
Beta Was this translation helpful? Give feedback.
-
|
Also have the same issue with the latest release. docker exec -it transmission-vpn ping 1.1.1.1 ping works but DNS keeps failing docker exec -it transmission-vpn ping google.com root@8b0f64dc4539:/# nslookup
|
Beta Was this translation helpful? Give feedback.
-
|
Would anybody have a clue on this issue eventually? :-) |
Beta Was this translation helpful? Give feedback.
-
|
When I check the version of transmission I get 2.94 not 2.95. I am using image ID: Which is running |
Beta Was this translation helpful? Give feedback.
-
|
2.94 is correct.. my bad for referencing 2.95(doesn’t exist) |
Beta Was this translation helpful? Give feedback.
-
|
Are there any tips to getting transmission to work with traefik reverse proxy again? It was working for me until the image upgrade. Heres my Compose File
|
Beta Was this translation helpful? Give feedback.
-
|
I've been noticing some DNS Leakage problems with the 4.0 Image in comparison to 3.7.1 on my Synology NAS (DSM 6.2.4). I'm also using the exact same ovpn config files I did with 3.7.1. This results in using my hosts DNS Server, at least Moving back to 3.7.1 with the same ovpn files and this works again as it should without any issues: Not sure if this has something to do with the image change from Alpine to Ubuntu in combination with the Synology NAS or if it's something different. Unfortunately there's nothing interesting in the logs regarding the tunnelUp script. I know the shortest solution would probably be to set the Is this working for everyone else here with their Setup/Provider? Am I missing something? |
Beta Was this translation helpful? Give feedback.
-
|
found the problem. fixed here #1973 |
Beta Was this translation helpful? Give feedback.
-
|
Very nice find, so it was indeed a problem with the script. Glad you gave it a try! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, just upgraded to v4 and experiencing problems with containers which use Haugene/transmission-openvpn v4. I should point out that transmission works fine and (therefore assuming) so too does OpenVPN. My problem is other docker containers which route via transmission-OpenVPN.
My issue is resolved when I regress back to v3.x There’s nothing in the logs which suggest a problem and, like I said before, all containers show as a healthy. Thank you for your work on this fantastic container! |
Beta Was this translation helpful? Give feedback.
-
|
I do not have any router restart - my guess it that it is related to the OpenVPN connection being reset after some time and then reconnecting but it is a wild guess. However, the issue does never appear on 3.7.1 so it is definetly related to the container. My connected containers crash quite quickly (few hours) so I restarting all the time as a quick fix feels wrong ;-) I will stay with 3.7.1 for now and hope that 4.0.1 some time down the road hopefully fixes this. Otherwise I will have to look for alternatives. |
Beta Was this translation helpful? Give feedback.
-
|
I have noticed similar issues but not in that frequency. Containers using this networks Container will go down every now and then, maybe a few hours, maybe a few days. I guess it's hard to debug why exactly, since the logs do not show anything. Neither the transmission containers nor the connected ones. Don't believe it has anything to do with the OpenVPN connection being reset but I can be wrong of course. Guess it is a niche setup so few people might even notice this. |
Beta Was this translation helpful? Give feedback.
-
|
In my initial thread I mentioned this link: docker/compose#6626 I can’t promise it’s the same scenario as you’re having, but I still suspect this is a wider Docker issue. Still begs the question why Haugene v3 didn’t lose connection, but v4 and (apparently by design) Docker more widely does. |
Beta Was this translation helpful? Give feedback.
-
|
could possibly have to do with diff openvpn versions..haven't looked into that but def. could be something there as afaik the versions are different between 3.7.1 and 4.0 |
Beta Was this translation helpful? Give feedback.
-
|
Would be great - I sadly lack the skills to do it and I hate the 3.0.0 transmission client :-) |
Beta Was this translation helpful? Give feedback.
-
|
Can you please post config? I assume nothing changed, but perhaps something
wasn’t quite correct before which has been fixed.
Cheers
…On Sun, Oct 10, 2021 at 20:08 nnb7pikfze ***@***.***> wrote:
Hi, just upgraded to v4 and experiencing problems with containers which
use Haugene/transmission-openvpn v4.
I should point out that transmission works fine and (therefore assuming)
so too does OpenVPN. My problem is other docker containers which route via
transmission-OpenVPN.
- all containers report as Healthy on Portainer
- when I try to navigate to the GUI for any secondary container
(JDownloader-2, Sonarr, Radarr etc.) I’m getting a “cannot connect” error
- any container which does *not* use transmission-OpenVPN to route to
the internet (e.g. Tautulli) continues to work fine
My issue is resolved when I regress back to v3.x
When running v4, I need to stop and restart all containers. But this is a
temporary fix, as a few hours later, the connection to the secondary
containers will fail again.
There’s nothing in the logs which suggest a problem and, like I said
before, all containers show as a healthy.
Thank you for your work on this fantastic container!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7OFYUYNC5HYDYEXH7BSJLUGFX2BANCNFSM5DNE3JAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
Hmm, When loosing connection, the container does indeed kill the connection, For what reasons do you need to reboot your router daily?? |
Beta Was this translation helpful? Give feedback.
-
|
I did have another read through that link.. you are saying that v3, with same setup, would reconnect properly after internet restored? Did any containers restart? |
Beta Was this translation helpful? Give feedback.
-
|
Reason for daily reboot is down to my VPN router. Without going into the detail, some local devices lose connection to my router’s 2.4GHz band and the workaround built into the firmware is to restart the router. You mentioned that v3.7.1 wasn’t working correctly. Is there any chance that there was a DNS leak? Was it unsafe? Before I installed v4, all Docker containers reconnected to the network through Haugene once the router reboot was complete. That’s why I reported this bug; v4 goes against what I had experienced. I have now created a scheduled task to restart all containers every day after the restart. So until this bug is fixed (I’m guessing by Docker), there is a workaround. One more thing, I’ve just noticed an error in my OpenVPN log file. Is this expected? ERROR: Linux route add command failed: external program exited with error status: 2 |
Beta Was this translation helpful? Give feedback.
-
|
well, there were a number of commits added since 3.7.1 to address various things like dns settings etc.. also moved back to ubuntu base from alpine..not sure why that would affect the linked containers though.. |
Beta Was this translation helpful? Give feedback.
-
|
I remember the mother/child problems, they've been along for a long time. But that's out of scope here. My main suspect here is the signal remapping. Can you try to set environment variable But the script does some good things as well, so that last one should be a last resort. It also depends on your provider and the configs. You might be dependent on some of the config changes for it to run at all. |
Beta Was this translation helpful? Give feedback.
-
|
After updating to the latest 4.0 I get an issue connecting I'm using the same PIA nameservers in my resolv.config as before (I haven't seen any mention that they have changed) I was able to get it to work if I change this to another nameserver like 1.1.1.1. Then it connects and starts up the container. And a new nameserver is placed in there: 10.0.0.243. It looks like its working, only to fail. After starting up, it seems that this new name server again fails to resolve |
Beta Was this translation helpful? Give feedback.
-
|
Please remove the resolv.conf override. |
Beta Was this translation helpful? Give feedback.
-
|
I am so far beyond confused. I have started a new container with version 4 and mounted /config. The container keeps creating it's own /data and storing transmission-home there. What the DEALIO? something change (again??-grin)? |
Beta Was this translation helpful? Give feedback.
-
|
? The /config as default is not yet in the main branch.. |
Beta Was this translation helpful? Give feedback.
-
|
could have sworn I read that /config IS the default now unless environment variable is found with different location. Just went back on a hunt and I guess I was reading discussion on dev branch changes. SIGH.... Ok.. Let's give this another try.. grin |
Beta Was this translation helpful? Give feedback.
-
|
Hi I have been running with an old version of this image, and decided to upgrade today and are having weird issues. With the latest version I am getting "Connection timed out" when it is trying to connect to the VPN IP. If I try version 3.7.1 it has no problems with connection, but then it reports the certificate is old and stops. Here is a log paste from the latest version: I am unsure on what to do next. Any help is much appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
based on the python error further down, are you running this on raspberry pi ? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! That solved the problem. |
Beta Was this translation helpful? Give feedback.
-
|
More-specific answer: Follow the steps outlined here to fix the "core dumped" errors on Raspberry Pi. |
Beta Was this translation helpful? Give feedback.
-
|
In case anyone else is like me and has been holding off updating to v4.0 of the image: The reason I held off is because it seemed like all of my torrents' data had been lost/reset after updating, but I finally tried again today and it looks like the issue is that Transmission just forgot the subfolders they were in. For example, if you use subfolders for *arr downloads, you will just need to set those folder locations again for the torrents in question. Might seem daunting, but you can just do it in batches: Set a bunch to e.g. /data/completed/Radarr, wait for rechecks to finish, then remaining to the Sonarr subfolder, and so on. |
Beta Was this translation helpful? Give feedback.
-
|
I spoke too soon, unfortunately. The container doesn't seem to retain changes made after a restart, in that torrents that were previously fixed (i.e. pointed to the correct download folder) or deleted are added again upon restart, and things like that. Based on other discussions here, it looks like all of the .torrent files in the torrents folder will need to be moved out and manually re-added to Transmission via the UI. For thousands of torrents, this isn't feasible for me right now, so I'm once again going to migrate back to 3.7.1. |
Beta Was this translation helpful? Give feedback.
-
|
On 3.7.1 I was not able to access Transmission over OpenVPN trough my router and I added second network line in Stacks compose that I comment out and update the stack when traveling. |
Beta Was this translation helpful? Give feedback.
and others
-
We will be rolling out version 4.0 of the image now. The overall goal of the release is to get a more maintainable project and more stable image. We've made some choices to go more in the LTS direction instead of bleeding edge. We will update packages slowly and steadily but will not prioritize to be on any bleeding edge.
The major changes are:
Please comment below if you have any questions or issues with the new image.
EDIT:
Please note that due to changes in hashing between Transmission 2.94(Used in this release) and transmission 3.0 (previous release),
Users with current torrents will need to re-validate and/or possibly re-add torrents to get them to properly validate. Also, recently deleted torrents MAY show up again. Please clean out your transmission folder for old torrent/resume files.
See #1937
Beta Was this translation helpful? Give feedback.
All reactions