VDR startet nicht Raspbian E-Tobi

    Moin!

    Aktuelles Raspbian mit Tobis VDR-Paketen.
    Der DVB-S Stick wird erkannt, aber VDR startet nicht. Ich habe schon diverse Möglichkeiten ausprobiert und nun weiß ich nicht, wo ich sonst noch suchen soll.
    Die Fehlermeldung sagt mir gar nichts.

    Code
    sudo systemctl start vdr
Job for vdr.service failed. See 'systemctl status vdr.service' and 'journalctl -xn' for details.

    Schau mal, was der VDR seit dem letzten Boot ins Log geschrieben hat:

    Code
    journalctl -u vdr -bl
    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.)

    Hallo Seahawk,

    sudo journalctl -u vdr -b1

    (Dein "l" sollte wohl eine "1" sein, oder?)

    Was ist denn zu sehen, wenn du mit installiertem vdr-dbg den vdr (oder w_scan) mit gdb ausführst?

    Code
    sudo apt-get install gdb
sudo gdb vdr
# in der gdb shell:
run
# nach dem Crash:
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.)

    Oha, da betreten wir jetzt einen Bereich, wo ich komplett nur Bahnhof verstehe:

    Code
    (gdb) run
Starting program: /usr/bin/vdr 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".


Program received signal SIGILL, Illegal instruction.
0x000bd418 in cRecording::Title(char, bool, int) const ()
    Code
    (gdb) bt
#0  0x000bd418 in cRecording::Title(char, bool, int) const ()
#1  0x00000008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
    Code
    (gdb) bt full
#0  0x000bd418 in cRecording::Title(char, bool, int) const ()
No symbol table info available.
#1  0x00000008 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

    Also mir sagt das eigentlich nicht viel. Scheint sowas wie ein SYS3175 zu sein, aber das hilft auch nicht weiter.
    Könnte einer der Koryphäen mir das Ergebnis bitte mal einordnen? Einfach Pech? Habe ich etwas falsch gemacht? Hat Tobi was kaputt gemacht? Liegt's am Wetter? Raspi kaputt?

    Klingt nach einem Binary-Incompatible Problem:
    CPU passt wohl nicht zum Binary oder umgekehrt.

    Poste bitte mal folgende Ausgaben:

    Code
    which vdr #um zu prüfen wo das vdr-binary liegt
file /usr/bin/vdr #sollte oben was anderes rausgekommen sein, hier entsprechend anpassen
uname -a  #zeige laufende Kernel version & binary details
file /usr/bin/file

    Ich antworte mal etwas ausführlicher: Ich habe zwei Raspi 2 B im Einsatz: Einen für die Aufnahme und einen für die Wiedergabe. Der Wiedergabe-Raspi funktioniert, der Aufnahme-Raspi hat das geschilderte Problem.
    Gemeinsame Eigenschaften:

    installiertes vdr-Paket: 2.2.0-5~etobi1

    Code
    file /usr/bin/vdr 
/usr/bin/vdr: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=c6e9409646ea3fa6a297d08ff3ece2b36f1a51c3, stripped
    Code
    file /usr/bin/file
/usr/bin/file: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=1c37ed46b1ba748dc1b82d3ebc2c95e49fb16cfe, stripped
    Code
    cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
deb http://e-tobi.net/vdr-experimental jessie base vdr-multipatch

    Nun zum Unterschied (und das entspricht wohl genau Deiner Vermutung):

    papagei (Wiedergabe, läuft)

    Code
    uname -a 
Linux papagei 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

    adler (Aufnahme, kaputt)

    Code
    uname -a 
Linux adler 4.4.21+ #911 Thu Sep 15 14:17:52 BST 2016 armv6l GNU/Linux

    Warum habe ich auf dem einen Raspi einen anderen Kernel als auf dem anderen? Dazu einmal armv6l und einmal armv7l?

    Auf dem kaputten System habe ich eine /etc/apt/preferences, auf dem laufenden System dagegen nicht. Ist das die Ursache?

    Code
    Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 600
 
