[功能请求]可不可以请求在云同步中加入同步追番列表的功能

[Anti-World]

No description provided.

[Predidit]

其实这部分代码已经写好并提交到仓库了，只是没有启用。

主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。

简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。

但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。

如果有什么好的解决办法，欢迎告诉我。

[Anti-World]

原来是这样，谢谢解答

[Predidit]

重新打开此问题以防止重复提问

[YCZ01111]

其实这部分代码已经写好并提交到仓库了，只是没有启用。

主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。

简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。

但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。

如果有什么好的解决办法，欢迎告诉我。

能否通过给同步文件名称添加时间戳的方式来避开缓存

[YCZ01111]

为何不直接接入bangumi的追番功能以及历史记录

[frostnotfall]

其实这部分代码已经写好并提交到仓库了，只是没有启用。

主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。

简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。

但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。

如果有什么好的解决办法，欢迎告诉我。

这些缓存一般也都是遵循HTTP标准，可以试着参考： HTTP 缓存

可以尝试两种方法：

1. 标准方法：设置请求头 Cache-Control: no-cache
2. 添加查询参数：在请求的 URL 后面加上时间戳或随机数，例如 file.txt?v=123456

对于第二种方法，一般的缓存策略，带参数都会忽略缓存的，但是也有专门配置忽略请求参数的，两者可以结合一下使用看看效果

[stevei5mc]

我觉得可以先加上手动同步来暂时满足同步追番列表的需求，自动同步等到有解决问题的方法在搞也不迟
还有就是可以将此issue置顶以防有人重复提出