Beiträge von mini73

    Moin!


    Zitat

    Original von hotzenplotz5
    ich glaube das war es wo es "hakt" :


    bei lnb:

    Code
    -cDvbTuner::cDvbTuner(int Device, int Fd_Frontend, int Adapter, int Frontend, fe_delivery_system FrontendType)
    +cDvbTuner::cDvbTuner(int Device, int Fd_Frontend, int Adapter, int Frontend, fe_delivery_system FrontendType, bool LnbSendSignals)  // LNB Sharing


    bei dynamite :

    Code
    cDvbTuner::cDvbTuner(int Device, int Fd_Frontend, int Adapter, int Frontend, fe_delivery_system FrontendType, cDvbDevice *Dvbdevice)


    Daraus machst du am besten

    Code
    cDvbTuner::cDvbTuner(int Device, int Fd_Frontend, int Adapter, int Frontend, fe_delivery_system FrontendType, bool LnbSendSignals, cDvbDevice *Dvbdevice)


    Und irgendwo weiter unten, wo "new cDvbTuner" steht, musst du beide Parameter in der richtigen Reihenfolge einsetzen ("this" aus dynamite ans Ende).


    Lars.

    Moin!


    <Offtopic>
    Danke, Klaus, für deine unermüdliche Arbeit.
    Da ich zur Zeit daran arbeite, den vdr mit einem Hotplug-Plugin zu versorgen, und deshalb "Unmengen" an vdr-Quellcode lesen "musste" (ich wollte es ja), weiß ich, dass du mit Sicherheit eine gut abgestimmte OSD-API entworfen haben wirst. Ich freue mich schon darauf, sie kennenzulernen. Ich hoffe, die Ausgabe-Plugin-Maintainer werden sie schnell adaptieren und implementieren, damit wir alle gut davon haben, egal, woran wir glauben. Ich gehöre nämlich zu keiner der bisher genannten Fraktionen, ich gucke mit einer PVR350 und "das ist auch gut so". :)
    </Offtopic>


    Ich überlege ernsthaft, mir auch eine Karte zu holen, obwohl ich bisher DVB-C habe, da ich eventuell in absehbarer Zeit zusätzlich eine Sat-Schüssel aufstellen könnte. Wenn dann 2x DVB-C plötzlich durch 2x DVB-S2 und 1xFF erweitert werden (wodurch meine PVR350 ersetzt würde), werde ich sicherlich ein nettes System haben (vermutlich werde ich dir dann aber einfach nur dabei helfen wollen, eine Alternate-Channel-Funktionalität zu integrieren :-)).
    :versteck


    Lars.

    Moin!


    Genau dein Problem ist auch ein Grund für dieses Plugin. Je nachdem, wie groß dein Basteltrieb (und -kompetenz) ist, kannst du natürlich auch selbst Hand anlegen. Aber dann natürlich auf eigene Gefahr.


    Was das Plugin bisher kann:
    Reagiert eine Karte eine gewisse zeitlang nicht mehr (liefert also keine Daten), dann kann das Plugin es automatisch aus dem vdr entfernen, so dass es nicht mehr benutzt wird. Dann startet er zumindest nicht neu und die restlichen Karten können noch aufnehmen. Evtl. kann es dann aber zu nicht aufgelösten Timerkonflikten kommen.


    Zum anderen kann es neu hinzugekommene Frontends im System per udev erkennen und dann automatisch in den vdr einbinden. Das passiert z.B., wenn man einen USB-DVB-Stick dazusteckt.


    Was noch fehlt (da wird dann wohl das yaVDR-Team einspringen müssen, weil es eine "root"-Sache ist):
    Hat sich das Device aufgehängt und dynamite es automatisch entfernt, muss ja irgendwas dafür sorgen, dass es wieder betriebsbereit ist, z.B. die Treiber ent- und neuladen. Da dafür root-Rechte nötig sind, wird das Plugin das nicht ohne Hilfe auslösen können. Es kann natürlich irgendeine Form von Signal oder Event senden, wenn es aufgrund eines Fehlers ein Device entfernt hat. Bloß fehlt noch die Gegenseite, die dann darauf reagiert.
    Und da wird es sicherlich auch irgendeine Script-Lösung geben müssen, da damit individuelle Probleme (je nach System) gelöst werden können müssen.


    Deine Fehlermeldungen erinnern mich an meinen DVB-T-Stick. Wenn ich den während des Betriebes abziehe, kommen so ähnliche Meldungen (auch immer wieder). Leider lässt sich dann das betroffene Modul auch nicht mehr entladen, das "modprobe -r" hängt sich genauso auf.
    Direkt nach dem Abziehen bekomme ich von udev eine Meldung, dass (bei mir zumindest) ein bestimmtes i2c-Device (das zum DVB-Stick gehört) entfernt wurde - darauf ließe sich bestimmt reagieren, damit der vdr den Stick möglichst schnell freigibt, damit es nicht zu dem Absturz kommt. Leider weiß ich noch nicht, wie ich aufgrund des i2c-Devices auf das passende Frontend schließen kann, da bin ich noch am recherchieren.


    Es wird also an der Lösung deines Problems gearbeitet. Dauert nur noch ein bisschen... :)
    Ich bin schon erstaunt genug, wie schnell ich da überhaupt was halbwegs Brauchbares produziert hab... :)


    Lars.

    Moin!


    Falls du Patches verwendest, die cDevice neue virtuelle Methoden hinzufügt, musst du auch dynamite anpassen. Sieh dir einfach in dynamite an, wie mit den anderen Methoden umgegangen wird, das Hinzufügen erklärt sich dann von selbst...
    Ein paar von yaVDR verwendete Patches sind als Beispiel drin.


    Lars.

    Moin!


    Hast du den vdr-Patch eingespielt? Ist im Unterverzeichnis "patches". Das sieht so danach aus.
    Wenn du keine vdr-Sourcen benutzt, sondern ein vdr-dev-Paket, weiß ich leider nicht, wie man dann den Patch einspielt.


    Lars.

    Moin!


    Zum Ausprobieren hab ich mal meine ersten Ergebnisse mit udev veröffentlicht - siehe ersten Beitrag (Version 0.0.5).
    Der vdr-Patch hat sich nicht geändert.


    Taucht ein neues Frontend im System auf, wird es automatisch eingebunden.


    Möchte man die udev-Meldungen etwas untersuchen, kann man dynamite mit dem Parameter "--log-udev" starten - dann wird das Log entsprechend vollgemüllt. Ist mal ganz interessant.


    Lars.

    Moin!


    Ok.


    Die ersten Tests mit udev liefen gestern schon sehr vielversprechend. Nach Anstöpseln des USB-DVB-Sticks hat sich der vdr das Gerät geholt und konnte es gleich benutzen. ;)


    Es gibt auch udev-Events, die mir sagen, dass etwas abgestöpselt wurde, das sind aber irgendwelche i2c-Devices im usb-Subsystem. Wie ich daraus dann das passende Frontend ableite, muss ich noch mal sehen.


    Zusammen mit dem GetTS-Timeout würde dynamite das Gerät ja schon mal loswerden, falls es gerade zum Empfang genutzt wird, aber dann stürzt bei mir irgendwann irgendwas im dvb-Subsystem ab, weil der Treiber nicht so richtig damit zurecht kommt, wenn ihm bei geöffnetem Device die Hardware geklaut wird. Danach muss ich immer rebooten...
    Und es wäre ja schöner, wenn dynamite das Device aushängt, auch wenn es nicht in Benutzung ist. Dann kommt es erst gar nicht zu dem Problem. Aber da bin ich dran.


    Lars.

    Moin!


    Zitat

    Original von gda
    Schön wäre es, wenn bei API-Änderungen, also bei Änderungen des VDR-Patches, die Version hochgeht. Also statt 0.0.4j -> 0.0.4k statt dessen 0.0.4j -> 0.0.5. Was meinst du?


    Das ist eine Idee - aber eigentlich dachte ich, dass ich die letzte Stelle hochzähle, wenn neue Plugin-Features hinzukommen (hätte ich mit dem Auto-Detach eigentlich schon machen können...).
    Mein nächster Plan ist ja die udev-Schnittstelle, damit dynamite automatisch neue Frontends einbindet. Ich plante, dass das ein 0.0.5 wert wäre.


    Ich könnte eine Versionsnummer an den Dateinamen mit dem vdr-Patch hängen, wie wäre das? Beim nächsten Mal wird da also eine "-1" dranhängen, was bedeutet, dass sich nichts geändert hat (also "momentaner Patch" == "-1").
    Falls da also plötzlich eine "-2" auftaucht, hat sich doch was geändert... :)
    Und ich könnte es zusätzlich in der HISTORY erwähnen.


    Lars.

    Moin!


    Gerald hat recht.


    Immer, wenn ich etwas veröffentliche, zähle ich die Version bei mir lokal schon mal sicherheitshalber hoch, es sollte also noch kein "j" gegeben haben. Sieht dem "i" aber auch zu ähnlich... :)


    Habt ihr auch schon das aktuelle pvrinput in unstable? Das funktioniert nämlich auch mit dynamite.


    Lars.

    Moin!


    Hab eine neue Version 0.0.4j hochgeladen.


    • nach einem "Detach" müssten jetzt endlich alle Handles, die der vdr auf einer DVB-Karte geöffnet hat, geschlossen sein - ich hab zumindest keine offenen mehr. Damit lässt sich z.B. eine zickige Karte vom vdr trennen, die Treiber neu laden (wenn sie von keiner anderen Karte benutzt werden) und wieder in den vdr hängen. Das geht aber bisher nur manuell.
    • Für so einen Fall wie oben beschrieben, ist ein neues Feature dazu gekommen: "Auto-Detach"
      Mit dem SVDRP-Kommando "SGTT /dev/dvb/adapter0/frontend0 15" lässt sich ein Timeout pro Device hinterlegen (SGTT steht für "set GetTS timeout", die Zahl hat die Einheit Sekunden). Liefert die Karte in ihrer GetTSPacket-Methode die gesetzte Zeitspanne lang keine Daten (Data wird auf NULL gesetzt), wird das Device automatisch ausgehängt (DETD wird aufgerufen).


    Ich hab auch schon angefangen, mich in libudev einzulesen. Die ist nicht schwer zu benutzen, demnächst könnte es also sein, dass dynamite von ganz alleine neu eingestöpselte DVB-Frontends erkennt und automatisch einhängt...


    Lars.

    Moin!


    Es gibt aber noch ein paar Probleme mit verschlüsselten Kanälen. Ansonsten scheint es schon ganz gut zu funktionieren.
    Da ich selbst keine CI-Hardware habe, ist es ein kleiner Blindflug, was das Programmieren angeht. Aber es gibt immer mal wieder Fortschritte... :)


    Lars.

    Moin!


    Am besten lässt du dir mit LSTT mal einen Timer ausgeben, dann weißt du, was du wie an NEWT übergeben musst.


    Und lass dich bloß nicht von kleinen unsinnigen Programmierprojekten abhalten, gerade diese machen am meisten Spaß! Und wenn man nur selbst was davon hat... :)


    Lars.

    Moin!


    Kann man das mcli-Plugin auch nutzen, ohne einen Netceiver zu haben?
    Kann das mcli-Plugin denn auch andere Devices dynamisch ein- und aushängen?


    Als nächstes steht ein Patch für pvrinput auf der Liste, dann wird man ganz einfach z.B. eine pvrusb2 bei Bedarf dazustöpseln können.
    Und ich hoffe mal, dass da gar nicht viel an pvrinput geändert werden muss, das werde ich dann sehen.


    Meine Änderung bezieht sich nicht nur auf DVB-Karten, sondern ließe sich mit allen Plugins nutzen, die etwas von cDevice ableiten und zur Verfügung stellen.
    DVB-Karten werden nur "out of the box" unterstützt, weil sie ohnehin im vdr sind und durch cDvbDeviceProbe erreichbar sind. Und mit irgendwas muss man ja anfangen... :)


    Aber ich erfinde gerne neue Räder, die sich auch drehen können. Ich hab eine Menge über den vdr gelernt, das zählt für mich noch viel mehr.
    Wenn man programmiert, um Geld zu verdienen, ist es auch mal schön, einfach aus Lust und Laune und für den Spaß zu programmieren.


    Und das es sinnvolle und sinnlose Plugins gibt, ist ja klar... :)


    Lars.

    Moin!


    Im ersten Beitrag ist eine neue Version (0.0.4i) verlinkt - die sollte jetzt auch mit veschlüsselten Kanälen zurecht kommen.
    Da ich aber kein CI/CAM habe, konnte ich es nur provisorisch testen - wenn jemand Lust hat, darf er's gerne ausprobieren... :)


    Lars.

    Moin!


    Seit ich mit vdr 1.7.16 herumexperimentiere, sehe ich auch diese Meldung. Hab dann ein wenig gewühlt und folgende Veränderungen im Konstruktor von cDvbDevice von 1.7.14 nach 1.7.15 gefunden:
    dvbdevice.c (1.7.14)


    dvbdevice.c (1.7.15)


    Meine Satelco EasyWatch sorgt dann für folgende Meldung im Log:

    Code
    frontend 1/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Philips TDA10023 DVB-C")


    In cDevice::GetDevice versucht nun der vdr eine Karte zu finden, die für eine Aufnahme oder streamdev oder was auch immer benutzt werden kann. Dabei versucht er, keine Karte auszuwählen, die mehrere Systeme unterstützt. Das soll z.B. verhindern, dass ein DVB-S-Kanal auf einer Karte geguckt wird, die DVB-S und DVB-S2 unterstützt. Damit dann eine spätere Aufnahme auf der jeweils anderen Modulation auch eine Karte findet.
    Es wird also versucht, die Karte mit den wenigsten Modulations-System zu benutzen. Die Meldung ist nicht unbedingt schlimm, es bedeutet nur, dass Karten mit unterstützten Systemen über eine gewisse Anzahl hinaus nicht mehr unterschieden werden.
    Aber eigentlich sind in der Funktion GetClippedNumProvidedSystems 4 Bits für die Anzahl reserviert, es sollten also eigentlich 15 Systeme unterschieden werden können. Warum da die Variable MaxNumProvidedSystems als 4 und nicht als 15 ausgerechnet wird, hab ich keine Ahnung...

    Code
    int MaxNumProvidedSystems = (1 << AvailableBits) - 1;


    AvailableBits ist 4, das hab ich mit einer Log-Meldung überprüft. Dann wird MaxNumProvidedSystems auch richtig ausgerechnet und der Fehler taucht nicht auf.
    Vielleicht eine komische Compiler-Optimierung? Ich nutze gcc 4.4.3.


    Lars.

    Moin!


    Zitat

    Original von tadi
    Und weil das so ist, und auch weil mir schon seit Jahren das umständliche Verwalten von Patches für den VDR negativ aufgefallen ist, hatte ich mich irgendwann hingesetzt und alle offiziellen VDR-Versionen in das VDR-GIT auf http://projects.vdr-developer.org/projects/vdr eingepflegt.


    Und anstatt jetzt ewig herum zu diskutieren sollte jeder, der einen oder mehrere Patches verwaltet, das obige GIT bei sich clonen, jeweils einen isolierten Patch pro Patch-Branch einpflegen und das ganze wieder auf projects.vdr-developer.org hochladen (Alternativ kann auch GIT-Hub etc. verwendet werden).


    Das werde ich demnächst mit meinem Patch mal machen (bis jetzt hab ich nur einen... ;-))
    Das ist ja eigentlich genau das, was hier besprochen wird (jedenfalls meiner Meinung nach).


    Zusätzlich werde ich einen entsprechenden diff natürlich weiterhin im tar-ball meines Plugins pflegen. Das ist dann ja nicht mehr weiter schwer.


    Das schwierigste an diesem git-tree: Wie erfahren neue Entwickler davon? Ich kannte ihn nicht, obwohl ich projects.vdr-developer.org durchaus kenne...


    Lars.