Gibt es für das Alexw Image 1.6.3 einen CVS Label?

[rasc]

also das HEAD funktioniert ja die letzten tage. was nervig ist, ist der demuxer. somit geht z.B. tuxtxt nicht, und waehrend des streamens kann man nicht fernsehen.

nimmt man dagegen das release branch, hat man die neuerungen in neutrino nicht (z.B. mp3 player). das ist schon etwas aergerlich.

Tja, es muesste halt jemand die HEAD-treiber fertig schreiben...

So ist das halt mit OpenSource - es darf jeder sein Glück versuchen...
Wenn aber alle warten dass es fertig wird, dann tut sich halt nichts...

Das Schoene daran ist, da die Soft nichts kostet, gibt es auch keinerlei Verpflichtungen - persoenlich ist mir das streamen recht egal. Ich gucke nur TV mit der dbox (und eben ab und zu Radio)... Ich kann also persönlich über den aktuellen Stand nicht viel meckern (ausser dass es halt nicht "schön" ist, dass der HEAD-Treiberstand nicht gerade der Beste ist...). Das tuxtxt nicht geht, damit muss ich eben leben...

[boxi]

denke, der emu szene ist alexw mittlerweile ziemlich egal...
d.h. alexw "schadet" eigentlich nur denjenigen, die sein image (aus welchen gruenden auch immer... tuner driver z.b.) fuer sich anpassen wollen.

[NoClue]

Müssige Diskussion, ob das nun GPL ist oder nicht. Wenn er nicht will, dann will er halt nicht, was solls... Ich kann es verstehen.

[kerlimann]

Müssige Diskussion, ob das nun GPL ist oder nicht. Wenn er nicht will, dann will er halt nicht, was solls... Ich kann es verstehen.

klar ist das mit dem pochen auf GPL quatsch. nur muss man nicht fuer alles andauernd irgendwas mit "schwarzglotzen" vorschieben.

wenn die treiber nicht funktionieren, und die alten ja, soll man sie halt solange rausnehmen. ich compile selbst mal gerne was. z.B. bei kleineren bugfixes (mp3 player etc..) ist das ganz praktisch, und ich muss nicht immer auf ein alexw warten. verlangt ja auch keiner, das alexw bei jedem pups fix en neues image baut <g>.

hier wurde lediglich gefragt, wie man die alten treiber mit dem neuen image nutzt. das hat doch absolut nix mit abuse zu tun. ich bin sicher nicht der einzige, der sich ueber den fehlenden tuxtxt aergert. oder ueber die knackserei im ton, usw..

[hardsofty]

Zitat: Er nutzt ja auch eigene Teile, die nicht unbedingt GPL sein muessen.

Das Problem (oder das gute an der GPL je nach dem wie man es sieht) ist: "einmal GPL, immer GPL". Auch für Teile die auf ursprünglichen GPL Code entstanden sind und Teil des "Ganzen" geworden sind (z.b. Binary) und einmal GPL waren sind immer GPL. In manchen Projekten hat es deshalb ja schon auch Codesplits gegeben.

Wenn jemand ein Programm selbst schreibt und das dem Image zugibt oder eigene Sachen schreibt um z.B. ein Image zu kreieren, dann hat das doch nichts mit dem GPL-Code im CVS zu tun, oder?

Doch, dann MUSS und IST der Teil wieder GPL. (Virulente Eigenschaft der GPL)

Sprich: Wenn jemand die Arbeit (in dem Fall tuxbox sourcen) verwendet und Erweiterungen macht, muß er diese wieder unter der GPL veröffentlichen.

Ansonsten koennte man ja auf Linux, oder mit einem gcc nie kommerzielle Software schreiben (je nach Art der "GPL"-Lizenz).

Ad1) Linux
=======
Der Linux Kernel steht unter der GPL, ausgenommen sind aber "User Mode Applikationen".

Siehe /usr/src/linux-2.4/COPYING

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ license (ie v2), unless explicitly otherwise
stated.

Linus Torvalds

----------------------------------------

[....] weiter gehts mit der GPL V2 ...

D.h. Erweiterungen zum Linux Kernel müssen wieder unter der GPL stehen.

Es gab auch Diskussionen ob z.B. Grafikkartentreibe unter Linux (z.b. von NVIDIA die es soweit ich weiss nur in binary gibt, *.so) nicht auch eigentlich GPL sein müßten, da sie ja keine "User Apps" sind.

