Beiträge von FJe

    moin,


    hab mich eben auch erschreckt.
    Mein vdr im wz meldete

    Code
    Sep 16 20:10:27 yvwz vdr: [1512] XVDR: removing outdated recording (7c753de7) '/srv/vdr/video.00/yvsz/%Alf%/Alf/In_letzter_Minute/2013-04-02.19.18.31-0.rec' from cache
    Sep 16 20:10:27 yvwz vdr: [1512] XVDR: removing outdated recording (7de3dfad) '/srv/vdr/video.00/yvsz/%Castle%/Castle/2013.05.31-20:15-Fr/2013-05-31.20.13.25-0.rec' from cache
    usw.


    Dachte auch erst, es wäre ein Löschen von Aufnahmen.
    Allerdings war es wohl nur, dass der XVDR die per avahi-mount gelesenen Aufnahmen aus seinem Cache entfernte, weil der Server gerade nicht lief.
    Ein Löschen der Aufnahmen hat er nicht gemacht, das hab ich gecheckt.


    Sah es zufällig im webif beim log-check. hab sofort vdr gestoppt und jetzt in der order.conf erst mal -xvdr eingetragen, bis ich weiss, ob das ungefährlich ist.
    Ist das normal? Und wird er nix löschen, wenn er aus dem cache geworfen hat und dann der avahi server wiederkommt und die Aufnahmen wieder da sind?
    Sollte man derzeit auf vnsi wechseln?


    Wäre für eine beruhigende Antwort dankbar.


    Bye
    Frank

    moin,


    woher kommt denn die erste Zeile?


    "Sep 13 23:22:00 frank1 vdr: [1764] XVDR: Recordings state changed (429)"
    und
    "Sep 14 12:41:32 frank1 vdr: [1858] XVDR: Recordings state changed (86)"


    sagt er da nicht, dass von irgendwoher ein Lösch-Kommando kam?
    Was war vorher?


    Bye
    Frank

    moin,


    das sieht nicht richtig aus, eigentlich müsste in der xorg.conf.yavdr ein Verweis auf die edid sein.
    Schätze, Du must noch mal neu installieren, ohne testing o.ä., yavdr 0.5a pur, ohne neuen Teiber o.ä.


    Falls Bild, im WebIF nach reboot Anzeige erkennen und schauen, ob media-build-experimental-dkms installieren wurde.


    Dabei sorgfältig auf Fehler schauen und die notieren.


    Dauert ja nich lang, geht schneller als Fehler suchen, meine Erfahrung.


    Sorry, keine besseren Nachrichten
    Frank

    Wenn Du keine edid bei Dir hast, dann boote den Rechner, geh ins WebIF, da findest Du unter Anzeige (glaube ich, aus dem Kopf) einen Knopf "Anzeige / Bildschirm neu erkennen".


    Den versuchen und dann nachschauen, ob edid erstellt wurde und was das syslog / dmesg sagen.


    Bei mir ging das mal auch erst nach dem zweiten reboot, seit dem läuft aber alles problemlos.
    Ob wegen des Receivers dazwischen manchmal bei der Installation die Erkennung nicht geht? (war bei immer nur der Effekt, wenn AV Receiver zwischen vdr und TV.)


    Bye
    Frank

    moin Polaris,


    genau das hab ich mir auch bestellt.


    Hast Du evt. mal weitere Info's wie xorf.conf.yavdr, von wann ist die edid, was sagt Xorg.?.log?
    Läuft über lsmod überhaupt ein nvidia-treiber und wenn welcher?
    wie sieht die xorg.conf nach "nvidia-xconfig" aus im Vergleich zur xorg.conf.yavdr?


    EDit: Ich vergaß: Welchen Kernel und hast Du den media-build-experimental-dkms installiert? (Könnte evt. das Ton-Problem lösen nach S.2 aus dem Post, den Du oben verlinkt hast?)


    Bye
    Frank

    moin,


    bei mir geht es nur mit "hpet=disable", "acpi_enforce...=lax" konnte bleiben, er wacht sauber auf zu den Timern.
    Kernel ist 3.2.0-49.


    Im Log steht nach wie vor, "System eventuell instabil wg acpi, wenn es Treiber gibt, nutze den statt Standard-Modul", scheitn aber keinen Einfluß zu haben, geht alles problemlos.


    bye
    Frank

    Hab's jetzt nicht im Kopf, ist bei einer Standard Installation im WebIF der Haken gesetzt für SSH beim Watchdog?
    Ich meine, ich hätte nach der Installation da einige Haken gesetzt, weiss aber nich mehr, ob SSH dabei war.


    Dann tut das bei mir prima.


    Bye
    Frank

    moin,


    als autodidaktischer Dilettant mit inzwischen zwei-drei verschiedenen vdr's als "normaler" TV-Geniesser mit den wundervollen vdr-Features kann ich sagen, dass mir das Wiki oft geholfen hat.
    Viele Fragen musste ich in Foren nicht stellen, weil sie aus dem Wiki (oder den distri-Dokus) beantwortet wurden.


    Denke, das geht vielen "nur-vdr-Nutzern" so, darum hier 500 Pfund sehr positives Feedback für alle Entwickler, Wiki-Autoren und Fragenbeantworter in Foren.


    Geh jetzt mit meinem VDR was Aufgenommenes fernsehen dank Euch.


    Bye
    frank

    moin,


    dann doch noch mal meine Erfahrung. Hab auch AMD Rechner und letztens fancontrol ausprobiert.
    Nach der Installation wachte der vdr auch nicht mehr auf.
    Im LOG stand "ACPI hat ein Problem mit inkompatiblen Modulen", pwmconfig hatte it87 in /etc/modules eingetragen, das wurde als Problem gelistet.

    Code
    dmesg|grep -i acpi


    zeigte es.


    fancontrol deinstalliert, /ertc/modules korrigiert, leider keine Änderung. acpid und ???acpi??? mit reinstall neu installiert, leider keine Änderung.


    dmesg|grep -i acpi sagt immer noch "System kann instabil sein, weil da was mit acpi nicht passt".


    Ich bau jetzt ein neues Motherboard ein und installiere neu.


    Bye
    Frank

    moin,


    ich hab sowas auch mal versucht, das dann aber aufgeben. Unix (Linux) ist dafür nicht gemacht.


    Hatte viel versucht mit geschachtelten mount's (SSD in 2 Partitionen geteilt, die 2. (nur 1 GB groß) nach /srv/vdr gemountet, da dann video.00 angelegt und dann auf diese /srv/vdr/video.00 die USB gemountet. Dann nahm der vdr bei Fehlen der USB eben nur max. 1 GB auf, aber die root-Platte konnte nicht volllaufen.)
    oder dann ein script-System in den dvb-hooks, dann udev-Regeln, die hab ich schnell wieder aufgegeben, wer das erfunden hat ...).


    Jetzt hab ich neben der SSD eine zweite normale 2,5-Zoll HDD drin, die per fstab nach /srv/vdr/video.00 gemountet wird als Aufnahmeverzeichnis und eine USB-Platte auch mit ntfs dran.
    Die Filme werden per cron und cp -xurpv quelle ziel Abends um 1900h von intern auf USB kopiert, dann kann ich jederzeit die USB abziehen und hab noch einen vollständigen vdr.
    Hören tut man die 2,5er aus 1m nicht mehr.


    Falls Du Lebensdauerangst hast bei der SSD wg. "Filme aufnehmen erzeugt zu viel write auf SSD", schätze, die anderen Komponenten im PC gehen kaputt, bevor die SSD nich mehr tut.


    bye
    Frank

    moin,


    ist das Konzept eine gute Idee? Denn der vdr verteilt die Aufnahmen auf drei Platten.
    (siehe die Ziele der drei ts-Dateien). Wenn eine der Platten defekt wird, sind die
    Aufnahmen unvollständig/zerstört weil eins der ts fehlt.


    Ich mach das so, dass ich die anderen Platten nach /mnt/sdb2 usw. mounte und
    dann als Link in das video-Verzeichnis hänge.
    Dann noch /mnt/sdxn in die /etc/exports mit rein und diese ggf. im WebIF auf dem
    client bekannt machen.


    Je nach Platz schieb ich dann bei gestopptem VDR Filme hin und her, je nach
    Archivierungsbedarf.


    Bye
    Frank

    moin,


    ich hab's gefunden.


    Der Vergleich zwischen dem vdr 1 und vdr2 zeigte, dass die Ordner und Dateien unter
    /home/user/ beim nicht funktionierenden vdr nicht dem User sondern root gehörten.
    Also
    /home/user/.dbus gehörte root mit drwx------ statt user und dazu die Dateien im sub-dir.
    Damit konnte nur root die DAteien von user sehen und lesen.


    ein beherztes "chown -R user:user /home/user/.dbus" brachte sofort einen superflinken firefox
    über openbox ohne weitere Fehlermeldungen, auch nach reboot.
    Auch die 100% Belastung der CPU ist seitdem weg.


    Vermute folgendes:
    Hatte Problem nach der Inst mit der Bildschirmerkennung,
    hatte mich auf tty1 angemeldet und als root ein X als :0 gestartet und in dem ein vdr-frontend
    (das zeigte mir, dass es grundsätzlich geht, später dann per Bildschirmerkennung gelöst)
    Dabei ist anscheinend unter /home/user von root das .dbus angelegt worden mit den Rechten root
    (weil das der erste Start eines X war).


    Danach hat dann die X :1 session immer versucht /home/user/.dbus zu lesen,
    was wg.
    drwx------ root ... 0 .dbus
    natürlich nicht ging.


    Uff.
    So geniesst man sein Hobby, oder?


    Schönen Abend
    Frank

    moin,


    mir ist noch was aufgefallen:


    auf dem vdrr2, da geht der firefox problemlos, läuft unter root eine dbus-session, die es beim vdr1 nicht gibt:


    ermittelt mit " locate dbus|grep \/\.dbus\/"
    vdr2 (geht):

    Code
    /home/yavdr05/.dbus/session-bus
    /home/yavdr05/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1
    
    
    /root/.dbus/session-bus
    /root/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1
    
    
    /var/lib/vdr/.dbus/session-bus
    /var/lib/vdr/.dbus/session-bus/836bf58bf273f74c17f4d300000004ef-1


    vdr1 (geht nicht)

    Code
    /home/frank/.dbus/session-bus
    /home/frank/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-0
    /home/frank/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-1
    
    
    ??? 
    
    
    /var/lib/vdr/.dbus/session-bus
    /var/lib/vdr/.dbus/session-bus/96b5cd5e45b8ca684f4dc414000002c8-1


    dafür laufen zwei sessions unter dem user.


    Was ist korrekt laut yavdr-SOLL?


    bye
    Frank

    moin,


    danke für die Antwort.


    Es ist der nvidia vdr1 mit der SSD.
    Das syslog liegt unter pastebinit (http://paste.ubuntu.com/5637588/)
    Das übliche greppen da drin nach error usw. und dbus in /var/log/* und /var/log/upstart/* hat zumindest mir nix gezeigt.



    Updates bietet er mir an


    Sollte nicht daran liegen (kernel und gnu utils), oder?.


    bye
    frank

    moin,


    habe nach der Neu-Installation leider zwei Kümmernisse:


    1. Der Firefox aus dem VDR oder dem Menue aufgerufen ist unbenutzbar, da er praktisch nicht reagiert.
    var/log/upstart/firefox.log läuft voll mit

    Code
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-aEtCr0FEbC: Verbindungsaufbau abgelehnt
    
    
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-HBKjo4hbeC: Verbindungsaufbau abgelehnt
    
    
    (firefox:2263): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
    Failed to connect to socket /tmp/dbus-EhL0zbZ5mr: Verbindungsaufbau abgelehnt


    ein "sudo restart dbus" oder andere Restarts des vdr helfen nicht, genauso wenig wie Reboots.
    Hatte ist in diesem Thread gelesen, sollte aber ja eigentlich nicht mehr auftauchen.



    Dazu kommt
    2. der vdr-sxfe Prozess belegt einen cpu-Kern mit 100%, auch hier helfen keine Reboots:


    Ich kann leider weder über go* noch hier im Portal Hinweise finden, was ich tun könnte.
    Hättet Ihr einen Tipp für mich, wie ich Ursachenforschung betreiben kann?



    Seufz
    Franl

    Moin,. ein simples "Anzeige erkennen im WFE" hat vorhin funktioniert, sorry für den langen Post.




    Moin,


    brauch mal Hilfe, da ich trotz intensiver Suche hier im Board nicht weiterkomme.
    Habe yavdr 0.5 auf neuer SSD am vdr1 mit nvidia gt430 und tbs6981 installiert, lief auch soweit alles gut.
    Nach Installation aktueller Treiber TBS hab ich auch EPG und im WFE unter Live/Fernbedienung alle Sekunde das TV Bild.
    Also vdr an sich geht, hat Empfang.
    Leider krieg ich nach Boot kein Bild auf den Schirm, der TV hat kein Signal, Ton über HDMI ist aber da, auch Abschalten frontend gibt kein Bild, keine openbox Oberfläche (weder xineliboutput noch softhddevice gehen, immer gleicher Effekt)
    Wenn ich auf ein anderes tty per strg-alt-F1 schalte, dort mit startx openbox starte, krieg ich graues Bild mit Maus und MEnue auf rechter Maustaste. Da dann Terminal öffnen, vdr-sxfe mit dem identischen Befehl wie beim Boot aufgerufen: geht, gutes Bild, Ton, Menue alles da.
    Also es geht, nur ist irgendwas beim Boot verhackt und ich hab nur folgende Hinweise in den anhängenden Logs gefunden, weiss aber nicht, wo danach suchen soll, sorry.


    aus /var/lib/upstart/vdr-frontend.log


    aus der /var/lib/uostart/openbox.log


    Ist es richtig, dass er auf Display :1 geht? Ist nicht :0 normal?


    Wo kann ich wohl suchen?


    Moin,. ein simples "Anzeige erkennen im WFE" hat vorhin funktioniert, sorry für den langen Post.



    Seufz
    fje