Mailing List Archive

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Dave
> Sent: Thursday, July 17, 2003 6:46 AM
> To: mythtv-users@snowman.net
> Subject: [mythtv-users] Multiple tuners with different channels
>

[snip]

>
> If this is the case, I have a suggestion as to how a channel available
> on multiple sources may be described. Sadly I'm not a good enough
> coder to actually implement this. Basically, the source id's in the
> database, rather than being numbered as "1,2,3,..,n" could be numbered
> as "1,2,4,8,...,n^2". Then, in the channel table a channel that is
> availble to the first source would have a sourceid of 1, a channel
> available to the second source would be 2, and a channel available on
> both sources would be 1+2=3. That way you could describe which
> channels are availble on which sources when you have multiple cards.

So, basically, you're saying that 'sourceid' from the videosource table
should always be a power of 2, and the 'sourceid' field in the channel table
(should probably be renamed to 'sourcemask') should be a bitmask of sources
containing that channel. Plus, obviously, whatever code changes would be
required. Then, for a given channel, or globally, you could specify a
preferred source from the list of available sources for that channel. In
addition to tuning (probably the easier set of changes), this would also
create serious complications in the backend setup/channel configuration and
mythfilldatabase -- you'd need to be able to create a video source with no
channels of its own, but instead tell it to add its sourceid to channels
already present in an existing source.

Did I get it?

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

--- "Joseph A. Caputo" <jcaputo1@comcast.net> wrote: > >
>
> So, basically, you're saying that 'sourceid' from the videosource
> table
> should always be a power of 2, and the 'sourceid' field in the
> channel table
> (should probably be renamed to 'sourcemask') should be a bitmask of
> sources
> containing that channel.

Yes, that's it, it would be a kind of bit-mask. It'd be a way of
expressing this kind of info, without having to have a column per
source or something, which would be unworkable. I do apprechiate that
doing operations on this kind of bit-mask number could be quite
difficult compared to the simple = operaton.

*snip*

> In
> addition to tuning (probably the easier set of changes), this would
> also
> create serious complications in the backend setup/channel
> configuration and
> mythfilldatabase -- you'd need to be able to create a video source
> with no
> channels of its own, but instead tell it to add its sourceid to
> channels
> already present in an existing source.


Well, for a GUI setup, it need not be too complicated. You could just
have it as a grid, with a list of channels down the side, and sources
along the top, and the user could just tick boxes to show which
channels each source had. Also, I don't see why mythfilldatabase
should be different, since it'll just grab listings for ALL channels
regardless of which sources they're available to.

And you shouldn't need to specify a "favourite" card for each channel.
It could still treat the first card as favourite overall, but if a
channel isn't available on that card, it'll just drop to the next card
and so on.

As I said before, I do feel guilty for posting a "what I would like
is...." without being able to offer actual code to back it up. I do
think Myth is already totally awesome, and I wish I could contribute.
But, from reading other emails in the archives, I'm sure I'm not the
only person with this kind of set-up.

Cheers again,

--Dave



________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

> -----Original Message-----
> From: mythtv-users-bounces@snowman.net
> [mailto:mythtv-users-bounces@snowman.net]On Behalf Of Dave
> Sent: Thursday, July 17, 2003 8:01 PM
> To: Discussion about mythtv
> Subject: RE: [mythtv-users] Multiple tuners with different channels
>
>
> Yes, that's it, it would be a kind of bit-mask. It'd be a way of
> expressing this kind of info, without having to have a column per
> source or something, which would be unworkable. I do apprechiate that
> doing operations on this kind of bit-mask number could be quite
> difficult compared to the simple = operaton.

Actually, that's the easy part...

[snip]

> Well, for a GUI setup, it need not be too complicated. You could just
> have it as a grid, with a list of channels down the side, and sources
> along the top, and the user could just tick boxes to show which
> channels each source had. Also, I don't see why mythfilldatabase
> should be different, since it'll just grab listings for ALL channels
> regardless of which sources they're available to.

It's not the GUI that'd be complicated, it's the underlying method by which
video sources & channels are set up. When you specify a video source, it
uses an external program (tv_grab_<region>) to grab your selected provider's
list of channels. Yes, a 'channel' (here meaning a television network) may
exist in more than one source, but it will not have the same frequency in
both sources. So, we *do* need to maintain separate database entities for
each channel, even if they are the same television 'network'. What we would
really need would be a way for Myth to be able to determine that two
channels are equivalent in terms of content (a 'networkid', i.e., 'CNN'
(network name), 'WPVI' (television station callsign) or a numerical
equivalent). If you have only one video source, you get a 1-1 mapping of
networkid <-> chanid. When you add subsequent sources, you would get
presented a list of the new channels with an opportunity to map them to an
existing networkid. Any new channel not mapped to an existing network
automatically creates a new network for itself.

