We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.0.2
Docker
主程序
无论是在v1还是现在的v2的版本,对下载完成后整理的工作流都是靠QB 触发transfer api来
后台自动完成的,想要补全或者增加其他流程目前只能靠插件定时来完成。 这种工作流不
是说不好,只是类似目录监控、strm生成这些有不必要的后台扫库,即使本地硬盘也有性能
浪费重复消耗的问题何况网盘这些还容易造成风控。
因此,还是建议在主程序增加工作流自定义: 比如在目录设置里面,增加执行顺序
整理方式 覆盖模式 执行顺序 1 智能重命名 执行顺序 2 刮削元数据 执行顺序 3 扩展调用1(可选择strm生成) 执行顺序 4 扩展调用2(媒体库刷新) 执行顺序 5
这样来保证可用流程是触发式的,可以把不必要的定时任务插件直接关闭了,一来性能资源
不会重复占用消耗,二来可以用户自己定义选择适合自己的工作流。
目前插件虽然很多,但是群里实际看到还是有用户多个插件重复进行一样的扫库,插件间联
动靠不同插件不同作者自身也做不到体验 统一。另外这样就不需要插件作者做啥联动适配了,主
程序只是在上一个py执行完除非下一个,和手动执行插件一样,即完善了工作流多样性、提高了
效率,又避免了插件作者直接改插件联动造成其他bug。
No response
The text was updated successfully, but these errors were encountered:
好想法
Sorry, something went wrong.
No branches or pull requests
当前程序版本
2.0.2
运行环境
Docker
功能改进类型
主程序
功能改进
无论是在v1还是现在的v2的版本,对下载完成后整理的工作流都是靠QB 触发transfer api来
后台自动完成的,想要补全或者增加其他流程目前只能靠插件定时来完成。 这种工作流不
是说不好,只是类似目录监控、strm生成这些有不必要的后台扫库,即使本地硬盘也有性能
浪费重复消耗的问题何况网盘这些还容易造成风控。
因此,还是建议在主程序增加工作流自定义:
比如在目录设置里面,增加执行顺序
整理方式 覆盖模式 执行顺序 1
智能重命名 执行顺序 2
刮削元数据 执行顺序 3
扩展调用1(可选择strm生成) 执行顺序 4
扩展调用2(媒体库刷新) 执行顺序 5
这样来保证可用流程是触发式的,可以把不必要的定时任务插件直接关闭了,一来性能资源
不会重复占用消耗,二来可以用户自己定义选择适合自己的工作流。
目前插件虽然很多,但是群里实际看到还是有用户多个插件重复进行一样的扫库,插件间联
动靠不同插件不同作者自身也做不到体验 统一。另外这样就不需要插件作者做啥联动适配了,主
程序只是在上一个py执行完除非下一个,和手动执行插件一样,即完善了工作流多样性、提高了
效率,又避免了插件作者直接改插件联动造成其他bug。
参考资料
No response
The text was updated successfully, but these errors were encountered: