![]() Currently the Share where the files write out to is an array (I use high watermark array) where both the donwloads and final media locations are, with the SSD cache as a buffer. Would hardlink versus copy have anything to do with the corruption? I'm not sure if I should have it set one way or the other. I'm pretty sure this is a qbittorrent corruption, as what good is a cache/unraid setup if it just corrupts files arbitrarily (barring actual physical hardware problems)? The cache is a brand new (literally 2 weeks old) seagate barracuda 500 GB. I am downloading to a share with an SSD cache enabled formatted with BTRFS. I use a script run every hour now to check for any errors. A corrupted file is generally going to be a drive issue of some sort.Īlso I found out the hard way that unraid does not monitor btrfs cache pools for errors like it does the main array. What format is it? BTRFS? Might be a good idea to run a scrub of it if so. I assume that you are downloading to the cache drive? This feature is available in several other torrent programs but not qbittorrent for some reason. Is it possible to use the API to change the trackers and have them stick after the port change?Ī nice feature to have in general would be the ability to add a list of trackers that would be updated automatically anyways. Great, at least you narrowed down the issue! So the problem is caused by the api, as soon as we set the port it resets one/some settings in the web ui, i think this is a bug in qbittorrent so i will raise it as such on their issue board and see what happens, im hoping for a workaround as the only other way to set the incoming port is to kill the qbittorrent process, hack the config file and start qbittorrent - every time the port changes!, not a nice prospect. Ok i got some good news and some bad news, the good news is ive identified what is causing the setting to be removed, the bad news is that in order to fix this it will break the ability to set the incoming port in qbittorrent :-(. certainly not something i am actively doing in this container. Line 9 - Bittorrent\TrackersList=test\ntest2īut as you have correctly identified, if you reboot then this is disabled and the list is shown as empty in the web ui, BUT the config is still present in the config file. So i would def say this is a bug in qbittorrent, most probably a new bug introduced after 4.1, as you said it wasn't present in that version.Įdit - actually the data DOES disappear from the config file once you have logged in after a restart of the container, no idea why that would happen!. Ok i had a poke about and it looks to be saving to the correct location, for instance adding in two trackers writes to the file:. PS: No, its not my hardware, I've memtest the crap out of it in the last 2 months, its an otherwise stable Xeon box with ECC ram running a few VM's. All I really need is a stable download manager that sits in the background and downloads what I tell it to. A threading/multitasking problem in the code? With what binhex replied to me above, it just seems qbittorrent, for all its bells and whistles and features, has WAY WAY WAY too many bugs filed. Granted I've got literally several DOZENS of torrents in all the stages of queuing, and downloading, so maybe its got some code that doesn't like tracking that many files at one time. I went and checked about 2 dozen other completed torrents, 3 others were also similarly broken. Plus the newly fixed file no longer has the corruption. I sha256 the original and newly fixed file, different hash so obviously something went weird. Make a copy of original, restart the "uncompleted" version, it finishes, I "force recheck" one more time just to be certain. ![]() So I went went back into qbittorrent, forced a recheck, 99.8% complete. qbittorrent says a file is 100%, then I watched, and there was a slight, albeit noticeable corruption. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |