sACN 备用源优先级更低却持续发包，接收结果怎样判读

备用sACN源持续发包不代表它会成为当前有效源。先按同一Universe比较有效源的Universe Priority，再列最高优先级候选；相同优先级下怎样合并，还要看接收实现。不能只凭“最后收到谁”判断哪个源生效。

先固定输入与适用条件

本例仅分析整Universe优先级，范围为零到二百，不使用每地址优先级扩展。参与比较的源被假设处于有效观测窗口，未模拟超时或源退出；若实际源已失效，应先按目标规范与实现处理生命周期，再进行优先级选择。

Art-Net字段按官方4版Release V1.4、Revision 1.4dp核对。sACN例子限定ETC sACN v2.0.2所声明的E1.31-2018兼容字段及IPv4样本；现行ESTA目录已列E1.31-2025，2018亦含IPv6。本文不声称旧库实现新版全部功能。

按字段与边界执行

1. 按Universe及CID建立源记录，保存priority、最后观测时间和有效状态。名称相同不合并身份，CID冲突需要先独立复核。

2. 拒绝超出零到二百的优先级；同一个范围内选择数值最高的有效候选。不要把默认值或自定义备用级别当作所有项目都相同。

3. 最高值只有一源时输出唯一候选，多源并列时输出候选集合和“合并策略待确认”。本题不会擅自选择最新一包，也不替接收器实施HTP或LTP。

4. 现场切换还需确认源超时、终止包和接收方容量限制。用公开软件支持说明及实际日志补足这些条件，不通过提高所有源优先级解决竞争。

用具体样例核对结果

场景一有90、100、120三个优先级，只有120进入最高候选；场景二有两个100并列，脚本保留两个CID，结果明确没有计算最终槽位。非法值201会被拒绝。这样能检查备用源存在是否合理，同时避免把优先级候选表伪装成真实灯光混合结果。

通过条件是同Universe来源齐全、无效项已排除、最高值候选准确、并列策略有明确证据。若备用持续发包却不生效，这可能是设计结果；若主源失联后迟迟不切换，应调查生命周期与超时，而不是只看priority。每地址优先级与标准整Universe优先级是不同层次，未经确认不应将厂家扩展写成所有E1.31接收器必选功能。

下载与复现

analyze.py、input.json、result.json。

下载输入与结果可以替换成脱敏的源快照，但应同时记录观测窗口和有效判据。最终现场报告还需实际槽位输出或接收状态，本文算法只负责候选选择的可审查部分。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看sACN（E1.31）灯光网络协议速查。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• priority有效范围。
• 固定2018兼容实现范围。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。