paralyze296

Is there anything in the works for this? Libtorrentv2 has a lot of issues, especially for systems like Unraid, but it's complicated enough to understand that most people have no idea and just assume the newer version is better, without realizing that performance is often worse. V2 was when libtorrent switched to memory mapped files which is part of why qbittorrent uses so much RAM. Libtorrent v2 has been out for 5 years now without fixing these core issues, and the developer has acknowledged them but still doesn't know how to fix them. There are posts for years on the libtorrent github and the qbittorrent github about this debate, and I'm not an expert so I won't try to understand all the complications involved, but it's very clear there's a lot of problems with v2 and that v1 should at least be an option. The qbittorrent team releases a v1 and v2 version of the program for every release, it would be very helpful to have this option since v2 does cause problems for Unraid users, whether we know it or not. Is this something that could be implemented with a simple environment variable that users can modify for v1 or v2, or would it require a fully separate branch? I know you already have a libtorrentv1 image, but it's extremely outdated and I can't tell if it was actually intended to be used by many people.

Are there any plans to release a version of this with libtorrent v1 like how linuxserver does? I apologize if this has been asked before, but there are other qbittorrent images are not nearly as convenient for me due to using proton vpn, and I've been told by people a lot smarter than me that libtorrent v1 is significantly better for torrenting.

I'm having issues where the RSS downloader rules are not saving correctly. I can change the search strings and which feeds the rule applies to, but changing most of the options, such as whether to create a subfolder, whether or not to add paused, or save to a different directory, will not be saved once I close out of the download rules window. I've found moderate success trying to edit the json file with the downloading rules, but it's hard to know what options to use when I can't save the options I want to use as a basis.

No, sorry, just to be clear, I'm saying the "ListOn..." settings ARE present in the docker container. I was trying to be a little lazy and create the server settings I wanted in the PC client's GUI, then copy the config file. Apparently, this no longer works, because the config files generated by the game when launched by steam on desktop don't create configs that are compatible with this container. The server is working properly now that I've just opened the default config from the container and changed it to my preference. I also discovered that something in the 1.0 update changed how they managed passwords, because my previous (30+ character) password no longer worked. Once I changed it to ~20 characters, there was no more issue. I've been running the server for about a day and a half now and it's running perfectly now.

I have restarted the container, as well as completely deleted all appdata and pulled it fresh The "ListOn..." settings were not present in the server settings I copied from the server I made on desktop, and I noticed that the desktop files used numbers for most of the settings, rather than true/false or other values. I think I've managed to get it working by editing the default config, rather than copying the config from the file created on desktop. For some reason there was also an error with the complex password I was using, even though it was identical to what I had yesterday when I checked to ensure it was working. I might try and troubleshoot that further but probably not, to be honest. Thanks for the tip

It doesn't appear to be. I just tried running mine and it seems to start alright, but I can't connect to it, even though I verified that the container was working yesterday with the previous version. The only thing in the server logs that I'm seeing to give any indication so far are the following lines: Internal: There are remaining Allocations on the JobTempAlloc. This is a leak, and will impact performance To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.

Update: Server has been running fine for a full week now, and this good behavior has persisted through a reboot, a parity rebuild, and the addition of an extra cache drive. Current uptime is 48 hours, which was very unlikely before, so I'll consider this solved. It looks like the culprit here was either faulty RAM (which has been replaced entirely) or a poorly installed CPU, which I re-seated and applied new thermal paste to.

Thanks, will definitely do that if it crashes again. After my last edit I lost my patience with it, shut it down, and re-seated the CPU and swapped out the RAM. So far, it's running fine, and has managed to get almost halfway into a data rebuild, so fingers crossed. I will update in a week or so if it's still going strong.

My setup: 2 unraid servers and a windows desktop all connected on the same network. The unraid docker settings have been appropriately adjusted to run two servers on the same network. Both unraid servers have been switched to ipvlan. Rocinante (server 1) works fine. Razorback (Server 2) has constant issues that bring down the entire network and require a hard reboot. It usually does not stay up longer than a few hours, but sometimes lasts for days before crashing. Bit of background in case it's relevant: Rocinante's original hardware (motherboard, cpu, RAM) is currently in Razorback, so I know that it worked correctly with unraid before. Rocinante originally started on 6.9.x, then upgraded to 6.12.6, without issue, and has been running this way for almost two whole years now. Razorback started on 6.12.x, and is currently on 6.12.6 as well. Nothing but constant crashes since I put it together a few months ago. I will attach both the most recent syslog and the diagnostics from this server. Edit: removed the extra syslog file as I realized it was included in the anonymized diagnostics