[mythtv-users] IPTV - MPEG-TS stream failed to receive bytes

[Captain Krypto]

On Wed, Jun 15, 2016 at 10:58 AM, Gary Buhrmaster <gary.buhrmaster at gmail.com>
wrote:
> On Wed, Jun 15, 2016 at 10:22 AM, Stephen Worthington
> <stephen_agent at jsw.gen.nz> wrote:
> ....
>> I do not know QT at all, and my C++ is also quite rusty.  But when I
>> had a look at that code and Googled QNetworkRequest, the thought I had
>> was to make the original query have the
>> QNetworkRequest::FollowRedirectsAttribute flag, so that it would
>> automatically follow any redirects without any further intervention.
>
> Just as an FYI:
>
> According to the docs that attribute was added recently (in Qt 5.6),
> and Qt 5.6 is beyond the "minimum supported Qt version" MythTV
> supports (which is Qt 5.2).  Adding a requirement to move forward
> in the Qt version would have to be negotiated with the devs.
> Otherwise, you likely have to implement your own redirection code.
>
> I believe MythDownloadManager supports following redirects,
> and moving to the MythTV abstraction might be viable, although
> perhaps a larger effort.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


I hadn't planned on submitting anything for release as this issue seems
pretty specific to my IPTV stream provider.

I was able to finally get things working with the following changes:

---
mythtv-0.28-fixes/mythtv/libs/libmythtv/recorders/httptsstreamhandler.h
2016-06-12 12:30:49.849391706 -0400
+++
mythtv-0.28-fixes-IPTV/mythtv/libs/libmythtv/recorders/httptsstreamhandler.h
2016-06-15 12:27:17.523334878 -0400
@@ -59,6 +59,7 @@
     HTTPTSStreamHandler    *m_parent;
     QTimer                  m_timer;
     QNetworkAccessManager   m_mgr;
+    QNetworkRequest         m_req;
     QNetworkReply          *m_reply;
     QMutex                  m_lock;
     QMutex                  m_replylock;

---
mythtv-0.28-fixes/mythtv/libs/libmythtv/recorders/httptsstreamhandler.cpp
2016-06-14 19:40:26.402093279 -0400
+++
mythtv-0.28-fixes-IPTV/mythtv/libs/libmythtv/recorders/httptsstreamhandler.cpp
2016-06-15 17:32:46.331242516 -0400
@@ -145,7 +145,13 @@

     // the HTTP request
     m_replylock.lock();
-    m_reply = m_mgr.get(QNetworkRequest(url));
+    m_req = QNetworkRequest(url);
+    m_req.setAttribute(QNetworkRequest::FollowRedirectsAttribute, true);
+    m_req.setRawHeader("User-Agent", "Kodi/16.0 (X11; Linux x86_64)
Fedora/23 App_Bitness/64 Version/16.0-Git:Unknown");
+    m_req.setRawHeader("Accept", "*/*");
+    m_req.setRawHeader("Accept-Charset", "UTF-8,*;q=0.8");
+    m_req.setRawHeader("Connection", "close");
+    m_reply = m_mgr.get(m_req);
     m_replylock.unlock();

     connect(&m_timer, SIGNAL(timeout()), &event_loop, SLOT(quit()));

It seems that the request needed to define a user agent other than a web
browser before the redirect would happen as well as other modifications to
the header data. Once I implemented
setAttribute(QNetworkRequest::FollowRedirectsAttribute, true) it worked
swimmingly with the redirect.

This patch is pretty specific to someone using IPTVsubs as their provider
and I'm sure there is a more robust solution, but it works for me.

Thanks again Stephen for your suggestion regarding using wireshark to
monitor the network traffic. That was invaluable to determining the nature
of the problem.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20160615/9a90d9e2/attachment.html>