Beiträge von gandalf

Hallo *,

nachdem ich jetzt 3 Tage auf der Suche war, habe ich mich entschlossen doch mal ein neues Thema anzufangen. Ich benutze seid einiger Zeit VDRConvert um Aufnahmen nach MPG zu wandeln, und sie anschliessend auf einem PC zu brennen. Nun habe ich seid einer Woche einen DVD-Brenner in den VDR Rechner eingebaut und wollte selbstverständlich sofort eine DVD erstellen.

Es funktioniert auch ab und zu ganz gut, es wird ein ISO Image erstellt, aber er brennt dieses nachher nicht auf die eingelegte DVD+R.

Was habe ich gemacht um die Sache vielleicht doch noch ans Laufen zu bringen:

• Habe in der vdrconvert.dvd.conf die Option DVD_AUTOWRITE=yes aktiviert.
• Den richtigen Typ DVD-Rohlinge nach Empfehlung gekauft.
• Gecheckt dass das DVD-LW erkannt wird: vdr kernel: hdc: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
• Auf allen möglichen Homepages von vdrconvert gefahndet, wie vdrconvert.vdr-portal.de und der Site des Authors.

Leider weiss ich nicht, wo ich jetzt noch suchen soll. Vielleicht hat ja jemand eine zündende Idee. Ich weiss das tausende user erfolgreich DVDs brennen, schluchz ich will auch.
gandalf

Zitat

Original von maxkr
Hi gandalf,

das oben ist (war :D) natürlich Mist. Richtigerweise müssen die beiden Zeilen in der /etc/apache2/mods-available/proxy_html.load ergänzt werden. Zumindest war das bei mir erforderlich, da ich sonst abenteuerliche Fehlermeldungen erhalten habe...

Danke für den Hinweis mit der /etc/apache2/mods-available/proxy.conf
Das werde ich vieleicht mal probieren - aber andererseits läuft es ja auch bei mir...!

Viele Grüße,
Max

Alles anzeigen

So wie ich das verstanden habe sind die .load Dateien für die Ladeanweisungen gedacht und die .conf Datei konfiguriert das System. Aber auf der anderen Seite "Who knows".

Gandalf

Zitat

Original von wilderigel
Wofür gibts die Option zum Ausschalten?
URLs automatisch umwandeln: fügt automatisch ['url] und [/url] in Internet-Adressen ein.

Und so lernt man jeden Tag was dazu. Danke wilder Igel.

Bei mir, Apache2, geht es einfach über ein Hinzufügen von drei Zeilen in der proxy.conf im Verzeichnis /etc/apache2/mods-available. Im Ganzen sieht die Datei hernach so aus:

<IfModule mod_proxy.c>


        #turning ProxyRequests on and allowing proxying from all may allow
        #spammers to use your proxy to send email.


        ProxyRequests Off
        ProxyPass /vdradmin/ [URL]http://127.0.0.1:8001/[/URL]


        <Proxy *>
                Order deny,allow
                Deny from all
                Allow from 192.168.0.100
        </Proxy>


        # Enable/disable the handling of HTTP/1.1 "Via:" headers.
        # ("Full" adds the server version; "Block" removes all outgoing Via: headers)
        # Set to one of: Off | On | Full | Block


        ProxyVia On


        # To enable the cache as well, edit and uncomment the following lines:
        # (no cacheing without CacheRoot)


        CacheRoot "/var/cache/apache2/proxy"
        CacheSize 5
        CacheGcInterval 4
        CacheMaxExpire 24
        CacheLastModifiedFactor 0.1
        CacheDefaultExpire 1
        # Again, you probably should change this.
        #NoCache a_domain.com another_domain.edu joes.garage_sale.com


        RedirectMatch ^/xxv /xxv/
        ProxyPass /xxv/ [URL]http://127.0.0.1:8080/[/URL]
        ProxyPassReverse /xxv/ [URL]http://127.0.0.1:8080/[/URL]


</IfModule>

Die letzten 3 Zeilen reichen für xxv, die Zeilen bzgl. vdradmin stammen wohl von früheren Tests und könnten eventuell so nicht funktioneren, dass habe ich nicht mehr getestet.

Vorher sollte man noch sicher stellen dass die entsprechenden proxy-... Dateien im Verzeichnis /etc/apache2/mods-enabled verlinkt sind, nur dann werden sie auch geladen.
Bei mir reichten folgende Einträge:

:
:
lrwxr-xr-x  1 root root 28 2005-02-03 19:06 proxy.conf -> ../mods-available/proxy.conf
lrwxr-xr-x  1 root root 36 2005-02-03 19:06 proxy_connect.load -> ../mods-available/proxy_connect.load
lrwxr-xr-x  1 root root 28 2005-02-03 19:06 proxy.load -> ../mods-available/proxy.load
:
:

ACHTUNG:
Alle Tags der Form '['URL], bzw. [/URL] werden vom VDR-Portal-System hinzugefügt und sind keinesfalls mit einzugeben. Vorsicht beim Kopieren, die müssen hernach alle wieder gelöscht werden!!!! Man selbst die Tags hier reinzuschreiben war gar nicht so einfach, normalerweise bleiben sie unsichtbar. Da half nur die erste Klammer in '' zu setzen, was natürlich nicht der Realität entspricht.

Gandalf

Zitat

Original von maxkr
Hi,

nachdem ich auch etwas gesucht habe bis es endlich funktioniert hat hier die schnelle Anleitung wie an Apache2 als Proxy vor den vdradmin schaltet:

:
:
/etc/apache2/mods-available

Code

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

... sonst gab es Fehler!

:
:

Alles anzeigen

Hmmm... bei mir ist /etc/apache2/mods_available ein Verzeichnis. Da will mein vi so recht nix reinschreiben, schon gar nicht die beiden Zeilen die du angegeben hast.

Wo schreib ichs nun hin? Uff, glück gehabt bei mir scheint es auch ohne dass zu gehen. Nur dass er die Seite

Forbidden


You don't have permission to access /xxv/ on this server.

raushaut. Kann es sein dass da aus irgendwelchen Gründen die Passwordseite nicht aufgerufen wird, und dass man ohne password halt eben keinen Zugang bekommt?

Gandalf

Zitat

Original von wilderigel
gandalf

Den Tread kennst du?

Ich schwöre ich bin schon ein paar Tage am Suchen

Na jetzt klappt es jedenfalls. Danke für die prompte Hilfe wilder Igel

Gandalf

Hi Tobi, TomG, Xpix, Hulk oder wer sonst noch sich berufen fühlt

Ich weiß es ist kein plugin, nicht mal ein addon, aber seid einigen VDR-Versionen, sicher zumindest seid der .23, ist wohl das Datumsformat für Timer und Aufnahmen geändert worden. Vdr-xxv hat enorme Probleme mit diesem neuen Speicherformat (z.B. werden auf der Timer-Seite alle Timer unter einem Datum angezeigt, mit den entsprechenden Überlappwarnhinweisen; Timer können nicht editiert werden, da dann das vom VDR kommende Datum als fehlerhaft angemeckert wird etc.)

Ist da schon eine Abhilfe in Sicht?

gandalf

Sorry, falsches Forum

Hi Hulk, xpix

Seid der Version 1.3.23 des vdrdevel (ist jedenfalls die erste bei der ich das gemerkt habe) wurde wohl endlich das Aufnahmedatum von einer blossen Zahl auf ein vollwertiges Datum geändert. Habt ihr schon ne angepasste Version von xxv in der Queue, oder kann man das Problem eventuell gar mit einem Fix beheben?

Gruß,
gandalf

Moin,

habe mir mal das log angeschaut und folgendes ist gegenüber der Beta dazugekommen

565 (1585) [11:54:31 02/28/05] Undefined subroutine &Template::Plugin::File::getpwuid called at /usr/lib/perl5/Template/Plugin/File.pm line 104.

Irgendeine Idee woran das liegt? Mir ist aufgefallen das mit der Debianisierung auch die Einführung eines dedizierten users für xxv einhergegangen ist. Hängt es damit zusammen?
gandalf

OK,

mit den oben genannten Änderungen funzt es wie bereits von den letzten Betas gewohnt. Das war doch mal problemlos.

Wenn mir jetzt noch jemand eine Konfiguration der Grabrate im Modul REMOTE reinmachen könnte wär ich schon glücklich... fürs erste. Ich hab immer den Eindruck es ist was abgestürzt wenn ich 5 sec. auf das nächste Bild warten muss ;D. Und so muss ich nicht bei jeder neuen Version in den widgets rumfuschen.

[EDIT]
Wers aber wissen muss, hier kann man das ändern:

remote.tmpl:201:var interval = 1

[/EDIT]

Superleistung aber das sagte ich ja bereits des Öfteren.
Gandalf

Hallo Tobi,

danke für deine Mühe. Versuche gerade von der Betaversion auf das Debian Paket umzusteigen. Habe dabei nach der Installation ein diff der Konfigurationsdatei gemacht. Dabei sind mir noch ein paar andere Pfadunterschiede aufgefallen. Es handelt sich immer um das vdr/vdrdevel Thema.

1. [CHANNELS]
< file=/var/lib/vdr/channels.conf
> file=/var/lib/vdrdevel/channels.conf

2. [EPG]
< epgfile=/var/cache/vdr/epg.data
> epgfile=/var/cache/vdrdevel/epg.data

3. [RECORDS]
< commandfile=/var/lib/vdr/reccmds.conf
> commandfile=/var/lib/vdrdevel/reccmds.conf

4. [TIMERS]
< file=/var/lib/vdr/timers.conf
> file=/var/lib/vdrdevel/timers.conf

Ausserdem habe ich im [VTX] Abschnitt mit

cache=packed

gute Erfahrungen gemacht, dass muss ich aber jetzt erst noch prüfen.

Mal sehen pb das Ding jetzt auch noch startet.

Gruss,
gandalf

Zitat

Original von Habib
Klasse, konnte noch nix "nicht funktionierendes" feststellen*g* klasse release.

Tja, es ist wirklich ägerlich

Nichts zu meckern soweit. Bis jetzt das beste Release! Ich habe sogar mal fast alle Vorschaubilder. Nur die leidigen Aufnahmen der Teletubbies haben wie gehabt kein Bild. Und das meiner Meinung nach völlig ohne Grund. Die Ordnerstruktur ist in keiner Weise verschieden zu Jim Knopf etc. Mal reinschauen. Oha, kann es sein das der Prozess Probleme bei der Bilderzeugung hat wenn die 001.vdr unter 3 Minuten enthält. Bei den Teletubbies scheint das regelmässig der Fall zu sein. In einem Fall hat der vdr 001.vdr-067.vdr(!) produziert. Die anderen beiden sind nicht ganz so schlimm aber immer ist die 001.vdr im Bereich von einem Mega. Darunter fällt sehe ich gerade auch eine Aufmnahme von Jim Knopf die insgesamt verpatzt wurde, der vdr hat nur 3 Minuten aufgezeichnet. Na denn ist das ja auch noch geklärt. Ich kann damit leben, normalerweise sind die Aufnahmen ja denn doch größer als 3 Minuten. Wenn ihr trotzdem was drehen wollt, ein find und ein ls -l liegen bei. Die fehlende Ordnerbasis ist [i]/video/Kinderserien/Teletubbies[]/i]

Gandalf

Zitat

Original von wilderigel
Habe es mal provoziert:

Müssen die ganzen mplayer Treads auf einmal laufen?

Hab es gar nicht provozieren müssen. Bei mir liegt wie schon berichtet in regelmässigen Abständen, alle 5 Minuten, das gesamte System lahm. Das beeinträchtigt dann auch laufende Aufnahmen, Artefakte sind die Folge.

