ERROR: invalid primary device number: 1

    Hi,

    ich habe auf meinem Raspberry Pi 3B unter Debian Buster einen VDR aufgesetzt. Nach einem Neustart macht der VDR leider Zicken. Sauberer Autostart leider nicht möglich. Ursache ist wohl das:


    Code
    Aug 11 10:18:07 raspberrypi vdr[482]: [482] ERROR: invalid primary device number: 1
  
Aug 11 10:18:07 raspberrypi vdr[482]: [482] ERROR: no primary device found - using first device!
Aug 11 10:18:07 raspberrypi vdr[482]: vdr: no primary device found - using first device!
Aug 11 10:18:07 raspberrypi vdr[482]: [482] ERROR: invalid primary device number: 1

    Nach einem

    Code
    sudo /etc/init.d/vdr restart && sudo /etc/init.d/vdradmin-am restart

    schnurrt das Kätzchen wieder und läuft.


    Ich vermute das ist ein Rechte-Problem. Mit sudo Restart läuft VDR ja dann als Root, richtig?

    Wie bekomme ich das ohne Restart per sudo zum Laufen?


    Danke

    Ich nutze einen DVB-C Stick namens TerraTec Cinergy HTC USB XS HD.

    Treiber geholt via:


    Code
    cd /lib/firmware/
sudo wget https://github.com/OpenELEC/dvb-firmware/raw/master/firmware/dvb-usb-terratec-htc-stick-drxk.fw


    VDR dient ausschließlich als Aufnahme-Server.


    Hilft das weiter?


    Danke

    Um das zu verifizieren, könntest Du den VDR Start erstmal mit einem einfachen Sleep verzögern. Raspbian ist ja auch systemd ... sowas in der Art:

    Code
    #/> cat /etc/systemd/system/vdr.service.d/delay.conf

[Service]
ExecStartPre=/bin/sleep 10

    HowTo: APT pinning

    Gefällt mir 1
    Zitat von jrie

    passt aber nicht zu systemd, oder?

    Also Raspbian Buster ist definitiv systemd. Die e-Tobi SysV init.d Scripte werden quasi unverändert innerhalb systemd verwendet. Nur upstart war anders ...


    Vmtl. funktioniert das "versehentlich" noch nach altem SysV Prinzip, hab ich nie probiert ... da seine Paket aus einer Quelle stammen, die auf eTobi zurückgeht wäre folgendes korrekt unter Raspbian Buster:


    sudo systemctl restart vdr.service && sudo systemctl restart vdradmin-am.service


    Das war ja eigentlich die unsichtbare Eleganz mit systemd, das SysV Init Script 1:1, getriggert von einem "wrapper", weiter funktionieren können ... und nicht alles neu musste, wie bei upstart.

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Gefällt mir 1

    Danke euch. Scheinbar ist die Erkennung meines DVB-C Sticks vom Mondstand abhängig. Eben ist es sauber gestartet, ohne dass ich was geändert habe. Mysteriös...


    Ich probiere beim nächsten Fehlstart eure Tipps aus und gebe Rückmeldung.


    :prost2

    Das ist ein übliches Timing-Problem. Die Hardware wird parallel zu den verschiedenen Diensten initialisiert. Wenn ein Dienst eine spezielle Hardware beim Start braucht, muss man das Init-System dafür benutzen, diese in der richtigen Reihenfolge zu starten.

    Gerade USB-Sticks sind manchmal etwas lahm bei der Initialisierung.

    Zitat von TawnyRoberts

    Es funktioniert:

    Ok, wenn ein "sleep" hilft, könntest Du es wie oben schonmal angerissen eleganter in das System einbetten, jeweils:


    #/> sudo vi /etc/systemd/system/vdr.service.d/delay.conf


    #/> sudo vi /etc/systemd/system/vdradmin-am.service.d/delay.conf


    Mit diesem Inhalt:

    Code
    [Service]
ExecStartPre=/bin/sleep 15

    Vorteil wäre hier, Du lässt die beiden Services nicht erst ins Leere laufen und "haust" Ihnen dann noch einen drauf, sondern sorgst dafür das diese erst 15 Zeiteinheiten später gestartet werden ... 8o


    Und vdradmin-am bräuchte den restart nicht, m.E. überlebt das den Restart des VDR service und verbindet sich erneut.


    Regards

    HowTo: APT pinning

    Gefällt mir 1

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden