[Prototyp] RPI Ausgabeplugin

    Ich habe eine Mystique SaTiX-S2 Sky USB am RPI. Die funktioniert unter OpenELEC mit TVHeadend recht problemlos.
    Unter MLD 3.0.1 wird sie anscheinend als DVB-Interface erkannt, ich habe ihr aber kein Bild entlocken können. Lange habe ich mich damit aber nicht beschäftigt und habe dann auf streamdev zu meinem Server umgestellt. Kann gerne heute Abend oder am WE die Logs mal durchgehen, ob dort etwas von Interesse drin steht.


    Grüße

    Server: MB-D510-MATX, 1GB RAM, DVBSKy S952 Dual, System: 8GB CF mit yavdr 0.5, Daten: 2x 1,5 TB Samsung HD154UI
    Client: SMT 7020s mit zen2mms 1.1 auf 80 GB Platte an Philips 32" LCD
    HD VDR 1: Asus M3N78-EM in Slimgehäuse, Athlon LE 1600, 2 GB RAM, 80GB HD, yavdr 0.5 an Samsung LE32A430
    HD VDR 2: ECS H55H-I in Slimgehäuse, i3 540, 4GB RAM, ATI 5570,     512MB USB Stick mit OpenELEC PVR, 320 GB HD für sonstiges an Philips PFL 32-8404h


    Hallo zusammen


    ich beobachte seit gestern Hänger beim beenden einer Wiedergabe.


    Es kommt hier ab und dann vor (nicht wirklich reproduzierbar - aber heute Abend 4x) - dann ich beim beenden der Wiedergabe mittels "back Taste" nur noch ein schwarzes Bild bekomme.


    Im Syslog ist dann zu finden:



    Vdr läuft noch:


    Code
    2425 pts/0    00:40:02 vdr


    Tut aber nicht wirklich viel:

    Code
    KiB Swap:   102396 total,        0 used,   102396 free,    13064 cached


  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
 2722 root      20   0  4668 1376 1028 R   1,0  1,1   0:00.20 top
    3 root      20   0     0    0    0 S   0,3  0,0   1:50.64 ksoftirqd/0
 2425 root      20   0  230m  64m 1692 S   0,3 53,8  40:02.46 vdr
    1 root      20   0  2144  352  248 S   0,0  0,3   0:02.35 init
    2 root      20   0     0    0    0 S   0,0  0,0   0:00.01 kthreadd


    Es hilft dann nur den VDR manuell zu beenden und neu zu starten.


    CU
    GTR

    Mit der MLD für RPI gibt's seit ein paar Tagen ein Problem. Da ist irgendwas beim bauen schief gegangen. Jedenfalls stürtzt der VDR immer wieder nach einigen Sekunden ab.
    Da das Kompilieren für den RPI recht langwierig ist, wird es frühstens Morgen Abend nen neues Image geben. Ob das dann wieder funktioniert muss sich zeigen. Schlimmstenfalls werde ich einen kompletten Rebuild anstoßen damit wieder alles zuverlässig zueinander passt, was dann aber noch einmal zwei Tage dauern wird.


    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

    Zitat von ollo

    ich habe gerade den aktuellen Stand vom GIT ausprobiert. Den Fix von djdagobert brauche ich aber immernoch. Ich verwende hier gcc-4.8.2.


    Hmm. Das kommt mir wirklich komisch vor! Könntest du mal testen, bei welchem Commit der Fehler "eingeführt" wurde? Ich selber benutze gcc-4.6.3 …


    Gruss
    Thomas

    Zitat von reibuehl

    Welche USB DVB-S2 kann man den für MLD auf dem Raspberry PI empfehlen?


    Wollte am we mal einen test mit meinen sticks fahren .. werde dann mal berichten...
    vg mentox

    Hi,


    ich konnte bisher den Grund für die Probleme bei der MLD noch nicht finden. Der VDR stürtzt seit einigen Tagen meistens direkt nach dem Start mit nem "Segmentation fault" ab. Aber nicht jedesmal. Sobald ich nen weiteres Plugin hinzu füge wird's noch instabieler. Nachdem ich den GPU Ram von 128 auf 196MB hoch gestellt habe waren die Abstürtze erst einmal weg. Bis hierhin hatte ich noch keine funktionierende Kanalliste installiert. Mit funktionierender Kanalliste stürtzt der VDR jedoch sofort nach dem Start wieder ab. Letzte Logmeldung ist dann "user.debug vdr: [4516] new device number 1". Wenn der VDR mal nicht sofort abstürtzt hat er eine Prozeslast von über 90%.
    Ich werd's morgen testweise noch mal mit ner Älteren Version des rpihddevice versuchen. Es könnte aber auch am VDR liegen, da ich während der letzten Woche zusammen mit dem rpihddevice auch den VDR auf Version 2.1.6 aktualisiert habe.


    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

    Einmal editiert, zuletzt von clausmuus ()

    Ich hab jetzt noch mal testweise die Version vom 16.3. genommen. Mit der funktioniert wieder alles problemlos. Ich werde gleich noch die Version vom 24.3. testen. Mal schauen ob die auch noch geht.


    EDIT: die Version vom 24.3. funktioniert auch schon nicht mehr. Der VDR startet zwar noch, nen Bild gibt's aber nicht, lediglich das OSD wird angezeigt. Danach steigt die Prozessor lasst immer weiter an, bis der VDR abstürtzt.


    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

    Hallo zusammen

    Zitat von clausmuus

    Ich hab jetzt noch mal testweise die Version vom 16.3. genommen. Mit der funktioniert wieder alles problemlos. Ich werde gleich noch die Version vom 24.3. testen. Mal schauen ob die auch noch geht.

    Danke, Claus, für das Feedback. Ich habe immer noch keine Erklärung für das Verhalten, geschweige denn für den vermeintlichen Fix von djdagobert - das macht zur Zeit für mich keinen Sinn. Was ich derzeit weiss:


    - Soweit mir bekannt, nutzen alle, bei denen die Probleme auftreten, gcc Version 4.8.2 - selber kann ich das nicht testen, da diese Version für arm unter Gentoo maskiert ist
    - mit gcc-4.6.3 kann ich das Problem nicht nachstellen
    - Das Plugin scheint hier festzuhängen:

    Code
    while (!m_ptsQueue.empty())
{
	delete m_ptsQueue.front();
	m_ptsQueue.pop();
}


    - gleichzeitig steht in den release notes zu gcc-4.8 folgendes:

    Zitat

    On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules for the layout of vectors that could lead to wrong code being generated. Vectors larger than 8 bytes in size are now by default aligned to an 8-byte boundary. This is an ABI change: code that makes explicit use of vector types may be incompatible with binary objects built with older versions of GCC. Auto-vectorized code is not affected by this change.

    Frage an die Kompilerexperten: Was will mir dieser Absatz denn genau sagen? Queues wie ich sie verwende, sind in meinen Augen ja nichts anderes als Vektoren. Könnte das zu Problemen führen, wenn das Plugin mit gcc-4.8 und der vdr mit einer vorherigen Version kompiliert wurden?


    Ok, die Chance, dass ich Käse zusammencodiert habe ist recht gross - trotzdem trägt dieser Hinweis nicht gerade zu meinem Verständnis bei…


    Gruss
    Thomas

    Ich hab bisher gcc 4.7 verwendet. Aufgrund Deiner Vermutung habe ich also das Plugin mit gcc 4.6 Kompiliert. Und was soll ich sage, es hilft. Mit gcc 4.6 funktioniert auch die neuste Version des Plugins.


    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

    reufer und natürlich auch alle andern.


    Ich habe hier schon mal gepostet dass es hier manchmal beim beenden der Aufnahme zum "aufhängen" des VDR kommt.
    Nach nun 2 Tagen Tests kann ich das ganze zwar eingrenzen - aber nicht 100% reproduzieren.


    Normal schaut das Beenden einer Aufnahme im Syslog so aus:


    Code
    Mar 30 12:19:03 raspberrypi vdr: [4662] non blocking file reader thread ended (pid=4605, tid=4662)