vdr-duero100:/var/log# top
top - 19:08:29 up  2:03,  2 users,  load average: 54.40, 19.58, 18.18
Tasks: 301 total,  73 running, 228 sleeping,   0 stopped,   0 zombie
Cpu(s):   2.9% user,  32.6% system,  64.5% nice,   0.0% idle
Mem:    515268k total,   510420k used,     4848k free,     9596k buffers
Swap:   996020k total,    52048k used,   943972k free,   190540k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7733 root      20  10  7044 7016 6956 R 13.2  1.4   0:00.60 mplayer
 7735 root      20  10  7044 7016 6956 R 12.9  1.4   0:00.45 mplayer
 7730 root      18  10  7312 7284 7176 R 12.5  1.4   0:00.76 mplayer
 7763 root      20  10  7044 7016 6956 R 10.7  1.4   0:00.34 mplayer
 7727 root      15  10  7308 7280 7172 R 10.3  1.4   0:00.92 mplayer
 7766 root      20  10  7044 7016 6956 R  7.8  1.4   0:00.25 mplayer
 7724 root      15  10  7316 7288 7180 R  6.3  1.4   0:01.14 mplayer
 7768 root      19  10  7260 7224 4152 R  5.6  1.4   0:00.18 mplayer
 7578 root      17   0  1212 1212  844 R  3.1  0.2   0:00.81 top
 1633 root       9   0 37164  17m 5148 R  1.9  3.6   1:18.12 vdrdevel
 3348 root       9   0 37164  17m 5148 S  1.9  3.6   0:03.48 vdrdevel
 1639 root       9   0 37164  17m 5148 S  1.3  3.6   0:33.07 vdrdevel
 3313 root       9   0 37164  17m 5148 S  0.6  3.6   0:05.71 vdrdevel
 7255 root      15  10 10496  10m 8388 R  0.6  2.0   0:00.75 mplayer
 7298 root      15  10  9896 9876 7856 R  0.6  1.9   0:00.79 mplayer
 7424 root      15  10  9888 9868 7856 R  0.6  1.9   0:00.81 mplayer
 7428 root      15  10  9884 9864 7856 R  0.6  1.9   0:00.67 mplayer
 7459 root      15  10  9888 9868 7856 R  0.6  1.9   0:00.74 mplayer
 7659 root      15  10  8916 8896 7792 R  0.6  1.7   0:00.92 mplayer
 7662 root      16  10  8940 8920 7788 R  0.6  1.7   0:00.96 mplayer
 1636 root       9   0 37164  17m 5148 S  0.3  3.6   0:12.43 vdrdevel
 1641 root       9   0 37164  17m 5148 S  0.3  3.6   0:21.66 vdrdevel
 3310 root       9   0 37164  17m 5148 S  0.3  3.6   0:00.01 vdrdevel
 3899 root      15  10 18656  18m 2264 D  0.3  3.6   0:14.49 xxvd
 7310 root      15  10  9916 9896 7856 R  0.3  1.9   0:01.05 mplayer
 7339 root      15  10  7620 7592 7460 R  0.3  1.5   0:00.03 mplayer
 7413 root      15  10  9900 9880 7856 R  0.3  1.9   0:00.78 mplayer
 7456 root      15  10  9892 9872 7856 R  0.3  1.9   0:00.71 mplayer
 7467 root      15  10  9872 9852 7856 R  0.3  1.9   0:00.79 mplayer
 7471 root      15  10  7620 7592 7460 D  0.3  1.5   0:00.01 mplayer
 7473 root      15  10  9924 9904 7856 R  0.3  1.9   0:00.79 mplayer
 7500 root      15  10  7520 7492 7368 D  0.3  1.5   0:00.03 mplayer
 7502 root      15  10  9888 9868 7856 R  0.3  1.9   0:00.84 mplayer
 7508 root      15  10  7520 7492 7360 R  0.3  1.5   0:00.02 mplayer
 7539 root      15  10  9556 9536 7780 R  0.3  1.9   0:01.07 mplayer
 7574 root      15  10  9560 9540 7780 R  0.3  1.9   0:00.89 mplayer
 7577 root      15  10  9568 9548 7780 R  0.3  1.9   0:00.71 mplayer
 7580 root      15  10  9552 9532 7780 R  0.3  1.8   0:00.73 mplayer
 7583 root      15  10  7620 7592 7468 R  0.3  1.5   0:00.01 mplayer
 7588 root      15  10  7620 7592 7468 R  0.3  1.5   0:00.02 mplayer
 7655 root      15  10  8904 8884 7788 R  0.3  1.7   0:00.98 mplayer
 7657 root      15  10  7620 7592 7476 D  0.3  1.5   0:00.02 mplayer
 7725 root      15  10  7364 7336 7248 R  0.3  1.4   0:00.01 mplayer

Die mplayer threads (34!)nehmen locker über 80% CPU in Anspruch.

Ich werde den xxvd Daemon bis auf weiteres nur bei Bedarf aktivieren können
gandalf

Zitat

Original von Hulk

Meine xxvd_mplayer.log Logdatei heisst /dev/null und bereitet keinerlei Platzprobleme
Sollte man aber nur machen wenn mplayer funktioniert...

Ansonsten sei "man logrotate" empfohlen.

Andreas

Alles anzeigen

Da ich jetzt innerhalb einer Stunde wieder 500 Mega mplayer_log hatte scheint mir /dev/null die einzige Möglichkeit zu bleiben. Siehe auch nächsten Post.

xpix
Irgendwas müsst ihr euch noch für die xxvd_mplayer.log einfallen lassen

-rw-r--r--  1 root        root 1478464057 2005-02-21 15:44 xxvd_mplayer.log

gandalf

Habe ich gemacht. Nach dem Neustart hat er aber jetzt wohl ein Problem mit der Timers DB. Also wollte ich die auch löschen. Der drop table TIMERS; dauerte aber dann doch seeehhhr lange, also versuchte ich einen /etc/init.d/mysql stop. Auch das kommt zu keinem Ende. Was ist da wohl kapput. Ich werde jetzt rebooten und nochmal einen Versuch starten. Wie droppt man denn die ganze DB xxv?
Gruß und Danke,
gandalf

P.S.: Ich habe gerade nochmal machgedacht was gestern abend anders war. Ich habe den Rechner mit vdrdevel-plugin-sleeptimer runtergefahren. Kann es sein das der so brutal vorgeht dass die DB im inkonstistenten Zustand gelassen wurde?

Uuhps im syslog steht:

Feb 22 16:30:38 vdr-duero100 mysqld[1228]: 050222 16:30:38 [ERROR] /usr/sbin/mysqld: Disk is full writing '/var/lib/mysql/xxv/EPG.MYI' (Errcode: 28). Waiting for someone to free space... Retry in 60 secs

Da waren 1,5 Gigabyte frei. Ich muss dringend was unternehmen, nur was?

xpix, Hulk

URGENT
Heute scheint der xxvd nicht so recht zu wollen. Gestern nacht habe ich ihn ordnungsgemäss runtergefahren und heute das:

vdr-duero100:~# tail -20 /var/log/xxvd.log
39 (3411) [14:48:24 02/22/05] Load Module XXV::MODULES::RECORDS = 0.01
40 (3411) [14:48:24 02/22/05] Load Module XXV::MODULES::MUSIC = 0.01
41 (3411) [14:48:24 02/22/05] Load Module XXV::MODULES::INTERFACE = 0.01
42 (3411) [14:48:24 02/22/05] Load Module XXV::MODULES::HTTPD = 0.02
43 (3411) [14:48:24 02/22/05] Load Module XXV::MODULES::GRAB = 0.01
44 (3411) [14:48:25 02/22/05] Load Module XXV::MODULES::EPG = 0.01
45 (3411) [14:48:25 02/22/05] Load Module XXV::MODULES::CONFIG = 0.01
46 (3411) [14:48:25 02/22/05] DBD::mysql::st execute failed: Can't open file: 'CHANNELS.MYI' (errno: 145) at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 145.
47 (3411) [14:48:25 02/22/05] Can't open file: 'CHANNELS.MYI' (errno: 145) - select * from CHANNELS WHERE 0 = 1 at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 60.
48 (3411) [14:48:25 02/22/05] =========== top of stack =========
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:61 (Tools::stackTrace)
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:145 (Tools::error)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/CHANNELS.pm:134 (Tools::fields)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/CHANNELS.pm:113 (XXV::MODULES::CHANNELS::init)
./bin/xxvd:192 (XXV::MODULES::CHANNELS::new)
./bin/xxvd:169 (main::init)
: ()
: ()
=========== end of stack =========
49 (3411) [14:48:25 02/22/05] Can't use an undefined value as an ARRAY reference at /var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/CHANNELS.pm line 134.

Was läuft da schief?

Gandalf

Zitat

Original von Habib
Hi xpix,

es nimmt langsam Formen an:) wird immer besser und runder das ganze.

Jetzt hab ich grad ein aktuelles Problem mit der "g". Ich kann in Konfiguration-->HTTPD keine Skins mehr in der Liste sehen. Ich hab jetzt testweise snow in die xxvd.cfg manuell eingetragen, das funktioniert auch soweit, nur per GUI bekomm ich wie gesagt keine Umschaltung mehr angeboten.

Mein Fehler? Ich hab die cfg wieder nur rüberkopiert?

Alles anzeigen

Verrätst du mir was du geändert hast. Ich habe das selbe Problem habe aber die cfg nicht kopiert sondern nur wieder mit meinen Einträgen wie mysql-user, -pw etc. gepatcht. Trotzdem habe ich keine Einträge in der Liste.
gandalf

xpix
Aber hallo, das wars in der Tat. Funzt.

Leider habe ich ein neues Problem. In regelmässigen Abständen ist der vdr Rechner schwer beschäftigt. Ich denke das liegt an dem separaten Update-Prozess der Aufnahmen. Habe jetzt auch was Neues im Log gefunden. Vielleicht gibt es ja einen Zusammenhang

73 (10207) [12:24:34 02/21/05] IO::Socket::INET: connect: Connection refused at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 60.
74 (10207) [12:24:34 02/21/05] =========== top of stack =========
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:61 (Tools::stackTrace)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:79 (Tools::error)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:96 (XXV::MODULES::SVDRP::connect)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:633 (XXV::MODULES::SVDRP::command)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:239 (XXV::MODULES::TIMERS::cmd)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:275 (XXV::MODULES::TIMERS::saveTimer)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:131 (XXV::MODULES::AUTOTIMER::autotimer)
/usr/lib/perl5/Event.pm:164 (XXV::MODULES::AUTOTIMER::__ANON__)
/usr/lib/perl5/Event.pm:164 ((eval))
./bin/xxvd:173 (Event::loop)
: ()
: ()
=========== end of stack =========
75 (10207) [12:24:34 02/21/05] Could not open the svdrp-socket! at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 60.
76 (10207) [12:24:34 02/21/05] =========== top of stack =========
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:61 (Tools::stackTrace)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:96 (Tools::error)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:633 (XXV::MODULES::SVDRP::command)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:239 (XXV::MODULES::TIMERS::cmd)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:275 (XXV::MODULES::TIMERS::saveTimer)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:131 (XXV::MODULES::AUTOTIMER::autotimer)
/usr/lib/perl5/Event.pm:164 (XXV::MODULES::AUTOTIMER::__ANON__)
/usr/lib/perl5/Event.pm:164 ((eval))
./bin/xxvd:173 (Event::loop)
: ()
: ()
=========== end of stack =========
77 (10207) [12:24:34 02/21/05] IO::Socket::INET: connect: Connection refused at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 60.
78 (10207) [12:24:34 02/21/05] =========== top of stack =========
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:61 (Tools::stackTrace)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:79 (Tools::error)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:96 (XXV::MODULES::SVDRP::connect)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:633 (XXV::MODULES::SVDRP::command)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:239 (XXV::MODULES::TIMERS::cmd)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:275 (XXV::MODULES::TIMERS::saveTimer)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:131 (XXV::MODULES::AUTOTIMER::autotimer)
/usr/lib/perl5/Event.pm:164 (XXV::MODULES::AUTOTIMER::__ANON__)
/usr/lib/perl5/Event.pm:164 ((eval))
./bin/xxvd:173 (Event::loop)
: ()
: ()
=========== end of stack =========
79 (10207) [12:24:34 02/21/05] Could not open the svdrp-socket! at /var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm line 60.
80 (10207) [12:24:34 02/21/05] =========== top of stack =========
/var/lib/xxv/xxv-0.17g/bin/../lib/Tools.pm:61 (Tools::stackTrace)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/SVDRP.pm:96 (Tools::error)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:633 (XXV::MODULES::SVDRP::command)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/TIMERS.pm:239 (XXV::MODULES::TIMERS::cmd)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:275 (XXV::MODULES::TIMERS::saveTimer)
/var/lib/xxv/xxv-0.17g/bin/../lib/XXV/MODULES/AUTOTIMER.pm:131 (XXV::MODULES::AUTOTIMER::autotimer)
/usr/lib/perl5/Event.pm:164 (XXV::MODULES::AUTOTIMER::__ANON__)
/usr/lib/perl5/Event.pm:164 ((eval))
./bin/xxvd:173 (Event::loop)
: ()
: ()
=========== end of stack =========

Irgendeine Idee was da an der Kommunkation mit dem vdr nicht tut. Der vdr läuft jedenfalls meiner Meinung nach problemlos. soll heissen ich kann fernsehen und alles. Im top stehen in diesen Phasen bis zu 10 Instanzen von mplayer, mysql schluckt gleich mal 10%! CPU und das scheint den Rechner doch ein wenig in die Knie zu zwingen. Jedenfalls gibts beim Fernsehen Artefakte, selbst die tail -f /var/log/xxvd.lo Logausgaben stocken etc.
gandalf