Bis jetzt wird diese GPL Verletzung aber ignoriert, da man froh über den Hardwaresupport ist.

Artikel war auch auf http://lwn.net finde ihn leider nicht mehr ...

Richard Stallman (GPL "Erfinder") sieht das allerdings anders (eindeutig eine GPL Verletzung) ...
http://lwn.net/2002/features/rms.php3

Zitat aus obigem Link:
There is, for example, some disagreement (among the copyright holders) over whether run-time loading of modules into the kernel, Linux, requires that the modules have a GPL-compatible license. As the creator of the GPL, do you feel that Linux kernel modules fall within the boundary?

They clearly are covered by the GPL; modules for Linux are extensions of Linux, so under the GPL these modules must be free. However, anything the copyright holders of Linux give permission for in use of Linux is certainly permitted, regardless of what the GPL by itself would say. The license used on a program is legally a statement of what the copyright holders permit. Any statements they make that they permit this or that, once others rely on them, have the same legal force.

Ad2) gcc
======
Der gcc steht unter der Library GPL (LPGL) , einer modifizierten Form der GPL, wo man abgeleitete Programme (z.b. binaries) sehr wohl NICHT unter die GPL stellen muß, alle gcc Erweiterungen selbst aber schon.

Man darf also LGPL Programme oder Libraries zu seiner proprietären Software dynamisch linken, ohne das man das Programm selbst unter die GPL stellen muß. Wenn man aber "Erweiterungen" zur Lib selbst macht, muß die Erweiterung wieder unter der GPL stehen.

Oder sind jetzt alle Sachen, die fuer die dbox2 automatisch geschrieben werden GPL? GPL muss es nur sein, wenn ich den Source (ioder Teile davon) aus dem CVS dazu nutze...

Liege ich da falsch?

Ja genau so ist es. Wenn Du die Sourcen nutzt (egal ob aus CVS, download, von einem Freund, etc) müssen die Erweiterungen wieder GPL sein.

Auch wenn man von einem "Freund" ein cdk.cramfs bekommt muß er Dir die Sourcen geben (oder zumindest einen Link).

Siehe z.B. auch: http://groups.google.com/groups?oi=djq& ... _650369353

Hoffe damit sind die Rechte und Pflichten aller beteiligten am Projekt (Benutzer und Entwickler) klarer geworden und Sätze wie "Fordert nicht, was Euch nicht zusteht" waren etwas zu voreilig.

Unabhängig von der GPL (obwohl es eindeutig eine Verletzung der GPL wäre): Wollen wir eine 2 Klassengesellschaft an Entwicklern? Die einen, die alles bekommen, und die anderen, die nur Teile bekommen?

Hardsofty

[hardsofty]

Müssige Diskussion, ob das nun GPL ist oder nicht. Wenn er nicht will, dann will er halt nicht, was solls... Ich kann es verstehen.

Ich kann es nicht ganz verstehen. Das wäre genauso wie wenn ich Dir heute das "Recht" wegnehmen würde, daß DU das Projekt nutzen darfst (z.b. alle bis auf NoClue dürfen die Software nutzen), was dank GPL auch nicht geht.

Hardsofty

[boxi]

verlange halt, dass alexw die sources rausrueckt...
er hat ja gesagt, dass ers macht, wenn du nur hartnaeckig genug mit einem anwalt drohst...

[Homar]

Ich glaube ein Hobby würde manchen Menschen gut tuen...

Habt Ihr (einige) nichts besseres zu tuen, als immer wieder auf alexW oder den Dev es rumzuhacken ???

...da will jemand was gutes tuen, und muss sich leider solch e eine Schickane gefallen lassen.

Das was alexW macht, ist doch schon ok !!!
Wenn mir das nicht gefällt, dann akzeptiere ich es entweder, oder ich mache mich dran es besser zu machen um es dann der Allgemeinheit zugänglich zu machen.

mit enem Anwalt zu drohen ...

...Briefmarken sammeln, da passiert sowas nicht ;-)

[DieMade]

Obelix hatte recht: die spinnen, die Römer

[Reichi]

@hardsofty: weißt du was, bau mal ein Image a la alexW dann weißt du, was da arbeit drin steckt...
und komm mir jetzt nicht mit kann ich nicht, dann LERNS!

