昨天睡（迫真）前突然想拖一顿rosefile站，花了大概一个小时对着之前用了114514年的kg系脚本和现在跑在github actions上的metart系脚本缝了1145.14秒，缝出了一个github actions用的脚本，一个站四个线程，12线程，启动！🤔但跑了一顿后出现了一大堆只有6xxxx字节的post，而且我下了其中某一个看上去不是6xxxx字节的post，它里面应该有两个rar但我最终下的东西里面只有一个（恼🤔

这说明多线程跑rosefile链接解析时，它的登录特性（一台机子登录后别的机子之前登录过生成的cookies光速失效）能够导致部分线程没法正常解析出链接🤔那么如果我设置成无限循环重试呢？它又会出现所有线程搞半天都处理不了任何一个文件的情形，此时它们估计忙着互相使对方的rosefile登录状态失效，最终没有一个号能解析出链接（撅望🤔

既然如此，在这些机子上完成rosefile链接解析基本上不可能力，如果是以前的话我肯定能光速撸一个cgi-bin脚本，rosefile只要能解析出cloudflare r2或者sharepoint的链接，接下来这些链接既不锁ip又不验证headers，随便哪个github线程都能随便下（确信🤔但我现在缺少撸这套玩意的基础设施，所以我还是在我的vps上跑单线程rosefile得了，那些github actions号如果实在是闲得没事干，不妨接着跑sexart去🤔

bruhfei

又跑了一两个sexart小站，某个github旧号有时候能跑20线程有时就只能跑1⑨个线程，此时我就需要对付它处于排队等待状态的那个线程（恼🤔比如我可以将它分配到的maindb.txt直接便乘一个空的，这样它哪怕到时候上线也只会光速结束（确信🤔然后我接着分配一次🤔

11451.4 secs later,,,

现在metart系只剩下一个alsscan和metart主站没拖🤔先拖alsscan，它有接近4000个图集和4000个视频🤔

这次我上了若干个号，某老号18线程，别的号5线程，总计33个🤔出于某种申必原因，这些号拖这4000个图集居然花了两小时半还没拖完，肉眼可见地要肝到三小时半甚至四小时（全恼🤔有没有可能因为这个alsscan，它有很大一部分图集体积是以GB计的？🤔

所以到该拖视频的时候，我是只开20线程呢，还是开个什么38线程？🤔但无论怎么开，我现在只需要短短的几句话，按下回车后它就会自动分割maindb自动分配任务，非常方便（确信🤔接下来我就要么坐等它完成，要么等六小时多十分钟甚至⑨分钟后自动合并，然后自动重新分配（确信🤔

barbruh

终于，alsscan的视频部分开拖力🤔上次我写了一个连续拖视频workflow直接导致我的某个老号被橄榄，所以这次我需要用github actions自身机制之外的玩意实现workflow无限续🤔而这其实相当好办，既然之前已经用repository_dispatch实现了几乎全自动分配任务，更早之前又实现了自动合并，那么我完全可以将这两者缝起来，也就是分配任务后定一个一个一个6小时零10分钟甚至⑨分钟的时，时间一到自动合并然后紧接着分配任务，以此重复三回啊三回（确信🤔至于定时，可以用简单的sleep来实现，也可以随便找个倒计时脚本，实现可视化的倒计时（确信🤔

现在理论上来说我再也不用人工干预这破玩意力，如果我不想人工干预的话🤔我要是中途想人工干预的话我就中断这个自动脚本的运行，停掉所有的workflows，然后重新开始这段脚本（确信🤔

只不过我现在这坨玩意跑在五个还是六个不同的github号上，而我懒得一个一个一个登录它们停掉workflows🤔我寻思下次我可以考虑写一个kill switch，换句话说它以后每次搞完并上传完后还会从某位置下载一个文件，根据文件内容来撅定继续还是中止整个脚本🤔但这次我懒得折腾力，github要是因为我跑满六小时就橄榄我的号就橄榄好了，懒得关心（吴慈悲🤔毕竟哪怕我接下来一整个月都没法用github actions，我现在雷普github actions生成的数据已经突破了0.05PB，就这样🤔