[vdr] Re: Some questions about plugin-features of vdr-developer...

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Jeremy Hall wrote:
> 
> I am putting together a standard patch that allows access to Dish Network
> switches.  It is quite possible to consider several different situations
> where users could have problems.
> 
> Firstly, I hijacked diseqc 17-20 and said:
> 
> For 17, 18, and 19, send SW21_1, followed by SW64_{1A,1B,2A,2B,3A,3B}
> depending on which input on the sw-64 you might want.  For 20, I tell it
> to send SW21_2.

I'm afraid this will collide with what I'm planning to do.
The current 'diseqc' parameter will soon be given a new meaning, namely
to identify the "source" of the channel. This can be either a satellite
(including its orbital position), "cable" or "terrestrial". Together with
the transponder frequency, polarization and other data stored in channels.conf
there will be a lookup in a new 'diseqc.conf' file which will generate the
resulting sequence of diseqc commands, tone and voltage settings. It will
be flexible enough to allow even the most exotic constellations.
The old numerical values will, of course, be handled just as they have been
previously, for compatibility reasons.

> This is because I have an SW-21 that connects to the DVB/S card, terminal
> 1 connects to an SW-64, which holds 3 birds, and port 2 of the SW-21 goes
> to a fourth.  In the future, this could  be extended to add more cascaded
> switches on either terminal to support a wide variety of configurations as
> long as I don't try to use two switches of the same type. (each dish
> network switch has its own address for its ports)
> 
> With the firm timers patch, a userspace program is capable of modulating
> voltage fast enough to command the switches.  I am not using diseqc,
> rather I am taking advantage of its properties.
> 
> I could try a cascading matrix test of all possible switch configurations,
> recursing for a _LONG_ time (but not a long long time) then store that in
> the setup and user can perform a switch test should he elect to change the
> parameters.  A smart user might be able to select a configuration and tell
> vdr what is connected to what, rather than vdr trying to figure it out for
> itself.
> 
> I have modified the guide such that service id's are unique by adding some
> digits to the front, since U.S. providers have up to 4 digits in their
> channels, I add a fifth for each provider.  One provider might be 1xxxx,
> while another might be 2xxx.  For example, HBO-E might be 10300 on the
> first provider, and the space channel might be 20454 on the other.
> 
> To straighten this out in the guide, I have added 10000 to the service id
> of those channels matching originalnetworkid of one provider, however many
> there may be, and 20000 to those matching another provider's
> originalnetworkid.  In this way, channels have the correct events.
> 
> In the dvbtune sources, in xml2vdr, I special-cased the
> originalnetworkid's again, this time fixing the serviceid and diseqc
> settings.  It is all automated now, but requires a patch to dvbtune (for
> channels.conf generation) and vdr (for the epg fixes etc)

Wouldn't it be enough to make a combination of the new "source" parameter, the
transponder frequency and the service id? If I'm not mistaken service ids are
unique within the same transponder, aren't they?

> oh yeah, and I am beginning to write a patch to vdr to allow the use of
> service id instead of number.  In the case where my channels.conf gets
> rewritten every few hours, picking up real changes, the channels can
> easily become renumbered from under me.  Since I am familiar with the
> service id's, I see very little use for Channel->numver().  Therefore I am
> carefully looking at each use of channel->number() and trying to decide
> how to use the service id.  It is hoped eventually the number would go
> away.

Do you really think this is a good idea? At least towards the user channel numbers
are the natural way to go. I want to have my channels numbered 1, 2, 3,...
and not 20435, 10234, 12549,...

> I understand that the only _UNIQUE_ identifier for a channel is its
> number, but since that is an internal vdr thing, I can see ways that
> renumbering the channels.conf could have desasterous effects on automated
> tasks etc.

Ok, that's true, since timers.conf and channels.conf are connected via the
channel numbers. But removing the channel numbers alltogether IMHO is not the
way to go. Towards the user they must always be numbered 1, 2, 3,...

> While we're on the subject of the EPG (and BTW I didn't mean to ramble
> like htis) I decided to adjust AddFilter so that the special case 0xff
> would mean add all tables on this pid.  This is especially useful for the
> EPG 0x12, so that all the EPG information that is available can be
> accumulated with a single filter.
> 
> I don't know if it is like this in Europe, but there are
> "special" transponders that carry EPG data for the whole bouquette[sp] for
> example transponder 1 on one provider does this.  I find that tuning to
> this transponder for about a minute populates my EPG for the next 3 days
> for this provider, switching to another provider's "special" transponder
> fills out the rest of my EPG, creating an epg.data of about 6mb.
> 
> oh and in libdtv, an assumption is made that the ShortDescription
> (title) of an event comes first, rather than the extended
> description.  This causes extended descriptions to be missed.  The fix is
> quite simple once it is tracked down.

Can you give a patch for this?

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________