[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