Mar 30 12:19:03 raspberrypi vdr: [4661] dvbplayer thread ended (pid=4605, tid=4661)
Mar 30 12:19:05 raspberrypi vdr: [4605] switching to channel 45
Mar 30 12:19:05 raspberrypi vdr: [4663] receiver on device 1 thread started (pid=4605, tid=4663, prio=high)
Mar 30 12:19:05 raspberrypi vdr: [4664] TS buffer on device 1 thread started (pid=4605, tid=4664, prio=high)
Mar 30 12:19:08 raspberrypi vdr: [4663] rpihddevice: set video codec to MPEG2
Mar 30 12:19:08 raspberrypi vdr: [4616] rpihddevice: decoding video 720x576i, enabling deinterlacer


    Wenn es zum genannten Problem kommt schaut das so aus:



    "failed to pass bufer to video decoder" kommt während der Wiedergabe einer PES Aufnahme - wenn dieser Log Eintrag zu sehen ist - dann passiert beim beenden der Wiedergabe genau das beschriebene Problem


    Was ich ebenfalls beobachtet habe: Wenn diese Meldung kommt dann kann man nicht mehr "spulen" - man erhält hier nur ein "standbild"
    Springen mit den Farbtasten geht noch.


    Wie im Log zu sehen schlägt dann der Watchdog nach 120 sekunden zu - aber auch ohne Watchdog hängt sich das System einfach weg und fängt sich auch nicht mehr - ein Neustart ist notwendig.


    Das ganze kann nicht auf eine spezielle -aufnahme festgemacht werden - ich habe auch schon versucht eine Aufnahme bei der das passiert ist nochmals 10x abzuspielen und zu beenden / zu spulen - aber ich konnte es nicht reproduzieren - 15 Minuten später ist´s dann bei ner anderen Aufnahme passiert.


    Nachdem das Plugin und der VDR nun schon derart gut auf dem RPI läuft ist das wirklich noch das einzige was "nervt"


    Evtl hat jemand eine idee ?


    CU
    GTR


    NACHTRAG: Es tritt offenbar nur beim beenden von alten PES Aufnahmen auf ...


    Korrektur vom 31.03.2014: Es tritt auch bei neuen Aufnahmen auf

    Hi Thomas,


    ich hab mal nen Kollegen auf das Compiler Versions Problem angesprochen. Seine erste Idee war gleich, dass da irgendwo auf nen falschen Speicherbereich zugegriffen wird, was bei dem vom einen Compiler erzeugten Code zufällig nicht stört, beim anderen aber schon.
    Es gibt Tool wie Valgrind oder dieses http://openbook.galileocomputi…xKap17007040006201F02E100, mit denen man solche Fehler aufspühren kann. Vielleicht hilft das ja weiter. Die Zeit wo ich selber aktiv C++ programmiert habe ist leider schon so lange her, dass ich mich nicht selber damit befassen möchte.


    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 Claus

    Zitat von clausmuus

    ich hab mal nen Kollegen auf das Compiler Versions Problem angesprochen. Seine erste Idee war gleich, dass da irgendwo auf nen falschen Speicherbereich zugegriffen wird, was bei dem vom einen Compiler erzeugten Code zufällig nicht stört, beim anderen aber schon.
    Es gibt Tool wie Valgrind oder dieses http://openbook.galileocomputing.de/linu…40006201F02E100, mit denen man solche Fehler aufspühren kann. Vielleicht hilft das ja weiter. Die Zeit wo ich selber aktiv C++ programmiert habe ist leider schon so lange her, dass ich mich nicht selber damit befassen möchte.

    Vielen Dank für den Hinweis! Das wird ziemlich sicher was in die Richtung sein, ich schau mir das mit den einschlägigen Tools mal an - danke auch für den Link.
    Bin derzeit gerade anderweitig recht beschäftigt, aber ich kümmer mich baldmöglichst darum!


    Gruss
    Thomas

    Ein erster und schneller Versuch würde auch mat gcc gehen.
    Ab gcc 4.1 gibt es die Stack-protector Flags. (-fstack-protector....)
    valgrind kann zwar noch deutlich mehr aber ist auch deutlich aufwendiger.

    Habe gerade ein wenig gegoogelt und gesehen, dass bei allen Beispielen zur Interthread-Kommunikation mittels STL-Queue, diese mit einem Mutex geschützt ist... das habe ich nicht berücksichtigt und wird höchstwahrscheinlich der Grund für die Probleme sein. Werde das entsprechend ändern...


    Gruss
    Thomas

    Danke für deinen Einsatz Thomas!

    Es ist immer wieder beeindruckend was der Raspberry so mit der richtigen Software leistet. Das führt zu meiner nächsten Frage: Hat das hier Auswirkungen auf das rpihddevice ?
    Wenn ja hoffentlich positive!


    http://www.raspberrypi.org/archives/6561


    Interessant ist hier auch die Aussage dass die Performance des Compilat welches mit gcc 4.7 gemacht wurde 10% schneller (performanter) als 4.6 ist.
    Könnte für rpihddevice auch von Vorteil sein?


    lg,
    Joe

    Zitat von reufer

    ... ausser du willst ein in 3D-animiertes OSD... ;)


    Na cool wäre es ja ... :D

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

    Zitat von reufer

    So wie ich das verstehe, geht es hier um 3D-Beschleuningung - daher nein, ausser du willst ein in 3D-animiertes OSD


    Nein, aber ich dachte damit ergeben sich auch z.B. für Deinterlacing oder sonstiges weitere Vorteile oder Möglichkeiten.


    lg,
    Joe

    Zitat von reufer

    Habe gerade ein wenig gegoogelt und gesehen, dass bei allen Beispielen zur Interthread-Kommunikation mittels STL-Queue, diese mit einem Mutex geschützt ist... das habe ich nicht berücksichtigt und wird höchstwahrscheinlich der Grund für die Probleme sein. Werde das entsprechend ändern...

    So, habe das mal geändert und sowohl die Audio-PTS- wie auch die OMX-Event-Queue mit einem Mutex geschützt - Patch ist angehängt. Ein kurzer Smoketest hat bei mir funktioniert, aber das muss ja nichts heissen... können das mutige Tester, die mit der aktuellen Git-Version Probleme haben, bitte mal testen? Wage mich nicht, das jetzt schon in Git einzuchecken... ;)


    Gruss
    Thomas

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden