Posts by Dr. Seltsam

  • softhddevice beim Start mit fullscreen - Menüleiste kurz sichtbar

    Ich starte vdr auf einem Ubuntu mit laufendem x-server und lightdm Windows manager (xfce). Mit der Option -f startet das Plugin ja im fullscreen-Modus. Ich habe eine bewusst einfache Installation gewählt und die runvdr einfach in den Autostart von xfce gelegt. So mache ich es seit Jahren. Früher (so um 2016) mit dem alten softhddevice-Plugin von johns und einer sogar schwächeren CPU habe ich beim Hochfahren nie etwas vom Desktop gesehen, es kam sofort das Fernsehbild. Dass aktuell (Ubuntu 20.10 mit softhddevice von lnj) der Desktop-Hintergrund noch kurz sichtbar ist, kann ich verschmerzen. Da ahbe ich mir jetzt ein vdr-Logo als Hintergrundbild eingerichtet. Dass man danach immer erst für etwa 1-2 Sekunden das softhddevice-Fenster mit Menüleiste sieht, ehe das Bild kommt und das Fenster wirklich fullscreen wird, nervt etwas. Ich habe schon mit der Ladereihenfolge der Plugins experimentiert, aber das ändert nichts. Auch ein Starten des Plugins im suspend-Mode mit resume nach vollständigem vdr-Start ändert nichts.

    Ich weiss, ich klage auf hohem Niveau :). Gibt es trotzdem irgendeinen Trick?

  • noch jemand der plötzlich mit Kodi Wiedergabeprobleme per NFS hat?

    Seit gestern Abend spielt mein Raspi 2 mit Libreelec plötzlich alle Filme nur noch mit grünen Artefakten ab. Ich glaubte schon an ein Hardwareproblem, aber es stellte sich heraus, dass das Problem nur bei Wiedergabe über NFS auftritt. Greife ich auf den gleichen Server per Samba zurück, ist wieder alles normal.


    Es gibt gleichartige Berichte seit Februar. Es scheint eine kernel regression zu geben, siehe auch hier. Mein Verdacht ist, dass Ubuntu den auslösenden commit zeitverzögert zurückportiert hat und er in dem Kernel 5.8.0-49-generic enthalten ist, der zufällig auch gestern bei einem update auf meinem Ubuntu 20.10-Server installiert wurde.

    Witzig ist, dass ich mit einem anderen Client (mein ubuntu-basierter VDR) über Kodi ohne Probleme vom NFS-Server wiedergeben konnte.


    Ich dachte, ich poste das mal hier, falls andere sich auch noch einen Wolf suchen...

  • Linux Desktop PC GraKa oder Board für UHD

    Die Preise haben tatsächlich angezogen. Ich habe meine erste GT1030 noch neu für 83,- und die zweite für den VDR gebraucht für 70,- erworben.


    Der fehlende Displayport bzw.das fehlende HDMI 2.0 war bei meinem Intel-Board das Problem, sonst hätte der i5-4570 wahrscheinlich gereicht und es wären 60 Hz möglich gewesen.

  • [osdteletext] 2.0.0 released

    Hilft auch bei mir. Kann sein, dass es damit schon wieder exakt auf dem vorherigen Niveau ist - muss ich nochmal weiter beobachten.

    Was für eine Message soll denn da bei einem Kanalwechsel angezeigt werden?? Und sollte das nicht besser nur dann erfolgen, wenn das Plugin auch aktiv ist (also nicht nur im Hintergrund läuft)?

  • aktuelle DVB-S2 Karte != USB

    Warum ist denn USB ein Ausschlusskriterium? Meine DVB-C-Sticks laufen besser als alle Steckkarten, die ich je hatte. Die Sticks sitzen direkt auf der Dose bzw. auf Verteilern und die Verbindung zum VDR erfolgt über ein ca. 1m langes USB-Kabel. Habe bei Sat jetzt nicht den Überblick, aber da gibt es doch bestimmt auch gute Empfänger.

  • Benötige Hilfe bei der Identifikation eines Elkos

    SMD-Elkos scheinen generell schneller zu altern. Ich ersetze sie inzwischen mit „normalen“ Elkos in Subminiatur-Ausführung und als 105 Grad Typ. Die Beine etwas abwinkeln, so dass sie auf die Kontaktfläche aufliegen und dann verlöten. Bin kein SMD-Lötheld und finde das viel einfacher.

  • [osdteletext] 2.0.0 released

    Ich hatte zuletzt vor etwa 2-3 Wochen zuletzt auf den damaligen git-Stand aktualisiert und heute nun die 2.0.0 installiert. Was ich nun aber bemerke ist, dass sich die Umschaltzeit deutlich erhöht hat, mindestens um 1 Sekunde. Ohne osdteletext ist die Umschaltzeit normal.

    Testweise habe ich die Änderung aus dem commit "clear teletext page on channel switch" entfernt, aber das hat nichts geändert.



    so sieht es ohne osdteletext aus:



    uns so zum Vergleich die Version 1.1.1


  • RPI 3B+: Kein Bild nach dem Umschalten

    Frage an alle: Ist die Umschaltgeschwindigkeit mit einer der letzten Änderungsvarianten denn wieder auf dem Niveau wie vor der Kerneländerung, oder immer noch etwas langsamer?

    Ich habe gestern mit dem aktuellen Raspian OS vdr + rpihddevice selbst kompiliert und mit dem iptv-Plugin auf meinem Raspi 2 ausprobiert. Es reicht anscheinend, nur m_omx zu deinitialisieren und neu zu initialisieren. Für m_audio ist es scheinbar nicht notwendig. Aber ich habe stets eine Umschaltgeschwindigkeit von über 2 Sekunden, meist sind es 3 oder 4. Kann aber auch an MagentaTV und dem langsamen LAN des Raspi 2 liegen. Mit einem Hauppauge DVB-C-USB Stick kriege ich keinen Empfang, liegt vielleicht daran, dass im Log was von Undervolting steht. Muss ich mit einem aktiven USB Hub nochmal probieren.

    zimuland : so führst Du SetVolumeDevice aber bei JEDEM Kanalwechsel durch, solange der Ton nicht gemutet ist. Ich würde da jede unnötige Aktion vermeiden. Es müsste möglich sein, das nur auszuführen, wenn der letzte Playmode zuvor 5 war.

  • softhd* und HW-Decoder mit i5-10400T

    oder hast Du Pay-TV in anderer Form (CAM mit Karte) laufen? Bei mir kommen die Meldungen nur auf verschlüsselten Sendern.


    Ich glaube nicht, dass die Art der Dekodierung Einfluss auf die Bildqualität hat. Mein Intel-Board (J4105) hatte HW-Dekodierung, und dennoch war das Bild längst nicht so brilliant wie bei der GT1030. Deswegen habe ich das Board vor kurzem wieder verkauft.

  • softhd* und HW-Decoder mit i5-10400T

    nobanzai wrote:

    nachdem mein neuer VDR mit der NVidia-Karte im Groben (bis auf die immer wieder auftauchende Meldung "video/vdpau: can't render mixer: An invalid handle value was provided.") läuft

    Da brauchst Du Dir keine Sorgen machen. Ich vermute, Du hast das dvbapi-Plugin laufen? Damit kommen diese Meldungen. lnj hatte kürzlich geschrieben, dass er darüber nachdenkt, die Meldung im softhddevice-Plugin zu unterdrücken.


    Was mich interessieren würde: Nachdem Du die Intel-Karte ja zumindest schon mit SW-Dekodierung laufen hattest - wie beurteilst Du denn die Bildqualität im Vergleich zur Nvidia? Welche Nvidia-Karte hast Du?

  • RPI 3B+: Kein Bild nach dem Umschalten

    Also sieht das neu so aus:

    Quote

    Beim Start des Plugins wird SetPlayMode() zurerst mit 0 (pmNone)

    ... dabei wird auch m_playmode auf pmNone gesetzt


    Quote

    und danach mit 5 (pmExtern_THIS_SHOULD_BE_AVOIDED) aufgerufen.

    ich finde keine Stelle im Plugin, wo dabei auch m_playmode auf 5 gesetzt wird!

    Quote

    Beim Beenden des Plugins folgt dann wieder ein Aufruf mit 0 (pmNone).

    Dass Deine Änderung ein erneutes Ausführen des Codes in pmNone verhindert, liegt nur daran, dass m_playmode zu diesem Zeitpunkt immer noch 0 und nicht 5 ist, was m.E. ein Bug im Code ist: Das m_playMode = pmNone; gehört m.E. ans Ende vor return true;, damit alle Playmode-Änderungen erfasst werden. Warum reufer das nur für den case pmNone vorgesehen hatte - keine Ahnung.


    Das TV-Bild kommt nach dem Beenden des mplayer-Plugins trotzdem normal zurückt? Das ist interessant: Nach einem Kanalwechsel im Plugin selbst will die Hardware neu initialisiert werden, aber nach Verwendung des externen omxplayers ist das nicht nötig!


    Im rpihddevice-Plugin ist derzeit überhaupt keine Handhabung für den Playmode pmExtern_THIS_SHOULD_BE_AVOIDED implementiert. Da der externe omxplayer bei laufendem Plugin funktioniert, hat das rpihddevice-Plugin anscheinend keinen exklusiven Zugriff auf die Hardware. Der omxplayer kann nun aber Initialisierungen an der Hardware durchführen, die das Plugin gar nicht mitkriegt. Deshalb wäre es schon besser, wenn das Plugin nach Rückkehr vom omxplayer re-initialisiert würde.


    Zu Deinem Problem: Die clock wird in m_omx->DeInit() zerstört und erst in m_omx->Init() wieder erzeugt. Nach dem ersten pmNone (vor dem Aufruf des mplayer-Plugins) ist die clock also schon weg. Wenn dann nach Rückkehr vom mplayer-Plugin erneut pmNone aufgerufen wird und über FlushStreams m_omx->StopClock(); und m_omx->ResetClock();aufgerufen werden, crasht es.


    Probier doch mal folgendes:


    Das Resetten findet hier also komplett in pmNone statt und damit auch bei jedem Kanalwechsel. Keine Ahnung, ob das Umschaltproblem damit auch gelöst ist und ob es Einfluss auf die Umschaltdauer hat. ich habe hier übrigens SetVolumeDevice(CurrentVolume()); rausgelassen, denn der Sinn im ursprünglichen Patch erschließt sich mir nicht. Es würde ja dazu führen, dass ein vorher stumm gemuteter vdr beim Kanalwechsel wieder laut wird.


    Bitte testen!