und du wirst feststellen dass es echt sauschwer ist ein anständiges image (so wie die von alexW sind) zu bauen.

ach ja: ich kanns nicht....

[hardsofty]

verlange halt, dass alexw die sources rausrueckt...
er hat ja gesagt, dass ers macht, wenn du nur hartnaeckig genug mit einem anwalt drohst...

Ihr solltet den Thread genauer lesen!!!!

Ich habe ihn nicht mit dem Anwalt gedroht, er hat nur geschrieben, daß er den Code auch OHNE Anwalt rausrückt.

Da ist ein gewaltiger Unterschied und das kann ich so nicht auf mir sitzen lassen!

Hardsofty

[hardsofty]

Ich glaube ein Hobby würde manchen Menschen gut tuen...

Habt Ihr (einige) nichts besseres zu tuen, als immer wieder auf alexW oder den Dev es rumzuhacken ???

...da will jemand was gutes tuen, und muss sich leider solch e eine Schickane gefallen lassen.

Das was alexW macht, ist doch schon ok !!!
Wenn mir das nicht gefällt, dann akzeptiere ich es entweder, oder ich mache mich dran es besser zu machen um es dann der Allgemeinheit zugänglich zu machen.

mit enem Anwalt zu drohen ...


..Briefmarken sammeln, da passiert sowas nicht ;-)

Du solltet den Thread genauer lesen!!!!

Ich habe ihn nicht mit dem Anwalt gedroht, er hat nur geschrieben, daß er den Code auch OHNE Anwalt rausrückt. Oder wo genau steht was von mir mit Anwalt drohen?

Da ist ein gewaltiger Unterschied und das kann ich so nicht auf mir sitzen lassen!

Hardsofty

[hardsofty]

@hardsofty: weißt du was, bau mal ein Image a la alexW dann weißt du, was da arbeit drin steckt...
und komm mir jetzt nicht mit kann ich nicht, dann LERNS!

und du wirst feststellen dass es echt sauschwer ist ein anständiges image (so wie die von alexW sind) zu bauen.

ach ja: ich kanns nicht....

Wenn es so kompliziert ist, rennt so und so was im Buildprozeß bzw. Configuration Management schief (damit hab ich als Configuration Manager tagtäglich zu tun, nur damit ihr nicht glaubt, daß ist nicht meine Thematik).

Wie gesagt: Ein make sollte reichen um ein AlexW Image zu erhalten (Idealfall natürlich).

Sonst muß man sich eben mehr mit taggen, branches, Koordination etc. auseinander setzen.

Weil eine alte (spezielle) Version von Treiber A, und eine bestimmte Version von Treiber B => Fall für einen Tag und wegbranchen bei Änderungen für den Release Branch.

Hardsofty

[hardsofty]

Obelix hatte recht: die spinnen, die Römer

Was bringt dir die Message als Entwickler?

Die spinnen nicht die Römer: Damit hast DU bewiesen, daß du die GPL und den OpenSource Gedanken nicht verstanden hast.

So eine Entwicklergemeinde ist mir noch bei keinem anderen Opensource Projekt untergekommen, daß man gleich beschimpft wird, wenn man auf die GPL pocht.

Ich habe auch in noch keinem anderen Projekt in der FAQ gefunden:
"Sind die Devs arrogant?"

Da muß also doch was wahres dran sein, oder doch nicht (Ich würde mich gerne überzeugen lassen, bei dem Thread schauts aber nicht so aus)?

Aber eigentlich habe ich mir vorgenommen auch für das Projekt AKTIV was zu tun,
(was natürlich nur mit aktuellen Sourcen Sinn macht), aber dann wird es wohl doch nur bei "glotzen" und warten auf das nächste hoffentlich stabiler werdende "AlexW" Image werden.

Ein vom D-Box2 Project und von den Entwicklern enttäuschter

Hardsofty

[Homar]

@hardsofty:

...ob ich wohl boxi gemeint habe ?!?!?!?!

[obi]

Kann dieses ewige "hoer doch auf zu meckern"-Gelaber mal aufhoeren? Natuerlich ist das fuer die, die es interessiert scheisse, dass sie keinen vollstaendigen Sourcecode von GPL binaries haben. Und natuerlich haben die Leute ein Recht darauf, den zu bekommen.

