我當時不知道該把這篇貼在哪裡。
我剛組好一台新的「伺服器」（Windows 10 Pro 64bit），發現每次錄影結束後，SageTV 就再也無法跟調諧器通訊。花了好幾天抓問題，用 Wireshark 才看到原來是 MCEBuddy 瘋狂對 Ceton 狂發 Upnp「請求」，每秒幾千筆，幾分鐘後調諧器就因為撐不住而開始噴錯誤。
這現象只在第一次錄影結束後才會出現（重開機後或重啟 MCEBuddy.service 後），而且會一直持續到我把 MCEBuddy.service 關掉或重開機為止。
把 MCEBuddy 裡的 Upnp 關掉後，一切就正常了，MCEBuddy.service 也不再狂打 Ceton。
Ceton 的 IP 是 192.168.200.1，送給 192.168.200.2；MCEBuddy 在 192.168.1.26（伺服器 IP），所以我也搞不懂為何 MCEBuddy 會對 192.168.200.x 瘋狂通訊。
或許我們需要能讓 MCEBuddy 綁定到特定網卡或位址的功能？
這是 Ceton 驅動程式的錯誤。MCEBuddy 只是使用 Windows API 在閘道裝置上啟用 UPnP 連接埠。Ceton 的驅動程式有一個錯誤，當它收到 UPnP 請求時會失控（它根本不應該回應，因為它不屬於 UPnP 裝置）。這在已知問題主題中有記載，Ceton 也已承認並發布了更新的韌體/驅動程式。
奇怪的是，為什麼那台機器上其他使用 UPnP 的程式似乎都沒有和 Ceton 發生衝突。也許它們沒有使用 Windows API？
Ceton 驱动程序的 bug 在于，它向 MCEBuddy 回应说自己支持添加/删除端口转发映射，于是 MCEBuddy 就给它发送端口映射信息，让它“转发”端口并“删除”旧端口。
只有网关/路由器设备才应该回应具备这些能力，不清楚为什么 Ceton 会报告自己是一个端口转发设备。
好的，我已經修改了 MCEBuddy 和 Windows UPnP 的行為，希望能解決 Ceton 電視調諧器韌體錯誤的問題。
我們將探索「回應」時間限制在 60 秒內，而不是保持開放狀態，並且 Windows UPnP 只會請求探索 WANIPConnection 和 WANPPPConnection 服務裝置。如果您的 Ceton 電視調諧器不是 WAN 裝置（我想不到它為什麼要宣告自己或回應這類探索請求），它就不應該回應，一切應該都會正常。
試試今天的 2.4.9 BETA 版本，然後告訴我結果如何。
謝謝 Goose，看來這些修改奏效了。