PAYATHON 2026

Stalker 5.2.0 的 create_link 为何返回错误剧集？

数据小许

应先检查是否遗漏了查询单集下媒体文件的步骤，再使用文件条目的 cmd 获取播放链接。不要将单集 id 或季 id 直接拼成 /media/{id}.mpg。

公开的 Stalker 源码副本采用了这种分层查询方式，但无法确认它与该 portal 部署的 5.2.0 代码完全一致。以下请求流程可供验证，能否用于当前环境，需要以接口返回或部署源码为准。

为什么单集 ID 会播放出其他内容？

同一个数字可以分别出现在电视剧、季、单集和文件记录中。这些是不同类型的标识，不能因为字段都叫 id 就互换使用。

公开实现中的 Video 类分别从 video、video_season、video_season_series 和 video_series_files 读取这些记录，单集记录与文件记录之间存在独立的映射关系。Video 类源码

你提供的现象与“把单集记录 ID 当成视频 ID 解析”相符。返回不同 CDN hash，只能说明请求解析到了不同资源，不能证明资源属于目标单集。

先查询目标单集的文件列表

公开源码中的 getOrderedList() 根据 movie_id、season_id 和 episode_id 逐层返回季、单集及文件。文件条目使用 is_file 标识，并生成文件级 cmd。Vod 类源码：列表分派与文件查询

如果当前 portal 保留了这一实现，可以使用示例条目中的三个 ID 继续查询：

type=vod
action=get_ordered_list
movie_id=36403
season_id=27657
episode_id=886710

这里的 episode_id 是单集条目的 id，不是 series_number=29。

以下示例假设现有客户端使用 Bearer token 和 Cookie 维持登录状态；实际鉴权信息应沿用已经能够播放电影的请求：

curl --get 'https://[portal]/stalker_portal/server/load.php' \
  --header 'Authorization: Bearer <TOKEN>' \
  --header 'Cookie: <EXISTING_SESSION_COOKIES>' \
  --data-urlencode 'type=vod' \
  --data-urlencode 'action=get_ordered_list' \
  --data-urlencode 'movie_id=36403' \
  --data-urlencode 'season_id=27657' \
  --data-urlencode 'episode_id=886710' \
  --data-urlencode 'p=1' \
  --data-urlencode 'JsHttpRequest=1-xml'

检查返回结果是否已进入文件层级，重点查看 is_file、文件条目的 id 和 cmd。如果有多条文件记录，再根据实际提供的语言、画质等信息选择。

Infomir 的管理文档区分了季、单集和单集下的文件，并说明一集可以关联多个语言或画质版本。即使只有一种可选版本，也不能因此跳过文件查询。Infomir：添加电视剧及单集文件

在上述公开实现中，/media/{id}.mpg 与 /media/file_{id}.mpg 进入不同的解析分支，后者用于查找文件记录。文件级 cmd 也可能直接来自已配置的 URL，应优先使用返回值。Vod 类源码：createLink

如果文件列表确实返回 /media/file_<fileId>.mpg，再按下面的方式请求。<fileId> 必须替换为文件列表返回的文件 ID，不能直接替换成 886710：

curl --get 'https://[portal]/stalker_portal/server/load.php' \
  --header 'Authorization: Bearer <TOKEN>' \
  --header 'Cookie: <EXISTING_SESSION_COOKIES>' \
  --data-urlencode 'type=vod' \
  --data-urlencode 'action=create_link' \
  --data-urlencode 'cmd=/media/file_<fileId>.mpg' \
  --data-urlencode 'series=29' \
  --data-urlencode 'JsHttpRequest=1-xml'

使用 series=29 的前提是当前部署保留了该源码的集号处理逻辑，且所选文件属于示例中的第 29 集。该分支会参考文件所属季和 series_number 选择单集，因此不要沿用独立电影测试中的 series=1。Vod 类源码：series 参数处理

如果实际文件条目的 cmd 是其他格式，应保留其内容，按该 portal 自带客户端的处理方式使用，不要强行改造成上述路径。

series 是否只是语言选择参数？

现有测试不足以得出这个结论。series=28 和 series=29 返回相同路径，只能确认它们没有让当前这组请求切换到不同资源。

原因可能是请求仍停留在父级视频路径、缺少文件上下文，也可能是该部署修改了参数处理逻辑。series_files: "1" 本身也不足以证明 series 的语义；即使已经确认只有一种语言版本，两者之间的关系仍需要源码或请求记录佐证。

MAG STB 是否使用了其他流程？

需要从能够正确播放的 MAG STB 或 portal 自带前端记录完整请求链，才能判断当前部署的实际行为。重点观察选择某一集后、发起播放之前是否还有一次文件列表请求，以及最终传给 create_link 的完整 cmd 和 series。

建议比较同一季的相邻两集，记录：

  • 查询文件时的 movie_id、season_id、episode_id。
  • 所选文件记录的 id 与 cmd。
  • 最终 create_link 请求参数及返回的播放命令。

如果正常客户端也执行了文件查询，就按它的流程实现。如果正常客户端使用额外 action，则以该部署实际发出的请求为依据。目前没有足够依据把 get_link 或 get_video_info 当成这个 portal 的可用替代接口。

文件查询仍然失败时怎么办？

先核对 ID 是否来自同一条数据链。示例单集的 season_id 是 27657，第五次尝试使用的是 26385；如果它们对应不同测试对象，需要分别核对，不能混用。

如果查询返回空列表、false，或者文件级 cmd 仍为空，让 portal 维护方检查目标单集是否关联了可访问的视频文件，以及当前账号是否有相应权限。还应检查部署中的 getOrderedList()、getFilesList() 和 createLink()，确认是否保留了公开实现的参数和路径规则。

上面的 GitHub 链接是可阅读的源码副本，不能证明它与当前部署版本一致；Infomir 链接说明的是管理端数据结构，也不是 5.2.0 的完整 STB API 参数规范。最终应根据部署源码和正常播放客户端的请求记录确认接口契约。

备注：内容仅供参考。