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

[jhall@UU.NET (Jeremy Hall)]

In the new year, Klaus Schmidinger wrote:
> 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.
> 
I think I would need to see this to make sure it meets my needs, but I
*THINK* it can do what I want.

> > 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?
> 
My understanding is that service id is unique within the scope
originalnetworkid::ts

To handle ``spot beam'' we have several ts with the same frequency.  The
SDT is linked to the TS.

> > 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,...
> 
It would be nice, but users have the service id published.  People
familiar with Dish Network, for example, probably want to use the Dish
Network channels, not some new number to memorize.  I would like to be
able to type 300 and HBO-E pops up, but because the desire exists for
unique service id's, 10300 is a compremize.

> > 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,...
> 
Perhaps the option for both should exist.  After I'm finished writing the
automated discovery, a user might find that channel 105 is no longer
channel 105 because a channel was added or removed somewhere in the
network.  As a user, I might become quite unnerved to find that channel
300, which was PBS Kids, is now SexTV because some transponders became
unreachable or something.  It would mean a user couldn't jump around from
channel to channel, guaranteeing he must look through the menu to find his
favourite channel.

I don't know about you, but there are almost 1200 channels in my
channels.conf.  Can you imagine trying to get from USA Network (your
channel 2) to BBC World, channel 20501? It's about a thousand channels
_that way_ actually it's channel #939, if memory serves.  I know that I
can remember 501, because that is a published number, and I know which
provider it is on, so adding the 20 is easy to remember.

> > 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
sure, as soon as I go reset my computer again.  I don't know if it is the
filters, I ned to go verify first.

_J

> -- 
> _______________________________________________________________
> 
> 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.