Package: *
Pin: release o=e-tobi.net
Pin-Priority: 1001

    armv6l ist ein RPi 1

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    RolfGF:
    Es schaut so aus, als ob da irgendwo das Problem begraben ist. Aber so ganz eindeutig ist das aus den bisherigen Informationen noch nicht.

    Meine erste Vermutung war, dass das VDR binary nicht zum Prozessor passt. Von den "file" Ausgaben her stimmt es soweit zusammen.
    Dennoch dürfte der VDR auf eine Prozessorfunktion zugreifen, die auf dem armv6l nicht verfügbar ist.

    Um der Sache näher zu kommen brauchen wir nun die Prozessor Details von beiden Geräten. Dazu sind die Ausgaben aus:
    "cat /proc/cpuinfo" interessant. Bitte beide posten.

    Es könnte schon sein, dass aus irgendeinem Grund auf einem Gerät ein anderer Kernel läuft, und das soweit problemlos. Es könnte auch sein, dass Hardwareunterschiede vorhanden sind, das gilt es abzuklären bevor man zum ruminstallieren/rumprobieren beginnt.

    Ohje, der eine Raspi ist ein B+, kein 2B. Einen zweiten 2B besitze ich gar nicht. Ich bin gerade "etwas" erschrocken über diesen Aussetzer. Tut mir leid, dass ich Euch unnötig Arbeit gemacht habe. Das muss ich erstmal verdauen. Hatte viel Stress in den letzten Wochen.
    Bedeutet das jetzt, dass Tobi keine Pakete für die älteren Raspis hat oder ist bei mir dann nur das falsche Paket installiert?

    papagei (Wiedergabe, läuft)

    adler (Aufnahme, kaputt)

    Mach dir nichts draus, das sind genau die Fehler die jedem passieren können und bei denen man manchmal den Baum vor lauter Wald nicht sieht.
    Es kommt vor, dass man stundenlange so einfache Dinge übersieht.

    Laut dem Blog Eintrag von Tobias sind die Pakete für OSMC, welches auf den offiziellen Debian armhf Paketen aufbaut.
    https://e-tobi.net/blog/2015/09/1…fur-raspberrypi

    Debian armhf liegt laut der Projektseite nur für armv7 vor:
    https://www.debian.org/releases/jessie/armhf/

    Laut der Debian Seite läuft auf dem RPI 1 die armel Architektur
    https://wiki.debian.org/RaspberryPi

    Soviel mal zu den Prozessoren.


    Jetzt ein möglicher Lösungsansatz:
    Wenn ein Binär-Paket auf deiner Umgebung nicht läuft, das das soweit ja noch nicht gesagt, dass es gar nicht geht.
    Um die E-Tobi Pakete zum Laufen zu bekommen kannst du versuchen diese selber für den Raspberry 1 zu kompilieren:

    Statt

    Code
    deb http://e-tobi.net/vdr-experimental jessie base vdr-multipatch
    Code
    deb-src http://e-tobi.net/vdr-experimental jessie base vdr-multipatch


    in die /etc/apt/sources.list eintragen. Und dann:

    Code
    apt-get update


    Am besten vor dem durchführen der Befehle immer die man-pages zum Befehl lesen, damit lernt man viel. :)

    Code
    cd /usr/src/
apt-get build-dep vdr  #damit installierst du alle Abhängigkeiten die benötigt werden um den VDR auf deinem System zu kompilieren.
apt-get source vdr -b  #sollte den VDR-Source Code von E-Tobi herunterladen, dabei die Addresse prüfen ob das Paket auch vom richtigen Server kommt. Das "-b" weist apt-get an das Paket auch gleich zu kompilieren


    Wenn alles glatt läuft, dann solltest du unter /usr/src/ nach einigen Minuten vdr & vdr-dev / vdr-dbg Pakete für armv6 vorfinden. Die kann man dann mit "dpkg -i installieren". Wenn das alles geklappt hat, kann man auch die Plugins auf diese Weise für die eigene Architektur kompilieren.
    Immer hilfreich bei solchen Dingen ist es die eigens gebauten Pakete auch mit apt-mark auf hold zu setzten, damit diese bei einem Update nicht überschrieben werden.

    Good Luck & ein schönes Wochenende! :]

    Danke für die aufmunternden Worte.

    Ich habe nun zunächst einmal den einfacheren Weg gewählt: Ich habe Tobis Pakete gepurget und die normalen Raspian-Pakete installiert. Die sind zwar älter aber funktionieren auch.
    Deine Anleitung probiere ich ggf. später mal aus. Vielen Dank.

    Ich schliesse mich dem Fragensteller an, vielen Dank für die Anregung hgutmann. Ich hätte es ohne Deinen Post garnicht erst versucht, aber apt-get source -b läuft einwandfrei auf dem ARM6 raspi mit den etobi sourcen. Der Compile Prozess hat dabei auch erträglich lange gedauert. Gerade läuft der 2. Versuch mit plugins, die im normalen repo nicht verfügbar sind.

    Danke!
    dzarth

    Für die Plugins gibt es noch eine gute Anlaufstelle unter:
    https://anonscm.debian.org/cgit/pkg-vdr-dvb

    Hier sind wesentlich mehr Packages enthalten als direkt in der Distribution, die meisten davon funktionieren auch problemlos.
    Die Vorgehensweise zum installieren ist wie folgt:

Participate now!

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

Register Yourself Login