Beiträge von OleS

    Dann verhält sich das Plugin aber merkwürdig - der VDR sollte ja sehen, dass er wegen einem ACPI-Wakeup Event geweckt wurde und dann MinEventTimeout warten, bis er den Shutdown einleitet (was steht da im syslog - "assuming manual start" oder "assuming start for acpi-wakeup"?):


    Code
    Mar  2 03:01:40 htpc vdr: [1232] scheduled wakeup time in 4 minutes, assuming automatic start of VDR
    Mar  2 03:01:52 htpc vdr-frontend[2127]: assuming start for acpi-wakeup

    Ok, gefunden:


    Das wären 3 Minuten vor der Zeit, hinzu kommt:

    Code
    MarginStart = 2


    Das wären dann insgesamt 5 Min. und woher kommen die fehlenden 3 Min.? *grübel*


    Cheers,
    Ole

    Hallo zusammen,


    ich habe hier mal wieder ein Timingproblem... :O


    Installiert ist xmltv2vdr in Kombination mit epgdata.com, der Abgleich der EPG-Daten soll nachts erfolgen, daher habe ich xmltv2vdr.options.wakeup = 1 in der setup.conf
    gesetzt und 3:09 als Aufwachzeit definiert. Im syslog habe nun folgendes:

    Code
    Mar  1 22:51:50 htpc vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2013-03-02 02:01:00


    Die Stundendifferenz rührt sicherlich vom UTC der RTC und die 8 Minuten kommen allem Anschein nach vom xmltv2vdr.
    Ein erstes Lebenszeichen im syslog:

    Code
    Mar  2 03:01:39 htpc kernel: imklog 5.8.6, log source = /proc/kmsg started.


    Und dann kommt der böse Shutdown (nach 5 Min., da das Frontend nicht aktiv ist - soll ja auch nicht.

    Code
    Mar  2 03:06:52 htpc vdr: [2071] dbus2vdr: new message, object /Shutdown, interface de.tvdr.vdr.shutdown, member ConfirmShutdown


    Die daraus resultierende Frage: Wo kann ich diesen Shutdown-Timeout einstellen, wenn das überhaupt so ohne weiteres möglich ist bzw. kann man xmltv2vdr
    dazu bringen, weniger als 8 Min. vor der Zeit zu booten?


    Cheers,
    Ole

    Hmm ok, und Probleme mit dem W im WAF möchte natürlich niemand...


    allerdings habe ich einen laufenden Suchtimer (der schon eine Zeit gut gearbeitet hat), der im Test mehr Ergebnisse liefert als er Timer anlegt.

    Daran könnte 'vermeide Wiederholungen' im Suchtimer schuld sein.
    Ansonsten vieleicht doch noch mal die timersdone.conf kontrollieren.


    Cheers,
    Ole

    Hallo zusammen,
    habe gerade --> hier <--einen evtl. zielführenden Hinweis erhalten - bin ja mittlerweile, was dieses spezielle Thema angeht, vorsichtig geworden. :D


    Ich habe (hatte) folgendes in der order.conf:

    Code
    graphtft
    -graphlcd
    -dvbhddevice
    -dvbsddevice
    -pvr350
    -dummydevice
    -xine
    -xineliboutput
    *dynamite


    Nachdem ich den graphtft-Eintrag gelöscht habe, konnte ich das System bisher immer (~15x) sauber booten. Also abwarten...


    Cheers,
    Ole


    PS: Ich betrachte das Thema als gelöst, da ich nach der oben genannten Änderung bisher immer sauber booten konnte.

    Es ist zum Haareraufen...die Kiste hängt immer noch sporadisch. Ich habe jetzt wieder den Urzustand hergestellt.
    Interpretiere ich richtig, dass der vdr an sich nicht startet?

    Code
    start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1


    Und hier mal ein Auszug vom syslog:


    Der letzte Eintrag stammt aller Wahrscheinlichkeit nach von meinem kill auf den vdr-Prozess.
    Ausschlaggebend ist wohl eher der Eintrag

    Code
    Feb 19 06:36:35 htpc kernel: [   14.276907] init: vdr main process (1185) killed by PIPE signal


    Vieleicht hat noch jemand eine Idee, in welche Richtung ich schauen kann?


    Cheers,
    Ole

    Nachdem ich heute schon wieder Bootprobleme (kein Bild am TV, DisplayLink-Device zeigt nur yaVDR-Logo) hatte, musste
    ich mich zwecks Ausrichtung des Haussegens mal wieder an diese Thema machen. Dabei fiel mir auf, dass das vdr-frontend
    mal vor und mal nach dem DisplayLink-Geraffel gestartet wurde...hmmmm.


    Schnell mal eine kleine Anpassung an /etc/init/vdr-frontend.conf gemacht (stopped openbox-tools in stopped openbox-tools-DL geändert):

    Code
    root@htpc:~# cp --parents -p /usr/share/yavdr/templates/etc/init/vdr-frontend.conf/10_start_stop /etc/yavdr/templates_custom/.


    /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/10_start_stop:

    Code
    start on started vdr or stopped openbox-tools-DL or started sound-device \
             or vdr-frontend-restart
    stop on stopping vdr or stopping openbox


    Code
    root@htpc:~# process-template /etc/init/vdr-frontend.conf


    Mal sehen, ob's das jetzt bringt. Sollte doch...


    Cheers,
    Ole

    Mit dem momentanen xvdr-Stand des ppa passt die Anzeige der Aufnahmen wieder:

    Code
    Paket vdr-plugin-xvdr:                            
    i A 0.9.6.git20130129-0yavdr-0~precise                                  precise                                          500 
    
    
    Paket xbmc-addon-xvdr:
    i A 0.9.7~git201301292346-0yavdr0~precise                               precise                                          500


    Cheers,
    Ole

    Jupp, läuft hier per cronjob:


    manuell geht's auch:

    Code
    root@htpc:~# svdrpsend-ng -d eplists.constabel.net -p 2006 -c -e UTF8 -o /var/cache/eplists/episodes TGET newer than 25 hours
    root@htpc:~#


    Und der normale Connect auf Port 2006 ist auch funktional:


    Evtl. Firewall auf deiner Seite oder das Connectionlimit des Servers eplists.constable.net ist/war überschritten (20 gleichzeitige Connects)?


    Cheers,
    Ole

    Nicht?


    Code
    -rw-r--r-- 1 root root   364 Feb 15 12:00 Apartment 23.episodes
    -rw-r--r-- 1 root root   346 Feb 15 12:00 2012 - Das Jahr Null.episodes
    -rw-rw-rw- 1 vdr  vdr   3066 Feb 15 12:00 Private Practice.episodes
    -rw-r--r-- 1 root root   689 Feb 15 12:00 What's up, Warthogs! - Die West Hill Highschool News.episodes
    drwxr-xr-x 2 vdr  vdr  36864 Feb 15 12:00 .
    -rw-r--r-- 1 root root   390 Feb 15 12:00 Wolfblood - Verwandlung bei Vollmond.episodes


    Hier geht's.


    Cheers,
    Ole

    Moin Holger,


    sieht gut aus:


    - joinfiles ohne vorhandene marks -> geht
    - prepare_traco_ts ohne vorhandene marks -> geht
    - joinfiles mit marks -> geht
    - prepare_traco_ts mit marks -> geht


    Danke und cheers,
    Ole

    Ausgecheckt und getestet:


    Fazit: Ohne marks funktionieren weder prepare_traco_ts noch joinfiles. Mit marks teste ich noch.


    Test mit marks:
    joinfiles funktioniert nicht, prepare_traco_ts schon.


    Cheers,
    Ole

    Hallo Holger,


    leider kein Erfolg:


    Cheers,
    Ole


    Nachtrag: joinfiles geht jetzt auch nicht mehr, wenn keine marks vorhanden ist. ;(

    Primäres Display im WFE ist :1.0 Panasonic TV, DFP-1, modeline: 1920x1080 50 Hz, falls du das meinst.
    Die X-Server laufen auch:

    Code
    root@htpc:/var/log/upstart# ps -ef | grep X
    root      1293  1285  0 10:32 tty7     00:00:01 X :1 vt7
    root      1444     1  0 10:32 ?        00:00:01 /usr/bin/X :2 -audit 0 -novtswitch -sharevts vt7


    Eigentlich geht jetzt auch alles wunderbar, mich hatte die Meldung bei meiner Suche nur in die falsche Richtung gebracht und wenn ich
    schon dabei bin, die Kiste zu debuggen... :) Sobald ich wieder Zugriff auf die Tastatur habe, werde mal testen ob x2x das macht, was es soll.


    Cheers,
    Ole