MCEBuddy Beating the crap out of my Ceton InfiniTV 4 with the Upnp 'requests'

Bugs / Feature Requests Bugs
1

I didn’t know exactly where to post this.

I just built up a new ‘server’ (Windows 10 Pro 64bit) and noticed that SageTV could not communicated with the tuner shortly after any recording ended. After days of diagnosing I discovered (using Wireshark) MCEBuddy was pounding the crap out of the Ceton with Upnp ‘requests’, thousands and thousands of coms being produced. After several minutes the tuner would start throwing error because it could handle all the requests.

It only seems to start after the first recording has ended after a reboot (or MCEBuddy.service restart), and then would not stop until MCEBuddy.service was shut down or the computer was rebooted.

After shutting off Upnp inside MCEBuddy everything worked as it should, and MCEBuddy.service stopped berating the Ceton.

The Ceton is on 192.168.200.1 delivering to 192.168.200.2. MCEBuddy is sitting on 192.168.1.26 (server ip) so I’m not sure why MCEBuddy is going nuts trying to communicate with 192.168.200.x.

Maybe we need the ability to bind MCEBuddy to a specific adapter or address?

2

That’s bug with the Ceton drivers. MCEBuddy just uses a windows API to enable UPnP ports on the gateway device. Ceton has a bug in their drivers where it goes nuts when it gets a UPnP request (which it should not be responding to in the first place since). It’s documented in known issues topic and Ceton has acknowledged it issued an updated firmware/driver

3

Strange why none of the other programs that use UPnP on that machine seem to get in a fight with the Ceton. Perhaps they don’t us the Windows API?

4

The bug with the Ceton driver is that it’s responding to MCEBuddy saying that it supports the ability to add/delete port forwarding mapping, so MCEBuddy sends it a port mapping information to “forward” the ports and “delete” old ports.

Only gateway/router devices are supposed to respond with those capabilities, not sure why Ceton reports it’s a port forwarding device.

5

Okay so I’ve modified the behavior of MCEBuddy and Windows UPnP to hopefully workaround the Ceton Tv Tuner firmware bug.

We’ve limited the discovery “response” time to 60 seconds instead of leaving it open and windows UPnP requests discovery of only WANIPConnection and WANPPPConnection service devices. If your Ceton tv tuner is not a WAN device (I don’t see why it should advertise itself or respond to such a discovery request), it should not respond and all should be good.

Try out today’s 2.4.9 BETA build and let me know how it goes.

1 Like
6

Thanks Goose, Looks like the changes did the trick.

1 Like