🐛 一次性下载多集会造成终端（Terminal）不能打字（无法显示新输入的字元） about bilili HOT 17 CLOSED

如果方便的话，比较建议迁移到 bilili v2（ https://github.com/yutto-dev/yutto ），使用方法与 bilili 基本相同，基本上可以使用 yutto -b 命令等效替代 bilili，详情可以参见文档（即 README）

from bilili.

感谢，来去试试看

from bilili.

不好意思，请教一下

我在 2.0 版找不到对应 1.0 版 -p 选集的相关说明，另外为什么还要多一个 -b 的参数
感觉有原本的 -p 就够了（已经可以直接指定下载多个） @@"

谢谢！

from bilili.

yutto 在不启用 -b 选项时只会下载确定的某一话，在启用 -b 后才会同时下载多话（即批量下载），而 bilili 只支持批量下载，我认为这是 bilili 的一个设计缺陷，因为部分场景只需要下载某一话，而 bilili 无法为此做出较好的输出结果（比如目录格式等），因此在设计 yutto 的时候在加 -b 时才会启用批量下载功能

我在 2.0 版找不到对应 1.0 版 -p 选集的相关说明

与 bilili 基本一致，只不过弃用了 ^ 作为开始选集，由于 -p 仅仅在 -b 启用才有意义，因此参数详情在批量下载参数部分，默认是折叠的，点击即可展开

from bilili.

感谢大老详尽的回覆

所以 -b 的意思是指定要下载清单上的全部集数对吧，
我原本是想说既然已经用 -p 指定下载多集（有需要批量才会给这参数）了，为什么还要 -b
有个小建议是不是可以在有 -p 参数但未指定欲下载集数（即空参数）的时候就预设下载全部集数，这样应该就可以不用 -b 参数？

THX

from bilili.

另外在 2.0 版有一段描述您写

使用协程而非多线程进行下载

但 Python 协程（asyncio ）虽然在实现上只用到了单线程，但却使用了线程池（即多线程）来处理阻塞式的 I/O 操作。
所以实际上差别只在于一个是直接操作多线程，一个是透过协程去操控多线程。

所以如果说使用协程而非多线程进行下载，可能有点不太恰当（因为其实最后还是用多线程去实现）

以上只是一个小小的建议，请勿怪

from bilili.

但 Python 协程（asyncio ）虽然在实现上只用到了单线程，但却使用了线程池（即多线程）来处理阻塞式的 I/O 操作。

关于这个，有相关的文档说明吗，或者如果有该位置的源码也可以

from bilili.

有个小建议是不是可以在有 -p 参数但未指定欲下载集数（即空参数）的时候就预设下载全部集数，这样应该就可以不用 -b 参数？

-b 是一个精准的控制是否启用批量下载的 flag，与 -p 是拥有不同职能的，其实在不指定 -p 时默认就是下载全部，因此只提供 -b 参数即可完成你所说的「在有 -p 参数但未指定欲下载集数（即空参数）的时候就预设下载全部集数」同样的功能，如果根据 -p 来确定是否是批量下载的话，一方面会增加逻辑的复杂度，另一方面也需要较多的文档来阐明这一点，会让用户更加难以理解

from bilili.

-b 是一个精准的控制是否启用批量下载的 flag，与 -p 是拥有不同职能的，其实在不指定 -p 时默认就是下载全部，因此只提供 -b 参数即可完成你所说的「在有 -p 参数但未指定欲下载集数（即空参数）的时候就预设下载全部集数」同样的功能，如果根据 -p 来确定是否是批量下载的话，一方面会增加逻辑的复杂度，另一方面也需要较多的文档来阐明这一点，会让用户更加难以理解

这部分我的想法和您刚好相反耶

1.没有 -b 就和 1.0 的参数都相同了，反而不需要去理解这个新参数的用途
2.同上没有 -b 就可以和 1.0 版保持使用上的一致性，USER 更容易使用
3.-b 容易和 -p 混淆，特别是您用 "批量下载" 来描述 -b 参数的时候（可能直接写明下载全部集数会比较好理解）
4.文档方面也容易，只需说明 -p 指定批量下载（若不选集则预设下载全部）
5.逻辑方面只需判断如果是空参数就下载全部，应该不复杂
6.有 -p 参数的时候表示一定要批量下载了，而且本身也具备可以指定下载全部的功能（但又还要加上 -b 才能用感觉多余）

以上只是我肤浅的想法，不一定正确，就交流交流看怎样能让 yutto 更好用 :P

from bilili.

但 Python 协程（asyncio ）虽然在实现上只用到了单线程，但却使用了线程池（即多线程）来处理阻塞式的 I/O 操作。

关于这个，有相关的文档说明吗，或者如果有该位置的源码也可以

这部分是我错了，因为我是从早期的 C C++ JAVA 这样一路学上来，早期作业系统没有协程（从 Windos Vista 之后才出现），学 Python 的时候又学到 asyncio 用单线程，去操作线程池，所以以为 Python 的 asyncio 只是 Python 用来操作多线程的技术而已，因为之前学其他语言的时候线程池只是管理多线程的方法而已，刚实际研究一下才发现原来不是这样，请原谅我的无知不好意思！

from bilili.

这部分是我错了，因为我是从早期的 C C++ JAVA 这样一路学上来，早期作业系统没有协程（从 Windos Vista 之后才出现），学 Python 的时候又学到 asyncio 用单线程，去操作线程池，所以以为 Python 的 asyncio 只是 Python 用来操作多线程的技术而已，因为之前学其他语言的时候线程池只是管理多线程的方法而已，刚实际研究一下才发现原来不是这样，请原谅我的无知不好意思！

这个没有关系的，还是比较欢迎讨论技术问题的(๑>؂<๑）～

from bilili.

这部分我的想法和您刚好相反耶

1. 没有 -b 就和 1.0 的参数都相同了，反而不需要去理解这个新参数的用途
2. 同上没有 -b 就可以和 1.0 版保持使用上的一致性，USER 更容易使用
3. -b 容易和 -p 混淆，特别是您用 "批量下载" 来描述 -b 参数的时候（可能直接写明下载全部集数会比较好理解）
4. 文档方面也容易，只需说明 -p 指定批量下载（若不选集则预设下载全部）
5. 逻辑方面只需判断如果是空参数就下载全部，应该不复杂
6. 有 -p 参数的时候表示一定要批量下载了，而且本身也具备可以指定下载全部的功能（但又还要加上 -b 才能用感觉多余）

以上只是我肤浅的想法，不一定正确，就交流交流看怎样能让 yutto 更好用 :P

其实我认为更主要的是一种语义的问题，-p 本身是指下载批量里的某一话，而默认不提供 -b 仅仅指定了下载某一话，如果在不提供 -b 的前提下直接提供 -p 其语义可能是「我要下载某一话，我要下载第 n 话」，这本身是说不通的，而加上 -b 后其语义则是「我要下载某一话所在的全部剧集，其中的第 n 话」，其实 -b 本身有一个特性是从单话链接中解析出整个剧集列表，而不提供这个参数时是不会这么做的，在使用 -b 时更多情况会有一种更加清晰的语义，让用户真的知道自己要做什么、在做什么

另外还有一个问题就是目前主要参数基本稳定了，这个基本已经无法修改了

from bilili.

其实我认为更主要的是一种语义的问题，-p 本身是指下载批量里的某一话，而默认不提供 -b 仅仅指定了下载某一话，如果在不提供 -b 的前提下直接提供 -p 其语义可能是「我要下载某一话，我要下载第 n 话」，这本身是说不通的，而加上 -b 后其语义则是「我要下载某一话所在的全部剧集，其中的第 n 话」，其实 -b 本身有一个特性是从单话链接中解析出整个剧集列表，而不提供这个参数时是不会这么做的，在使用 -b 时更多情况会有一种更加清晰的语义，让用户真的知道自己要做什么、在做什么

另外还有一个问题就是目前主要参数基本稳定了，这个基本已经无法修改了

感觉语意应该没问题，只是每个人的想法不同

1.-p 本身是指下载批量里的某一话（应该说某几话更正确？），您说「我要下载某一话，我要下载第 n 话」，
这边某一话和第 n 话看不出有什么不同，为什么要分两句来说。
2.不提供 -b 仅仅指定了下载某一话（不提供 -p 也是一样呀），只是批量和单话会用不同下载模版路径对吧。
3.您说 -b 的语意是下载全部剧集，但您目前的说明应该只有写批量下载（所以才容易和 -p 混淆） <= 这是从 1.0 版过来的 USER 观点来看
4.如果没有 -b 只给 -p 意思直接就是 「我要下载全部剧集，其中的第 n 话」了！这样一步到位，又和 1.0 可以完全保持一致不是吗？

建議：

保留 -b ，但改成可以只给 -p ，有 -p 的时候可以不用 -b 也就是等同已有 -b
这样 USER 也更容易理解，因为说明就可以不用特别说 -p 只能在有 -b 的情形下才能用！
反正给 -p 就自动有 -b 了。

像您说的参数最好不要乱改，保持一致性，這點我非常認同
我会觉得 -b 拿掉比较好也是为了和 1.0 保持一致性。

上面说的请您考虑一下，感谢！

PS.另外我发现改成用协程 --block-size 的预设值被从 1.0 版的 128MB 直接下杀到剩下 0.5 MB ，
先前我把 128MB 改到剩下 4MB 就已经在考虑会不会改太多了 ...

只想说一句大老是个狠人啊 XD

（谜之音～猜想应该是和我一样想解决到最后越下载越慢的问题吧！？）

from bilili.

这边某一话和第 n 话看不出有什么不同，为什么要分两句来说。

这里我们可以看这样一个例子，比如 ep395211，ep 号是可以唯一定位番剧某一话的，他就是 转生史莱姆日记 的第一话，他并没有批量下载的语义，因此在这种情况下，默认不带 -b 时行为很明确（yutto ep395211），就是下载这一话

而 yutto ep395211 -p 2 本身是没有意义的，因为 ep395211 只是第一话，但在这里为什么我们突然要让一个一话的链接去下载第二话呢？

此时我们改为 yutto ep395211 -b -p 2 语义就变了，此时其语义为找到该链接对应的视频列表，并批量下载该视频列表，由于指定了仅下载第二话，因此我们只下载列表中的第二话。

这里的关键就是 -b 的语义是「找到其对应的视频列表」，而省略了 -b 则有点说不通

另一方面就是，批量下载并不是只有 -p 一个参数，目前还有 --with-section 参数，未来可能会有更多的参数

其实在我最开始的设计时批量下载是完全作为一个子命令的，叫做 yutto batch，但考虑到从 bilili 迁移过来有点麻烦，而且其使用频率较高，因此这里做出了一部分的妥协，直接使用一个 -b/--batch 选项即可，进一步的妥协可能会比较麻烦，毕竟如果我们支持了这个特性，出于兼容性考虑，整个 2.0 基本不可能做出删除这一个特性的变动了，因此这种变动需要深思熟虑才可

另外我发现改成用协程 --block-size 的预设值被从 1.0 版的 128MB 直接下杀到剩下 0.5 MB

这里的话，其实都按照默认值就好，两者架构完全不同，你可以认为是完全重写，yutto 采用了纯内存 Buffer 缓存数据的策略，以避免低效且难以维护的硬盘文件缓存，以其特性而言，是不可能设置大的 --block-size 的，否则会导致靠后的块迟迟无法写入硬盘而占用大量内存，而 bilili 则不同，如果设置较小的块反而因为频繁维护造成磁盘读写的负担。但也并不是说 yutto 的设计是没有任何负担的，yutto 需要在内存中频繁维护其有序性，一方面内存负担会稍微高一些，另一方面需要 CPU 来维护这个有序性，但在默认设置下都在可接受范围内。

两者的默认值都是较为合适的设置，其实不修改是最好的，因为两者设计架构的不同，也是没有可比性的。

from bilili.

首先感谢您那么详尽的回覆：

因为您是从设计者角度去看，其实从 USER 角度的话很简单，只要能达到他想要下载的目的就行了！
若先不管您说的语意，因为没有第二话所以 yutto ep395211 -b -p 2 也一样下载不到东西不是吗？
如果假设一开始就没有 -b，如第一版光是 -p 就已经表示批量并直接去找对应列表下载的指定集数。

或许，也可以参考其他下载器的作法，一般而言会比较像您第一版这样，其实全部就只有批量的概念，
要不要资料夹或者需要怎样的结构，USER 自己透过路径模版去设置。

我的想法是尽量让他简单化，能达到目的就好，开发者容易维护，USER 也好用。

from bilili.

yutto 采用了纯内存 Buffer 缓存数据的策略，以避免低效且难以维护的硬盘文件缓存，以其特性而言，是不可能设置大的 --block-size 的，否则会导致靠后的块迟迟无法写入硬盘而占用大量内存，而 bilili 则不同，如果设置较小的块反而因为频繁维护造成磁盘读写的负担。但也并不是说 yutto 的设计是没有任何负担的，yutto 需要在内存中频繁维护其有序性，一方面内存负担会稍微高一些，另一方面需要 CPU 来维护这个有序性，但在默认设置下都在可接受范围内。

了解原来如此，其实如果不嫌麻烦还可以用混和架构，就是先下载到 Buffer 达到指定容量之后（如 128MB）再写入硬盘，这样不需太多内存又可以降低磁盘负担，Buffer 到多少写入一次硬盘让 USER 依据自己的环境去决定，所以鱼与熊掌还是可以兼得 ...
甚至如果还有空闲，可以帮 USER 侦测计算机的环境，自动佳化各个参数（如果 USER 没强制指定某些参数） XD

from bilili.

我的想法是尽量让他简单化，能达到目的就好，开发者容易维护，USER 也好用。

……我不想再花太多时间去讨论这个问题，这已经与最开始的讨论完全不一样了（与标题更是毫不相关），这里我明确给出关于 -b 的答复：不会改，除非收到更多反馈，yutto 已经开放这么久了你是第一个反馈的，我不会因为一个反馈而做出这么大的改变

了解原来如此，其实如果不嫌麻烦还可以用混和架构，就是先下载到 Buffer 达到指定容量之后（如 128MB）再写入硬盘，这样不需太多内存又可以降低磁盘负担

这里并不是你想的那样，而且对我来说 128 MiB 已经是不可接受的程度了，在 Buffer 超过 64MiB 时就会以红色预警，事实证明在大多数情况下 yutto 的内存 Buffer 不会超过 64 MiB。

如果还有问题可以到 https://github.com/yutto-dev/yutto/discussions 反馈，本 issue 就先 close 了

from bilili.