Beiträge von xblades

  • TT S2-6400 - saa716x kompilieren unter 22.04

    Ich habe mir das mal genauer angesehen, da sich bei mir Abhängigkeiten zwischen CH0 und CH1 der TT6400 ergeben haben.

    Sie LNB-Steuersignale sahen alle gut aus, saubere 13,4V und 18,4V und 22kHz Signal sah gut aus.

    Wenn CH0 kaputt war, konnte ich mehrfach zwischen anderen Adaptern schalten und es blieb kaputt. Erst als ich CH1 der TT6400 neu getunt habe, war auch CH0 wieder ok. Das aber nicht immer konsistent. Habe mal probehalber den CH1 im VDR deaktiviert und werde mal beobachten, ob dann die Fehler nochmal auftauchen.

  • TT S2-6400 - saa716x kompilieren unter 22.04

    Hallo zusammen,

    ich habe mich mal an Debian 12 bookworm begeben, da ich wegen support das system jetzt nicht mehr auf 11 aufsetzen wollte.

    Natürlich war der Treiber SAA716x nicht drin. Habe daher kernel 6.5.7 gezogen https://mirrors.edge.kernel.or…l/v6.x/linux-6.5.7.tar.gz

    Und eine ältere source für den SAA716X benutzt (War irgendein SAA7165x_thorvalds), habe ich als zip angehängt. Dazu noch die letzten patches von hier eingebaut, angehängt sind die patche für 6.5.7 und die benutzen sourcen. Eingehängt habe ich den Treiber unter /driver/media/pci


    Das scheint soweit zu laufen, auch video snapshots. Aber ich habe auch Proleme, die ich so nicht zuordnen kann :

    Mein System : TT6400 als Adapter 0,1 2x DVBSKY S952 als Adapter 2,3,4,5 - Letzte verfügbare Firmware

    Manchmal habe ich nach dem Umschalten kein Bild (OSD geht), femon zeigt an, dass die Signal strength ok ist, aber signal to noise liegt bei 0. Das betrifft immer nur TT6400, manchmal ch0, manchmal ch1. Wenn ich bei femon durch die Adapter schalte sind die anderen ok, wenn ich wieder auf den defekten channel schalte ist dieser auch wieder ok. Ein paar recordings sind nicht erfolgt - das ist natürlich das Hauptproblem für den Haussegen.

    2 mal hatte ich gar kein Bild mehr, sondern nur OSD, das war aber nur mit Rechner Neustart zu beheben.

    Zuvor lief das System noch auf Debian 8, ab und zu auch mal kein Bild, aber keine recordings fehlgeschlagen.


    Daher hier mal meine die Fragen :

    Kennt das jemand ?

    Spinnt die Hardwrae ?

    Davor ist ein Multischalter (Quadro LNB -> 16) eventuell der - aber nur bei der TT6400 ?

    Kann mir mal jemand die SAA716x sourcen geben, die definitiv funktionieren ?

    Kann mal jemand über die Patche schauen - sehen für mich in Ordnung aus - dafür geht ja auch zuviel.

    Gruß,

    Stefan

  • Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    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.

  • [softhddevice-Plugin] „Ton läuft weg“ -

    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();


    }


    }

  • [gelöst] live plugin - keine icons

    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.

  • [gelöst] live plugin - keine icons

    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

  • Probleme dvb-ff 2.3 tuning to 12544

    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.

  • Probleme dvb-ff 2.3 tuning to 12544

    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.

  • Probleme dvb-ff 2.3 tuning to 12544

    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 :

  • Probleme dvb-ff 2.3 tuning to 12544

    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.

  • Probleme dvb-ff 2.3 tuning to 12544

    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

  • Probleme dvb-ff 2.3 tuning to 12544

    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


  • vdr selbst kompilert und systemd (gelöst)

    Zitat von seahawk1986

    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.

  • vdr selbst kompilert und systemd (gelöst)

    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.

    Zitat von seahawk1986

    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...

  • vdr selbst kompilert und systemd (gelöst)

    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).