Beiträge von dtriphaus

Hallo zusammen!

Gleiches problem hier mit der 0.3, ich sehe zum Beispiel in der DVD-Wiedergabe und XBMC diese weißen Artefakte in schwarzen Flächen, gleiches gilt auch für die TV-Ausgabe mit XINE-Frontend. Hat von euch schon jemand eine Lösung gefunden?

Aber alles in allem an dieser Stelle erst nochmal ein riesen Lob an die yavdr-Entwickler! Die 0.3 ist echt genial geworden

Hallo zusammen,

ich glaube ich habe die Ursache des Verhaltens gefunden. Es ist wohl nach meinen jüngsten Tests so, dass Timer nicht gelöscht werden, wenn ich VPS für den Timer aktiviere, der Sender allerdings kein VPS zur Verfügung stellt. Erstelle ich Timer ohne VPS für Sender ohne VPS werden die Timer scheinbar immer gelöscht, erstelle ich Timer mit VPS für Sender die VPS unterstützen werden die Timer ebenfalls gelöscht. Lediglich die Timer mit VPS für Sender, die kein VPS unterstützen scheinen nicht (oder maximal selten) gelöscht zu werden. Kann jemand dieses Verhalten bei sich ebenfalls feststellen oder mir sagen woran das liegt, bzw ob dies eine logische Ursache ist?

Gruß

Hallo zusammen,

ich habe das Problem, dass manchmal die timer nach der Aufname nicht entfernt werden. Die timer müssen dann manuell gelöscht werden (z.B. über das OSD). Das Nichtentfernen ist deswegen so ärgerlich, da der VDR dann nach der Aufnahme nie herunterfährt, selbst dann nicht, wenn der Inaktivitätstimer greifen müsste, er läuft also ewig weiter bis der Timer manuell gelöscht wird. Woran kann das liegen, dass es manchmal passiert? Hier einmal 2 Beispiele, wie die timers.conf aussieht, wenn die Einträge nicht gelöscht wurde. Warum der Status manchmal so "hoch" ist (erste Zahl) weiß ich dann auch nicht, ist aus dem Wiki nicht ersichtlich wie das zustande kommen kann. Allerdings werden (ist getestet) auch Timer mit einem so hohen Status ordnungsgemäß gelöscht.

Beispiel 1 (date && cat /etc/vdr/timers.conf)

Sa 9. Mai 00:11:07 CEST 2009
29:S19.2E-133-33-51:2009-05-08:2210:0025:50:99:The Call 2:
5:S19.2E-1-1089-12040:2009-05-08:2341:2345:50:99:S RTL:


Sa 9. Mai 00:24:33 CEST 2009
29:S19.2E-133-33-51:2009-05-08:2210:0025:50:99:The Call 2:
5:S19.2E-1-1089-12040:2009-05-08:2341:2345:50:99:S RTL:


Sa 9. Mai 00:46:22 CEST 2009
21:S19.2E-133-33-51:2009-05-08:2210:0025:50:99:The Call 2:
21:S19.2E-1-1089-12040:2009-05-08:2341:2345:50:99:S RTL:

Beispiel 2 (date && cat /etc/vdr/timers.conf)

So 10. Mai 02:14:53 CEST 2009
21:S19.2E-1-1107-17501:2009-05-09:2212:2358:50:99:Saw III:

Noad ist übrigens zum testen momentan komplett deaktiviert, sollte demnach nicht schuld sein.

Wär für jeden Hinweis dankbar! Ich nutze übrigens VDR 1.7.0 und easyvdr mit HDRepack2.

Gruß

Ja die Einstellungen stimmen überein und ich nutze (wie ich deinem Beitrag vorher entnehme) auch die gleichen Configdateien, wobei: Muss es da nicht remote.conf heissen statt remotes.conf? Im Zweifel würde ich die Dateien nochmal kontrollieren, evtl wurden die überschrieben (durch was auch immer...)

Also bei mir kann ich bisher nur sagen, dass der Treiber läuft! Riesendank an dich Rene!

T.H.S.: hast du in der sysconfig den lirc aktiv?

EDIT: Diese beiden Einstellungen:
START_LIRC_REMOTE="yes"
USE_LIRC="yes"

Scheint allerdings auch nicht jedes mal zu klappen, hier die Fehlermeldung:

