[announce] ALCD 0.4.0

Oh schön was Neues.
Danke, gleich mal probieren.

Gruss ulf

btw. bis jetzt ja alle alcd Versionen ohne Probleme

helau, kannst du evtl einen "hab activy frontpanel ja/nein" standalone dingsi basteln?

hintergrund: linvdr auto-detect activy install

wuerde ja nen exit code 0 bzw !0 langen.

-- randy

Hi,

also bei meiner AMC350 bringt biosinfo folgendes

Zitat

[root@amc350 nvram-wakeup-0.97]# ./biosinfo
Following DMI entries found:
- Mainboard vendor: "FUJITSU SIEMENS"
- Mainboard type: "D1636"
- Mainboard revision: "S26361-D1636"
- BIOS vendor: "FUJITSU SIEMENS // Phoenix Technologies Ltd."
- BIOS version: "4.06 Rev. 1.01.1636"
- BIOS release: "12/10/2003"

Alles anzeigen

bei einer AMC200 neu sollte D1638 kommen, wenn Zeit ist werd ich das mal prüfen.

CU
9000h

Hi.

lspci -v AMC350

Zitat

[root@amc350 nvram-wakeup-0.97]# lspci -v
00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory Controller Hub] (rev 03)
Flags: bus master, fast devsel, latency 0

00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=120
I/O behind bridge: 00003000-00003fff
Memory behind bridge: fc000000-fdffffff

00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02)
Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) (prog-if 80 [Master])
Subsystem: Intel Corp. 82801AA IDE
Flags: bus master, medium devsel, latency 0
I/O ports at 1c00 [size=16]

00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) (prog-if 00 [UHCI])
Subsystem: Intel Corp. 82801AA USB
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at 1000 [size=32]

00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02)
Subsystem: Intel Corp. 82801AA SMBus
Flags: medium devsel, IRQ 5
I/O ports at 1400 [size=16]

00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02)
Subsystem: Unknown device 1734:1025
Flags: bus master, medium devsel, latency 0, IRQ 5
I/O ports at 2000 [size=256]
I/O ports at 1800 [size=64]

01:06.0 VGA compatible controller: Intergraphics Systems CyberPro 5000 (rev 03) (prog-if 00 [VGA])
Subsystem: Unknown device 0280:7000
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
I/O ports at 3000 [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]

01:08.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10)
Subsystem: Siemens Nixdorf AG: Unknown device 008b
Flags: bus master, medium devsel, latency 66, IRQ 9
Memory at fc120000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 3400 [size=64]
Memory at fc100000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [dc] Power Management version 2

01:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000
Flags: bus master, medium devsel, latency 123, IRQ 11
Memory at fc121000 (32-bit, non-prefetchable) [size=512]

01:0a.0 Multimedia controller: Sigma Designs, Inc. EM840x REALmagic DVD/MPEG-2 Audio/Video Decoder (rev 01)
Subsystem: Sigma Designs, Inc.: Unknown device 00ff
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at fc000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [40] Power Management version 1

Alles anzeigen

CU
9000h

Hi,

hier noch der einzige Error von einem kurzen Test des neuen alcd-0.4.0 auf der AMC350

Zitat

Jan 17 22:26:15 amc350 vdr[3971]: starting plugin: alcd
Jan 17 22:26:15 amc350 vdr[3983]: Streamdev: Listening (HTTP) on port 3000
Jan 17 22:26:16 amc350 vdr[3971]: alcd-plugin: Failing Command: <8900>
Jan 17 22:26:16 amc350 vdr[3971]: alcd-plugin: ResCode: 2 <8922>
Jan 17 22:26:16 amc350 vdr[3971]: alcd-plugin: Activy300-LCD-SW Revision: Release: 2 Version: 0 PreRelease: VirtualNumber: 51

Alles anzeigen

ich glaub das war die Abfrage der HW Revision die in der neuen Firmware nicht mehr unterstuetzt wird.

CU
9000h

Zitat

Original von 9000H
also bei meiner AMC350 bringt biosinfo folgendes

Hi,
bei meiner AMC-320 sieht es genau so aus:

./biosinfo
Following DMI entries found:
 - Mainboard vendor:   "FUJITSU SIEMENS"
 - Mainboard type:     "D1636"
 - Mainboard revision: "S26361-D1636"
 - BIOS vendor:        "FUJITSU SIEMENS // Phoenix Technologies Ltd."
 - BIOS version:       "4.06  Rev. 1.01.1636"
 - BIOS release:       "12/10/2003"

Hallo Leute,

nur als Tipp, damit Ihr nicht in die gleiche Falle lauft wie ich.

Nach dem erfolgreichen "Debianisieren" und Installieren des Plugins, konnte das Display beim Starten des VDRs nicht gefunden werden. Fehlermeldung im Log "Failed ..." In den Plugineinstellung stand auch der Punkt "Display vorhanden" auf "nein".

Hintergrund war bei mir, dass der VDR nicht mit root-Rechten lief und deshalb das /dev/ttyS0 nicht beschreiben konnte.

Beim ctVDR4.5 reichte es aus, einfach den User "vdr" zur Gruppe "dialout" hinzuzufügen.

Jetzt klappt es auch mit dem Plugin

Hallo,

super, bei mir funktioniert's.

Nur eine Bitte: Kannst Du bitte den Funktionszweck der einzelnen Skripte dokumentieren? Ich habe z.B. nicht verstanden, ob activy_pb.sh den Power-Button an oder ausschaltet und wie.

Und ein kleiner Bug-Report: Wenn ich activy_msg.sh benutze, kommt es manchmal vor, dass die Tastatur "neu erkannt" wird und von meinem 2.6.15.1 Kernel als /class/input/input(alte nummer +1) erkannt wird.

Ist dies das Display-Problem, von dem hier immer wieder geschrieben wurde?

Danke,

Hanno

Zitat

Iiiiih - dann nehme ich doch lieber die Scripte raus als diese zu dokumentieren

Äh, ich versteh Dich ja, ich bin auch Software-Entwickler. Aber trotzdem: In der jetzigen Form ist das Plugin-Quellpaket etwas schwer zu verstehen, wenn man alle Hintergrundinfos hier im Forum zusammensuchen muss. Also: Bitte, bitte... Es hätte ja ein Einzeiler am Start des Skripts gereicht.

Zitat

activy_pb [...]

Danke für die Info!

Zitat

Zum activy_msg problem kann ich gar nichts sagen, sofern vdr laeuft koenntest Du anstelle dessen auch svdrpsend.pl MESG nutzen. Damit kommt auch die Anzeige an, und es kollidiert nicht mit dem ALCD plugin.

Ich hatte activy_msg nur getestet, während vdr nicht lief.

Wann tritt dieses "Panel stürzt ab" Problem eigentlich auf? Ich habe erst seit vorgestern einen gebrauchten Activy und bin aus den Forenbeiträgen zu diesem Problem nicht so ganz schlau geworden - weder ob man das Problem wirklich lösen kann, noch, ob ich mit Doktern am Symptom nun die Activy-Fernbedienung guten Gewissens benutzen kann oder wegen der ständigen Panel-Absturzgefahr doch lieber auf die FB meiner DVB-Karte wechseln sollte. Die Einschalt-Möglichkeit per FB sehe ich doch als einen Riesenvorteil...

Nochmals danke,

Hanno

Hi,

hier ein Patch für alle die vdr-1.3.38 oder größer haben.

CU
9000h

Merkwürdiges Phänomen:

Wenn ich vdr per /etc/init.d/vdr stop beende, wird die Hintergrundbeleuchtung des Displays (wie in den Plugin-Einstellungen gewünscht) abgschaltet.

Wenn ich vdr aber über die Fernbedienung beende, bleibt sie hell.

Zitat

Original von 9000Hhier ein Patch für alle die vdr-1.3.38 oder größer haben.

Was macht denn der Patch? Bei mir funktionierte schon das ungepatchte Plugin unter 1.3.40.

Danke,

Hanno

Zitat

Original von Hanno
Merkwürdiges Phänomen:

Wenn ich vdr per /etc/init.d/vdr stop beende, wird die Hintergrundbeleuchtung des Displays (wie in den Plugin-Einstellungen gewünscht) abgschaltet.

Wenn ich vdr aber über die Fernbedienung beende, bleibt sie hell.

Ich habe ein wenig nachgeforscht und habe ein Symptom, aber noch keine Ursache. Das Verhalten ist reproduzierbar und tritt bei allen Tests wie oben beschrieben auf.

Wenn ich /etc/init.d/vdr stop auf der Konsole eingebe, fährt der vdr sauber herunter.

Jan 31 01:39:45 localhost vdr: [3741] caught signal 15
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: alcd
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: timeline
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: text2skin
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: femon
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: dvd
Jan 31 01:39:45 localhost vdr: [3741] stopping plugin: osdteletext
Jan 31 01:39:45 localhost vdr: [3808] KBD remote control thread ended (pid=3808, tid=3808)
Jan 31 01:39:45 localhost vdr: [3741] saved setup to /var/lib/vdr/setup.conf
Jan 31 01:39:46 localhost vdr: [3756] tuner on device 1 thread ended (pid=3756, tid=3756)
Jan 31 01:39:46 localhost vdr: [3810] receiver on device 1 thread ended (pid=3810, tid=3810)
Jan 31 01:39:47 localhost vdr: [3757] section handler thread ended (pid=3757, tid=3757)
Jan 31 01:39:47 localhost vdr: [3741] deleting plugin: alcd
Jan 31 01:39:48 localhost vdr: [3741] deleting plugin: timeline
Jan 31 01:39:48 localhost vdr: [3741] deleting plugin: text2skin
Jan 31 01:39:48 localhost vdr: [3741] deleting plugin: femon
Jan 31 01:39:48 localhost vdr: [3741] deleting plugin: dvd
Jan 31 01:39:48 localhost vdr: [3741] deleting plugin: osdteletext
Jan 31 01:39:48 localhost vdr: [3741] buffer stats: 0 (0%) used
Jan 31 01:39:48 localhost vdr: [3741] max. latency time 1 seconds
Jan 31 01:39:48 localhost vdr: [3741] exiting

Wenn aber der sysvinit beim Herunterfahren des Systems /etc/init.d/vdr stop ausführt, stürzt der "KBD remote control thread" (hier Thread Nr. 4123) ab:

Jan 31 01:41:07 localhost vdr: [4056] caught signal 15
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: alcd
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: timeline
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: text2skin
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: femon
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: dvd
Jan 31 01:41:07 localhost vdr: [4056] stopping plugin: osdteletext
Jan 31 01:41:10 localhost vdr: [4056] ERROR: thread 4123 won't end (waited 3 seconds) - canceling it...
Jan 31 01:41:10 localhost vdr: [4056] saved setup to /var/lib/vdr/setup.conf
Jan 31 01:41:11 localhost vdr: [4071] tuner on device 1 thread ended (pid=4071, tid=4071)
Jan 31 01:41:11 localhost vdr: [4125] receiver on device 1 thread ended (pid=4125, tid=4125)

Irgendeine Idee, warum "vdr stop" sich unter diesen beiden Umständen so unterschiedlich verhalten kann? Ich habe mir das Environment beider ausgeführten Kommandos anzeigen lassen. PATH ist bei beiden gleich gesetzt. Beide werden von root ausgeführt.

Zitat

Original von Hanno
Merkwürdiges Phänomen

So, ein Update auf c't vdr 1.3.41 mit dem alcd-Plugin (inkl. 9000H Patch) ergibt folgendes:

Das Display bleibt weiterhin hell, wenn ich vdr über die Fernbedienung oder über "Menu / Befehle / System herunterfahren" beende. (Das war auch bei der vorherigen Version falsch.)

Jetzt schaltet sich das Display korrekt ab, wenn ich den Rechner per "halt" herunterfahre (Das war bei der vorherigen Version noch falsch.)

Das Display schaltet sich korrekt ab, wenn ich von der Konsole aus "/etc/init.d/vdr stop" ausführe. (War zuvor auch korrekt.)

Offenbar wird das Plugin nicht beendet, wenn vdr herunterfährt. Oder so. Liegt der Fehler beim Plugin oder beim vdr?