[mythtv-users] IPTV - MPEG-TS stream failed to receive bytes
stephen_agent at jsw.gen.nz
Wed Jun 15 03:48:10 UTC 2016
On Tue, 14 Jun 2016 18:05:27 -0400, you wrote:
>On Tue, Jun 14, 2016 at 2:52 PM, Stephen Worthington <
>stephen_agent at 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
>> >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:
>> >#EXTINF:-1,300 - ANIMAL PLANET HD
>> >I successfully added the channels and program data and can see the
>> >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
>> >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(
>> >DownloadStream -- begin
>> >2016-06-13 18:25:08.938128 I [5221/5743] StreamHandler
>> >recorders/httptsstreamhandler.cpp:179 (DownloadStream) - HTTPReader(
>> >DownloadStream -- end
>> >2016-06-13 18:25:08.938189 I [5221/5743] StreamHandler
>> >recorders/httptsstreamhandler.cpp:114 (run) - HTTPTSSH(
>> >DownloadStream failed to receive bytes from
>> >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:
>> >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_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
>> >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
>> >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.
>> 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.
More information about the mythtv-users