Speicherzugriffsfehler
(none) kernel: [  170.283329] Oops: 0000 [#1] PREEMPT SMP
 (none) kernel: [  170.283334] last sysfs file: /sys/devices/pci0000:00/0000:00:18.3/temp4_input
 (none) kernel: [  170.283373] Process insmod (pid: 8178, ti=f4902000 task=f6102440 task.ti=f4902000)
 (none) kernel: [  170.283375] Stack:
 (none) kernel: [  170.283381]  f7133400 f69b7108 f611dc00 f8c948a0 c059c267 f8c948a0 c059c85a f69d9a00
 (none) kernel: [  170.283386]  00000000 f69d9a1c f8c948a0 c059d766 f69d9a1c f69d9a94 c04569e0 f8c94820
 (none) kernel: [  170.283391] Call Trace:
 (none) kernel: [  170.283393]  [<c01d3d45>] sysfs_addrm_finish+0x15/0x1d0
 (none) kernel: [  170.283400]  [<c01d3ab2>] sysfs_add_one+0x12/0x50
 (none) kernel: [  170.283403]  [<c059c267>] usb_match_one_id+0x27/0xc0
 (none) kernel: [  170.283407]  [<c059c85a>] usb_autopm_do_device+0x7a/0xf0
 (none) kernel: [  170.283410]  [<c059d766>] usb_probe_interface+0xa6/0x150
 (none) kernel: [  170.283412]  [<c04569e0>] __driver_attach+0x0/0x80
 (none) kernel: [  170.283417]  [<c04569e0>] __driver_attach+0x0/0x80
 (none) kernel: [  170.283419]  [<c04568e8>] driver_probe_device+0x88/0x180
 (none) kernel: [  170.283422]  [<c06c2399>] _spin_lock_irqsave+0x19/0x40
 (none) kernel: [  170.283427]  [<c04569e0>] __driver_attach+0x0/0x80
 (none) kernel: [  170.283429]  [<c0456a5e>] __driver_attach+0x7e/0x80
 (none) kernel: [  170.283432]  [<c0455fe8>] bus_for_each_dev+0x38/0x60
 (none) kernel: [  170.283435]  [<c0456766>] driver_attach+0x16/0x20
 (none) kernel: [  170.283438]  [<c04569e0>] __driver_attach+0x0/0x80
 (none) kernel: [  170.283440]  [<c045653e>] bus_add_driver+0x1be/0x230
 (none) kernel: [  170.283444]  [<c0456bdd>] driver_register+0x4d/0x120
 (none) kernel: [  170.283447]  [<c059cff1>] usb_register_driver+0x81/0x100
 (none) kernel: [  170.283450]  [<f87e7000>] imontouch_init+0x0/0x6f [lirc_imontouch]
 (none) kernel: [  170.283453]  [<f87e7000>] imontouch_init+0x0/0x6f [lirc_imontouch]
 (none) kernel: [  170.283456]  [<f87e7043>] imontouch_init+0x43/0x6f [lirc_imontouch]
 (none) kernel: [  170.283460]  [<c0101127>] do_one_initcall+0x37/0x1b0
 (none) kernel: [  170.283462]  [<c017a9cb>] free_unmap_vmap_area_noflush+0x2b/0x70
 (none) kernel: [  170.283466]  [<c017ab48>] __vunmap+0x58/0xc0
 (none) kernel: [  170.283469]  [<c01512a2>] load_module+0x1772/0x1970
 (none) kernel: [  170.283473]  [<c01512a2>] load_module+0x1772/0x1970
 (none) kernel: [  170.283477]  [<c03e5c48>] __percpu_counter_add+0x98/0xf0
 (none) kernel: [  170.283482]  [<c0151527>] sys_init_module+0x87/0x1a0
 (none) kernel: [  170.283484]  [<c018cdfd>] sys_close+0x6d/0xb0
 (none) kernel: [  170.283489]  [<c01033a2>] syscall_call+0x7/0xb
 (none) kernel: [  170.283491] Code: 39 c9 f8 89 44 24 08 b8 ff 34 c9 f8 89 44 24 04 e8 48 a0 49 c7 31 c0 ba d0 00 00 00 e8 9c 7c 90 c7 85 c0 89 c3 0f 84 2                                         1 06 00 00 <8b> 45 28 be ff 34 c9 f8 8b 40 28 89 74 24 04 c7 04 24 1c 3a c9
 (none) kernel: [  170.283518] EIP: [<f8c923be>] imontouch_probe+0xbe/0x7d0 [lirc_imontouch] SS:ESP 0068:f4903ce0
<<

Gruß

EDIT: Scheint zu funktionieren wenn man das device erst anschließt nachdem die Treiber geladen sind, zumindest beobachte ich das Phänomen hier.

Hallo rehar,

erstmal verbindlichsten Dank für die Bemühungen deinerseits, dass unter 2.6.28.x ans Laufen zu bekommen!

Wenn ich die module wie von dir beschrieben nicht beim start laden lasse, sondern später gibt es keine probleme, beim booten hängt die kiste sich allerdings komplett auf. (Die Neuinstallation kann man sich allerdings durch einfaches abziehen des USB-Devices auch sparen, falls man noch dran kommt). Hast du ne idee warum das beim Bootvorgang nicht klappt, später allerdings schon? Kanns an der Reihenfolge beim laden liegen oder sowas in der Art?

Hallo, ich habe das GA-M56S-S3 ebenfalls hier verbaut, allerdings bekomme ich ACPI-Wakeup nicht mit Datum ans laufen, lediglich Uhrzeit funtioniert. Hier ein paar Infos:

/proc/acpi/alarm nach dem Reboot (vorher stimmts halt noch)

2009-00-00 20:18:00

wie man sieht kein Datum...

Hier der Auszug aus /proc/acpi/fadt

root@easyVDR:~# xxd -g 1 fadt.bin
0000000: 46 41 43 50 74 00 00 00 01 dd 47 42 54 20 20 20  FACPt.....GBT
0000010: 4e 56 44 41 41 43 50 49 31 2e 30 42 4e 56 44 41  NVDAACPI1.0BNVDA
0000020: 01 01 01 01 00 00 ef 7f c0 30 ef 7f 00 01 09 00  .........0......
0000030: 2e 14 00 00 a1 a0 00 00 00 10 00 00 00 00 00 00  ................
0000040: 04 10 00 00 00 00 00 00 1c 10 00 00 08 10 00 00  ................
0000050: 20 10 00 00 a0 14 00 00 04 02 01 04 08 10 20 00   ............. .
0000060: 65 00 e9 03 00 00 00 00 01 03 *7d* *7e* 32 00 00 00  e.........}~2...
0000070: *a5* 04 00 00                                      ....

laut VDR Wiki (http://www.vdr-wiki.de/wiki/index.php/ACPI_Wakeup) sollten die in * stehenden Werte, falls ungleich Null ein Indiz dafür sein, dass Tag und Monat sowie Wakeup aus S4 (für mich egal) funktionieren sollen. Naja tun Sie aber nicht!

Hier noch der Auszug aus /proc/drivers/rtc

rtc_time        : 21:20:44
rtc_date        : 2009-04-14
rtc_epoch       : 1900
alarm           : 20:18:00
DST_enable      : no
BCD             : yes
24hr            : yes
square_wave     : no
alarm_IRQ       : no
update_IRQ      : no
periodic_IRQ    : no
periodic_freq   : 0
batt_status     : okay

Habe hier im Board schon gelesen, dass es funktionieren soll mit dem Mainboard, kann mir vielleicht jemand helfen? Evtl liegts an der Bios-Version? Ich habe aktuell F5 (ist das neuste).

Gruß

Es liegt/lag wohl daran, dass beim herunterfahren die /etc/vdr/setup.conf nicht korrekt geschrieben wurde und demnach auch der Eintrag "NextWakeupTime" nicht korrekt gesetzt wird. Dann kann der VDR auch nicht wissen, dass er wegen dieses Timers gestartet wurde. Geholfen hat eine Erhöhung des Wertes "KILLWAIT" in der /etc/init.d/Runvdr von 10 auf 20. Vielleicht hilft es ja anderen auch weiter.

Hallo, ich nutze EasyVDR (VDR 1.4.7, Kernel 2.6.28.7) und ACPI-Wakeup. Wakeup funktioniert einwandfrei, auch mit Vorlaufzeit. Allerdings fährt der Rechner nach der Aufnahme nicht mehr herunter (nur, wenn die Inaktivitätszeit erreicht wird). Normalerweise sollte der doch nach 5 Minuten oder sowas herunterfahren. Ich habe folgende Stellen im Log gefunden, die warscheinlich damit zusammen hängen:

... Apr 12 21:12:37 (none) user.debug vdr: [6255] assuming manual start of VDR ...

...
Apr 12 21:25:01 (none) user.info vdr: [6255] timer 2 (5 2115-2125 'kabel eins') stop
...
Apr 12 21:25:02 (none) user.debug vdr: [6255] max. latency time 2 seconds
Apr 12 21:25:02 (none) user.info vdr: [6255] connect from 127.0.0.1, port 36630 - accepted
Apr 12 21:25:02 (none) user.info vdr: [6255] caught signal 13
Apr 12 21:25:02 (none) user.err vdr: [6255] ERROR (svdrp.c,413): Datenýbergabe unterbrochen (broken pipe)
Apr 12 21:25:02 (none) user.info vdr: [6255] closing SVDRP connection
...

...
Apr 12 21:25:43 (none) user.info vdr: [6255] connect from 127.0.0.1, port 36631 - accepted
Apr 12 21:25:43 (none) user.info vdr: [6255] caught signal 13
Apr 12 21:25:43 (none) user.err vdr: [6255] ERROR (svdrp.c,413): Datenübergabe unterbrochen (broken pipe)
Apr 12 21:25:43 (none) user.info vdr: [6255] closing SVDRP connection
Apr 12 21:26:13 (none) user.info vdr: [6255] deleting timer 2 (5 2115-2125 'kabel eins')
...

Vielleicht hilft das ja jemandem mir zu helfen ;), ich habe schon versucht da mehr ausfindig zu machen, weiß aber nicht mehr weiter. Sollte noch etwas an Informationen fehlen, ich reiche gerne nach.

Danke schonmal im voraus!