Re: alevt-dvb 1.7.0: new version, should be free from bugs now

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Mittwoch, den 17.02.2010, 15:50 -0800 schrieb Emil Meier:
> 
> --- On Sat, 2/13/10, Chicken Shack <chicken.shack@xxxxxx> wrote:
> 
> > From: Chicken Shack <chicken.shack@xxxxxx>
> > Subject: Re: alevt-dvb 1.7.0: new version, should be free from bugs now
> > To: "Francesco Lavra" <francescolavra@xxxxxxxxxxxx>
> > Cc: "Linux media" <linux-media@xxxxxxxxxxxxxxx>
> > Date: Saturday, February 13, 2010, 6:11 AM
> > Am Samstag, den 13.02.2010, 10:56
> > +0100 schrieb Francesco Lavra:
> > > On Thu, 2010-02-11 at 22:26 +0100, Chicken Shack
> > wrote:
> > > > Hi,
> > > > 
> > > > my way to say "Thank you".
> > > > Just enjoy this tiny little program with the
> > latest kernel.
> > > > Debian files for producing a Debian binary
> > included.
> > > > This version needs libzvbi as dependency to run.
> > > > Thanks to Tom Zoerne for the implemention patch
> > that I found by
> > > > accident.
> > > > 
> > > > 
> > > > Cheers
> > > > CS
> > > > 
> > > > P. S.: There are two issues in the TODO list.
> > > > Please drop me a note if you can fix those issues
> > mentioned there.
> > > > 
> > > > ENJOY!
> Does this version work with recent kernels without reverting dvb-demux?

Good question!

Unless Greg Kroah-Hartman does not publish another sublevel of 2.6.32
this version ( plus the appended one ) will run on all kernel except
from 2.6.32.
As 2.6.32 is exposed to become a reference kernel for many distros I
will Cc him in this mail......

 
> > > What about adding this program to v4l-dvb (under
> > v4l2-apps/util/)?
> > > AFAIK, alevt currently doesn't have a proper site
> > where development
> > > could take place.
> > > I think it would enjoy a better maintenance if it was
> > hosted in vl4-dvb,
> > > and it could be an additional testing tool useful for
> > drivers
> > > development.
> > > And it is GPL-licensed.
> > > 
> > > Francesco
> > 
> > Hi Francesco,
> > 
> > I wish your point of view were right. But it isn't at all.
> > 
> > There are a couple of reasons for that:
> > 
> > 1. As long as there is not at least one person doing the
> > necessary DVB
> > maintenance sponsored by some industry there will never be
> > a significant
> > change at all.
> > The roots of the DVB project were a company called
> > Convergence media in
> > Cologne, Germany. When this company broke down, the
> > relevant persons
> > vanished one by one leaving behind their heritage.
> > For details ask the administrator of linuxtv.org, Johannes
> > Stezenbach.
> > 
> > 2. Right now the personnel of the DVB development appears
> > and vanishes
> > whenever they want to. It's completely absurd to build up a
> > kernel
> > branch nearly only on volunteers, but that's the way it
> > is.
> > Even Linus Torvalds does not see that there should be a
> > change:
> > Do everything to win skilled ans sponsored people for the
> > work to be
> > done.
> > 
> > 3. I do not trust in the capabilities of the man who is
> > maintaining the
> > actual dvb-apps. His mouth is too big, his thoughts are
> > malicious very
> > often, his experience level is rather low, and his
> > capabilities aren't
> > even mediocre.
> > And worst of all: exaggerated egoism instead of real
> > partnership work,
> > real team work, same problem as with Mauro Carvalho
> > Chehab.
> > 
> > Applying for a job these people wouldn't even pass at least
> > one
> > so-called assessment test (which is checking out the human
> > skills).
> > But there seem to be places in the world where this kind of
> > tests aren't
> > mandatory at all.
> > 
> > 
> > Basic rule: Centralization itself does not resolve any
> > problem at all.
> > You need qualified people and, as a minimum adequate
> > demand, at least
> > one sponsored person if the job is not only a "fun bringer"
> > but at least
> > in significant parts a rather "unthankful" one.
> > 
> > DVB development at linuxtv.org has been a stepchild for
> > more than 5
> > years now.
> > All the former significant people have vanished.
> > 
> > As long as this continues we're on our own: It's us picking
> > up the
> > issues, it's us to investigate etc.
> > We cannot continue to delegate issues in the traditional
> > paternalistic
> > spirit - at least not with these people.
> > 
> > 
> > To get back to the program:
> > 
> > I still do not comprehend why alevt-dvb hangs when the
> > transponder is
> > changed.
> > I've found out that if you start it without any commandline
> > parameters
> > it does the following:
> > 
> > a. read and parse the PAT
> > b. read and parse the SDT
> > c. read and parse the PMT
> > 
> > It will always start reading the videotext of the program
> > with the first
> > found (i. e. the lowest) PMT.
> > 
> > 2 effects out of its standard behaviour:
> > 
> > 1. When you change the channel within the current
> > transponder the
> > program takes a short break and then comes back continuing
> > to read the
> > same PMT. It will not follow the external player doing the
> > tuning to the
> > new channel.
> > 
> > 2. When you change the channel AND change the transponder
> > the program
> > will hang and will only get finished by _killall_.
> 
> Or you can tune back to the original transponder or a transponder with the same provider, then alevt works again.
> So there is may be a check for the provider name.

