Must stop and wait up to 10 seconds to change channels when connected via rtl_tcp

[djp952]

When the PVR addon is connected via rtl_tcp, the user must stop playback and wait up to 10 seconds before selecting another channel, otherwise a 'recv() error' will occur.

This is a problem caused by an assumption in the PVR that needs to be addressed. When developing the addon I used USB exclusively, and there was no problem with initializing/uninitializing the RTL-SDR device at the stream level in Kodi. However with rtl_tcp, when the connection is closed, it takes the server up to 10 seconds to reset itself. In that time the client can't reconnect.

The best solution to this will be to cache off the internal RTL-SDR connection for a period of time, perhaps 30 seconds, and re-use it if the user opens another stream. There used to be a "SwitchChannel" API in Kodi that no longer exists that would probably have been a good solution too, but in current Kodi the expectation is that a proper pair of Open/Close operations will occur when switching channels.

[djp952]

Resolved for Matrix baseline via cb21ccf

Solution will need to back-ported to Leia baseline as well, implementation will differ. Will close this issue after that has been completed.

The way this worked out, as long as the RTL-SDR device is actively being used, a reference to that device will be maintained. So for rtl_tcp connections, the connection itself will not be closed for at least 30 seconds after it was last used. This isn't a perfect solution, it can still fail if the user tries to open a new rtl_tcp connection within a few seconds of it actually getting released, but in practice it's working pretty well. The only other real alternative is to maintain the connection indefinitely which would be horrible for users with multiple clients hitting the same rtl_tcp instance. After using it, you'd have to shut down/restart Kodi on one system to use it on another.

I'm sure this will need adjustments in the future.

[djp952]

Changeset for Leia baseline committed via 172ab4a

Closing Issue.

[djp952]

Re-opening issue because I'm not satisfied with the results. While the proposed solution 'works', rtl_tcp loads up a bunch of packets from the currently tuned frequency and will dump them to the client when it reconnects. I would prefer a more definitive DISCONNECT type of thing here, which may be possible by modifying the SO_LINGER socket option.

The ideal scenario would be to get rtl_tcp to disconnect immediately and reset itself without waiting for 5-10 seconds. Until that happens I don't see how this can work properly ...

[djp952]

Instead of trying to work around the problems with rtl_tcp, I've modified my forked version of the rtl-sdr library to include blinick's patch that gets rid of the condition variable that causes the delay (https://github.com/blinick/rtl-sdr/tree/wip_rtltcp_ringbuf). I've also upped the connect timeout to 5 seconds instead of 1 second in the PVR, but that's still not enough to 'solve' the problem with the official rtl_tcp.

Marking as closed; will be a documentation concern.