ctreleaven at cogeco
Nov 21, 2007, 8:46 AM
Post #15 of 46
(3778 views)
Permalink
|
|
Re: Video Sources - time to call them what they are?
[In reply to]
|
|
At 10:31 AM -0500 11/21/07, Michael T. Dean wrote:
>On 11/21/2007 09:07 AM, Craig Treleaven wrote:
>>From a user perspective, this setup screen is how we tell Myth where to get guide data. If there is a vote, I'd say it ought to be titled 'TV Listings source' or 'Guide data source'. I don't know if one works better internationally than another.
>
>How do you connect a TV listings source to an input on your capture card
>(think Input Connections)? Personally, I connected an RG-6 cable from
>my antenna to the capture card. This cable happens to be the source of
>the video my capture cards capture.
>
>Since the video source uses the US broadcast frequency table--which I
>had previously configured as the default for my Myth setup--I also
>specified that information in the video source configuration. And, of
>course, I gave it a nice descriptive name, "OTA", that I could use to
>refer back to the video source when connecting inputs to my capture cards.
>
>If I also had a cable TV subscription, I would have a separate video
>source provided over a different RG-6 cable connected to the cable
>company's network. That video source would use the same listings
>source, Schedules Direct, that's used by my OTA source. However, I
>would specify a different lineup within that listings source.
>Similarly, in other parts of the world, multiple video sources may need
>to be configured to use the same listings source (XMLTV data provided
>from whatever web site).
>
>And, now that the Schedules Direct code supports using a single
>Schedules Direct lineup with multiple video source, calling a "video
>source" a "TV listings source" or whatever would be even farther from
>reality. The same cable from the cable company may carry analog
>channels and unencrypted digital channels and channels that are only
>accessible through an STB (via either firewire output or analog
>output). In that case, Myth requires the user create multiple video
>sources--a fact that would be lost in calling the video source a "TV
>listings source" since they all may use the same Schedules Direct
>account and lineup (OK, this only applies in the US, but if someone were
>to write some caching support into XMLTV and update mythfilldatabase to
>support it...).
>
>To me, the term "Video sources", seems to be about right. The one case
>where it's not necessarily accurate is when a cable company or satellite
>company may provide audio only channels (i.e. "digital radio").
>However, in most (if not all) cases I've seen, there is actually a video
>signal, too--though recording it may be a waste.
>
>Apologies to Bruce for any places where I may have butchered the true
>meaning/reasoning behind these terms, but I think this view of a video
>source is much truer than the "listings source" view.
>
>Even "channel group" doesn't seem right (though, probably closer)--after
>all, if I were to list my favorite channels, they would be a group of
>channels, but it's meaningless in configuring Myth (i.e. "channel
>groups" sounds more like something to be used to separate out channels
>for various views--i.e. favorites, Science and History, News, etc.--on
>the frontend) Perhaps, "Groups of channels that are available through a
>particular video source using a particular capture card input with a
>particular frequency table and/or channel change command." Maybe we
>could find one or two words in that description to use to
>shorten/approximate the meaning. ;)
>
>In other words, I think these terminology changes may be
>over-simplifications. But, that's just my $0.02 (which is less valuable
>than it would have been a couple of years ago since the dollar is weak.
Wow, Mike. You type a lot!
I agree that coaxial cables are generally the source of our video signals. That's why calling this screen "Video Sources" troubles me. The screen is really about getting listing data into Myth so that, in the Input Connections screen, we can associate the video capture sources with listings data.
I also agree that a user may need multiple sources of listings data; even if it is just different lineups from the same listings provider. The design of the screen makes it obvious. That doesn't change that this screen is about getting listings--not video.
To me, the title should focus on what the user is going to accomplish in the screen. I think maybe you're getting wound up in how the code is going to use the information?
Craig
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
1
