[vdr] Re: Small wishes for VDR ;-)

[Matthias Schniedermeyer <ms@citd.de>]

On Tue, 4 Dec 2001, Klaus Schmidinger wrote:

> 
> Matthias Schniedermeyer wrote:
> > 
> > > > Maybe a last question: is there some point in having EPG in channels
> > > > that didn't respect to the standard (bad time...)? I know it was
> > > > discussed a lots of time, but it would really be great to have those EPG
> > > > for such channels...
> > >
> > > I'm doing some tests on how to find out whether a channel broadcasts wrong
> > > timestamps in its EPG information. Unfortunately those channels are not
> > > consequent enough to also broadcast the system time the wrong way (so that
> > > it would fit to the wrong event times). If that were the case, the solution
> > > would be easy. Currently I'm trying to check the start times of the events
> > > marked as "running", and if such a start time is more than a certain
> > > threshold value in the future (let's say 1000 seconds), I assume that this
> > > channel broadcasts non standard timestamps and treat them as if they were
> > > in "localtime". There are, however, two remaining problems: how to know
> > > what timezone the "locatime" is related to, and there are currently several
> > > channels that mark events as "running" which are actually _not_ running at the
> > > current time (these are NVOD channels). I haven't found a way yet to filter
> > > them out.
> > >
> > > Oh well, it could be so easy if those channels would simply adhere to the
> > > standard... I wonder what kind of idiots make such decisions...
> > 
> > I don't think that you should build something like that into VDR. I would
> > suggest to call an external-"epg-fix"-Programm. This way you only have to
> > program the "infrastructure" in VDR once and the Fix-Programm can be
> > developed/distributed seperatly. (And it can be programmed in Perl. Which is MUCH
> > "better" for this kind of task.)
> 
> VDR already contains several EPG "bugfixes", and I don't think that it
> is such a good idea to establish a link to an external program and
> permanently send data in and out for this. I also fail to see how Perl
> would be any big help in determining the time offset of EPG events?!
>
> Do you have any EPG bugfixes that VDR currently doesn't perform yet
> (apart from the wrong event timestamps)? As far as I can see the EPG
> data in VDR (with EPGBugfixLevel set to '3') is already pretty clean.

Currently VDR has more bugfixes because you watch channels i don't even
configured.

> Using Perl would also be a big disadvantage for systems that, e.g., boot from
> a flash card. I guess the additional 5MB (or is it more) for a Perl installation
> would not be very much appreciated...

You know the "standard" argument for "Modules"

e.g. You don't have to get a new release of VDR just to get the newest
EPG-Bugfixes. (And you could stay with an old version (of VDR) und have
still have the current bugfixes.)

There are many more parts in VDR that would be a "good(tm)" candiate for
making them external modules.

e.g. "Where do i store the next recording". Imagine what would be possibel
if an external modules makes the decission where to store the files. (From
the simple "echo /video" up to a solution that spreads the recordings
automatically to diffrent HDD/machines/...)

Or the Counter-Case "Collect all Entries for the recordings-Sub-Menu".
What would be possibel if an external Program would be called to collect
the Menu-Entries. (From the simple "ls /video/*" up to a DB-Query with all
recordings ever made (and possibly archived, where VDR would "warn" the
user to get the correct Media to fetch. For e.g. you could have a Sub-Menu
with all you DVDs)

There are MANY more "decissions" that would, when made as external
modules, make VDR a "really great" tool.

For e.g. i still do

scp <movie> dvb2:/dev/video0

for watching my recordings, because it would be much to many hassle to do
it with VDR. (I use a stone-age Version of DVB-Driver/VDR. Current-Version
of DVB-Driver doesn't support such a simple method as just "drop" the file
into a device)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.