Beiträge von alda

    Ich habe den Fehler gefunden: Kernel Parameter!

    Die waren vom System wie folgt gesetzt:


    Code
    1. GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    2. GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi=noirq"

    und ich habe diese abgeändert in:


    Code
    1. GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    2. GRUB_CMDLINE_LINUX_DEFAULT="quiet"
    3. GRUB_CMDLINE_LINUX="hpet=disable"

    danach lief es dann. Ich hätte nur in meiner alten Installation nachschauen müssen. Aber man muss ja erst mal drauf kommen, das es an den Kernelparametern liegt.

    Vielen Dank, seahawk1986, für deine Antwort.

    Vielen Dank, seahawk1986,


    ich habe brav noch eine Stunde gewartet, aber er wacht nicht auf. Meines Wissens unterscheidet sich aber auch die Systemzeit von der Bioszeit, da ja UTC die allgemeine Zeit ist.


    Nichts desdo trotz gibt ein


    und das ist so ziemlich das gleiche wie bei der alten Installation. :(

    Noch irgendjemand eine Idee?

    Hallo, liebes Forum,


    vielleicht (bestimmt) könnt Ihr mir wieder mal helfen. Ich habe ca 2. Jahre einen VDR auf einem Elitegroup A780GM-A laufen. Jetzt habe ich den vdr neu aufgesetzt mit Debian Stretch mit systemd. Die alte Installation steht noch zur Verfügung als Referenz.

    Mit der alten Installation wacht das Board


    Code
    1. echo 0 > /sys/class/rtc/rtc0/wakealarm
    2. echo 1514806200 > /sys/class/rtc/rtc0/wakealarm

    wie gewünscht auf. Bei der Neuen tut sich schlicht nichts. Debian läuft auf UTC, Bios-Uhr ist eine Stunde zurück. Heruntergefahren habe ich das Board mit


    Code
    1. shutdown -h now und
    2. systemctl hibernate oder
    3. systemctl suspend (jeweils testweise)


    Hat jemand eine Idee?

    Danke schon mal im Voraus.

    Hallo SurfaceCleanerZ,


    vielen, wenn auch späten Dank, für Deine Antwort. Mit UHD TV hat es hier nichts zu tun. Mittlerweile läußt das Menü aber wieder. Ich habe die komplette setup.conf von meinem anderen System eingespielt. Woran es gelegen hat, weiß ich aber nicht.

    Trotzdem vielen Dank.

    Hallo,


    ich brauche wieder mal Eure Hilfe.

    Ich habe einen vdr neu aufgesetzt auf Devian Stretch 9.3. Ich benutze einen raspberry und greife (bzw. ich will) auf aus Menu des Servers zu. Das hat auch schon mal funktioniert, jetzt habe ich es "kaputgespielt". Wenn ich im raspberry den entsprechenden Punkt "Remotemenu" anwähle, geht das Menü auch auf. Will ich jetzt einen Punkt auswählen, wird das Menü wieder geschlossen. Rufe ich dann Remotemenü abermals auf, kommt die Meldung: "Remotemenu already in use".

    Hier die sys.log:


    [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB

    Dec 17 18:30:37 vdr4 vdr: [1779] device 2 TS buffer thread ended (pid=1744, tid=1779)

    Dec 17 18:30:37 vdr4 vdr: [1778] buffer stats: 110544 (2%) used

    Dec 17 18:30:37 vdr4 vdr: [1778] device 2 receiver thread ended (pid=1744, tid=1778)

    Dec 17 18:30:37 vdr4 vdr: [1784] [xine..put] Detected video size 720x576

    Dec 17 18:30:37 vdr4 vdr: [1744] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB

    Dec 17 18:30:39 vdr4 vdr: [1744] timeout on SVDRP connection

    Dec 17 18:30:39 vdr4 vdr: [1744] closing SVDRP connection

    Dec 17 18:30:43 vdr4 vdr: [1744] connect from 192.168.178.26, port 59881 - accepted

    Dec 17 18:30:44 vdr4 vdr: [1744] switching to channel 6 (SAT.1)

    Dec 17 18:30:45 vdr4 vdr: [1744] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB

    Dec 17 18:30:45 vdr4 vdr: [1784] [xine..put] Detected video size 720x576

    Dec 17 18:30:47 vdr4 vdr: [1744] timeout on SVDRP connection

    Dec 17 18:30:47 vdr4 vdr: [1744] closing SVDRP connection

    Dec 17 18:30:49 vdr4 vdr: [1744] connect from 192.168.178.26, port 59882 - accepted

    Dec 17 18:30:50 vdr4 vdr: [1744] switching to channel 6 (SAT.1)

    Dec 17 18:30:50 vdr4 vdr: [1744] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB

    Dec 17 18:30:50 vdr4 vdr: [1784] [xine..put] Detected video size 720x576

    Dec 17 18:30:52 vdr4 vdr: [1744] timeout on SVDRP connection

    Dec 17 18:30:52 vdr4 vdr: [1744] closing SVDRP connection

    Dec 17 18:31:33 vdr4 vdr: [1744] max. latency time 2 seconds

    Dec 17 18:31:54 vdr4 vdr: [1744] connect from 192.168.178.26, port 59883 - accepted

    Dec 17 18:31:56 vdr4 vdr: [1744] timeout on SVDRP connection

    Dec 17 18:31:56 vdr4 vdr: [1744] closing SVDRP connection


    Kann damit jemand was anfangen?

    MegaV0lt, das Profi ist nicht übertrieben: Er ist aufgewacht!


    Code
    1. Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=590f5XXX ro hpet=disable quiet


    Vielen Dank! Jetzt muss ich das gleiche nur noch mit dem VDR testen.


    Ergänzung:
    Getestet und: Funktioniert!
    Vielen Dank noch mal an alle!

    Danke für Eure Antworten. Und: Asche über mein Haupt. Ich bin davon ausgegangen, das mein Wakealarm funktioniert, weil: ich habe diesen VDR neu aufgesetzt, das Board ist aber schon ca. 2 Jahre mit einer älteren VDR Version gelaufen. Das ACPI hat immer völlig problemlos funktioniert, so dass ich gar nicht auf die Idee gekommen bin, das es hier Schwierigkeiten gibt. Gibt es aber.


    Er wacht einfach nicht auf. Ich kann die Aufwachzeit setzen und bekomme dann dieses hier (es ist 18:47):


    Code
    1. echo 0 > /sys/class/rtc/rtc0/wakealarm
    2. echo 1428425700 > /sys/class/rtc/rtc0/wakealarm


    und



    wenn ich

    Code
    1. cat /proc/driver/rtc
    2. hwclock --debug
    3. date -d @`tail /sys/class/rtc/rtc0/wakealarm`


    Ach ja. An den Bios-Einstellungen habe ich nichts verändert. Die waren beim "alten" VDR genauso.
    Ich habe, wie es hier beschrieben wird, auch das script /etc/init.d/hwclock.sh modifiziert. Es wird am Anfang des Script die Aufwachzeit gelesen, gesichert und zum Schluss wieder zweimal nach wakeup geschrieben. Ohne Erfolg.


    Kann mir jemand einen Tip geben?

    Es ist schon oft behandelt worden, aber ich komme nicht weiter:


    wenn ich als root ./S91.acpiwakeup 1428008400 ausführe, wird in /sys/class/rtc/rtc0/wakealarm brav geschrieben,
    su vdr -c ./S91.acpiwakeup 1428008400
    funktioniert nicht.
    Ich nehme an, das deswegen mein acpiwakeup nicht funktioniert. Kann mir jemand bitte helfen? Wie kann ich die Rechte setzen, dass vdr nach wakealarm schreiben kann?


    Als Ergänzung:
    Ich habe mittlerweile nach https://github.com/VDR4Arch/vd…er/vdr/shutdown-wrapper.c ein wrapperscript gebaut.
    Wenn ich mich als "normaler User" anmelde, funktioniert dieses script:


    Code
    1. /etc/vdr/shutdown-hooks/S91.acpiwakeup 1428130800
    2. alexander@vdr4:~$ shownextwakeup
    3. Sa 4. Apr 08:55:00 CEST 2015


    wobei sich hier hinter S91.acpiwakeup das obige wrapper verbirgt.


    Leider kann ich das unter vdr nicht direkt testen, weil ich mich nicht als user vdr anmelden kann.

    Code
    1. root@vdr4:/home/alexander# whoami
    2. root
    3. root@vdr4:/home/alexander# su vdr
    4. root@vdr4:/home/alexander# whoami
    5. root


    Was muss ich tun, damit vdr ein "echter" User wird?


    Noch eine Ergänzung. Auszug aus dem syslog beim runterfahren:


    Also, er möchte ja schon nach wakealarm schreiben, kann es aber anscheinend nicht.


    Jemand eine Idee?


    Linux vdr4 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
    vdr (1.7.28/1.7.28) - The Video Disk Recorder
    conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
    epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
    svdrposd (0.1.1) - Publish OSD menu via SVDRP
    xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin
    streamdev-server (0.6.0) - VDR Streaming Server
    epgsearch (1.0.1) - search the EPG for repeats and more
    quickepgsearch (0.0.1) - Quick search for broadcasts

    Hallo Zusammen,


    kann mir vielleicht jemand weiterhelfen. Ich habe auch meinem Raspberry folgendes installiert:


    Der Server ist ein Debian-linux mit

    Code
    1. vdr (1.7.28/1.7.28) - The Video Disk Recorder
    2. svdrposd (0.1.1) - Publish OSD menu via SVDRP
    3. xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin
    4. streamdev-server (0.6.0) - VDR Streaming Server


    Beim Versuch, das Osd des Servers aufzurufen, bekomme ich obige Fehlermeldung: Remote menu not available - Connection failed


    syslog vom raspi sagt folgendes:
    rpihddevice: set video codec to MPEG2

    Code
    1. Aug 24 18:05:10 raspberrypi vdr: [2562] rpihddevice: decoding video 720x576i, enabling deinterlacer
    2. Aug 24 18:05:16 raspberrypi vdr: [2552] loading /var/lib/vdr/themes/lcars-default.theme
    3. Aug 24 18:05:16 raspberrypi vdr: [2552] svdrpservice: Error connecting to 192.168.0.39:2001: Connection refused
    4. Aug 24 18:05:16 raspberrypi vdr: [2552] loading /var/lib/vdr/themes/lcars-default.theme


    während auf dem Server ein
    tail -n 150 /var/log/syslog | grep -i 6419

    Code
    1. Aug 24 18:04:11 vdr4 vdr: [3549] SVDRP listening on port 6419


    ergibt.


    In der Setup.conf auf dem raspi ist aber folgendes eingetragen:

    Code
    1. svdrpservice.ConnectTimeout = 5
    2. svdrpservice.ReadTimeout = 6
    3. svdrpservice.ServerIp = 192.168.0.39
    4. svdrpservice.ServerPort = 6419


    Sollte svdr auf dem Raspi nicht versuchen, eine Verbindung auf 6419 herzustellen? Aus dem Syslog des Raspis sehe ich jedoch: Aug 24 18:05:16 raspberrypi vdr: [2552] svdrpservice: Error connecting to 192.168.0.39:2001: Connection refused, also versucht er es unter port 2001?


    Was ist hier falsch?


    Ich wäre für jede Hilfe dankbar.

    Ok, habe den "kaputtgespielten" VDR jetzt wieder so weit am laufen wie vorher.


    @DocViper


    hier die syslog:



    und die setup.conf



    und die order.conf



    Ja, und der vdr 1.6 ist alt, aber bis jetzt galt: never change a running system


    und die Signatur: kommt, sobald ich Zeit habe


    In der Syslog steht folgendes, wie ich gerade gesehen habe:

    Zitat

    326 Mar 16 12:23:03 vdr3 vdr: [2922] Remote decoder/display server (cXinelibServer) thread started (pid=2787, tid=2922)
    327 Mar 16 12:23:03 vdr3 vdr: [2922] ERROR (thread.c,225): Keine Berechtigung
    328 Mar 16 12:23:03 vdr3 vdr: [2922] [xine..put] cXinelibServer: Can't set priority to SCHED_RR 2 [1,99]
    329 Mar 16 12:23:03 vdr3 vdr: [2922] [xine..put] Local interface address 192.168.0.0/24 is invalid !

    Vielleicht ist das ja der Fehler. Obwohl ich im Moment keine Ahnung habe, wo ich da drehen muss.

    Vielen Dank noch mal für Eure Antworten.


    ATD : nein, dass hilft leider nicht.
    Leider habe ich (fragt mich nicht wie), einige Konfigurationsdateien zerschossen. Ich hatte plötzlich links, die auf sich selbst gezeigt haben.
    Bin dabei, wenigstens den alten Zustand wieder herzustellen.


    Wenn Ihr mir danach weiterhelfen könntet?

    Hallo ATD,


    danke noch mal für Deine Antwort.


    Ich weiß, das diese IP-Adressen "doppelt gemobbelt" sind. Wie oben erwähnt, habe ich einfach alles ausprobiert.
    Der Port von streamdev-client und server ist 2004. Aber mein raspberry funktoniert ja auch mit streamdev einwandfrei und auf Anhieb.
    Ich möchte aber mit dem vdr-plugin-xineliboutput konekten. Der Default-Port ist hier 37890. Streamdev nützt mir hier nichts, da ich die Funktionen und das Menü direkt vom Server benötige. Das Menü funktioniert ja auch. Auf dem Server selber konektiert ein vdr-sxfe local und macht alles, was man so vom vdr erwartet. Nur brauche ich genau diese Funktion jetzt über das Netzwerk. Wie gesagt, die Fernsteuerung mit Aufrufen des Menüs funktioniert ja auch. Nur leider habe ich kein Bild.


    Also: ich möchte auf meinem Remote-PC vdr-sxfe aufrufen, dieses Programm soll mit dem VDR auf meinem Videoserver zusammenarbeiten und mit das Menü und das Bild vom Server anzeigen.

    Danke Gerald für Deine Antwort.


    Meine allowed_hosts.conf. sieht so aus:



    Habe da ein bißchen mit den ip-Adressen gespielt.


    Wie kann ich vorgehen?

    Zuerst einmal: ich weiß, dass dieses Thema oft diskutiert wurde, aber ich bin seit Tagen im Forum und auch anderswo dabei, nach einer Lösung zu suchen, finde aber keine:


    Ich habe einen vdr VDR-1.6.0-2. Dieser läuft schon lange mit xineliboutput-1.0.90-cv local mit vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.14, using xine-lib 1.1.20) auf dem vdr.
    Neu habe ich jetzt einen raspberry pi mit streamdev aufgesetzt, nach dieser Anleitung: http://www.vdr-wiki.de/wiki/in…Streamdev_und_rpihddevice
    Auch das läuft sehr gut. Vielen Dank an wen auch immer für dieses wiki, hat auf Anhieb funktioniert.


    Ich möchte nun aber vdr-sxfe auf einem anderen Rechner (os ist Linux ubuntu2Kern 3.2.0-58-generic) laufen lassen. vdr-sxfe startet und Ich kann das Menü des vdr auch aufrufen und bedienen, habe aber kein Bild, immer nur "NO Signal".


    Starte ich mit ./vdr-sxfe


    bekomme ich folgende ausgabe:


    Hier beschwert er sich über Pipe not found.



    starte ich mit ./vdr-sxfe --udp, also mit dem Zusatz --udp so erhalte ich folgendes





    Jetzt sagt er, das er den Stream findet, aber ich habe immer noch kein Bild. wie gesagt: vdr läuft einwandfrei auf dem Server und raspberry.


    Die streamdevhosts.conf sieht so aus:



    wobei 192.168.0.31 der raspberry und 192.168.0.48 mein Arbeitsrechner ist.


    Die plugin.xineliboutputput.conf sieht dann so aus:




    Ich bin komme echt nicht mehr weiter und bin für jede Hilfe dankbar.