Posts by linuxdxs

    Ich habe das Skript original kopiert und eingefügt, einmal auf einem Raspberry von dem die Fernabfrage geschehen soll und einmal auf meinem SuSE VDR Server. Jetzt das komische. Das Skript direkt auf dem Server ausgeführt bringt die richtige Ausgabe. Das selbe Skript, erweitert mit IP und Port, auf dem Raspberry ausgeführt bringt die falsche Ausgabe wie oben angegeben. Ich denke iwi wird das "rel" nicht übers Netz mit übertragen.

    Ok, das wäre nicht das Problem, meine Rückmeldung vom VDR sieht im Bashscript so aus:

    250 26 Sat Mar 25 22:06:00 2023order 2.4.7; Sat Mar 25 21:48:24 2023; UTF-8

    Hier fehlt die relative zeit bis zum nächsten Timer.

    Wenn ich auf der Konsole

    svdrpsend 10.10.10.15 6419 "next rel"

    eingebe, habe ich folgende Ausgabe:

    220 localhost SVDRP VideoDiskRecorder 2.4.7; Sat Mar 25 22:06:54 2023; UTF-8

    250 26 -55

    221 localhost closing connection

    Hier ist die relative Zeit angegeben. Es müssen aber die Anführungsstriche dabei sein, sonst funktioniert es auch auf der Konsole nicht

    Hallo Forum,

    ein kleines Problem was folgendermaßen zeigt:

    Ich möchte in einem Bashcript folgenden Befehl ausführen:

    TEMP=$(/usr/bin/svdrpsend $IP $SVDR_PORT next rel)

    In $TEMP steht folgender Wert:

    221 localhost closing connectionrder 2.4.7; Sat Mar 25 19:58:45 2023; UTF-8

    Ich benötige aber die relative Zeitangabe.

    Hat jemand eine Idee wie ich das gebacken bekomme?

    Vielen Dank im voraus

    Ich habe die Lösung:

    Mein Testskript hat einen kleinen Zusatz bekommen:

    hwclock --systohc --localtime

    DEV=/sys/class/rtc/rtc0/wakealarm

    sudo chmod a+wr $DEV

    ethtool -s eth0 wol g

    # wakealarm löschen (wenn schon gesetzt, muss er gelöscht werden)

    echo 0 > $DEV

    #alarm setzen

    timedatectl set-local-rtc 0

    nextboot=`date --date "now +180 seconds" "+%s"`

    echo $nextboot > $DEV # Einige Mainboards sind etwas begriffsstutzig,

    echo $nextboot > $DEV # sie kapieren erst nach zwei Aufrufen, was Sache ist.

    echo "Aktuelle Zeit: "`date "+%Y-%m-%d %H:%M:%S"`

    echo

    cat /proc/driver/rtc

    echo

    echo "Fahre Rechner runter."

    shutdown -h now

    EXITSTATUS=0

    exit $EXITSTATUS

    Jetzt funktioniert das Skript

    Danke für Euro Denkanstöße

    Ich habe die Batterie ausgetauscht, Clear Cmos gemacht und die RTC auf UTC eingestellt. Jetzt ein paar aml ca. 2 Std gewartet. Aber das Bord will sich nicht einschalten.

    timedatectl gibt folgendes aus


    Local time: Sa 2021-09-18 12:40:58 CEST

    Universal time: Sa 2021-09-18 10:40:58 UTC

    RTC time: Sa 2021-09-18 12:40:58

    Time zone: Europe/Berlin (CEST, +0200)

    System clock synchronized: yes

    NTP service: active

    RTC in local TZ: yes

    Warning: The system is configured to read the RTC time in the local time zone.

    This mode cannot be fully supported. It will create various problems

    with time zone changes and daylight saving time adjustments. The RTC

    time is never updated, it relies on external facilities to maintain it.

    If at all possible, use RTC in UTC by calling

    'timedatectl set-local-rtc 0'.

    Hätte noch jmd eine Idee?

    timedatectl gibt folgendes aus:

    Local time: Fr 2021-09-17 18:10:52 CEST

    Universal time: Fr 2021-09-17 16:10:52 UTC

    RTC time: Fr 2021-09-17 18:10:52

    Time zone: Europe/Berlin (CEST, +0200)

    System clock synchronized: yes

    NTP service: active

    RTC in local TZ: yes

    Warning: The system is configured to read the RTC time in the local time zone.

    This mode cannot be fully supported. It will create various problems

    with time zone changes and daylight saving time adjustments. The RTC

    time is never updated, it relies on external facilities to maintain it.

    If at all possible, use RTC in UTC by calling

    'timedatectl set-local-rtc 0'.

    Was soll ich jetzt machen?

    Bei mir läuft openSUSE Leap 15.3. Das Bord selber könnte schon ca. zehn Jahre alt sein.

    Das Skript, welches den Timer programmiert sieht folgendermaßen aus;

    #!/bin/sh

    sudo hwclock --systohc --localtime

    DEV=/sys/class/rtc/rtc0/wakealarm

    sudo chmod a+wr $DEV

    # wakealarm löschen (wenn schon gesetzt, muss er gelöscht werden)

    echo 0 > $DEV

    #alarm setzen

    nextboot=`date --date "now +180 seconds" "+%s"`

    echo $nextboot > $DEV

    echo $nextboot > $DEV

    ethtool -s eth0 wol g

    echo "Aktuelle Zeit: "`date "+%Y-%m-%d %H:%M:%S"`

    echo

    cat /proc/driver/rtc

    echo

    echo "Fahre Rechner runter."

    poweroff

    #shutdown -h now

    EXITSTATUS=0

    exit $EXITSTATUS

    Hallo Forum,

    ich weiß, es ist ein altes Board, aber dieses Bord habe ich halt hier. Auf dem Bord läuft open Suse. Ich wollte dieses Bord per ACPI zum Aufnahmzeitpunkt starten. Es funktioniert weder durch ACPI noch durch nvram. Kann es sein, daß dieses Bord grundsätzlich nicht per Timer aktiviert werden kann?

    Was mir auch auffällt, obwohl die Alarmzeit richtig eingestellt wurde, steht diese nach einem händischen einschalten auf 00:00 Uhr und dem nächsten Tag.

    Einstellen der Weckzeit:

    Aktuelle Zeit: 2021-09-17 09:33:34

    rtc_time : 09:33:34

    rtc_date : 2021-09-17

    alrm_time : 09:38:34

    alrm_date : 2021-09-17

    alarm_IRQ : no

    alrm_pending : no

    update IRQ enabled : no

    periodic IRQ enabled : no

    periodic IRQ frequency : 1024

    max user IRQ frequency : 64

    24hr : yes

    periodic_IRQ : no

    update_IRQ : no

    HPET_emulated : no

    BCD : yes

    DST_enable : no

    periodic_freq : 1024

    batt_status : okay


    cat /proc/driver/rtc nach händischen neustart

    rtc_time : 09:47:29

    rtc_date : 2021-09-17

    alrm_time : 00:00:00

    alrm_date : 2021-09-18

    alarm_IRQ : no

    alrm_pending : no

    update IRQ enabled : no

    periodic IRQ enabled : no

    periodic IRQ frequency : 1024

    max user IRQ frequency : 64

    24hr : yes

    periodic_IRQ : no

    update_IRQ : no

    HPET_emulated : no

    BCD : yes

    DST_enable : no

    periodic_freq : 1024

    batt_status : okay

    Hättet ihr eine Idee wie man dieses Problem lösen könnte?

    Ich bin noch überm schauen, aber jetzt ist der Server einfach beim Umschalten abgestürzt.

    Was soll das mit dem "Bad file descriptor"?

    Hab jetzt folgendes gemacht:
    Auf einem Client ARD, auf dem nächste RTL, dann im PIP Pro7 und auf dem letzten JAMFM. Es funktionieren alle vier Empfänger einwandfrei. Kann ich dann davon ausgehen, daß alle Empfanhsteile richtig arbeiten?

    Heute Morgern war folgende Fehlermeldung vor dem Absturz in der LOG-Datei:

    Wieß keiner woran das wohl liegt?

    Hallo Forum, ich schon wieder. Jetzt das nächste Problem. Ich habe diesen kopflosen Sever in dem die Empfängerkarten eingebaut sind, läuft ja auch relativ stabil, außer wenn z.B. sich ein neuer Klient anmeldet, dann stürzt der VDR einfach ab.

    Hier der Logbucheintrag


    Wo soll ich anfangen zu suchen? Soll ich eine andere Version des streamdev-Plugin probieren(zur Zeit ist vdr-plugin-streamdev-69b654d5393189c9c23dcc1241d8ab0588bae355.tar.gz installiert). Ich habe auch gelesen, daß solch eine Fehlermeldung bei falschen Dateirechten passieren kann. Darauf hin habe ich alle Dateirechte nach 666 getauscht. Hat aber auch nicht geholfen.

    Mal wieder ein dickes Danke für eure Hilfe.