Je viens de monter un nouveau « serveur » (Windows 10 Pro 64 bits) et j’ai remarqué que SageTV ne parvenait plus à communiquer avec le tuner peu après la fin de chaque enregistrement. Après des jours de diagnostic, j’ai découvert (via Wireshark) que MCEBuddy mitraillait le Ceton avec des « requêtes » Upnp, produisant des milliers et des milliers de communications. Au bout de plusieurs minutes, le tuner commençait à renvoyer des erreurs car il ne supportait pas la charge.
Le phénomène ne démarre qu’après la fin du premier enregistrement suivant un reboot (ou un redémarrage du service MCEBuddy), puis ne s’arrête plus tant que le service MCEBuddy n’est pas arrêté ou que l’ordinateur n’est pas redémarré.
En désactivant Upnp dans MCEBuddy, tout est rentré dans l’ordre et le service a cessé de harceler le Ceton.
Le Ceton est sur 192.168.200.1, livrant à 192.168.200.2. MCEBuddy est sur 192.168.1.26 (IP du serveur), donc je ne comprends pas pourquoi MCEBuddy s’acharne à contacter 192.168.200.x.
Peut-être faudrait-il pouvoir lier MCEBuddy à une interface ou une adresse spécifique ?
C’est un bug avec les pilotes Ceton. MCEBuddy utilise simplement une API Windows pour activer les ports UPnP sur le périphérique de passerelle. Ceton a un bug dans leurs pilotes où il devient fou lorsqu’il reçoit une requête UPnP (à laquelle il ne devrait pas répondre en premier lieu). C’est documenté dans le sujet des problèmes connus et Ceton l’a reconnu et a publié un micrologiciel/pilote mis à jour
Étrange qu’aucun des autres programmes utilisant UPnP sur cette machine ne semble entrer en conflit avec le Ceton. Peut-être qu’ils n’utilisent pas l’API Windows ?
Le bogue avec le pilote Ceton est qu’il répond à MCEBuddy en indiquant qu’il prend en charge l’ajout/suppression de mappages de redirection de port, donc MCEBuddy lui envoie une information de mappage de port pour « transférer » les ports et « supprimer » les anciens ports.
Seuls les périphériques de passerelle/routeur sont censés répondre avec ces capacités, on ne sait pas pourquoi Ceton déclare être un périphérique de redirection de port.
J’ai donc modifié le comportement de MCEBuddy et de Windows UPnP pour contourner, espérons-le, le bogue du micrologiciel du tuner TV Ceton.
Nous avons limité le délai de « réponse » de découverte à 60 secondes au lieu de le laisser ouvert, et Windows UPnP ne demande la découverte que des périphériques de service WANIPConnection et WANPPPConnection. Si votre tuner TV Ceton n’est pas un périphérique WAN (je ne vois pas pourquoi il devrait s’annoncer ou répondre à une telle requête de découverte), il ne devrait pas répondre et tout devrait bien se passer.
Essayez la version BÊTA 2.4.9 de dites-moi comment ça se passe.