[mythtv-users] Multiple tuner channel idea

Steve Davies steve at one47.co.uk
Tue Oct 28 17:05:05 EST 2003


Some lines snipped...

Bruce Markey wrote:
> Ian Forde wrote:
> 
>> But if one tuner is connected to a cable box and the other takes a
>> direct feed using its internal tuner (with a subset of the same
>> channels) there's a problem... In that situation (which I have) I copied
>> one .xmltv file to a new file,

I am setting up much the same scenario. I will have 2 cards and 3 inputs
1)  DVB card - Has about 20 channels
2a) Terrestrial Tuner - Has 5 basic channels
2b) Cable + IR Blaster - Has lots of channels

Common to all feeds are the 5 basic channels on 2). Most of the DVB channels 
are also available from the cable feed.

>> and editted out the cable-box-only
>> channels (buy putting "not" in front of them).  My question is: 
>> Wouldn't it be better instead to have the program guide recognize the
>> fact that the channel names/numbers/frequencies are the same, collapse
> 
> s/names\/numbers\/frequencies/callsign/p

Is the general consensus that callsigns are unique? From my limited 
experience, I would say that this is true. Anyone got any counter examples?

>> the listings to only list one set of channels in the guide, and allow
>> recordings to proceed based on whether or not the requested tuner can
>> access that channel?  (As opposed to each channel having a list of
>> tuners, which would be wasteful...)

I am considering implementing this feature as a selectable "option" - The 
cosmetic part is probably the easiest, and would go along the lines of:

* Collapse all repeated callsigns to a single guide entry.
* If a channel change is requested (channel is available on current input)
   - Use current source
* If a channel change requires a different input
   - Use the tuners in priority (id) order
* Recording requests will store channid using the priority (id) field.

To avoid conflicts (mythfilldatabase would eventually be able to fix this), 
schedules would be displayed from the highest priority card for each callsign.

> The problem isn't just cosmetic. The reason you see two listing
> for channel 3 is that they are two different entities; chanid 1003
> for the coax input and 2003 for the cable box input. If you chose
> a show on one line from the EPG, it will only record on that one
> input. If you select it on the other line it will only record on
> the other input.

And from my usage perspective this is the "problem".
> 
> It seems like the scheduler should be able to determine that
> two entries in the channel table have the same callsign and, if
> the record table stored the callsign rather than the chanid, it
> should be able to choose to record a show on KVBC from either
> input. At first glance it seems this would be the Right Way to
> do things even though it may add a lot more complexity to the
> scheduler.

Agreed. I am threatening to make this very change :-) I don't expect it to 
happen fast though!!!

> However, in practice segregating the digital channels turns out
> to be a Good Thing. You don't want to miss recording a show on
> a digital channel because the cable box input is occupied recording
> an analog channel that it could have recorded on any other input.

This implies that the scheduler would not work out this conflict, and swap the 
channels between the two sources.
> 
> --  bjm
> 

My proposal would be:
* Run the existing scheduler, which will attempt to keep the recording on the 
same sourceid as the recording was originally for.
* If there are no conflicts, stop there and leave well enough alone.
* If the user has not selected the new scheduler-style, stop now.
* For any remaining conflicts, pull the callsign, and see if
       numCallSignInputs[callsign] > 1
* Where numCallSignInputs[callsign] > 1, add the item to a list.
* Run the same scheduler logic as normal on this list, with the scheduling 
focus changed from sourceid to callsign.

I have studied the scheduler, and am quite sure this is "hard"

If a real whiz C++ coder thinks this makes sense, and wants to do this, feel 
free. My C++ is rusty! On the other hand, if no-one picks this up, I might 
have it done by mid 2004 :-)

Suggestions, comments and opinions required.

Regards,
Steve

-- 
Steve Davies                   steve at one47.co.uk

PGP Fingerprints:
DH/DSS : 5D85 8164 91D7 E9CC 4F80  842B AB86 93D9 8938 7612
RSA    :      4E2E E60F 3D76 9E7E  70F9 901B 70FA 56C8
RSA4096: 02BE 5C0E EFA2 E1E4 EA89  C9CC 1E4F F654 3BC7 B65E



More information about the mythtv-users mailing list