[mythtv-users] Network Tuner Support
raymondboettcher at yahoo.com
Thu Nov 8 11:09:17 UTC 2012
> From: Karl Dietz <dekarl at spaetfruehstuecken.org>
> Subject: Re: [mythtv-users] Network Tuner Support
> To: mythtv-users at mythtv.org
> Date: Thursday, November 8, 2012, 2:23 AM
> On 08.11.2012 07:43, Raymond
> Boettcher wrote:
> > Recently my ticket was closed as a WontFix because they
> removed live555
> > from MythTV. Granted in my usage of live555, I fully
> understand why this
> This one? http://code.mythtv.org/trac/ticket/9670
Yup, that's it...
> > was needed. Live555 is old and has many issues.
> However, you implemented
> > HTTP Streaming over the network tuner in 0.26.0... Is
> this the only
> > method that the network tuner supports now or has the
> entire network
> > tuner been abandoned? If not I assume that udp:// and
> rtsp:// is
> > abandoned now or is any of that code still working?
> The Networkrecorder in 0.26 should support everything from
> 0.25 + HLS.
> I think on master UDP/RTP (with RTSP) is working right now.
> The HLS
> streaming needs to be hooked up to the new Networkrecorder
> new glue code). I can't find a reference to RTSP with TCP
> (which I was
> using to feed on demand from VLM to the Networkrecorder)
> > I'm just trying to adapt my feed translation program to
> work with the
> > new copy of MythTV. The network tuner is a good entry
> point into the
> > MythTV system which is why its ideal for my project. I
> would just adapt
> > the network tuner but with all the constant code
> changes, it seems
> > easier to just feed video data directly to an existing
> virtual tuner.
> Hooking up the new MythMusic Shoutcast reader to a MPEG-TS
> wrapper to
> the NetworkRecorder would be a nice little project leaving
> only the more
> foreign (aka. not even close to MPEG codecs) streams to be
> (Basically wrapping PES into TS, maybe )
MythMusic Shoutcast Reader...... I must be a little behind, I'm still running 0.23.1 because of the partially working Network Tuner. Plus analog tuner support works correctly in 0.23.1... After 0.23.1, the analog tuner will fail to change channels without kicking out for some reason. There is a ticket laying around about that as well. 6 months ago I went to a digital tuner with HD Over-the-air and took out the analog tuner but never upgraded because that means I have to upgrade MythTV in Slackware 13.1 on 4 different machines in my house. That alone is a half a days work worth of compiling, etc. I wanted Network Tuner support to fully work and hopefully analog tuner support to work again correctly before I left 0.23.1.
> Is your feed translation program available somewhere? Does
> it inject
> EIT, too? I'd be interested in that from the guide provider
> and MythTV
> EIT scanner side. ;)
The project page is up but there is no source files uploaded currently. The project is still in its infancy. I was able to feed a Shoutcast TV Feed into the MythTV Network Tuner at one point using my program. I also had a URL to the BBC News feed before it went down and it was mms:// which I used my program to recode (using external stuff like ffmpeg) and then feed a MPEG-TS into the Network Tuner over UDP. The program currently monitors a list of udp ports that mythbackend will open up based on which channel the network tuner is tuned too. Each channel is assigned to a different UDP Listen Port Number in the m3u playlist file that I created for the MythTV Network Tuner. When the port is opened by mythbackend my program automatically starts sending a MPEG-TS Feed to that port. When mythbackend closes the port and opens another port my program automatically adapts and kills off the stream for the 1 channel and starts the feed for the other udp
port. My program simply monitors /proc for the changes in port numbers opened by mythbackend. The program does support multiple channel stream, simply add multiple Network Tuners and give them all the same m3u playlist URL and same connection to the respective "channel list" in mythtv-setup. My program simply keeps "fork-ing" in order to start up each feed and then terminates the needed "fork" after that channel goes down (ie: channel change, leaving Live TV or the Scheduler stopping the recording).
There is a few things slowing my program down. Programs like mencoder tend to take a while or timeout while in stream causing no feed data to get received by my program in order to re-encode and relay to the Network Tuner. Also mencoder has a bad habit of letting the stream get stale and never timeout on its own making it more difficult for me because then I have to manage the mencoder process from inside my program and kill it off and restart it automatically. I thought about gathering the feed myself inside my daemon then feeding to ffmpeg which would eliminate any problems I was having with mencoder.
The second problem is in the last version of mythtv (0.23.1) that had somewhat working Network Tuner support, I've found the tuner to be impatient. After 10 seconds or so the tuner will timeout and stop listening for a feed while leaving the udp port open and drop out of Live TV with some error about the "Ring Buffer". Upon re-entry the Network Tuner was "Busy" until the backend was restarted.
Mencoder was the other way around and liked waiting longer than mythtv was willing to wait. I later fixed the problem by making my program automatically stream a "status" MPEG-TS feed to display what the "daemon" was up to, like "Connecting...", with the RayLine Networks MythIPTV Project on the screen. It was a 5 second MPEG-TS stream that my program would just auto-repeat until the real feed begins to keep the MythTV Network Tuner busy while my program was starting up the real feed (Plus it was better than MythTV just saying Partial-Lock, etc, etc). That way it wouldn't timeout which would eventually result in the Tuner being flagged busy ever after leaving Live TV and reentering to see if the Network Tuner would startup again. That is why I originally started Ticket #9670. The network tuner would also sometimes leave the UDP Port open even after Network Tuner shutdown causing my program to keep delivering the stream to that port even know
mythbackend was clearly ignoring it. I eventually found that if the feed "stuck" long enough because mythbackend left that UDP Port Open, mythbackend would eventually show a slow "memory leak" where the process started taking up more memory slowly as the unanswered udp socket (that is open by mythbackend) keeps stacking up its buffers until eventually mythbackend would crash.
The program doesn't currently deliver EIT Data for the program guide. However, I did figure out the Guide Data structure in the MySQL Database. I was going to write a separate mythfilldatabase to fill in for the "Network Channels." and eventually I was going to create a Ticket System to report non-working channels and just make everyone point my program and the channel list url on my webserver and then auto-generate the M3U Network Tuner "Playlist File".
I was eventually going to bother the dev's on Schedules Direct to see if they could create a line-up specific to Network TV Support that listed all the channels I had in the line-up. The only problem with that is some of the stations are over-seas and as I understand you must use xmltv for that. If the dev's at XMLTV or Schedules Direct weren't willing to handle that respect of the system, then I maybe able to subscribe to both xmltv and schedules direct and compile 1 list from both sources that only had the Network TV Stations my list supplied. However I haven't done that yet because I need permission from both xmltv and schedules direct to capture and redistribute certain channel guide data from both sources in order to accommodate all the various countries and channels that I have compiled.
The nice thing is the guide feeds are in XML and I stole the XML Temp file from mythfilldatabase (while it was running) at one point to look over the file and it seems pretty straight forward. However all my attempts to create my own XML and copy past some code out of the "temp file" XML file to manually feed to mythfilldatabase always ends in the respective channels never getting populated and I haven't figured out why yet (I'm thinking its XMLID related). However, if I directly alter the guide data or insert rows in the MySQL database then it works like a charm. But I'd much rather mythfilldatabase do it because it will tell the backend to reschedule recordings, etc that is needed after database population. mythfilldatabase also "expires" all the old guide data out of the database after each run and I like that.
I also created a Shoutcast TV Streamer that provided Guide Data in HTML Format so that a Shoutcast TV Channel can have a web page with the current guide data along with a flash plugin, etc to connect to the channel and watch the NSV directly in the browser. I was going to modify that program to also output an XML file with the HTML file that my program would attempt to auto-retrieve from each Shoutcast Station individually. But my NSV Streamer is MUCH better than all these lame partially completed streaming projects for NSV and works great with both Shoutcast and Icecast. I already released that project under GPL and don't charge anything for the usage or distribution of that program. The source isn't posted but if someone really wanted it, I would e-mail them a copy. It's a Windows Installer anyway and most people in Windows isn't really looking to change the program.
Between my two programs you can setup a Shoutcast/Icecast TV Station and also use my MythIPTV Daemon with MythTV to gather guide data from those "amateur" stations and watch their feed, schedule a recording, etc. At one point I thought about making my NSV TV Streamer subscribe to a "directory" and upload its guide data. I would let my website host said directory and keep track of all of those feeds and allow the MythIPTV Daemon to collect all that data from a central source instead of probing each channel individually for the XML file. Just because someone is using my NSV Streamer, doesn't always mean they are also hosting an apache server, etc to host the HTML and XML my program generates. In that regard, having the NSV TV Streamer check-in to a central source is more desirable.
Anyhow, sorry about the ramble. But it's something I want to make work correctly and I can't do that as long as the Network Tuner is buggy. However now that HTTP Streaming support has been implemented I may rewrite the entire program to act as a mini-webserver and provide the feeds over HTTP. Maybe even a gcc compiled binary CGI that I can make apache execute when mythbackend contacts apache via URL.
In the end, the nice thing is I can make the MythTV Network Tuner accept *ANY* type of streaming feed URL. As we all know, the Network Tuner was limited to UDP or RTSP and even then it really wanted a MPEG-TS feed which you almost NEVER find with an online streaming URL. Eventually MythTV will make my project obsolete by implementing mmsh://, etc and accept the full range of codecs and frame rates instead of the strict standards of MPEG-TS. But I imagine it will be quite some time before they do that. As it is it took over a year to get a "WontFix" response on Ticket #9670. So my program will be quite useful for a long while until such support has been implemented into mythbackend internally.
More information about the mythtv-users