@alexW:
komm mal wieder auf den Boden zurueck und committe den Kram ins CVS, oder stell die Patches auf nen Webserver. Das ganze gepiense, es koennte jemand was schlimmes damit tun ist doch Kinderkacke. Wenn Du aber lieber versuchst, nen Monopol zu schaffen und andere an Mitentwicklung zu hindern, dann tut es mir leid. Schliesslich hast nicht Du die Software geschrieben, also hast Du auch nicht das Recht ueber die Sourcen zu bestimmen.

- obi

[boxi]

gut gebruellt obi!!!
(haett ich jetzt irgendwie gar nicht erwartet)

[rasc]

... ok, ich gebe mich auch geschlagen.


Und jetzt freue ich mich auf das public CVS der Dreambox.
Wo ist denn das?

Oder hatte ich das Ganze wieder falsch verstanden?

[hardsofty]

... ok, ich gebe mich auch geschlagen.


Und jetzt freue ich mich auf das public CVS der Dreambox.
Wo ist denn das?

Oder hatte ich das Ganze wieder falsch verstanden?

Das mit der Dreambox hab ich noch nicht ganz verstanden, aber wenn der Sourcecode vom DBOX2 Projekt abgeleitet ist, muß auch dieser Code wieder unter der GPL im Source veröffentlicht werden (ja der GPL Virus )

Entwickelt ihr (oder zumindest einige) bei der Dreambox Hardware oder Software mit?

Hardsofty

[obi]

ich weiss ehrlich gesagt jetzt nicht, was die dreambox mit dem topic zu tun hat. davon abgesehen ist die dreambox software bei uns im cvs und es merkt nur keiner, dass es das gleiche enigma ist, das auf der dbox2 laeuft... also wo ist da jetzt das grosse problem?

btw: https://tuxbox.berlios.de/forum/viewtopic.php?t=18266

[kerlimann]

leute, ich befuerchte fast, das geht hier mittlerweile in irgendeine politische ecke, was niemandem dient.

ich glaube nichtmals, das es unbedingt um die klamotte von alexW geht. interessiert irgendwie nicht wirklich, oder?

ich denke es geht primaer darum, das man sich ein vernuenftiges image selbst compilen kann - und zwar ein LAUFFAEHIGES. eigentlich sollte hierzu mal das REL_1_0_0 gedacht gewesen sein. nun ist dem aber nicht mehr so, da dort enigma drin weiterentwickelt wird, und somit der stabile stand nicht mehr gegeben ist. neutrino hingegen wird nur noch im HEAD weiterentwickelt, allerdings sind hier die treiber unter aller kanone.

was die leute wollen, ist ein mittelweg, denke ich mal. ein stabiler branch halt. und das duerfte doch nicht zuviel verlangt sein - denn sonst kann doch niemand ernsthaft was damit anfangen.

beispiel: trotz meiner bescheidenen programmierkuenste habe ich es hinbekommen, das HEAD zu compilen (vor paar tagen). habe das komplette image auch allen zur verfuegung gestellt. OK, nun stellte ich aber fest, das tuxtxt nicht laeuft. also kurzerhand mal LazyT gefragt. resultat: liegt an den neuen drivern (API), kann ich nix machen. tja, klar, koennte ich ja REL nehmen (1_0_0), aber da ist neutrino veraltet, und enigma laesst sich nicht compilen.

also, jungs, da muss es doch einen mittelweg geben. ich denke dann sind auch alle zufrieden. loesungen gibt es da IMHO lediglich 2 zu, derweil:

a) neutrino wird simultan wie enigma im REL mit den alten drivern entwickelt (die knacken wenigstens nicht im audio <g>).

b) jemand erklaert mal hier wie man im HEAD die alten driver nutzen kann (vielleicht eine option im makefile setzen?).

wie ich schonmal schrieb, hat das doch nichts mit abuse oder schwarzglotzen zu tun, dafuer braucht keiner den alexw. ich fuer meinen teil wuerde gerne tuxtxt in meinem headimage nutzen koennen.

also echt, da musses doch ne loesung geben. alles andere ist voll die farce.

PS: vielleicht noch ein festes branch, welches unter garantie zuckt. fuer die neueinsteiger. das entlastet ja auch das forum. das ein entwicklerbranch nicht immer durchcompiled, ich denke das ist jedem klar.

