Hydra 搭配 Real-Debrid 为什么总把同一个游戏下载两遍3处改动完整指南【免费下载链接】hydraHydra Launcher is an open-source gaming platform created to be the single tool that you need项目地址: https://gitcode.com/GitHub_Trending/hy/hydraHydra Launcher 是一款开源游戏发行与下载平台一个客户端就覆盖了找资源、下文件、装游戏的全流程。不少人在 Hydra 里挂 Real-Debrid 走磁力下载时都碰到过这种糟心事明明上次就下完过的游戏今天再点一次又从 0% 开始或者下载目录里躺着一份下完的压缩包旁边又多出一份双胞胎。这篇文章带你从原理层面看懂 Hydra Real-Debrid 重复下载是怎么发生的并用 3 处不大不小的改动把它按住。先还原一个真实场景带宽又烧了一遍假设你昨晚用磁力链接下好了某款游戏今天打开 Hydra 想顺手把更新包也拉下来结果发现主文件又在重新下载了。更隐蔽的情况是你根本没主动操作只是重启了客户端队列里的任务状态一刷新原本已完成的任务又变回了等待中然后老老实实从头传。这类问题集中出现在磁力链接场景直接后果有三个白白消耗 Real-Debrid 的流量额度、下载目录里堆着文件名高度相似的两份文件、以及队列被卡住后其他游戏跟着等。好消息是它并不是 Hydra 的下载队列本身记不住任务而是磁力链接 → 直链这段路上有几个环节会重复走、重复判断。动手前先避开 3 个常见误区误区一同一游戏点了两次下载所以出问题了。其实 Hydra 的下载队列是按商店 游戏 ID做唯一键存的见 src/main/level/sublevels/downloads.ts你点对同一个游戏两次本地只会有一条记录不会真的在队列里生成两个任务。真正反复跑的是另一层——每次任务启动时都会重新向 Real-Debrid 要一次直链。误区二磁力链接相同服务器端就一定只有一份。方向对了但结论下早了。Real-Debrid 内部确实以种子的哈希值infoHash去重问题在于去重成功和状态可用是两回事——哈希能对上但那份种子在服务端可能还卡在转换、压缩环节客户端此刻去取直链只会拿到空手。误区三把本地文件删掉重来就好。这解决不了任何根因只是把问题藏起来下次还会原样复现。看懂一条传送带磁力链接到直链之间发生了什么可以把 Real-Debrid 想成一条快递传送带。你丢上去一个 magnet 链接相当于下单服务器要先做几道工序解析磁力、等待文件列表、必要时全部选中文件、然后下载进它的缓存状态才会走到downloaded这时才有一张提货单直链可以给你。Hydra 这边负责对接传送带的代码在 src/main/services/download/real-debrid.ts核心就两个方法getTorrentId拿到 magnet 后先从你账号的种子里按 infoHash 找有没有老订单找到了就复用它的 ID找不到就调addMagnet下一张新订单。getDownloadUrl拿着种子 ID 查状态只有状态恰好是downloaded时才返回直链其他任何状态一律返回 null。对照 src/types/download.types.ts 里的RealDebridTorrentInfo类型能看到状态远不止downloaded一种还有magnet_conversion磁力转换中、waiting_files_selection等选文件、compressing打包压缩中等等。重复下载正是从这条传送带的缝隙里漏出来的主要是两个点状态竞争种子明明已经在传送带上了甚至快传完了但客户端查到的那一刻还没到downloaded于是本次任务失败、抛NotCachedOnRealDebrid下次再启动任务时整个流程又走一遍。没有提货记录Hydra 本地只存了这个游戏用哪个下载器、下到百分之几并没有存这个游戏对应的是哪条种子、直链长什么样。于是每次启动都重新翻全量种子列表、重新走一遍状态判断。改动一下新订单之前先翻一遍旧订单这是收益最直接的一处。思路很简单既然 Real-Debrid 按 infoHash 去重那客户端在调addMagnet之前应该先把自己账号里的种子按 infoHash 排一遍队——找到downloaded状态的直接复用它的 ID一条新订单都不用下找到还在downloading/waiting_files_selection的同样复用别再去addMagnet避免服务端出现同哈希的重复条目它们会互相干扰还各占一份资源完全没找到才老老实实创建新种子。核心改动集中在getTorrentId示意如下static async getTorrentId(magnetUri: string) { const { infoHash } await parseTorrent(magnetUri); const userTorrents await RealDebridClient.getAllTorrentsFromUser(); const reusable userTorrents.find((t) t.hash infoHash t.status ! dead ); if (reusable) return reusable.id; // 老订单直接续用 return (await RealDebridClient.addMagnet(magnetUri)).id; }改完之后同一个游戏反复下的大头就砍掉了只要服务端那份种子还在客户端永远不会为它再下一张新订单。改动二别只瞄一眼就下结论轮询把状态等出来改动一解决不再重复下单改动二解决不再误判失败。原逻辑是查一次状态不是downloaded就返回 null上层 src/main/services/download/download-manager.ts 收到 null 会立刻抛错。对于一条刚丢上去、正在转换磁力的种子这一眼瞄下去几乎注定扑空。更稳的做法是当状态落在还在路上的状态magnet_conversion、waiting_files_selection、compressing时隔几秒再查最多重试若干轮再下判断let info await this.getTorrentInfo(torrentId); if (info.status waiting_files_selection) { await this.selectAllFiles(torrentId); info await this.getTorrentInfo(torrentId); } for (let i 0; i 3 info.status ! downloaded; i) { await sleep(2000); info await this.getTorrentInfo(torrentId); } if (info.status downloaded info.links.length 0) { const { download } await this.unrestrictLink(info.links[0]); return decodeURIComponent(download); } return null;注意保留selectAllFiles这一步磁力种子到达时通常处于waiting_files_selection不替用户把文件全勾上它一辈子都到不了downloaded。这段逻辑原代码里已经有了重构时别顺手删掉。改动三在本地记账本上留一笔提货记录前两条改动都发生在每次启动任务的路径上。再往前进一步可以像收银台贴小票一样把解析结果记在本地Hydra 用 LevelDB 做本地存储下载任务存在downloads子库里。按同样的模式可以新增一个以 infoHash 为键的轻量缓存内容就是这条种子对应的 Real-Debrid 内部 ID 解析出的直链 过期时间。Real-Debrid 的直链有时效所以记账时必须写过期时间读的时候先验期// 写入rd:infoHash - { torrentId, url, expiresAt } await downloadsSublevel.put(rd:${infoHash}, { torrentId, url: directUrl, expiresAt: Date.now() 24 * 3600 * 1000, }); // 读取过期即弃 const hit await downloadsSublevel.get(rd:${infoHash}).catch(() null); if (hit hit.expiresAt Date.now()) return hit.url;有两点值得强调直链过期后优先回退到按 infoHash 找种子再重新取链即改动一的路径而不是重新addMagnet。因为文件很可能早在 Real-Debrid 缓存里躺好了重新取链是秒级操作重新下单才是分钟级。这份缓存只是加速与兜底不是数据源。真正确认文件是否可用的永远是服务端的种子状态。改完之后怎么确认一份 5 分钟自查清单重下同一个游戏选一个已完成的磁力游戏重新发起下载。观察日志——应该走复用已有种子的分支而不是出现新的addMagnet调用。盯着状态跑一遍对一个刚丢上去的磁力链接确认任务在magnet_conversion→downloaded之间是平滑过渡的而不是失败后由人工再点一次。看本地存储找到 Hydra 的数据目录Linux 下通常在~/.config/hydra确认出现了以rd:为前缀的缓存键且再次下载同游戏时能命中。看下载目录确认没有再生成文件名仅差一个序号的重复压缩包。重启客户端重启后队列恢复、任务不再死灰复燃是本地记账生效的最直观信号。改动前后对比观察点改动前改动后同游戏二次下载可能重新下单、重新取链直接复用已有种子状态未就绪时一次查询失败即报错有限次轮询减少误判每次启动任务拉全量种子列表比对本地缓存命中则跳过带宽消耗重复拉取已缓存文件基本只走一次进阶提示让这套流程长期不掉链子并发别贪多同时挂太多磁力任务时Real-Debrid 侧的转换排队会更久状态轮询的窗口也要相应放宽。2~3 个并发是比较稳的节奏。网络抖动有兜底Hydra 的下载编排器src/main/services/download-orchestrator.ts已经处理了断网宽限与重连恢复改上面三处逻辑时别绕过它否则断网场景会退化。定期给账号减负重Real-Debrid 里死掉、过期的种子建议手动清一清。本地按 infoHash 记账虽然不怕重复但服务端条目太多会让全量列表拉取变慢。想读完整实现可以拉源码对着看git clone https://gitcode.com/GitHub_Trending/hy/hydra重点目录是 src/main/services/download/各家下载服务的适配层和 src/main/level/sublevels/本地状态存储。一句话收个尾重复下载从来不是下载器忘了自己下过而是每次都在重新问一遍而答案来得太慢。把先查旧账、等状态、记一笔这三件事补上Real-Debrid 这条传送带就不会再让你重复付运费了。【免费下载链接】hydraHydra Launcher is an open-source gaming platform created to be the single tool that you need项目地址: https://gitcode.com/GitHub_Trending/hy/hydra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
