[Prototyp] RPI Ausgabeplugin

  • Hallo Reufer,


    - vdr-2.0.6
    - rpihddevice git von heute


    mit queue_mutex.diff und der Makefile Anpassung, führten leider nicht zum Erfolg.



    Habe weder Ton, Bildausgabe oder osd Anzeige.


    Im Syslog steht nur:


    epg data reader thread ended (pid=2484, tid=2489)




    Getestet mit:


    gcc version 4.7.2 (Debian 4.7.2-5+rpi1)



    MfG
    bobmeier

  • reufer:


    Hatte es grad wieder (Hangup beim beenden einer Wiedergabe):


    Diesmal konnte ich folgende beobachten:



    Nach dem Beenden war der TON komplett weg (sowohl Live als auch bei dem versuch einer erneuten Wiedergabe).
    Auch das Bild "ruckelte komisch".


    Ich habe daraufhin eine weitere Wiedergabe gestartet woraufhin sich beim Beenden der VDR dann wieder "aufhing":



    VDR läuft noch:


    Code
    root@raspberrypi:/vdr/VDR216_2# ps -a
      PID TTY          TIME CMD
     9033 pts/2    00:00:00 screen
    10022 pts/3    00:00:00 svdr
    10023 pts/3    02:44:26 vdr
    10520 pts/0    00:00:00 ps


    Hat aber kaum CPU Last:

    Code
    PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
    10023 root      20   0  244m  77m 1992 S   0,7 31,4 164:26.70 vdr

    (0,7%)


    Wie gesagt - der RPI läuft bei mir 24/7 durch - Live habe ich eigentlich keinerlei solcher "hänger" dass Streamdev ab und dann mal bei Zappen schwarz bleibgt hab ich ich einem anderen Thread schon mal geschrieben - ist evtl auch sache von Streamdev.


    Das ist jetzt eigentlich der einzige Hänger den ic hier mit dem Plugin +VDR auf dem RPI habe ....


    Muß nochmals betonen wie "cool" VDR auf dem RPI ist wenn man das Verhältnis von Hardware zu einem System mit VDPAU ist - (bevor jetzt wieder jemand mit dem Leistungs-Thema anfängt - das ist mir bewusst...)


    CU
    GTR

  • reufer


    Nachtrag - gerade eben noch ein Absturz nach dem gleichen Schema - während der Wiedergabe traten "fehlermeldungen" im Lug auf - es kommt aber zu keinen Bild oder Audio Störungen.


    Beendet man dann die Wiedergabe hängt sich der VDR auf.



    cu GTR

  • Hallo reufer,


    Viele auslaendische Sender die ich brauche senden noch in 4:3, gibt es eine moeglichkeit 4:3 Material in 16:9 anzuzeigen ?
    Bei xineliboutput gab es eine einstellung anamorphic, damit war das bild auch nicht verzerrt. Planst du sowas auch einzufuehren ?


    Gruss,


    Franz

  • Hallo francescosoft


    ich habe das Problem vor allem bei "alten Aufzeichnungen im 4:3" Format.
    Wenn ich dich richtig verstehe möchteste du dass auch die4:3 Sendungen in 16:9 gestretched werden ?


    Dafür gibts nen Patch - wobei da eigentlich nur in der omxplayer.c (aus dem Kopf jetzt) ein False in ein True geändert werden muss...


    Gibt nen Post hier zu dem Thema.


    CU
    GTR

  • Danke GTRDRIVER,


    Ich werde den Patch mal suchen. Gibt es denn plaene die Einstellung ins Menu zu uebernehmen ?
    Ist das ein einfaches stretch oder anamorphic ?
    Uebrigens die Probleme die du weiter oben beschrieben hast habe ich auch bei Live TV bei gewissen Sender ueber die mann hier nicht sprechen darf die manchmal kleine aussetzer haben.


    Gruss,


    Franz

  • Hi GTR

    Nachtrag - gerade eben noch ein Absturz nach dem gleichen Schema - während der Wiedergabe traten "fehlermeldungen" im Lug auf - es kommt aber zu keinen Bild oder Audio Störungen.


    Beendet man dann die Wiedergabe hängt sich der VDR auf.

    Danke für den Hinweis - das Log ist in dem Fall sehr hilfreich... kommt auf meine ToDo-Liste!


    Gruss
    Thomas

  • Hi Franz

    Gibt es denn plaene die Einstellung ins Menu zu uebernehmen ?
    Ist das ein einfaches stretch oder anamorphic ?

    Ja, die gibt es. Kommt bald rein, es werden drei Modi sein: Letter/Pillarbox, Center Cut Out und Auto Fill. Bei der Terminologie bin ich mir noch nicht 100% sicher, aber ich denke, die Funktion sollte klar sein.


    Gruss
    Thomas

  • Also, ich hab mir nun extra ein Raspbian aufgesetzt und mir gcc-4.8 nach diesem How-To installiert:

    Code
    pi@raspberrypi /usr/src/vdr $ gcc --version
    gcc (Raspbian 4.8.2-16) 4.8.2
    Copyright (C) 2013 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


    VDR und rpihddevice sind aus dem Git:


    Wenn ich VDR starte...

    Code
    pi@raspberrypi /usr/src/vdr $ ./vdr -P rpihddevice -P streamdev-client -P "remote --port=tcp:3333"


    ... hab ich sofort Bild.


    Frage: Was mache ich falsch? ?(


    Gruss
    Thomas

  • Hallo Thomas,


    offenbar liegt es nicht nur an der gcc Version. Ich verwende ein komplettes Rasbian "Jessie". Das hat doch auch aktualisierte glibc, libc++, libstdc++ !?!


    Kernel und FW entsprechend dem aktuellen Stand im github per rpi-update.


    Gruß, ollo

  • offenbar liegt es nicht nur an der gcc Version. Ich verwende ein komplettes Rasbian "Jessie". Das hat doch auch aktualisierte glibc, libc++, libstdc++ !?!


    Kernel und FW entsprechend dem aktuellen Stand im github per rpi-update.


    Kernel und Firmware habe ich gestern mittels rpi-update aktualisiert. Wenn du mir sagst, wie ich zu einem "Jessie" komme, versuch ich das bei mir auch...


    Gruss
    Thomas

  • reufer


    Auch wenn der Link schon 2 Monate alt ist, vermute ich mal das es genauso funktioniert: http://menzerath.eu/artikel/ra…n-8-jessie-aktualisieren/


    Gruss


    Macavity


    P.S.: Warum mir jedoch immer kein Grund einfällt, warum man immer bei Debian im Testing-Zweig "rumwühlen" muss. Es gibt "Stable" - und das hat meist einen Grund. :D

    Capulet:
    HW: Dell Dimension 3100, Pentium 4 3GHz, 2GB RAM, 160GB HDD (System), 1TB HDD (Video), 1 x TT S2-1600, 1 x Technisat Skystar HD | SW: Debian 7.4, VDR 2.0.4 (selfcompiled), dummydevice 2.0.0, streamdev-server 0.6.1, NFS-Server


    TiViPi01:
    HW: Raspberry Pi Mod. B Rev. 2, 512MB RAM, 8GB SD-Card, Teko TEK-BERRY.9 Gehäuse, Ednet 85024 USB 2.0 Hub, Digitainer X10 Funk-Fernbedienung | SW: Raspbian 01/2014, VDR 2.0.4 (selfcompiled), rpihddevice 0.0.8, ffmpeg 1.0.8, streamdev-client 0.6.1, NFS-Client

  • Auch wenn der Link schon 2 Monate alt ist, vermute ich mal das es genauso funktioniert: http://menzerath.eu/artikel/raspberry-pi…-aktualisieren/


    Danke für den Link. Hab ich nun gemacht:

    Code
    pi@raspberrypi /usr/src/vdr $ cat /etc/apt/sources.list
    deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
    deb-src http://archive.raspbian.org/raspbian jessie main contrib non-free rpi


    und:


    Scheint also schon alles auf dem neusten Stand zu sein...

    P.S.: Warum mir jedoch immer kein Grund einfällt, warum man immer bei Debian im Testing-Zweig "rumwühlen" muss. Es gibt "Stable" - und das hat meist einen Grund. :D


    Sehe ich auch so...


    Gruss
    Thomas

  • Sehe ich auch so...


    Vielleicht sollte man sich auf eine Version verständigen.


    Bugfixing für unstable/testing halte ich persönlich (während der Entwicklung) für Resourceverschwendung.


    Gruss


    Macavity

    Capulet:
    HW: Dell Dimension 3100, Pentium 4 3GHz, 2GB RAM, 160GB HDD (System), 1TB HDD (Video), 1 x TT S2-1600, 1 x Technisat Skystar HD | SW: Debian 7.4, VDR 2.0.4 (selfcompiled), dummydevice 2.0.0, streamdev-server 0.6.1, NFS-Server


    TiViPi01:
    HW: Raspberry Pi Mod. B Rev. 2, 512MB RAM, 8GB SD-Card, Teko TEK-BERRY.9 Gehäuse, Ednet 85024 USB 2.0 Hub, Digitainer X10 Funk-Fernbedienung | SW: Raspbian 01/2014, VDR 2.0.4 (selfcompiled), rpihddevice 0.0.8, ffmpeg 1.0.8, streamdev-client 0.6.1, NFS-Client

  • Vielleicht sollte man sich auf eine Version verständigen.


    Bugfixing für unstable/testing halte ich persönlich (während der Entwicklung) für Resourceverschwendung.


    Einerseits ja, anderseits hat mich in der Vergangenheit noch jeder Fehler irgendwann mal eingeholt, auch wenn ich ihn zuvor ignoriert habe. Daher würde ich den Effekt mit dem Patch von djdagobert schon gerne verstehen... Die Wahrscheinlichkeit, dass ich was unerlaubtes tue, ist um ein vielfaches höher, als dass in gcc, libc, etc. noch ein Fehler steckt, der gerade mir als erstes auffällt.


    Gruss
    Thomas

  • Hi,


    vielleicht verwendet Ihr unterschiedliche Optimierungs- und Debugsymbol- Einstellungen, was die nicht reproduzierbarkeit erklären könnte.


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Hi ollo

    kannst Du das Problem nun nachvollziehen? Ich verwende ebenfalls die Sourcen direkt und ohne weitere Optimierungen.

    Nein. Aber mein Ersatz-Pi läuft nun mit Raspbian ab DVB-T seit gut 24h durch: 1x Buffer stall (ohne Folgen) und 1x ein korruptes Audio-Frame (ebenfalls ohne Folgen).


    Gruss
    Thomas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!