Next, (and this is, I think, the really tricky part) the trick is modifying
the scheduler and TV tuning code to consider the new concept of a networkid
and how it relates to channels and video sources. Also, how does all of
this affect the concept of channum/chanid and how is it all represented in
the EPG?

I'm not saying it's impossible, but when you look at all the discussion and
effort that went into something as conceptually simple as separating the
concept of channum/chanid from the tuner frequency, and consider that this
is (IMHO) a much more complicated idea, you begin to see that it's not as
simple as all that...


> And you shouldn't need to specify a "favourite" card for each channel.
> It could still treat the first card as favourite overall, but if a
> channel isn't available on that card, it'll just drop to the next card
> and so on.

Actually, the concept of a favorite card per channel is (IMO) much simpler
to implement and is applicable even if you have only one video source (but
multiple tuners). It's quite possible that different channels might have
better picture quality based on a particular cabling & tuner card setup.

Anyway, I don't mean to discourage you; I'm sure that if there is enough
interest someone will tackle the concept you've put forth; I just wanted to
give you an idea of the magnitude of what you're suggesting. Of course, I
could also be completely wrong in my assessment of the complexities involved
:-)

-JAC

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

--- "Joseph A. Caputo" <jcaputo1@comcast.net> wrote: > > -----Original
Message-----

*snip*

> When you specify a video
> source, it
> uses an external program (tv_grab_<region>) to grab your selected
> provider's
> list of channels. Yes, a 'channel' (here meaning a television
> network) may
> exist in more than one source, but it will not have the same
> frequency in
> both sources. So, we *do* need to maintain separate database
> entities for
> each channel, even if they are the same television 'network'. What
> we would
> really need would be a way for Myth to be able to determine that two
> channels are equivalent in terms of content (a 'networkid', i.e.,
> 'CNN'
> (network name), 'WPVI' (television station callsign) or a numerical
> equivalent).

Ah, now being a Brit, we don't have the same kind of TV Networks over
here, so that's not something I'd thought of. Over here, although we
do have national stations, which the local station will opt-out of with
local programming from time to time, in most cases that local variation
will be the only option available to you for that "network", so it
really only appears as a single channel. That is changing very
slightly for some D-Sat viewers, but on the whole, that's the way it
is, BBC1 on analoge == BBC1 DTT == BBC DCable == BBC1 DSat, etc.

>
> I'm not saying it's impossible, but when you look at all the
> discussion and
> effort that went into something as conceptually simple as separating
> the
> concept of channum/chanid from the tuner frequency, and consider that
> this
> is (IMHO) a much more complicated idea, you begin to see that it's
> not as
> simple as all that...

Yes, the more I think of it, the more I (generally) see what you're
saying. I don't see that you could have two tuner cards where channels
have different frequencies on both (unless your slave backend is MILES
away ;), but yes, I can see that if you had an analoge tuner, a DTT
card, a DSat card, an external line-source, etc.

It does sound a lot more complicated that I originally thought,
although I agree, not impossible. I'd imagine it would involve another
table, listing channel and sourceid, then type of source, some columns
that are going to be common for each type (like tuning frequency, even
if the numbers there have different meaning for different types of
source), some DVB specific columns (all DVB sources will have FEC's,
PIDs, etc), and then some that are specific to some sources and NULL
for other sources, as well as some kind of favourite or quality
ranking. That table would possibly contain channels several times, and
would be seperate to the table which defines a channel in terms of
callsign, "number" listings source, etc.

All certainly much more than the "minor adjustment" that I was
originally thinking of.

>
> Anyway, I don't mean to discourage you; I'm sure that if there is
> enough
> interest someone will tackle the concept you've put forth; I just
> wanted to
> give you an idea of the magnitude of what you're suggesting. Of
> course, I
> could also be completely wrong in my assessment of the complexities
> involved
> :-)
>
> -JAC


No, that's fine JAC, it has made me realise that there are a massive
number of combinations possible.

I still don't know how best to set up my system though ;)

--Dave



________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users