Mailing List Archive: IPTV - MPEG-TS stream failed to receive bytes

IPTV - MPEG-TS stream failed to receive bytes

Jun 14, 2016, 9:24 AM

Post #1 of 8 (2243 views)

Basically, I am trying to use mythbackend as a PVR for a paid IPTV service,
but the back end fails to stream any data from the URL.

I used mythtv-setup to create an IPTV capture card using an m3u file with
the following format:

#EXTM3U
#EXTINF:-1,300 - ANIMAL PLANET HD
#EXTMYTHTV:xmltvid=57394
http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/5010.ts

I successfully added the channels and program data and can see the channels
and program data on my Kodi front end as well as in Mythweb.

However, when I go to watch a channel live or record a program, I am not
getting any data streaming into the buffers. I set the timeout for the card
to 60000 ms, but it appears to only attempt the connection for a few
seconds at most. I can open the URLs just fine in VLC and the video starts
to play in just a few seconds.

Here is a snippet from the back end log using --setverbose channel,record
and --setloglevel debug:

2016-06-13 18:25:08.621845 I [5221/5743] StreamHandler
recorders/httptsstreamhandler.cpp:137 (DownloadStream) - HTTPReader(
http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
DownloadStream -- begin
2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
DownloadStream -- end
2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
DownloadStream failed to receive bytes from
http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts

More from the same log: http://pastebin.com/4kFuWnxR

You can see that the entire attempt to stream the data only lasts a few
seconds. I thought that maybe the '@' symbol was causing an issue so I
tried to escape it using '\@', but it resulted in the same behavior.

Here is mediainfo output from a sample stream I pulled through VLC:
http://pastebin.com/DCEUCbq7

I initially tried this setup on 0.27/fixes and encountered the same issue
so I did a fresh compile of 0.28/fixes and deleted/re-created the IPTV
tuner and sources to the same end.

Here is my mythbackend version:

MythTV Version : v0.28-35-g812ec08
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20160309-1
QT Version : 5.6.0
Options compiled in:
linux release use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl using_bindings_python
using_bindings_php using_crystalhd using_dvb using_frontend using_hdhomerun
using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu
using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc
using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript
using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv
using_systemd_notify using_bindings_perl using_bindings_python
using_bindings_php using_freetype2 using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2

It seems like the back end is *trying* to open the stream, but it doesn't
like what it is seeing so my initial thoughts were that it either doesn't
like the URL format, or that it is receiving data that it isn't expecting...

Should this setup theoretically work? Is there a way to get more debugging
into to determine why the stream isn't opening?

Any ideas are appreciated.

Thanks,

Dave

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

stephen_agent at jsw

Jun 14, 2016, 11:52 AM

Post #2 of 8 (2230 views)

Permalink

On Tue, 14 Jun 2016 12:24:03 -0400, you wrote:

>Basically, I am trying to use mythbackend as a PVR for a paid IPTV service,
>but the back end fails to stream any data from the URL.
>
>I used mythtv-setup to create an IPTV capture card using an m3u file with
>the following format:
>
>#EXTM3U
>#EXTINF:-1,300 - ANIMAL PLANET HD
>#EXTMYTHTV:xmltvid=57394
>http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/5010.ts
>
>
>I successfully added the channels and program data and can see the channels
>and program data on my Kodi front end as well as in Mythweb.
>
>However, when I go to watch a channel live or record a program, I am not
>getting any data streaming into the buffers. I set the timeout for the card
>to 60000 ms, but it appears to only attempt the connection for a few
>seconds at most. I can open the URLs just fine in VLC and the video starts
>to play in just a few seconds.
>
>Here is a snippet from the back end log using --setverbose channel,record
>and --setloglevel debug:
>
>2016-06-13 18:25:08.621845 I [5221/5743] StreamHandler
>recorders/httptsstreamhandler.cpp:137 (DownloadStream) - HTTPReader(
>http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>DownloadStream -- begin
>2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
>recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
>http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>DownloadStream -- end
>2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
>recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
>http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>DownloadStream failed to receive bytes from
>http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts
>
>More from the same log: http://pastebin.com/4kFuWnxR
>
>You can see that the entire attempt to stream the data only lasts a few
>seconds. I thought that maybe the '@' symbol was causing an issue so I
>tried to escape it using '\@', but it resulted in the same behavior.
>
>Here is mediainfo output from a sample stream I pulled through VLC:
>http://pastebin.com/DCEUCbq7
>
>I initially tried this setup on 0.27/fixes and encountered the same issue
>so I did a fresh compile of 0.28/fixes and deleted/re-created the IPTV
>tuner and sources to the same end.
>
>Here is my mythbackend version:
>
>MythTV Version : v0.28-35-g812ec08
>MythTV Branch : fixes/0.28
>Network Protocol : 88
>Library API : 0.28.20160309-1
>QT Version : 5.6.0
>Options compiled in:
> linux release use_hidesyms using_alsa using_oss using_pulse
>using_pulseoutput using_backend using_bindings_perl using_bindings_python
>using_bindings_php using_crystalhd using_dvb using_frontend using_hdhomerun
>using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu
>using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc
>using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript
>using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv
>using_systemd_notify using_bindings_perl using_bindings_python
>using_bindings_php using_freetype2 using_mythtranscode using_opengl
>using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
>using_libxml2
>
>It seems like the back end is *trying* to open the stream, but it doesn't
>like what it is seeing so my initial thoughts were that it either doesn't
>like the URL format, or that it is receiving data that it isn't expecting...
>
>Should this setup theoretically work? Is there a way to get more debugging
>into to determine why the stream isn't opening?
>
>Any ideas are appreciated.
>
>Thanks,
>
>Dave

You can run Wireshark on the MythTV box to capture the traffic on port
8000 and see exactly what mythbackend is doing with its connection
attempt. And do the same with VLC and see what is different.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

captainkrypto at gmail

Jun 14, 2016, 3:05 PM

Post #3 of 8 (2227 views)

Permalink

Thanks for the brilliant suggestion Stephen... I did run a wireshark
capture for both mythbackend and VLC. This is my first time using wireshark
so my analysis of the captures is very rudimentary. However, I did notice
that the mythbackend issued several GET requests for the URL and basically
nothing happened. On the other hand, when VLC issued a GET request there
was a URL redirection (HTTP 302) and another URL which was followed by
another GET request to what looks like a dynamically created URL with a
hash value and a time stamp. It looks like mythbackend is failing, or at
least not getting the anticipated data returned when the stream is
requested. I could post the captures for comparison if anyone thinks that
would help, but I'm not sure how to save it as a text file.

Is there a way to tell the IPTV recorder to follow URL redirects or perhaps
some URL pre-processing to get the "final" URL to the capture card? I hope
I am not dead in the water on this one... Any ideas?

On Tue, Jun 14, 2016 at 2:52 PM, Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Tue, 14 Jun 2016 12:24:03 -0400, you wrote:
>
> >Basically, I am trying to use mythbackend as a PVR for a paid IPTV
> service,
> >but the back end fails to stream any data from the URL.
> >
> >I used mythtv-setup to create an IPTV capture card using an m3u file with
> >the following format:
> >
> >#EXTM3U
> >#EXTINF:-1,300 - ANIMAL PLANET HD
> >#EXTMYTHTV:xmltvid=57394
> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/5010.ts
> >
> >
> >I successfully added the channels and program data and can see the
> channels
> >and program data on my Kodi front end as well as in Mythweb.
> >
> >However, when I go to watch a channel live or record a program, I am not
> >getting any data streaming into the buffers. I set the timeout for the
> card
> >to 60000 ms, but it appears to only attempt the connection for a few
> >seconds at most. I can open the URLs just fine in VLC and the video starts
> >to play in just a few seconds.
> >
> >Here is a snippet from the back end log using --setverbose channel,record
> >and --setloglevel debug:
> >
> >2016-06-13 18:25:08.621845 I [5221/5743] StreamHandler
> >recorders/httptsstreamhandler.cpp:137 (DownloadStream) - HTTPReader(
> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >DownloadStream -- begin
> >2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
> >recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >DownloadStream -- end
> >2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
> >recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >DownloadStream failed to receive bytes from
> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts
> >
> >More from the same log: http://pastebin.com/4kFuWnxR
> >
> >You can see that the entire attempt to stream the data only lasts a few
> >seconds. I thought that maybe the '@' symbol was causing an issue so I
> >tried to escape it using '\@', but it resulted in the same behavior.
> >
> >Here is mediainfo output from a sample stream I pulled through VLC:
> >http://pastebin.com/DCEUCbq7
> >
> >I initially tried this setup on 0.27/fixes and encountered the same issue
> >so I did a fresh compile of 0.28/fixes and deleted/re-created the IPTV
> >tuner and sources to the same end.
> >
> >Here is my mythbackend version:
> >
> >MythTV Version : v0.28-35-g812ec08
> >MythTV Branch : fixes/0.28
> >Network Protocol : 88
> >Library API : 0.28.20160309-1
> >QT Version : 5.6.0
> >Options compiled in:
> > linux release use_hidesyms using_alsa using_oss using_pulse
> >using_pulseoutput using_backend using_bindings_perl using_bindings_python
> >using_bindings_php using_crystalhd using_dvb using_frontend
> using_hdhomerun
> >using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu
> >using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc
> >using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript
> >using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv
> >using_systemd_notify using_bindings_perl using_bindings_python
> >using_bindings_php using_freetype2 using_mythtranscode using_opengl
> >using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
> >using_libxml2
> >
> >It seems like the back end is *trying* to open the stream, but it doesn't
> >like what it is seeing so my initial thoughts were that it either doesn't
> >like the URL format, or that it is receiving data that it isn't
> expecting...
> >
> >Should this setup theoretically work? Is there a way to get more debugging
> >into to determine why the stream isn't opening?
> >
> >Any ideas are appreciated.
> >
> >Thanks,
> >
> >Dave
>
> You can run Wireshark on the MythTV box to capture the traffic on port
> 8000 and see exactly what mythbackend is doing with its connection
> attempt. And do the same with VLC and see what is different.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

stephen_agent at jsw

Jun 14, 2016, 8:48 PM

Post #4 of 8 (2213 views)

Permalink

On Tue, 14 Jun 2016 18:05:27 -0400, you wrote:

>On Tue, Jun 14, 2016 at 2:52 PM, Stephen Worthington <
>stephen_agent@jsw.gen.nz> wrote:
>
>> On Tue, 14 Jun 2016 12:24:03 -0400, you wrote:
>>
>> >Basically, I am trying to use mythbackend as a PVR for a paid IPTV
>> service,
>> >but the back end fails to stream any data from the URL.
>> >
>> >I used mythtv-setup to create an IPTV capture card using an m3u file with
>> >the following format:
>> >
>> >#EXTM3U
>> >#EXTINF:-1,300 - ANIMAL PLANET HD
>> >#EXTMYTHTV:xmltvid=57394
>> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/5010.ts
>> >
>> >
>> >I successfully added the channels and program data and can see the
>> channels
>> >and program data on my Kodi front end as well as in Mythweb.
>> >
>> >However, when I go to watch a channel live or record a program, I am not
>> >getting any data streaming into the buffers. I set the timeout for the
>> card
>> >to 60000 ms, but it appears to only attempt the connection for a few
>> >seconds at most. I can open the URLs just fine in VLC and the video starts
>> >to play in just a few seconds.
>> >
>> >Here is a snippet from the back end log using --setverbose channel,record
>> >and --setloglevel debug:
>> >
>> >2016-06-13 18:25:08.621845 I [5221/5743] StreamHandler
>> >recorders/httptsstreamhandler.cpp:137 (DownloadStream) - HTTPReader(
>> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>> >DownloadStream -- begin
>> >2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
>> >recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
>> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>> >DownloadStream -- end
>> >2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
>> >recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
>> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
>> >DownloadStream failed to receive bytes from
>> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts
>> >
>> >More from the same log: http://pastebin.com/4kFuWnxR
>> >
>> >You can see that the entire attempt to stream the data only lasts a few
>> >seconds. I thought that maybe the '@' symbol was causing an issue so I
>> >tried to escape it using '\@', but it resulted in the same behavior.
>> >
>> >Here is mediainfo output from a sample stream I pulled through VLC:
>> >http://pastebin.com/DCEUCbq7
>> >
>> >I initially tried this setup on 0.27/fixes and encountered the same issue
>> >so I did a fresh compile of 0.28/fixes and deleted/re-created the IPTV
>> >tuner and sources to the same end.
>> >
>> >Here is my mythbackend version:
>> >
>> >MythTV Version : v0.28-35-g812ec08
>> >MythTV Branch : fixes/0.28
>> >Network Protocol : 88
>> >Library API : 0.28.20160309-1
>> >QT Version : 5.6.0
>> >Options compiled in:
>> > linux release use_hidesyms using_alsa using_oss using_pulse
>> >using_pulseoutput using_backend using_bindings_perl using_bindings_python
>> >using_bindings_php using_crystalhd using_dvb using_frontend
>> using_hdhomerun
>> >using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu
>> >using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc
>> >using_mheg using_opengl using_opengl_video using_qtwebkit using_qtscript
>> >using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv
>> >using_systemd_notify using_bindings_perl using_bindings_python
>> >using_bindings_php using_freetype2 using_mythtranscode using_opengl
>> >using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
>> >using_libxml2
>> >
>> >It seems like the back end is *trying* to open the stream, but it doesn't
>> >like what it is seeing so my initial thoughts were that it either doesn't
>> >like the URL format, or that it is receiving data that it isn't
>> expecting...
>> >
>> >Should this setup theoretically work? Is there a way to get more debugging
>> >into to determine why the stream isn't opening?
>> >
>> >Any ideas are appreciated.
>> >
>> >Thanks,
>> >
>> >Dave
>>
>> You can run Wireshark on the MythTV box to capture the traffic on port
>> 8000 and see exactly what mythbackend is doing with its connection
>> attempt. And do the same with VLC and see what is different.

>Thanks for the brilliant suggestion Stephen... I did run a wireshark
>capture for both mythbackend and VLC. This is my first time using wireshark
>so my analysis of the captures is very rudimentary. However, I did notice
>that the mythbackend issued several GET requests for the URL and basically
>nothing happened. On the other hand, when VLC issued a GET request there
>was a URL redirection (HTTP 302) and another URL which was followed by
>another GET request to what looks like a dynamically created URL with a
>hash value and a time stamp. It looks like mythbackend is failing, or at
>least not getting the anticipated data returned when the stream is
>requested. I could post the captures for comparison if anyone thinks that
>would help, but I'm not sure how to save it as a text file.
>
>Is there a way to tell the IPTV recorder to follow URL redirects or perhaps
>some URL pre-processing to get the "final" URL to the capture card? I hope
>I am not dead in the water on this one... Any ideas?

Anyone with Wireshark can read the original capture files, which is
usually better than a text post anyway as you can do filtering and so
on. So it is better to post those if you have a place to post them
on. I just use my personal web server. If there is extraneous data
in a captured file, you can use a Wireshark filter (eg select one
packet from the ones you want and do Analyze / Conversation Filter /
TCP on it so that you only get the relevant TCP packets), then File /
Export specified packets to save only those packets.

From your description, it looks like mythbackend does not have any
code to handle 302 redirections, so for the moment, you may be out of
luck getting it to work (unless you are up to adding that code
yourself). It is possible to download the MythTV source code and see
what it does and does not do. It is unlikely to be a major project to
handle redirections - if you are really lucky, it will just be turning
on the option to do redirections in a library call. I did a quick
browse of my copy of mythtv-trunk and the code for http streaming
seems to be in mythtv/libs/libmythtv/recorders/httptsstreamhandler.*,
but I have not had time to look at how it works yet.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

captainkrypto at gmail

Jun 14, 2016, 9:59 PM

Post #5 of 8 (2217 views)

Permalink

Thanks for hanging in there with me Stephen. I have actually been trying to
hack something together, but my c++ is rusty and I'm not too familiar with
the Qt framework... My latest attempt was to try and get the http status
and redefine the url variable if the status code is 302.

From mythtv/mythtv/libs/libmythtv/recorders/httptsstreamhandler.cpp
starting at line 133

Original:

// the HTTP request
m_replylock.lock();
m_reply = m_mgr.get(QNetworkRequest(url));
m_replylock.unlock();

Changes:

// the HTTP request
m_replylock.lock();
m_reply = m_mgr.get(QNetworkRequest(url));
m_replyStatus =
m_reply->attribute(QNetworkRequest::HttpStatusCodeAttribute);
if (m_replyStatus == 302)
{
const QUrl url =
m_reply->attribute(QNetworkRequest::RedirectionTargetAttribute).toUrl();
}
m_replylock.unlock();

The code compiles, but it is still not using the redirected URL as far as I
can tell. I am going to keep hacking away tomorrow, but if you have any
suggestions I am open to them.

Thanks,
Dave

On Tue, Jun 14, 2016 at 11:48 PM, Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Tue, 14 Jun 2016 18:05:27 -0400, you wrote:
>
> >On Tue, Jun 14, 2016 at 2:52 PM, Stephen Worthington <
> >stephen_agent@jsw.gen.nz> wrote:
> >
> >> On Tue, 14 Jun 2016 12:24:03 -0400, you wrote:
> >>
> >> >Basically, I am trying to use mythbackend as a PVR for a paid IPTV
> >> service,
> >> >but the back end fails to stream any data from the URL.
> >> >
> >> >I used mythtv-setup to create an IPTV capture card using an m3u file
> with
> >> >the following format:
> >> >
> >> >#EXTM3U
> >> >#EXTINF:-1,300 - ANIMAL PLANET HD
> >> >#EXTMYTHTV:xmltvid=57394
> >> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/5010.ts
> >> >
> >> >
> >> >I successfully added the channels and program data and can see the
> >> channels
> >> >and program data on my Kodi front end as well as in Mythweb.
> >> >
> >> >However, when I go to watch a channel live or record a program, I am
> not
> >> >getting any data streaming into the buffers. I set the timeout for the
> >> card
> >> >to 60000 ms, but it appears to only attempt the connection for a few
> >> >seconds at most. I can open the URLs just fine in VLC and the video
> starts
> >> >to play in just a few seconds.
> >> >
> >> >Here is a snippet from the back end log using --setverbose
> channel,record
> >> >and --setloglevel debug:
> >> >
> >> >2016-06-13 18:25:08.621845 I [5221/5743] StreamHandler
> >> >recorders/httptsstreamhandler.cpp:137 (DownloadStream) - HTTPReader(
> >> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >> >DownloadStream -- begin
> >> >2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
> >> >recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
> >> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >> >DownloadStream -- end
> >> >2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
> >> >recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
> >> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts):
> >> >DownloadStream failed to receive bytes from
> >> >http://2.welcm.tv:8000/live/xxx@xyz.com/xxxpasswordxxx/4649.ts
> >> >
> >> >More from the same log: http://pastebin.com/4kFuWnxR
> >> >
> >> >You can see that the entire attempt to stream the data only lasts a few
> >> >seconds. I thought that maybe the '@' symbol was causing an issue so I
> >> >tried to escape it using '\@', but it resulted in the same behavior.
> >> >
> >> >Here is mediainfo output from a sample stream I pulled through VLC:
> >> >http://pastebin.com/DCEUCbq7
> >> >
> >> >I initially tried this setup on 0.27/fixes and encountered the same
> issue
> >> >so I did a fresh compile of 0.28/fixes and deleted/re-created the IPTV
> >> >tuner and sources to the same end.
> >> >
> >> >Here is my mythbackend version:
> >> >
> >> >MythTV Version : v0.28-35-g812ec08
> >> >MythTV Branch : fixes/0.28
> >> >Network Protocol : 88
> >> >Library API : 0.28.20160309-1
> >> >QT Version : 5.6.0
> >> >Options compiled in:
> >> > linux release use_hidesyms using_alsa using_oss using_pulse
> >> >using_pulseoutput using_backend using_bindings_perl
> using_bindings_python
> >> >using_bindings_php using_crystalhd using_dvb using_frontend
> >> using_hdhomerun
> >> >using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu
> >> >using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc
> >> >using_mheg using_opengl using_opengl_video using_qtwebkit
> using_qtscript
> >> >using_qtdbus using_taglib using_v4l2 using_x11 using_xrandr using_xv
> >> >using_systemd_notify using_bindings_perl using_bindings_python
> >> >using_bindings_php using_freetype2 using_mythtranscode using_opengl
> >> >using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
> >> >using_libxml2
> >> >
> >> >It seems like the back end is *trying* to open the stream, but it
> doesn't
> >> >like what it is seeing so my initial thoughts were that it either
> doesn't
> >> >like the URL format, or that it is receiving data that it isn't
> >> expecting...
> >> >
> >> >Should this setup theoretically work? Is there a way to get more
> debugging
> >> >into to determine why the stream isn't opening?
> >> >
> >> >Any ideas are appreciated.
> >> >
> >> >Thanks,
> >> >
> >> >Dave
> >>
> >> You can run Wireshark on the MythTV box to capture the traffic on port
> >> 8000 and see exactly what mythbackend is doing with its connection
> >> attempt. And do the same with VLC and see what is different.
>
> >Thanks for the brilliant suggestion Stephen... I did run a wireshark
> >capture for both mythbackend and VLC. This is my first time using
> wireshark
> >so my analysis of the captures is very rudimentary. However, I did notice
> >that the mythbackend issued several GET requests for the URL and basically
> >nothing happened. On the other hand, when VLC issued a GET request there
> >was a URL redirection (HTTP 302) and another URL which was followed by
> >another GET request to what looks like a dynamically created URL with a
> >hash value and a time stamp. It looks like mythbackend is failing, or at
> >least not getting the anticipated data returned when the stream is
> >requested. I could post the captures for comparison if anyone thinks that
> >would help, but I'm not sure how to save it as a text file.
> >
> >Is there a way to tell the IPTV recorder to follow URL redirects or
> perhaps
> >some URL pre-processing to get the "final" URL to the capture card? I hope
> >I am not dead in the water on this one... Any ideas?
>
> Anyone with Wireshark can read the original capture files, which is
> usually better than a text post anyway as you can do filtering and so
> on. So it is better to post those if you have a place to post them
> on. I just use my personal web server. If there is extraneous data
> in a captured file, you can use a Wireshark filter (eg select one
> packet from the ones you want and do Analyze / Conversation Filter /
> TCP on it so that you only get the relevant TCP packets), then File /
> Export specified packets to save only those packets.
>
> From your description, it looks like mythbackend does not have any
> code to handle 302 redirections, so for the moment, you may be out of
> luck getting it to work (unless you are up to adding that code
> yourself). It is possible to download the MythTV source code and see
> what it does and does not do. It is unlikely to be a major project to
> handle redirections - if you are really lucky, it will just be turning
> on the option to do redirections in a library call. I did a quick
> browse of my copy of mythtv-trunk and the code for http streaming
> seems to be in mythtv/libs/libmythtv/recorders/httptsstreamhandler.*,
> but I have not had time to look at how it works yet.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

stephen_agent at jsw

Jun 15, 2016, 3:22 AM

Post #6 of 8 (2201 views)

Permalink

On Wed, 15 Jun 2016 00:59:36 -0400, you wrote:

>Thanks for hanging in there with me Stephen. I have actually been trying to
>hack something together, but my c++ is rusty and I'm not too familiar with
>the Qt framework... My latest attempt was to try and get the http status
>and redefine the url variable if the status code is 302.
>
>From mythtv/mythtv/libs/libmythtv/recorders/httptsstreamhandler.cpp
>starting at line 133
>
>Original:
>
> // the HTTP request
> m_replylock.lock();
> m_reply = m_mgr.get(QNetworkRequest(url));
> m_replylock.unlock();
>
>Changes:
>
> // the HTTP request
> m_replylock.lock();
> m_reply = m_mgr.get(QNetworkRequest(url));
> m_replyStatus =
>m_reply->attribute(QNetworkRequest::HttpStatusCodeAttribute);
> if (m_replyStatus == 302)
> {
> const QUrl url =
>m_reply->attribute(QNetworkRequest::RedirectionTargetAttribute).toUrl();
> }
> m_replylock.unlock();
>
>
>The code compiles, but it is still not using the redirected URL as far as I
>can tell. I am going to keep hacking away tomorrow, but if you have any
>suggestions I am open to them.
>
>Thanks,
>Dave

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

gary.buhrmaster at gmail

Jun 15, 2016, 7:58 AM

Post #7 of 8 (2197 views)

Permalink

On Wed, Jun 15, 2016 at 10:22 AM, Stephen Worthington
<stephen_agent@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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: IPTV - MPEG-TS stream failed to receive bytes [ In reply to ]

captainkrypto at gmail

Jun 15, 2016, 3:05 PM

Post #8 of 8 (2182 views)

Permalink

On Wed, Jun 15, 2016 at 10:58 AM, Gary Buhrmaster <gary.buhrmaster@gmail.com>
wrote:
> On Wed, Jun 15, 2016 at 10:22 AM, Stephen Worthington
> <stephen_agent@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@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!