Not exactly. As long as there is no necessity to reread the PAT (Program
association table) everything is working fine. At the current state the
mechanism (or system call) to restart or reset the reading and parsing
process of PAT, SDT, PMT is missing. And that exactly poses the problems
as soon as you change the transponder......
As long as you do not change the transponder, PAT, SDT and PMT stay the
same.
Transponder is not equal to provider........
google is your friend or have a look at etsi.org.......

The required monitoring demon MUST work independently from the external
player application doing the tuning.

My current script switches off and restarts alevt at every channel
change, including waitstates so that the player application and alevt do
not interfere when accessing the demux device (->timing issue)....
But that's just a very dirty workaround.....

> > The task is to change that behaviour. alevt-dvb should
> > follow the new
> > channel. In mtt (by Gerd Hoffmann @ bytesex.org - xawtv-4.0
> > pre) a
> > module called dvb-monitor does that job.
> > 
> > Cheers
> > 
> > CS
> Thanks for your this version.

You're welcome as every other user is.

> Emil

Emil and others: Will you please use the appended version?

I kicked out a nasty error message that printed out an error every time
when alevt was entering a zero entry in the PAT.
This error message wasn't even relevant for debug purposes, so I
eliminated it.
I dropped some lines about external dependencies in the README file.

Some critical words on that one:

http://linuxtv.org/hg/dvb-apps/rev/7de0663facd9

1. alevt-dvb is not a DVB-only application. It's core origin is to
address analogue cards. Only within a rather incomplete patchset alevt
can address DVB cards too. In so far that's a bad idea to put it into
the dvb-apps.....

2. With the exception of Christoph Pfister who has done a very good job
with the latest kaffeine the personal scenery @ linuxtv.org is like a
rat race in the production of appropriate drivers.
Production and maintenance of applications is rather cemetary-like @
linuxtv.org, i. e. de facto not existing.

It's for instance hihghly questionable why there are still 2 formats for
a channels.conf file (vdr format and the reduced zap format).
The zap format is obsolete IMHO.

As the situation is as it is, this expectation at least sounds utmost
naive and has got nothing to do with reality as it is:

"What about adding this program to v4l-dvb (under v4l2-apps/util/)?
AFAIK, alevt currently doesn't have a proper site where development
could take place. I think it would enjoy a better maintenance if it was
hosted in vl4-dvb, and it could be an additional testing tool useful for
drivers development. And it is GPL-licensed. (Francesco Lavra)"

For Greg Kroah-Hartman:

This one should go into kernel 2.6.32, just to close a gap of kernel
regressions:

http://linuxtv.org/hg/v4l-dvb/rev/2dfe2234e7ea

ENJOY!

CS

Attachment: alevt-1.7.0.tar.bz2
Description: application/bzip-compressed-tar


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux