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

[jhall@UU.NET (Jeremy Hall)]

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.

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)

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.

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.

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.

I would like to somehow standardize all this work so that the user can
configure this to meet his or her setup without needing to go muck about
in sources.  I can send my work to an interested party offline for
consideration, but I don't want my work to only benefit me.

_J

In the new year, Klaus Schmidinger wrote:
> Sven Karlsson wrote:
> > 
> > Hi,
> > 
> > With regards to DiSEqC. What are the reason for not having the handling as a
> > plugin? It is only of interest to DVB-s users and it looks like it is rather
> > complicated to implement full functionality given all the possible
> > combinations of rotors and switches. It looks to me that whatever you do
> > there will still exist unhandled special cases which will possibly lead to
> > people adding their own patches to vdr.
> > 
> > Wouldn't it be better to keep it in a stand-alone module rather than in the
> > main vdr code?
> 
> DiSEqC _is_ only of interest for DVB-S cards, and it is a central
> part of tuning in case you have a DiSEqC equipment.
> I do believe the DiSEqC handling can and should be done by the
> cDvbDevice itself. At the moment I see no advantages in handing
> this over to a plugin. If you can come up with a _concrete_ scenario
> where this would _not_ be possible, please let me know.
> 
> 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
> _______________________________________________________________
> 
> 


-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.