更新了v2版本的后，会重新下载一遍收藏

[Moyuuko]

更新了v2版本的后，会重新下载一遍收藏，还有问下video_name留空是不是可以不生成目录

[amtoaer]

1. 是的。 更新文档里提到的配置不兼容包括数据库结构不兼容，这意味着程序无法读取 v1.x 中保存的视频下载状态。
2. 不可以。 1.x 版本最开始没有考虑到多页视频，所以初始使用的是平铺。但多页视频必须存储在单独的文件夹中才能被 emby 当作电视剧读取，因此 1.x 版本在支持多页视频后实际使用了两套路径结构，很不和谐。 基于上述原因，我在 2.x 版本开发之初就决定统一将视频分页放到单独的文件夹（video_name）中，避免这方面的差异。当前程序是无脑 join video_name 的，如果将 video_name 留空，至少肯定会导致多页视频平铺出来，tvshow.nfo 与 poster 被重复覆盖，此外还可能会有其它的非预期问题。 我的建议是保证 video_name 非空，并使用模板确保每个视频都有全局唯一的 video_name。

[lemonhall]

能不能写个升级指引之类的？重新下载一遍。。。太恐怖了，3000-4000的视频收藏，几个T啊

[amtoaer]

需注意的是，出于项目功能和实现难度上的考量，该版本与 v1.x 的 Python 版本配置不兼容。

emm，我认为版本说明中的“不兼容”已经描述得足够明白了，为了避免意料外的升级专门使用了新的包名。

我提到了“出于项目功能和实现难度上的考量”，展开来讲：

1. 项目功能是“下载b站收藏夹”，这意味着绝大部分视频是可重复获取的，只需要付出部分带宽成本就能恢复到原有的下载状态。（我相信需要重新下载几 T 的是极少数，绝大部分人付出很小的代价就能恢复下载）
2. 实现难度方面，首先要说明的是，跨语言的重写，或者更具体地说“更换 ORM” 时要兼容老的结构本身就有不小的心智负担。 此外，我在开发新版过程中展开看了看 python 版本 bilibili-api 的实现，发现它在许多地方会有隐性的网络请求。比如下载视频页依赖视频的 cid，如果只传入页码就会隐性请求获取一次 cid。弹幕下载与转 ass 格式依赖视频的时长和宽、高，也会隐性获取一次视频的页信息，而这些信息实际上是前面步骤就已经获取过的。因此在新版本的实现中，我将 cid，视频时长和宽、高等信息全部记录了下来，可以在下载步骤避免掉不必要的请求。如果对原有的表结构做迁移，这些字段不太好填充为有效的值。

基于上面的考虑，最终决定不再兼容 1.x 的配置。

如果你真的想要跨大版本升级时确保程序不下载历史视频，想了想有一个非常 hack 的方法。在程序运行到“正在下载未处理的视频时”把程序终止（开始下载视频说明这个收藏夹里的视频信息已经获取完毕），使用数据库管理工具打开 sqlite 文件，将 video 表中的所有行的 valid 设置为 0/false（标记视频为失效）。继续运行程序，程序应该会跳过所有失效视频，继续处理第二个收藏夹，重复上述操作，直到所有收藏夹中的旧视频都被标记为失效。此时关闭旧版本 bili-sync，仅运行 bili-sync-rs 即可。