Greasy Fork

作者你好，最近脚本在批量添加功能中，“时间同步”按钮点出来的时间总是到十多天前（发帖时间算起），可能是B站改版了

好吧，刷新再刷新再手动终止批量添加后，“时间同步”又正常了……见鬼了……
同样见鬼的是，时不时会出现复选框空着但实际是checked 的状态……

现在明确“时间同步”按钮点出来的时间出问题的条件：重启浏览器。
只要开着浏览器，一直批量添加都会跟随更新这个同步时间，但一旦关闭Firefox，再打开就会跳出一个很久之前的时间。
刚才我就是点了一次“时间同步”，显示4.0天（小数就忽略吧），然后关闭Firefox再重新打开，再点“时间同步”，就变成8.9天了。
估计恐怕不是Firefox更新造成的，更有可能是TamperMonkey更新造成的。

这个问题困扰我很久了，但一直没什么头绪。从你描述来看，Firefox 上出现的情况会严重很多，我这边一个月顶多出现两三次，而且跟重启没什么关系，一般是跨标签页的时候有可能出问题。你换浏览器试试吧，看能不能提供多点线索。反正仅靠目前的信息我是修不了了。

更新 TamperMonkey 最新版之后，好像问题消失了。似乎是 TM 5.0.0 引入的bug，但更新说明中又没提到有涉及 GM-setValue 的修正……回看5.0.0更新的时间，似乎对得上印象中开始出现时间同步问题的时间。
————
之前的现象是追踪整个时间戳写入的过程都正常，甚至 batchLastAddTime 写入后再读取都是新写入的时间戳；但在 TM 的脚本编辑中“存储”内的 batchLastAddTime 值却是没变的，也就是 TM 把值缓冲在临时区域而没写入存储区域，这样刷新网页就会丢失新的 batchLastAddTime 值。
————
另外有小概率会出现“时间同步”按钮点出来个极小的时间数（不是时间戳），不知是时间换算出问题，还是“无有效新稿件时直接更新同步时间”被意外触发，暂时未能确定重现。

如果时间间隔确实很小的话点出极小时间数也很正常。除此之外出现极小时间数的异常状态我一次都没见过。

按其记录 batchLastAddTime 的语句来看，出现极小时间数可能因为其会在加载新稍后再看新视频完成后写入一次（写入载入完成时间），一般是添加新视频后按最后一个添加到列表的新视频时间为最终时间数，但若不添加新视频的话，这个时间数就会造成极小的时间数；合理的机制应该是加载新视频后待添加新视频数为零时才以载入完成时间写入。

1.加载并不会更新时间，只有当加载不出新稿件时才会更新（加载不出新稿件且没有错误意味着这段时间没有人投稿，无效时间直接跳过）。具体机制详见右键悬浮说明。

2.我并不明白你说的极小数是什么意思，即使出现了也很正常。如果刚更新完时间，又进行新一次同步，那么期间只间隔了几秒，出现 0.000001 这样的间隔是理应如此的，并不理解你为什么说这是个问题。

好像有点理解你说的是什么了，但这是预期设计。同步时间的预期是：在理论上不遗漏关注线上的所有稿件的前提下尽量靠后。

举个例子：

你在凌晨三点钟点击了「时间同步」，把想添加的稿件都添加了，最后一个稿件正好是三点整上传的，最后同步时间是 3:00。当你熬夜熬到第二点早上 11:00 的时候，你再次点击「时间同步」，很遗憾 3:00-11:00 这段时间并没有人上传新视频，既然 3:00-11:00 已经被确认找不到东西了，那么同步时间就应该更新为 11:00 而非停留在 3:00。

为什么要这么设计？假设一个极端的例子：

你只有一个关注，他上次发布视频时间是 2020 年 2 月 2 日，之后就销声匿迹了。你很关心他，每天都同步一次看是否有新稿件。直到 2024 年 2 月 28 日，他终于回来了，你点下「时间同步」按钮，脚本会从你上次的加载时间 2024 年 2 月 27 日 0:00 开始查找，不一会就找到。在另一个时间线，脚本的设计是不考虑零加载情况的，此时脚本得从 2020 年 2 月 2 日开始查找，找到 2024 年 2 月 28 日为止。显然这是荒谬的。

当然有一种特殊情况，就是新关注了几个人，他们正好在 3:00-11:00 上传了视频。但在我看来，这些视频是理应被遗漏的，因为你在上一次同步的时候并没有关注他们，但关注他们的时间点必然在同步时间点后，所以下次同步能包含关注他们后他们才发布的视频。