当您有大量需要重新检查的种子时，这并不完全理想。 我也更喜欢在串行/并行处理之间进行选择以进行强制重新检查的选项。

相关讨论： https :
@arvidn @airium

这是“强制启动”（即不是自动管理的）种子的行为。 每当用户强制重新检查种子时，qBitTorrent 是否有可能清除自动管理标志？
否则，也许你所有的种子在你强制重新检查它们之前都是强制启动的。

@Syst3mSh0ck ：您的陈述令人困惑。 起初听起来你认为我的建议是垃圾，但听起来你的意思是当前的行为是垃圾。 请说清楚。

@arvidn ：我对此一无所知。 我不使用“强制启动”，但我会在选择的已完成的种子上使用“强制重新检查”，在那里我将设置位置更改为另一个硬盘，然后我使用强制重新检查来确认文件仍然存在完整性（作为文件副本验证）。

无论如何，在任何情况下，qBittorrent 一次重新检查多个 torrent 或来自同一存储设备的多个 torrent 似乎总是愚蠢的。 这只会摧毁任何表现的希望。

@ sledgehammer999 在我的情况下（qbt 4.1.1，WIn10），当我突出显示 2 个种子并强制重新检查时，
然后一个 torrent 停滞在 0%，另一个是 99%。 然后当我重新检查“0%”一个时，它工作并以 99% 结束。

同样在这里。 刚刚从 uTorrent 导入，我不得不一次重新检查种子 1，因为它试图并行重新检查所有内容，导致非顺序读取的颠簸。

[编辑] 我意识到如果我首先强制重新检查所有这些，然后暂停它们，然后取消暂停它们，它会依次进行重新检查。 因此，尽管仍然是 [错误/功能]，但不会使人衰弱。

作为一项功能，如果可以对每个挂载的分区并行进行重新检查，那也很好。

感谢您找到@dakusan ！ 下次我将不得不尝试这个技巧......选择多个种子，选择强制重新检查，然后暂停，然后继续。

根据 libtorrent 文档，有一个单独的种子队列用于检查状态。 它的默认值应该是 1，所以它应该一次检查 1 个 torrent。 所以不确定 qBittorent 是如何检查它们的。 我检查了最新的源代码，它似乎没有在任何地方设置 active_checking 值。

未设置auto_managed标志的种子不受任何排队逻辑的约束

未设置auto_managed标志的种子不受任何排队逻辑的约束

在本主题的前面我提到我在 Windows 10、64b、qbt 4.1.1 上遇到了这个问题
现在我尝试在 Windows 7、64b、qbt 4.1.4 上没有问题，我尝试重新检查多个手动、多个自动管理种子和混合。 这些种子都是 100% 完成的，它总是一次检查 1 个种子，但是当我为不完整做同样的事情时（比如下载了 10%），它同时检查了多个种子，但显然再次没有将种子设置为的问题如我之前的回复所述，下载率为 0%。 .

有人在本线程前面提到问题出在FORCE Recheck 。 您必须关闭FORCE ，然后它会将重新检查一一排入队列。 如果不先进行 FORCE 重新检查，您就无法开始重新检查。 我自己已经验证了这种行为。

如果不先进行 FORCE 重新检查，您就无法开始重新检查

我不明白您所描述的内容以及如何“关闭强制”，但是在此线程中，当我谈到“重新检查”时，我总是指用户从 Torrent 右键单击​​菜单中手动触发的“强制重新检查”选项。

您可以通过再次单击FORCE来关闭它。 执行两次选择、右键单击菜单例程。 然后它会一一排队重新检查。

Force -> Un-force -> Force -> Un-force -> Force -> Un-force ...

从我所看到的，重新检查暂停的种子会为他们清除auto_managed标志。 这是一个修补程序，虽然我觉得这是一种解决方法。 平@qbittorrent/半神

--- a/src/base/bittorrent/torrenthandle.cpp
+++ b/src/base/bittorrent/torrenthandle.cpp
@@ -1270,13 +1270,21 @@ void TorrentHandle::forceRecheck()
 {
     if (!hasMetadata()) return;

+    if (hasError())
+        m_nativeHandle.clear_error();
+    if (hasMissingFiles())
+        m_hasMissingFiles = false;
+    if (isForced()) {
+        m_startupState = NotStarted;
+        m_needsToStartForced = true;
+    }
+
+    m_nativeHandle.auto_managed(true);
     m_nativeHandle.force_recheck();
     m_unchecked = false;

-    if (isPaused()) {
+    if (isPaused())
         m_nativeHandle.stop_when_ready(true);
-        resume_impl(true, true);
-    }
 }

 void TorrentHandle::setSequentialDownload(bool b)

@thalieht ，我还没有时间详细看，我稍后会做。 至少触摸m_startupState是完全不正确的，它破坏了相关逻辑。 “启动状态”用于处理 torrent 的初始启动。 初始化完成后，torrent 始终处于“已启动”状态。

这就是为什么我说解决方法。 我只是想到达
https://github.com/qbittorrent/qBittorrent/blob/b87987ec89bee54b2462f6a529db472b2511f65e/src/base/bittorrent/torrenthandle.cpp#L1558

从我所看到的，重新检查暂停的种子会为他们清除auto_managed标志。

这是因为resume_impl(true, true); 。 你可以试试resume_impl(false, true);吗？

哦！ 我知道，但没想到去尝试。 但是我现在发现了这个：#8711

为了解决这个问题，torrent 被放置在 upload_mode 和 out of
自动管理。

哦！ 我知道，但没想到去尝试。 但是我现在发现了这个：#8711

但是自从我上次更改后，我们不再依赖“已检查”警报。 现在它由“stop_when_ready”标志驱动，libtorrent 同步暂停它。 所以我们可以尝试恢复它并在此处使用resume_impl(false, false); 。

这里https://github.com/arvidn/libtorrent/issues/2759#issue -293012044 @ sledgehammer999 说他尝试了各种东西，包括“stop_when_ready”。 也许等待一些反馈？

理想情况下，libtorrent 应该将繁重的磁盘操作（例如移动/检查）限制为每个磁盘 1 个。 我不明白有什么理由在同一驱动器上同时检查 2 个以上的种子。 如果您允许，即使使用 SSD 性能也会受到影响。 此外，自动种子管理不应该真正适用于这些繁重的磁盘操作。 我认为更好的解决方案是让 qBittorrent 管理自己的队列，以便 libtorrent 一次只检查 1 个 torrent。

例如，假设您选择 5 个种子文件并单击强制重新检查。 qBittorrent 应该有一个单独的队列，它将这些种子放在一个列表中。 然后从该列表中获取第一个 torrent 并更新 libtorrent 中的状态。 它一直等到 torrent 检查完成，然后再使用下一个 torrent 并切换状态。

我希望我能帮上忙，但我已经很长时间没有接触 C/C++ 了。 在过去的 15 年里一直是 C# 开发人员。

@iheartcsharp我可能之前错过了一些东西。 libtorrent 队列是否有足够的原因？ 您可以将active_checking为 1（这是默认值）。 非自动管理的种子（即设置了torrent_flags::auto_managed标志）不受任何限制。 检查限制是否是一种特殊情况以允许非自动管理的种子受制于它是否重要？ 如果是这样，为什么？

我可以看到 qbt 管理检查种子本身的主要好处是它可以尝试评估种子属于哪个驱动器，并且每个驱动器都有单独的队列。 然而，这是一件令人惊讶的复杂事情。 也许它可以在最常见的情况下工作。 但是并没有说一个种子文件中的所有文件都存储在同一个驱动器上。 事实上，如果您有一个逻辑卷，其中块设备跨越多个驱动器，那么即使单个文件也可以存在于多个驱动器上。

考虑到目前强制重新检查每个 torrent 的极端情况，理想的极端情况是一次只检查 1 个 torrent，而不管文件在哪里。

正如我之前提到的，后一种行为是可能的，但您必须发出两次重新检查操作，因为第一个操作是“强制重新检查”，然后第二个操作是“重新检查”（不强制）。

因此，目前的解决方案是从第一个操作中删除该强制切换。 这是我们可以在下一个版本中完成并发布的最快修复程序。

@ sledgehammer999 在https://github.com/arvidn/libtorrent/issues/2759#issue -293012044 你说你尝试了各种东西，包括stop_when_ready()现在顺便使用。 什么对它不起作用？ 是补丁修复的东西吗？ 如果是，并且由于我们将仅支持 1.1.7 之后的某些版本作为最低要求，是否可以在重新检查暂停的种子时再次启用auto_managed ？
在#8711 中，您提到了stop_when_ready()阻止的竞争条件。
从文档：

stop-when-ready 标志修复了等待的固有竞争条件
为 state_changed_alert 然后调用 pause()。

所以我们可以尝试恢复它并在此处使用resume_impl(false, false); 。

我的快速测试没有显示任何问题。 它会一一检查种子文件，然后再次暂停它们。
现在我想将此补丁嵌入到我的个人构建中并在此处发布 PR 以让更多人参与测试。

10242

不确定是否有计划，但将此修复添加到 4.1.x 分支会很好。这有点大不了。

它已关闭但在 4.1.5 中仍未解决？

如何在 4.1.5 版本中修复它？ 此版本是在问题解决之前发布的。

/me 头撞墙，
没有看上次回复的日期，虽然它会尽快修复，因为这是一个很长一段时间的问题。
感谢修复，我希望能在 4.2 分支之前的版本中尽快看到它

@glassez于2019 年发表评论1. 欧洲中部时间 06:53 ：

#10242

我认为通过 Qbittorrent 移动文件应该考虑这种行为。 （例如：设置位置，或下载文件夹和目标之间的 QB 自动移动）

很明显，它是并行完成的。 我只是移动了几个种子，甚至不是大的。 硬盘工作量很大，花了很长时间才搬完。 在那之后，其他人很快就完成了。

我同意 mzso，但我的印象是文件移动使用​​队列系统。 至少在我看来是这样，因为我要求添加“移动”状态。 设置了“Force”标志的种子可能会同时移动而不是在队列中移动。 （Force 是一个标志，每个 torrent 都会打开和关闭，用于覆盖 torrent 排队系统。）

@a-raccoon对2019发表评论6. 22:03 CEST ：

我同意 mzso，但我的印象是文件移动使用​​队列系统。 至少在我看来是这样，因为我要求添加“移动”状态。 设置了“Force”标志的种子可能会同时移动而不是在队列中移动。 （Force 是一个标志，每个 torrent 都会打开和关闭，用于覆盖 torrent 排队系统。）

我已经有很长一段时间没有使用强制了。 但是根据我描述的症状，他们没有排队似乎很明显。

您声称此问题已针对新版本 4.1.6 关闭？

https://i.imgur.com/rExR3QJ.png

对我来说绝对没有修复，我有 69 个带有“丢失文件”的种子，因为我的外部在某个时候断开连接，qBitorrent 决定必须再次检查它们...... .

我更新到新版本，它自动开始执行屏幕截图中的操作，并且我明显看到“检查百分比”同时上升多个种子。 我不得不手动暂停它们以使其停止一次检查多个。

我可以确认@Zentriert在 4.1.6 版上看到的行为。 我让我的 NAS 暂时断开连接，我退出了 qBittorrent 以尽量减少损坏。 然而，一旦我重新启动它，每一个被破坏的种子现在都会同时重新检查。

https://i.imgur.com/mnHgmBk.png

@glassez你能看看这个吗？

@glassez你能看看这个吗？

这个程序已经死了，没有人在乎。 很多年了还是有很多bug

远非如此，Libtorrent 有显着的发展，这个客户至少有五个人在他们自己的时间里工作。 它的势头相当强劲。

我目前正在处理它。 但是我很难解决一个我在日常生活中没有亲自接触过的问题。 我必须故意重新创建它。 但是我的空闲时间很少。

谢谢你，弗拉基米尔。 对此，我真的非常感激。

如果有什么我可以做的让你更轻松，请告诉我
繁殖。

在周五，2019年6月28日，22:09弗拉基米尔Golovnev [email protected]
写道：

我目前正在处理它。 但我很难解决一个问题
我在日常生活中没有亲自接触过。 我必须重新创建它
目的。 但是我的空闲时间很少。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/qbittorrent/qBittorrent/issues/9120?email_source=notifications&email_token=AB2XLJ3JFKZDZCH4III54Q3P43VALA5CNFSM4FGHH472YY3PNVWWK3TUL52HS4DFVREXG43MVVMWSQWWJKZCH4III52HS4DFVREXG43MVVMWSQWWWJKZCH40043MVXWWWWJKZCH4300400000000000000000
或静音线程
https://github.com/notifications/unsubscribe-auth/AB2XLJ4YBADSWJIMHYRKB7TP43VALANCNFSM4FGHH47Q
.

如果有什么我可以做的事情可以让您更轻松地重现，请告诉我。

如果我的工作完成后，受影响的人帮助在其系统上对此进行测试，那就太好了。 您应该自己编译它，或者我可以在补丁中提供二进制文件（适用于 Windows x64）。

远非如此，Libtorrent 有显着的发展，这个客户至少有五个人在他们自己的时间里工作。 它的势头相当强劲。

2,526 问题是什么都没说？

远非如此，Libtorrent 有显着的发展，这个客户至少有五个人在他们自己的时间里工作。 它的势头相当强劲。

2,526 问题是什么都没说？

好吧，您不能对免费和开源的东西抱有更多期望。 即使是由组织支持的 Firefox 也饱受拖延数年甚至数十年的大大小小的错误的困扰。

远非如此，Libtorrent 有显着的发展，这个客户至少有五个人在他们自己的时间里工作。 它的势头相当强劲。

2,526 问题是什么都没说？

据说用户比开发人员多得多。 可能有些用户不时为已经有票的问题创建票。

@glassez我认为解决方案是根本不触摸auto_managed标志。 可能除了“强制启动”之外，但是一旦 torrent 离开强制启动状态， auto_managed标志就应该放回原处。

2,526 问题是什么都没说？

是的，其中一些问题可能早就解决了，而其他问题可能根本不是实际客户的问题。 实际上，Libtorrent 和 qBt 方面的情况都变得更好了，所以我希望这个数字会减少，不要让这劝阻你使用 qBt。 4.1.7 即将到来，4.2.0 看起来是一个很大的改进，现在不会太久了。

@glassez我认为解决方案是根本不接触 auto_managed 标志。 可能除了“强制启动”之外，但是一旦 torrent 离开强制启动状态，就应该放回 auto_managed 标志。

我不知道你推荐它的确切原因。 但是，当我们启动 torrent 以满足我们的需求时，我们必须使用 auto_managed/paused 标志“播放”。 当然，我们应该在所有准备工作完成后将其恢复原状。 不幸的是，libtorrent 不允许我们以任何其他方式做这些事情。

有人可以测试 #10871 吗？

如果我的工作完成后，受影响的人帮助在其系统上对此进行测试，那就太好了。 您应该自己编译它，或者我可以在补丁中提供二进制文件（适用于 Windows x64）。

@glassez ：您在此线程中放置的任何

https://yadi.sk/d/BA5Gd1y_kGS2VA

@a-raccoon评论2019. jún。

如果我的工作完成后，受影响的人帮助在其系统上对此进行测试，那就太好了。 您应该自己编译它，或者我可以在补丁中提供二进制文件（适用于 Windows x64）。

@glassez ：您在此线程中放置的任何

您也可以检查移动种子（在不同的驱动器上设置位置）吗？

上面的二进制已更新。

您也可以检查移动种子（在不同的驱动器上设置位置）吗？

也许下次我可以从我的个人生活中抽出几个小时......

@glassez评论。

您也可以检查移动种子（在不同的驱动器上设置位置）吗？

也许下次我可以从我的个人生活中抽出几个小时......

好吧，我正在回复似乎渴望测试的@a-raccoon。

但是因为这也被窃听了（根本没有排队），如果要修复它，开发人员需要在某个时候查看它。

@glassez ：我尝试了提供的二进制文件，但在询问我是否要将其设为种子和磁力链接的默认应用程序后，它立即崩溃了。 我有一个小型转储，所以如果有什么办法可以将它发送给您，请告诉我。

有没有可能在此修复之后构建 4.1.7 版本以及需要向后移植的任何内容？ 你需要大锤吗？ 看来他已经离网了。

这终于在 4.1.7 中修复了对吗？

你做了测试不是吗？ 我认为关闭是安全的。

Moving...固定的，还是移动仍然并行而不是顺序发生？

它们仍然并行发生.. 也用 4.20 Alpha 进行了检查。 :(

@Ryrynz其中一个或多个种子是强制的，对吗？ 在这种情况下我可以重现。

@a-raccoon 仍然平行。

没有，没有强求。 只需添加两个种子，下载并移动。

搬家了？ 这是关于并行重新检查。

然后也将其添加到列表中。

@Ryrynz通常最好拥有特定的票证，并且在解决特定问题后可以关闭票证。 您可能应该创建（或在现有票证中发表评论，我确定有一个）关于种子的并行移动。 这张票的主题是并行检查种子。

@thalieht评论了2019 年。

搬家了？ 这是关于并行重新检查。

也提到了搬家，因为这是一个类似的问题，带来同样痛苦的后果。

@arvidn对2019发表评论8. 13:22 CEST ：

@Ryrynz通常最好拥有特定的票证，并且在解决特定问题后可以关闭票证。 您可能应该创建（或在现有票证中发表评论，我确定有一个）关于种子的并行移动。 这张票的主题是 _checking_ 并行的种子。

由于问题数量众多，新问题不太可能引起关注。

@arvidn对2019发表评论8. 13:22 CEST ：

@Ryrynz通常最好拥有特定的票证，并且在解决特定问题后可以关闭票证。 您可能应该创建（或在现有票证中发表评论，我确定有一个）关于种子的并行移动。 这张票的主题是 _checking_ 并行的种子。

无论如何，他似乎已经打开了一个问题 (#9158)，然后就被忽视了。

避免不必要的移动也会有帮助：#7916

我认为这里也提到了移动，因为@glassez (et al) pull #10871 可能是为了解决顺序重新检查和顺序移动的问题。 这两个文件操作甚至应该共享相同的代码才有意义，特别是考虑到 qbt 选项在 torrent 完成后重新检查 torrent（并且大概从 \temp 移动到 \complete）。

@iheartcsharp于 1 月 8 日发表评论

理想情况下，libtorrent 应该将繁重的磁盘操作（例如移动/检查）限制为每个磁盘 1 个。 我不明白有什么理由在同一驱动器上同时检查 2 个以上的种子。 如果您允许，即使使用 SSD 性能也会受到影响。 此外，自动种子管理不应该真正适用于这些繁重的磁盘操作。 我认为更好的解决方案是让 qBittorrent 管理自己的队列，以便 libtorrent 一次只检查 1 个 torrent。

文件移动从一开始就是这个线程的一部分。

有没有办法解决文件移动问题？ 我觉得有点莫名其妙的是，围绕极重 IO 的想法编写的库和工具也会以严重损害性能的方式编写。

qbitorrent 没有任何类型的内部队列可以完成 async-io 吗？ 似乎需要将这些移动排入该队列以按顺序完成。

鉴于可以一次“检查”一个文件，这似乎是可能的。 如果我们可以一次“检查”一个……为什么不能对移动做同样的事情？

请启用一些选项来排队移动，我有 3GB/s 的 ssd 临时下载位置和 1GB/s 容量的磁盘阵列，但是当我同时进行 7 个以上的移动时，一切都变得糟糕，需要永远移动，甚至种子传输停止，可能是因为磁盘过载检测。

我只是为我拥有的标签更改了一个位置，而不是提供移动种子或只是不这样做（就像我希望的那样），它只是立即开始移动所有种子。

仔细观察，虽然它看起来好像实际上是按顺序移动它们，但所有种子都被标记为“移动”，但我的磁盘性能从 60MB/s 到 90MB/s 不等，如果它正在移动它们肯定不会一次全部。 磁盘内容似乎也证实了这一点。

因此，看起来理想情况下，我们只在移动时将种子标记为“移动”，而在未移动时标记为“排队等待移动”。

理想情况下，进度指示器也可以做一些事情。

@FranciscoPombal现在应该关闭了吧？ 现在有一个用于移动种子的排队系统。

@an0n666是的。 由于以下原因，现在可以使用请求的功能：
https://github.com/qbittorrent/qBittorrent/pull/10242
https://github.com/qbittorrent/qBittorrent/pull/10266
https://github.com/qbittorrent/qBittorrent/pull/12035
https://github.com/qbittorrent/qBittorrent/pull/12188