Posts by xblades

    Du könntest folgenden patch probieren.

    Hatte Probleme auf einem PC beim Umschalten, ca jeder 8. Versuch erzeugte einen Blackscreen, OSD war noch in Ordnung. War auch darauf gestoßen, dass es mit 2.3.9 hineingekommen ist.

    Der Patch ist schon an KLS gegangen, der möchte sich das noch einmal anschauen, da die Änderungen auf 2.3.9 wohl besagt, dass es Probleme mit einem Deadlock gegeben hat.

    Sobald Receiver->Activate(false); im Lock mit drin ist, habe ich die Probleme. Meine Vermutung ist, dass es da zu einem Timeout beim Tunen kommt, sobald der aktive Receiver für die Schleife gelockt ist, will heißen es könnte auch an anderer Stelle zu fixen sein.

    Ich selbst habe eine SD-FF Karte und 2x DvbSky S952 auf Intel Celeron.

    Files

    • device.patch

      (1 kB, downloaded 237 times, last: )

    Bei vdr 2.4.1 in der Datei device.c funktion detach (fast am Ende) den Lock nicht über die ganze Schleife laufen lassen. Sobald Receiver->Activate(false); im Lock ist, bleibt manchmal das Bild aus (OSD geht noch). Habs an KLS geschickt, der wollte sich das nochmal ansehen, da das wohl in 2.3.9 nicht ohne Grund geändert wurde.


    void cDevice::Detach(cReceiver *Receiver)


    {

    for (int i = 0; i < MAXRECEIVERS; i++) {


    mutexReceiver.Lock();


    if (receiver[i] == Receiver) {


    receiver[i] = NULL;


    Receiver->device = NULL;


    mutexReceiver.Unlock();


    Receiver->Activate(false);


    for (int n = 0; n < Receiver->numPids; n++)


    DelPid(Receiver->pids[n]);


    }


    else {


    if (receiver[i]) {


    receiversLeft = true;


    }


    mutexReceiver.Unlock();


    }


    }

    Files

    • device.patch

      (1 kB, downloaded 94 times, last: )

    So, Icons habe ich wieder,

    hatte ein neues vdr-kompilat eingespielt, da war vohl der installationspfad ein anderer. flugs die css-dateien aus dem Kompile-verzeichnis dahingeschoben und erstmal ok.

    Die Zeit ist immer noch kein 24h-Format, Der Tag hat 2x 1-12 Stunden, man muss raten, was vor- und nachmittag ist.

    Hallo,

    habe beim live plugin keine icons mehr (z.b. Recording Buttons sind weiße Kästchen) und die Zeit ist nicht mehr 24h-Darstellung, Remote hat überhaupt keine Buttons - das TV-Bild ist ok.

    Text, Anordnung usw. sieht ok aus.

    Neustart des vdr bringt keine Änderung.

    Hat jemand eine Idee, was das sein könnte ?

    Ist mir eine config verloren gegangen ?

    Wenn ich tcp über port 8008 connecten kann sollte die Verbindung doch ok sein, oder braucht live auch udp ?

    Bin mir sicher, dass es neulich noch ging.

    Version zeigt 2.3.1 bei vdr 2.4.1


    Stefan

    Lösung gefunden - war eine externe Störquelle - natürlich selbst eingebaut vor 2 Monaten.


    Das Sytsem steht auf dem Dachboden und versorgt das Haus per Modulator (839MHz) an den Antenneneingang des Sat-Verteilers mit dem VDR über Ausgang FF-Karte.

    Zusätzlich wurde ein DVB-T Modulator installiert, um den HDMI-Ausgang auf 650MHz in das System einzuspeisen. Leider stört er das SAT-Signal auf der Frequenz 12544 MHz.

    Ich war auch davon Ausgegangen, das der Antenneneingang des SAT-Verteilers bandbegrenzt ist, scheint nicht der Fall zu sein.

    Jetzt hängt hinter dem DVB-T-Modulator ein LTE-Filter bis 790 MHz und alles geht.


    Danke für eure Hilfe.

    syslog.zip

    Anbei mal der syslog mit Umschaltung auf problematischen Sender. Alles was nicht vdr ist gelöscht.

    Habe das System wieder auf die problematische Karte umgebaut. Habe mal mit verschiedenen Frequenzeinträgen gespielt - keine Änderung Signalstärke immer hoch, SNR 0. Wenn ich auf 12520 runtergehe findet er einen Lock (Signalstärke und SNR hoch), aber kein Bild - vermutlich ein anderer Transponder ?


    Was ich im Moment nicht nachvollziehen kann - anscheinend sucht er bei Lock-Timeout mit anderen Frequenzen, bis das Signal besser wird. Dazu habe ich aber noch nirgendwo code gefunden. Habe bei mir in der channels.conf das Erste mit gutem Empfang mit Frequenzen von 11822 bis 11853 eingetragen. Ergebnis war, dass der vdr die Kopien in der channels.conf gelöscht hat. Beim Schalten mit 11822 konnte man auf femon sehen, dass er bei SNR=0 gestartet hat und das Signal dann immer besser wurde - wie gesagt, der Code dazu ist mir nicht bekannt.


    Den Patch habe ich mir mal angesehen, konnte aber nichts wirklöich relevantes erkennen, was man nicht mit anderen Frequenzeinträgen auch erreichen würde. Ich bau mir jetzt erst mal nen Kernel mit mehr Debug-Ausgaben beim tunen.

    Danke,

    alps_bsrv2_tuner_set_params() sah so vielversprechend aus,

    es wird aber alps_bsbe1_tuner_set_params() sein, und das ist fast identisch zu alps_bsru6_tuner_set_params()


    das ist auffällig beim bru6 :

    channels.zip

    Erstmal die channels.conf, log-datei geht erst später...


    Ich habe mal in die Av7110.c vom Kernel reingeschaut.

    Denke dass die alps_bsrv2_tuner_set_params() Funktion für den ALPS BSBE1-502a der Nexus 2.3 zuständig ist.

    Für den BSRUG6-502a der Nexus 2.1 wäre es dann die alps_bsru6_tuner_set_params() - die ich noch nicht finden konnte :-(

    Jedenfalls gibt es dort eine Bereichsumschaltung :


    if (p->frequency > 2000000) 1580

    pwr = 3;
    else if (p->frequency > 1800000)
    pwr = 2;
    else if (p->frequency > 1600000)
    pwr = 1;
    else if (p->frequency > 1200000)
    pwr = 0;
    else if (p->frequency >= 1100000)
    pwr = 1;
    else
    pwr = 2;


    Die übergebene Frequenzen sind :

    bei 12604 -> 2004000

    bei 12544 -> 1944000

    bei 12480 -> 1880000


    das bedeutet, dass die Bereichumschaltung direkt nach 12544 kommt. Da ich kein Datenblatt dazu habe, kann ich jetzt nur vermuten, dass das BIAS-Einstellungen des VCO sind. Es könnte in meinem Fall sein, dass die Bereichsumschaltung unter 1944000 stattfinden müsste. Meistens gibt es bei den VCO auch sich überschneidende Bereiche -> wäre einen Versuch wert. Wäre ein Task fürs Wochenende.

    Habe mal weiter geforscht - Im VDR dvbdevice.c wird in cDvbTuner::SetFrontend() die Frequenz und alle anderen Parameter an den Treiber übergeben - für alle identisch.

    Das würde bedeuten es kommen noch

    - Hardware (halte ich eher für unwahrscheinlich, da alle Kanäle im oberen Band liegen, Horizontal/Vertikal gehen, die Frequenzen oberhalb und unterhalb von 12544 funktionieren - 12545 habe ich auch probiert)

    - Kerneltreiber (AV7110 ?)

    - Firmware (läuft halt mit Rev 2.1- ist vermutlich auch nur für den MPEG-Decoder)

    in Betracht.


    Als Module sind geladen :

    - dvb_ttpci

    - dvb_core

    - ttpci_eeprom

    - saa7146_vv

    - saa7146

    Hallo,

    ich habe hier ein seltsames Verhalten mit 2 dvb-ff Karten Nexus-S Rev 2.3 - sie schaffen es nicht auf die Frequenz 12544 zu tunen.

    Im syslog kommt: frontend 0/0 timed out while tuning to channel 5 (SAT.1), tp112544

    Es sind alle Kanäle betroffen, die auf der Frequenz liegen, bei allen anderen Frequenzen tritt der Fehler nicht auf.

    Normalerweise betreibe ich das System mit zusätzlich 2xDVBSky S952, die können die Programme einwandfrei empfangen. Deswegen ist das Problem nicht so schnell ersichtlich geworden, da der VDR auf ein device wechselt, wo die Programme funktionieren.

    Habe schon etliches getestet, diverse Firmware's. Habe die Karte durch eine baugleiche ersetzt, dasselbe Problem. EIne Nexus Rev. 2.1 (memory mod und budget patch) hat das Problem nicht.

    Insofern kann ich etliche Sachen ausschließen und verorte es bei der Hardware der Nexus 2.3, bzw dessen Ansteuerung.

    Wenn die Frequenz 12544 gewählt ist, zeigt femon sehr hohe Signalstärke, aber SNR von 0, kein carrier, kein lock. Die korrekte Steuerspannung und 22kHz liegen an. Somit dürfte es allein am Tuner liegen.

    Das seltsame ist, dass ich zu 95% sicher bin, dass es zuvor mit easyvdr (ubuntu 14.01) keine Probleme gegeben hat.

    Derzeit habe ich Ubuntu 20.04 (Focal Fossa) mit vdr-2.4.1, als firmware die dvb-ttpci-01.fw-fb2624 (alternativ 2622 und 261f)

    Ich bin hin und her gerissen, die Nexus 2.1 drin zu lassen oder den Fehler mit der 2.3 zu finden - beide haben anscheinend unterschiedliche Tuner.


    Kann sich da jemand einen Reim drauf machen oder hat Tipps, wo ich ansetzen kann ?


    Gruß,

    Stefan


    Welchen Skin nutzt du denn? Die Bandbreite für das OSD ist bei den FF-Karten ja beschränkt, so dass man da animierten OSD-Inhalte wie Laufschriften eher nicht haben will.

    Skin ist LCARS.

    Dürfte eher nicht daran liegen, da VDR2.2.0 mit gleichem Skin das Problem nicht hat. Bei beiden Versionen schein dvbsddevice2.2.0 verwendet zu werden, somit dürfte das plugin auch nicht die Ursache sein.

    Andere Plugins sind nicht aktiv, bzw. ändern nichts, wenn ich sie aktiviere.


    systemd hatte ich als startvariante gewählt, da ich eventuelle Unterschiede beim vdr-start ausschliessen wollte. Es hilft ja auch nichts, wenn es direkt gestartet laufen würde - ich brauche ja den Fehlerfall. Der ist noch nicht reproduzierbar. Mal ist es nen halben Tag alles ok, dann geht wieder gar nichts, ich werde mal mehrere Aufnahmen starten und sehen, ob es daher kommt.

    Da man die meisten Programme im Hintergrund starten kann, hatte ich erst mal keine Probleme erwartet, da der VDR von systemd oder init ja auch als Hintergrundprozess benutzt wird - na ja zumindest früher gab es dafür ein eigenes Terminal.


    Die Frage zielte gerade darauf ab, ob das Flag -d genau dafür gedacht ist. Es schaltet kbdremote ab, aber ich kann nicht absehen, was es noch bewirkt.

    Welchen Sinn hat es denn einen Prozess im Hintergrund zu starten, wenn er von stdin lesen soll? Wenn das nur zum Testen ist und du noch andere Dinge in einer Shell erledigen willst, schalte auf ein anderes TTY oder nimm einen Terminal-Multiplexer wie tmux. Oder du schaltest die kbdremote ab, wenn du sie nicht benötigst.



    Das lässt sich aus der vdr.service Zeile 8 ableiten, worauf er wartet:

    Also muss der VDR mit Unterstützung für sd_notify kompiliert werden (vgl. https://projects.vdr-developer…/Make.config.template#n91 im Template für die Make.config) - wobei mir nicht klar ist, warum du nicht gleich die Quellen für das VDR-Paket nutzt, wenn du schon die Systemd-Unit daraus verwenden willst.

    Gar nicht, der VDR liest die Konfiguration selbstständig aus dem ARGSDIR - das sollte wie in der

    /usr/share/doc/vdr/README.Debian.gz bzw. https://www.yavdr.org/documentation/0.6/de/ch01s06.html beschrieben funktionieren.


    Gut das füllt schon mal Wissenslücken.

    Hatte schon mal kurz mit Klaus Schmidinger Kontakt wegen dem OSD, und er schlug vor, mit sauberen Sourcen anzufangen, da nicht klar ist, welche Patche beim Paket eingebaut wurden.


    Das mit den Parametern hatte ich vermutet, aber es zu Wissen ist doch gut. Allerdings frage ich mich, warum dann der vdr in der Konsole gestartet die Pfade alle aus den conf-Dateien nimmt, der "vdr &" aber nicht. Ist aber auch nicht wichtig...

    Hallo,

    ich bin dabei ein Problem beim vdr-osd bei mir zu suchen und brauche noch Nachhilfe.
    Habe bei mir ein Ubuntu 20.04 server frisch aufgesetzt und vdr-Paket und vdr-plugins installiert. Soweit so gut, läuft erst mal. Allerdings wird mein OSD zeitweise äusserst langsam, dazu versuche ich nun die Ursache zu suchen. Zuerst hatte ich eine sehr lange channels.conf mit Senderleichen im Verdacht, derzeit sind es eher threads, wenn aufgenommen wird. Mit vdr2.2.0 hab ich das noch nicht beobachtet, aber vielleicht muss ich länger beobachten....


    Hier mal die Fragen :

    vdr2.4.1 und plugins kann ich kompilieren und startet von konsole.

    wenn ich den vdr im Hintergrund starten will (vdr &), dann bleibt der hängen, wenn er kbdremote erzeugt.

    muss ich den vdr für diesen Fall als daemon aufrufen ?


    wenn ich den vdr von konsole starte stimmen alle Pfade.

    wenn ich vdr & starte (habe das kbdremote mal auskommentiert) stimmen die pfade nicht mehr (sucht /usr/share..)

    hat jemand eine Idee, warum das sich unterschiedlich verhält ?


    wenn ich den paket-vdr über systemd starte (z.b. service vdr start) ist alles ok.

    wenn ich den vdr unter /usr/bin durch meinen selbst kompiliert ersetze, dann startet "service vdr start" den vdr, wartet aber auf irgendwas und bricht dann mit timeout den vdr wieder ab.

    Nach meinem Verständnis wird dabei im service-skript ebenfalls nur /usr/bin/vdr aufgerufen.

    Wie übergibt das service-skript dem vdr die Parameter ?

    Anscheinend wird der vdr hier ebenfalls nicht als daemon aufgerufen, aber das Problem mit dem kbdremote taucht nicht auf...

    Was könnte der Grund für den Timeout sein (der vdr startet ja, so etwas wie ein PID-File konnte ich noch nicht finden) ?


    Fragen über Fragen ...

    Ich hoffe, dass jemand Ideen hat.



    Ach so - konkret ist mein Problem, dass das OSD (dvbsddevice) nicht mit dem Bildaufbau hinterherkommt und der vdr nahezu unbedienbar ist. So ein Bildaufbau kann schon mal 5 Sekunden brauchen - schön zeilenweise. Die Hauptschleife läuft dabei ohne Zeitverlust durch, will heißen wenn ich per Fernbedienung 4 Zeilen runtergehe, dann tut sich auf dem OSD erstmal nichts und nach dem nächsten Bildaufbau ist er 4 Zeilen tiefer.

    Manchmal ist aber auch alles wieder schnell. Manchmal ist das OSD nach dem vdr-start schnell, manchmal langsam. Ursache ist halt unklar. CPU-Last bei ca. 13%

    Soweit ich sehen konnte ist das dvbsddevice bei vdr2.2.0 und 2.4.1 identisch.


    Gruß,

    Stefan


    Hardware ist ein Celeron G3900 mit 2x dual receiver und 1x ff-Karte für das OSD und AUsgabe, Aufnahmen gehen auf Festplatte (Softwareraid).