My2Cents

[obi]

@kerlimann:
du scheinst zu vergessen, dass es neben dbox2 programmierung noch andere dinge gibt, die man zu tun hat. was bringt ein dritter cvs zweig, um den sich keiner kuemmert? enigma wird nunmal hauptsaechlich fuer die dreambox entwickelt und braucht deshalb dvb api version 1. *irgendwann* wird es auch dafuer treiber geben, die dem aktuellen stand entsprechen. der rel_bla_bla genannte zweig ist ansonsten als abstellgleis zu betrachten. irgendwo hoerts ja auch auf.. wenn man irgendwie mit der entwicklung, die auch *ausserhalb* unseres bescheidenen projektchens stattfindet, mithalten will, dann muss man eben hier und da schlussstriche ziehen und sich darum kuemmern, dass die programme aktuellen/zukuenftigen standards entsprechen. fuer den endanwender kann das vielleicht langweilig oder sinnlos erscheinen, aber der endanwender muss eben das nehmen, was er bekommt. ich kenne eigentlich auch keinen (oder nur einen *g*), der noch keinen cvs schreibzugriff bekommen haette, um seine ideen einbringen zu koennen. diejenigen, die sich momentan beteiligen und sich in die treiber rein wagen, haben einfach gerade keine zeit oder einfach nicht die moeglichkeit, das alles fortzufuehren und zu testen. also fuehl dich frei, das problem mit mehreren clients pro pid zu fixen - und zwar so, dass es nicht *irgendwie* geht sondern allgemein akzeptiert wird und auch von anderen genutzt werden kann - damit dein tuxtxt auch mit dem aktuellen cvs stand funktioniert.

- obi

p.s.: wenn du in enigma bzw. zapit einfach kein DMX_PES_TELETEXT startest (vbi reinsertion), dann geht das sicherlich..

[kerlimann]

hi obi,

>du scheinst zu vergessen, dass es neben dbox2 programmierung noch
>andere dinge gibt, die man zu tun hat.
das ist mir bewusst. wir alle haben auch noch anderes zu tun. es war nur ein vorschlag.

>was bringt ein dritter cvs zweig, um den sich keiner kuemmert?
da muss sich niemand drum kuemmern. ich befuerchte du hast mich missverstanden? dieser 3te CVS stand fuer newbees soll nicht gepflegt werden, sondern lediglich EINEN lauffaehigen stand wiederspiegeln. der soll auch nicht weiter gepflegt werden, oder gar aktuell sein. der soll einfach einen stand (zum bleistift 4.12.02 - wild aus der luft gegriffen) beinhalten, welcher sich fuer NEUE (newbees) compilen laesst. diese leute koennen somit ihre eigenen fehler erstmal einkreisen und finden. sobald sich das erste erfolgserlebnis bei dieser gruppe dann einstellt, gewinnt das projekt (IMHO) auch neue heranwachsende programmierer.

>der rel_bla_bla genannte zweig ist ansonsten als abstellgleis zu
>betrachten.

vielleicht sllte man dies dann mal hier: http://tuxbox.berlios.de/forum/viewtopic.php?t=13803 kundtun?

>die sich momentan beteiligen und sich in die treiber rein wagen, haben
>einfach gerade keine zeit oder einfach nicht die moeglichkeit, das alles
>fortzufuehren und zu testen.
darum frage ich mich, warum diese treiber dann drin sind, wenn niemand lust und zeit hat diese zu testen. nein, meine bescheidenen kenntnisse reichen nicht zur treiberprogrammierung aus. und so scheint es ja 99% aller anderen poster hier zu gehen. ich mein, irgendwer muss ja mal "bestimmt" haben, das nun diese neue API genutzt werden soll, oder? nur sollte dieser, sofern er sieht da ist kein progress drin, vielleicht wieder davon abstand nehmen, zumindest vorlaeufig.

und so schlecht waren die alten driver doch nicht, eigentlich waren die ja "fertig". aus meiner sicht liefen die perfekt. kannst du mir ein problem nennen, welches an den alten treibern liegt? ich bin da einsichtig ;)

>also fuehl dich frei, das problem mit mehreren clients pro pid zu fixen -
>und zwar so, dass es nicht *irgendwie* geht
noe, denn "irgendwie" gehts ja jetzt schon, leider nur teilweise.

>sondern allgemein akzeptiert wird und auch von anderen genutzt werden
>kann - damit dein tuxtxt auch mit dem aktuellen cvs stand funktioniert.

wenn es allgemein akzeptiert werden wuerde (von den derweiligen devs) haette keiner ein problem, aber dem scheint ja nicht so zu sein, oder warum wird der kram sonst "schweine api" genannt? :-))

>p.s.: wenn du in enigma bzw. zapit einfach kein DMX_PES_TELETEXT
>startest (vbi reinsertion), dann geht das sicherlich..

hmm, ich probieren, thx.

[kerlimann]

wenn du in enigma bzw. zapit einfach kein DMX_PES_TELETEXT
startest (vbi reinsertion), dann geht das sicherlich..

nur mal ene verstaendnisfrage: sehe ich das richtig, das dann das TV bild weg ist, und ich NUR den teletext habe? waere nicht schlimm, ich versuche lediglich das nachzuvollziehen.

[obi]

>was bringt ein dritter cvs zweig, um den sich keiner kuemmert?
da muss sich niemand drum kuemmern. ich befuerchte du hast mich missverstanden? dieser 3te CVS stand fuer newbees soll nicht gepflegt werden, sondern lediglich EINEN lauffaehigen stand wiederspiegeln.

diesen fiktiven zustand haben wir doch im rel branch. du siehst doch, wie es sich in der realitaet widerspiegelt. die paar backports, die alex von head auf den alten kram gemacht hat, wird sicher kein zweiter nochmal machen. uebersetzen laesst sich das ding sicherlich. dass es jeder unter allen umstaenden schafft ist leider nicht machbar.

frage ich mich, warum diese treiber dann drin sind

damit die programme auch auf anderen platformen laufen koennen, mit aktuellen kernel versionen. ist das denn so kompliziert zu verstehen?

wenn niemand lust und zeit hat diese zu testen.

war die rede von "keine lust"? mir fallen spontan vier leute ein, die sicher lust haben, die aber andere dinge tun muessen. ich selbst habe diesen monat ziemlich viel zeit aber nichtmal ne sat-schuessel im moment, geschweige denn einen eigenen internet anschluss, wenn ich zuhause bin.

nein, meine bescheidenen kenntnisse reichen nicht zur treiberprogrammierung aus

das habe ich von mir auch mal behauptet.

irgendwer muss ja mal "bestimmt" haben, das nun diese neue API genutzt werden soll, oder? nur sollte dieser, sofern er sieht da ist kein progress drin, vielleicht wieder davon abstand nehmen, zumindest vorlaeufig.

zu dem zeitpunkt wurde der rel branch fuer die alte api erstellt. dass die ganzen programme auf der neuen api weiterentwickelt wurden und werden ist die entscheidung eines jeden einzelnen entwicklers

und so schlecht waren die alten driver doch nicht, eigentlich waren die ja "fertig". aus meiner sicht liefen die perfekt. kannst du mir ein problem nennen, welches an den alten treibern liegt?

nein, sie waren nicht schlecht. nur scheisse zu lesen und inkompatibel zu anderen platformen, zum teil mangels vollstaendigkeit der implementierungen diverser linux apis, zum teil durch schaffung eigener schnittstellen, fuer die es standard apis gibt. wie auch immer, es hoert sich an, als waeren die alten treiber fuer immer vernichtet worden. sie sind aber noch vorhanden, und wenn sie jemand benutzen will, dann kann er das tun.

>sondern allgemein akzeptiert wird und auch von anderen genutzt werden
>kann - damit dein tuxtxt auch mit dem aktuellen cvs stand funktioniert.
wenn es allgemein akzeptiert werden wuerde (von den derweiligen devs) haette keiner ein problem, aber dem scheint ja nicht so zu sein,

ich hab noch keinen fix dafuer gesehen, also weiss ich nicht was dein kommentar bedeuten soll. im uebrigen ist das hauptsaechlich ein problem der api-schicht und deinen patch kannst du an linux-dvb@linuxtv.org schicken.

oder warum wird der kram sonst "schweine api" genannt? )

wer ausser dir nennt es denn so? wenn du konstruktive beitraege zur aenderung der api hast, dann schicke sie ebenfalls an linux-dvb@linuxtv.org

- obi