[Prototyp] RPI Ausgabeplugin

  • Ja gelb und grün wenn konfiguriert

    #S1: Gigabyte GA-H77M-D3H, Intel 1610 Celeron, 4GB RAM, Cine S2 6.5 + Duoflex S4, NVIDIA GT 630, IBM SSD 240GB, Atric IR Einschalter, DVD-Brenner mit easyvdr 3 oder MLD5
    #S2 (offline) POV MB-D510-MATX, 2GB, GT 220, TT 1600
    #C1: RPi3 MLD5.1

  • Quote

    Genau das macht doch die Sprungtaste. Bei mir springen die Farbtasten um je eine Minute vor bzw zurück.

    decembersoul
    Danke. Da benutze ich den VDR schon solange, aber diese Funktion ist an mir vorbeigegangen. Mit meiner FF war ich ja mit dem schnellen Vorlauf sehr zufrieden, da habe ich gar nicht nach einer alternativen Methode gesucht.

  • reufer,

    nutze das plug/den rpi nun seit Anfang des Jahres produktiv (RPI übertaktet 1100Mhz, skinnopacity, streamdev-client, epg2vdr,externalplayer..) im Wohnzimmer.
    Auch hier war das Problem mit Das Erste HD, zeitweise (zufällig) andere 720pHD Sender, signifikant - mit der Git Änderung von gestern, konnten bisher keine Hänger mehr beobachtet werden.
    Feststellen konnte ich auf ARD kurze Audio-Plops - allerdings im erträglichen Rahmen.
    Denke Du bist absolut auf dem richtigen Weg.

    PS: Seit einiger Zeit sehe ich allerdings kein OSD mehr, wenn ich von XBMC zurück zum VDR gehe (externalplayer) - XBMX 13.0 test builds - allerdings muss das mit XBMC bzw. der RPI Firmware (aktuell) zusammhängen. Vielleicht hat ja jemand ähnliches beobachtet..?

    Gruss

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC

    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • nutze das plug/den rpi nun seit Anfang des Jahres produktiv (RPI übertaktet 1100Mhz, skinnopacity, streamdev-client, epg2vdr,externalplayer..) im Wohnzimmer.
    Auch hier war das Problem mit Das Erste HD, zeitweise (zufällig) andere 720pHD Sender, signifikant - mit der Git Änderung von gestern, konnten bisher keine Hänger mehr beobachtet werden.
    Feststellen konnte ich auf ARD kurze Audio-Plops - allerdings im erträglichen Rahmen.
    Denke Du bist absolut auf dem richtigen Weg.

    Danke für das Feedback! Hast du es mal ohne Übertakten versucht? Der Audio-Render des Rpi stellt nähmlich auf stumm, sobald die Geschwindigkeit ungleich "normal" ist. Das eine Prozent schneller oder langsamer, das bei der Taktnachführung korrigiert wird, liegt scheinbar noch innerhalb der Toleranz. Vielleicht gibt das beim Übertakten Probleme...

    Gruss
    Thomas

  • Hi

    Ja, hab ich getestet und funktioniert:

    Gruss
    Thomas


    Hi Thomas.

    Ist zwar aktuell noch unwichtig, aber trotzdem die Info:
    Habe diesen Patch aktiviert. Wenn beim Start des VDR ein Kanal eingestellt ist der aktuell ein 4:3 Bild ausgibt, dann habe ich links und rechts weiterhin die schwarzen Balken. Wenn ich kurz vor-/zurück Zappe sind die Balken weg.
    Wie gesagt, nur schonmal für den Hinterkopf ;)

    Gruß Patrick

    [size=8]* Meine NeverEndingProjects ;) *

    Meine VDR's

    1x Dell Optiplex GX620 VDR 2.2.0 / 4x DVB-S2 (DD Cine S2 Flex) / 1x Sundtek DVB S2 USB auf Debian Jessie als Headless-Streaming-Server
    4x RaspberryPi1/2/3 VDR 2.2.0 / rpihddevice-Frontend und KODI auf Raspbian Jessie eigenkonstruktion als Mediacenter und Streaming-Client


    vectra --- glasslike ---

  • Hallo vectra

    Bei sd oder hd aufnahmem ?
    Ich hab das schon ne weile aktiv und das bei sd noch nie gehabt.

    Cu
    Gtr

    Ps. Ich hab seit dem update auf die letzte version aus dem git immer wieder segfaults

    Gesendet von meinem GT-I9505 mit Tapatalk

  • Nutze aktuell nur SD

    Segfaults kann ich nicht bestätigen

    Gruß Patrick

    [size=8]* Meine NeverEndingProjects ;) *

    Meine VDR's

    1x Dell Optiplex GX620 VDR 2.2.0 / 4x DVB-S2 (DD Cine S2 Flex) / 1x Sundtek DVB S2 USB auf Debian Jessie als Headless-Streaming-Server
    4x RaspberryPi1/2/3 VDR 2.2.0 / rpihddevice-Frontend und KODI auf Raspbian Jessie eigenkonstruktion als Mediacenter und Streaming-Client


    vectra --- glasslike ---

  • Habe diesen Patch aktiviert. Wenn beim Start des VDR ein Kanal eingestellt ist der aktuell ein 4:3 Bild ausgibt, dann habe ich links und rechts weiterhin die schwarzen Balken. Wenn ich kurz vor-/zurück Zappe sind die Balken weg.

    Das kann gut sein. Wenn im VDR-DVB-Setup 4:3 als Ausgabeformat konfiguriert ist, scheint der VDR SetVideoDisplayFormat() bei 4:3-Material nicht aufzurufen. Man müsste deshalb das noaspect-Flag schon beim Initialisieren setzen.

    Allerdings habe ich nicht vor, das zu implementieren, da für mich das Verziehen von Video-Material eigentlich ein no-go ist…

    Gruss
    Thomas

  • Hallo Reufer

    wie gesagt - hatte ich auch vorher ab und dann mal - aber eigentlich kaum noch.

    Hab das Plugin gestern neu aus dem aktuellen CVS gebaut - läuft ansich wesentlich besser - vor allem HD läuft nun sehr gut - nur eben von Zeit zu Zeit "segfaults"

    Ganz aktuell grad:

    Code
    [mp3 @ 0x10fe000] Header missing
    [ac3 @ 0x1109bc0] frame CRC mismatch
    [mp3 @ 0x10fe000] Header missing
    Segmentation fault

    Im Syslog steht dazu:

    Du schreibst "core dump" - - ich würde gerne helfen - wenn du mir sagst wie ?!?

    CU
    GTR

  • Du schreibst "core dump" - - ich würde gerne helfen - wenn du mir sagst wie ?!?


    Installier dir gdb, dann startest du den VDR mal von Hand so:

    Code
    ulimit -c unlimited
    gdb --args vdr -P rphihddevice [restliche Plugins und Argumente]
    run


    Sobald er crasht lässt du dir in gdb den Backtrace anzeigen:

    Code
    bt
    bt full
    Meine VDRs

    VDR 1: Point of View Ion-330-1, 2x Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, Ubuntu 18.04 (yavdr-ansible)
    VDR 2: Acer Revo 3610, Pinnacle PCTV SAT 452e, Medion X10, yaVDR 0.6
    VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce GT 1030, Ubuntu 18.04 (yavdr-ansible), VDR 2.4.1, CIR-Empfänger
    Client 1: Raspberry Pi 2, Arch Linux ARM, VDR 2.3.8
    vdr-epg-daemon auf Cubietruck mit 32 GB SSD, Arch Linux ARM

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Edited once, last by seahawk1986 (March 2, 2014 at 3:49 PM).

  • Hallo Reufer

    Quote

    Allerdings habe ich nicht vor, das zu implementieren, da für mich das Verziehen von Video-Material eigentlich ein no-go ist…

    Das ist Ansichtssache. Ich nutze VDR seit dem 15.07.2000 und von Anfang an mit einem 16:9 Fernseher.
    Da damals das Material noch zu ca. 50% in 4:3 gesendet wurde, nervten mich damals die "schwarzen Balken" so dass ich von Anfang an das Material "gestreckt" auf dem TV ausgegeben habe.
    Immer wieder sagten Bekannte "warum haben bei dir die Leute solche "Eierköpfe" - aber das ist einfach "Gewohnheitssache".

    Noch immer stören mich die schwarzen Balken bei 4:3 Material - auch zu Zeiten von HDMI und HD...

    Daher empfinde ich es als Entscheidung jedes Einzelnen ob er diese Option nutzen möchte oder nicht und ich bin mir sicher es gibt auch noch viele andere es so denken wie ich - genau so viele denken auch ander - aber allen kann man es eben nie recht machen ...

    Daher mein Rat: so lange man das im Source selbst anpassen kann, kann ich (und sicher auch viele) Andere damit gut leben - für die, die sich nicht zutrauen an den Sourcen was zu ändern bleibt diese Möglichkeit natürlich verschlossen.

    Zum Thema Audio "Pops":

    Quote

    Danke für das Feedback! Hast du es mal ohne Übertakten versucht? Der Audio-Render des Rpi stellt nähmlich auf stumm, sobald die Geschwindigkeit ungleich "normal" ist. Das eine Prozent schneller oder langsamer, das bei der Taktnachführung korrigiert wird, liegt scheinbar noch innerhalb der Toleranz. Vielleicht gibt das beim Übertakten Probleme..

    Ich habe das auch immer wieder - vor allem wenn ein Sender länger läuft - und vor allem bei SD Sendern (aktuell N24).

    Es ist ein UK RPI ohne jegliche Übertaktung also out of the BOX. - FFMPEG aus den RPI RESP - nicht von source -

    Im Syslog ist nix zu sehen.

    Soweit ich das bisher beobachten konnte tritt das nur bei LIVE TV und nicht bei Aufnahmen auf.

    Update 18;37

    Es liegt an der eingesetzten VDR Version !
    Habe grad auf die 2.0.4 zurückgeschaltet und siehe da - ich höre keine "Plops" mehr ....

    Das ist einerseits gut da damit klar ist wo es herkommt andererseits schlecht, da VDR DEVEL (2.1.14) in bezug auf "große Aufnahme Verzeichnisse" wesentlich stabiler läuft !


    CU
    GTR

    Edited 3 times, last by GTRDRIVER (March 2, 2014 at 6:40 PM).

  • Hi GTR

    Daher mein Rat: so lange man das im Source selbst anpassen kann, kann ich (und sicher auch viele) Andere damit gut leben - für die, die sich nicht zutrauen an den Sourcen was zu ändern bleibt diese Möglichkeit natürlich verschlossen.

    Mein Plan ist, das Setup-Menü des Plugins möglichst schmal zu halten und die Einstellungen des VDRs zu nutzen. Sobald im DVB-Setup nebst "Letterbox" und "CenterCutOut" auch sowas wie "Auto Fill" zur Auswahl steht, werde ich das selbstverständlich übernehmen. In dem Zusammenhang stehe ich auch mit Klaus in Kontakt und er ist prinzipiell bereit, das API entsprechend zu erweitern.

    Bis dahin möchte ich einfach auf eine entsprechende Option im rpihddevice-Setup verzichten - das ist bitte nicht als Arroganz zu verstehen.

    Gruss
    Thomas

    Edited once, last by reufer (March 2, 2014 at 7:46 PM).

  • Zum Thema Audio "Pops":
    Zitat
    Danke für das Feedback! Hast du es mal ohne Übertakten versucht? Der Audio-Render des Rpi stellt nähmlich auf stumm, sobald die Geschwindigkeit ungleich "normal" ist. Das eine Prozent schneller oder langsamer, das bei der Taktnachführung korrigiert wird, liegt scheinbar noch innerhalb der Toleranz. Vielleicht gibt das beim Übertakten Probleme..


    Ich habe das auch immer wieder - vor allem wenn ein Sender länger läuft - und vor allem bei SD Sendern (aktuell N24).


    Es gibt aktuell noch ein Problem mit der Variable, welche die Anzahl freier Buffer nachführt - es gehen Buffer "verloren", was wahrscheinlich am fehlenden Mutex-Schutz bei cOmx::OnBufferEmpty() liegt. Sprich, die Variable ist plötzlich 0, obwohl noch freie Buffer verfügbar wären. Das kann momentan dazu führen, dass bei längerem Live-TV auf dem selben Kanal plötzlich wieder "TS packet not accepted"-Meldungen im Log auftauchen. Ich arbeite an einer Lösung…

    Gruss
    Thomas


  • Darf ich fragen, bei welchem Sender das passiert? Die 24kHz kommen mir komisch vor, könnte sein, dass sich der Audio-Parser irgendwie verrennt…

    Allerdings sehe ich bei einem Decodier-Fehler ("rpihddevice: failed to decode audio frame!") keine potentielle Absturzstelle. Ein Dump, wie von seahawk beschrieben, würde hier schon helfen.

    Gruss
    Thomas

  • reufer:

    Das war NATGeo.

    Danke auch für deine zahlreichen Rückmeldungen.

    Was mich ein wenig irrigiert ist, dass die Audio Drops unter der aktuellen VDR DEVEL Version auftreten...

    CU
    GTR

    Kannst du mir mal eine Aufnahme zur Verfügung stellen, die bei dir zu den genannten Problemen führt? Das würde mir die Fehlersuche erleichtern…

    Gruss
    Thomas

  • Hallo Reufer

    ich kann dir gerne ne Aufnahme von dem Sender zukommen lassen.
    Ob du das dann reproduzieren kannst kann ich jedoch nicht sagen !

    CU

    Also die erste Frage wäre, ob sich der Fehler nur bei Live-TV oder auch bei Aufnahmen zeigt. So wie ich dein Problem beurteile, sollte der Fehler auch beim Abspielen auftreten. Und wenn er das bei dir tut, dann wird das hoffentlich auch bei mir der Fall sein… ;)

    Gruss
    Thomas

  • Hallo Reufer

    ich versuch jetzt mal das ganze zu reproduzieren - wenn mir das gelingt - dann mache ich ne Aufzeichnung und lasse dir diese zukommen.

    Hast du eine Idee warum das Plugin mit der DEV Version des VDR nicht zurecht kommt (oder umgekehrt) ?

    CU
    GTR

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!