[mythtv] IPTV not working in 0.27 -- possible bug in mythsocket.cpp?

Wed Nov 27 11:46:42 UTC 2013

TL;DR

Is mythsocket using QTcpSocket for "remote content", even
for RTP UDP-Multicast connections when it should use QUdpSocket
instead?

Long post:

Hi, this is part cross-posted from mythtv-users, but since my original
posting I've found (I believe) some additional information that perhaps
make this more a -dev matter than a -users matter.

I've recently subscribed to a new Internet provider (Movistar, Spain)
which includes a set of about 30 channels in their offer (The TV
platform name is "Imagenio")

Those channels can be accessed using rtp:// adresses, for example:
rtp://239.0.0.74:8208 corresponds to "Fox". If I'm not mistaken, that
IP address corresponds to an IP Multicast net.

I'm able to watch those channels without major issues using VLC
without any additional router/host configuration:

user$ vlc rtp://239.0.0.74:8208

opens the video player and everythings works as expected. However, as
you may suspect, I'm trying to make available all those channels to
mythtv (0.27) using an IPTV (Network Recorder, Freeebox) tuner.

I've followed several instructions found around the net to do the
obvious: define a freebox tunner, a no-grabber video source, scan .m3u
file for channels and connect those two. So, at the end, I have a new
input/source in myth but here come the problems:

Whenever I try to change to that source, the frontend shows nothing in
the screen (literally, nothing, not even the tuning-status info that
usually shows when trying to tune to a channel). Actually, the
frontend stops responding to keypresses even (can't use back to exit
from LiveTV, have to kill the mythfrontend process)

Searching for information about how to debug this issue, I've found
about mythavtest, so I've used in order to obtain some information
about what's going on. I've launched it with the rtp:// url as
parameter, as follows:

user$ mythavtest -v playback rtp://239.0.0.74:8208

The log obtained from that command can be found here:
http://pastebin.com/RNPJp4iU

I'm only able to see a couple of errors. First set of errors is about
mythavtest not being able to register some UDP sockets:

2013-11-26 11:36:41.205357 E  Failed binding to UDP 127.0.0.1:6948 -
Error 8: The bound address is already in use
2013-11-26 11:36:41.205555 E  Failed binding to UDP 192.168.1.3:6948 -
Error 8: The bound address is already in use

I'm assuming this is more or less OK, since the backend and the
frontend are  running. The second error is more related to the issue,
I think:

2013-11-26 11:36:42.686326 I  TV: Attempting to change from None to
WatchingVideo
2013-11-26 11:36:42.687885 I  FileRingBuf(rtp://239.0.0.74:8208):
OpenFile(rtp://239.0.0.74:8208, 2000 ms)
2013-11-26 11:36:42.689732 E  MythSocket(7fcfd0:-1): Failed to connect
to (239.0.0.74:8208) Network unreachable
2013-11-26 11:36:42.689824 E  RemoteFile::openSocket(control socket):
Could not connect to server 239.0.0.74:8208
2013-11-26 11:36:42.690258 E  FileRingBuf(rtp://239.0.0.74:8208):
RingBuffer::RingBuffer(): Failed to open remote file
(rtp://239.0.0.74:8208)

Looks like mythavtest is unable to connect/subscribe to the
rtp-multicast stream? Any hint about this? As I've told previously,
VLC works out of the box, without additional changes to
router/routes/hosts/etc.,so I'm assuming mythtv should be also able to
work out of the box, but perhaps there's some networking setup that
needs to be done?

Just to add additional information: I tried that previously on 0.26,
and the frontend complained about not getting lock on the channel
(-l-- was the tunning status). I saw there was an IPTV-code revamping
going on so I decided to upgrade to 0.27, but no luck here.

I've also tried an alternate setup where mythtv doesn't connect
directly to the multicast address but to a vlc instance with a VOD
defined that remuxes and allows to access the rtp://239... address
using rtsp://127.0.0.1/Fox. On 0.26 it kind of worked, but not
consistently: playback was choppy and freezed after 20-30 seconds. On
0.27 mythtv doesn't event contact the vlc instance, as nothing shows
in the vlc log. Anyway, I'd prefer a direct connection from mythtv to
the IPTV provider, in order to save cpu cycles and reduce the number
of intermediate hops (that, from my experience, produces
pixelation/choppy playback)

After some searches in github I've been able to find the exact line
that corresponds to the previous error:

The search:

https://github.com/MythTV/mythtv/search?q=%22%3A+Failed+to+connect+to+%28%22&type=Code

The suspect:

https://github.com/MythTV/mythtv/blob/84fa3fe02d6731d06b4d64573253710405767923/mythtv/libs/libmythbase/mythsocket.cpp

In this file, I can see that the error:

MythSocket(7fcfd0:-1): Failed to connect to (239.0.0.74:8208) Network
unreachable

Is generated in this piece of code:

    m_tcpSocket->connectToHost(addr, port, QAbstractSocket::ReadWrite);
    bool ok = m_tcpSocket->waitForConnected();
    if (ok)
    {
        LOG(VB_SOCKET, LOG_INFO, LOC + QString("Connected to (%1:%2)")
            .arg(addr.toString()).arg(port));
    }
    else
    {
        LOG(VB_GENERAL, LOG_ERR, LOC +
            QString("Failed to connect to (%1:%2) %3")
            .arg(addr.toString()).arg(port)
            .arg(m_tcpSocket->errorString()));
    }
    *ret = ok;

And looking at the definition of m_tcpsocket, looks like it is a
QTcpSocket (sorry,
little experience here with C++)

If that's the case, and given that, from
http://qt-project.org/doc/qt-5.1/qtcpsocket.html ,
QTcpSocket is a TCP Socket, that would explain why myth isn't able to connect to
rtp://239.0.0.74:8208, since that is a multicast address (and, If I'm
not mistaken, RTP
and multicast implies UDP, not TCP)

Am I right? Or perhaps I'm wrong and QTcpSocket can actually be used
to subscribe to
multicast groups? From this other page:
http://qt-project.org/doc/qt-5.1/qtnetwork/qudpsocket.html
looks like the right way to do this is by using QUdpSocket which has
methods like
joinMulticastGroup...

Best,
Jose