Beiträge von kls

Halt, ich muss mich korrigieren. cControl::Control() liefert NULL zurück, wenn es zwar ein cControl gibt, dieses aber im Moment "hidden" ist. Also könnte mein Vorschlag von #6 doch funktionieren.

Bitte ausprobieren.

Klaus

Das beobachte ich hier auch und bin in Kontakt mit Thomas.

Wahrscheinlich wird zur Unzeit ein OSD-Flush oder sowas gemacht.

Wir klären das, kann aber etwas dauern.

Klaus

Da fällt mir ein, der "Transfer-Mode" (cTransfer) benutzt ja auch ein cControl. Somit scheidet mein Vorschlag von oben auch schon gleich wieder aus, denn sonst würde der VDR im Live-TV-Modus auch nie runterfahren.

Also bleibt wohl nur, den Patch zurückzuziehen und das Radio-Plugin muss sich etwas anderes überlegen. Was muss es auch ständig das OSD offen halten?

Klaus

Das ursprüngliche Problem wurde von Ulrich Eckhardt berichtet und bestand darin, dass das Radio-Plugin dauerhaft ein OSD offen hält, um die RDS-Daten anzuzeigen. Der Patch sollte dafür sorgen, dass der VDR trotzdem automatisch heruntergefahren wir. Nun weiß ich nicht, ob das Radio-Plugin ein cControl anlegt für seine Wiedergabe (ich fürchte ja). Wenn nicht, dann könnte es helfen, in vdr.c die Zeile

if (!cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {

in

if (!cControl::Control() && !cRecordControls::Active() && !RecordingsHandler.Active() && (Now - cRemote::LastActivity()) > ACTIVITYTIMEOUT) {

zu ändern. Sollte aber das Radio-Plugin tatsächlich ein cControl anlegen, dann würde ich eher dazu tendieren, den ganzen Patch zurückzuziehen und zu sagen, dass, wenn ein cControl aktiv ist, der automatische Shutdown halt eben ausgehebelt ist.

Kann bitte mal jemand klären, ob das Radio-Plugin ein cControl benutzt?

Klaus

Zu den Warnungen in recording.c:

Zeile 2901 sieht bei mir in VDR 2.4.0 so aus:

FileName::~cFileName()

also handelt es sich wohl um eine gepatchte Version.

Die memcpy()-Stelle hat nur mit dem Index zu tun, kann also an der falschen Sortierreihenfolge nicht schuld sein.

Ich glaube zwar nicht, dass die strncpy()-Stelle etwas damit zu tun hat, aber um das auszuschließen wäre es zunächst interessant zu wissen, ob beim Start von VDR die Option --dirnames oder --vfat angegeben wurde.

Am besten baut ihr mal in der Funktion cRecording::SortName() (in recording.c) ein paar Debug-Ausgaben ein um zu sehen, welche Namen da für die Sortierung erzeugt werden.

Klaus

I'm afraid there is no such logging option in VDR.

Klaus

If your CAM has a "debug menu" you might be able to observe the EMM/ECM counters. If they increase over time, the CAM is receiving the necessary data.

And no, I don't use any external patches ;-).

Klaus

I also use the DD DuoFlex CI with DVB-S, and my subscriptions get updated just fine. It even works via SAT>IP.

Klaus

You need to tune to the transponder that carries the subscription updates from time to time.

Klaus

Danke für den Test. Vielleicht sollte ich erstmal klären warum "setxkbmap -query" bei mir etwas anderes liefert.

Ich habe die Spur jetzt nach /etc/X11/xdm/keytable und weiter nach /etc/X11/xorg.conf.d verfolgt. Dort steht bei mir in /etc/X11/xorg.conf.d/00-keyboard.conf:

Irgendwie soll diese Datei wohl via /etc/X11/xdm/keytable erzeugt werden, aber ich schaffe es nicht, da was anderes als "us" reinzubringen.

Kannst du bitte mal den Inhalt deiner /etc/X11/xorg.conf.d/00-keyboard.conf posten?

Klaus

openSUSE speichert diese Dateien anscheinend in /usr/share/X11/xkb/symbols.

Ein "setxkbmap -query" liefert bei mir

rules: evdev

model: pc105

layout: us

was etwas verwunderlich ist, denn ich habe als Tastaturbelegung bei der Installation "German, nodeadkeys" angegeben.

In der Hoffnung, meine via Xmodmap eingestellte Tastaturbelegung auf einfache Weise dort hinterlegen zu können, habe ich mit "xkbcomp $DISPLAY" eine Datei server-0.xkb erzeugt, die vom Aufbau her den Dateien in /usr/share/X11/xkb/symbols recht ähnlich sieht. Diese habe ich dann unter /usr/share/X11/xkb/symbols/us gespeichert und den X-Server neu gestartet - mit dem Ergebnis, dass überhaupt keine Tastatureingaben mehr möglich waren :-(. Nachdem ich die ursprüngliche "us"-Datei wieder eingespielt hatte, funktionierte es zumindest wieder so wie vorher.

Ich hänge meine server-0.xkb mal hier dran, vielleicht kannst du ja erkennen, warum diese nicht apzeptiert wird.

Klaus

Einen Aufruf von xmodmap (direkt oder über udev) wollte ich eigentlich vermeiden, denn das dauert einige Zeit, während der der Desktop teilweise recht träge ist und die Tasten eben noch nicht richtig belegt sind.

Was ich erreichen möchte ist, dass das System meine Tastenbelegung als "nativen Default" benutzt. Irgendwo muss es ja wohl eine Datei geben, die hierfür zuständig ist

xkbcomp hab ich gerade nochmal probiert, es bringt aber auch auf dem neuen System die o.g. Meldungen.

Müsste ich das als root laufen lassen? Oder müsste ich das server-0.xkm File irgendwo hinkopieren, wo es beim Start greift?

Klaus

Nachdem ich dieser Tage meinen Arbeitsrechner neu installieren musste (openSUSE Leap 15.0), greife ich diesen etwas älteren Thread nochmal auf, in der Hoffnung, dass vielleicht noch jemand eine Idee hat, die zur Lösung des Problems führt.

Ich benutze eine Apple Aluminium Tastatur, auf deren Tasten ich die zum Programmieren nötigen Sonderzeichen wie z.B. '[]{}\@' an meine gewohnten Stellen gelegt habe. Dazu benutze ich eine Datei die Keycodes wie z.B.

enthält. Diese gzippe ich und kopiere sie nach /usr/share/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz, ersetze also damit die vom System installierte Version dieser Datei.

In /etc/vconsole.conf steht bereits von der Installation her "KEYMAP=mac-de-latin1-nodeadkeys", so dass ein "mkinitrd" die von mir veränderte Datei für künftige Sysetmstarts einbaut. Nach einem Reboot habe ich dann an den virtuellen Konsolen (tty1 etc.) die gewünschte Tastaturbelegung.

Für den Desktop unter X11 habe ich die Tastaturbelegung bisher über ~/.Xmodmap gemacht, aber leider geht diese Belegung verloren, sobald die Tastatur vom USB-Port abgetrennt wird (ich schalte wie oben erwähnt über einen KVM-Switch zwischen verschiedenen Rechnern um). Nach dem Zurückschalten auf den Desktop-Rechner muss ich jedesmal erst wieder "xmodmap ~/.Xmodmap" machen.

Nun habe ich versucht herauszufinden, wo die Default-Tastenbelegung liegt, die X11 verwendet (wenn der Benutzer keine ~/.Xmodmap hat). Wenn ich diese (so wie oben für die virtuellen Konsolen) austauschen könnte, dann wäre der Default gleich für mich passend. Nur leider finde ich nicht heraus, was das Äquivalent zu /usr/share/kbd/keymaps/legacy/mac/all/mac-de-latin1-nodeadkeys.map.gz für X11 ist.

Kann da jemand weiterhelfen?

Klaus

Hab's gefunden: https://ask.fedoraproject.org/…dont-require-the-fn-press

echo 2 > /sys/module/hid_apple/parameters/fnmode

bzw.

echo "options hid_apple fnmode=2" > /etc/modprobe.d/50-hid_apple.conf

Klaus

Nachdem ich auf meinem Arbeitsrechner openSUSE Leap 15.0 installiert habe ist die Belegung der F-Tasten plötzlich invertiert. Wenn ich z.B. 'F3' drücke, werden alle offenen Fenster verkleinert angezeigt, anstatt die Funktion 'F3' an die laufende Applikation weiterzugeben. Ich muss jetzt jedesmal 'fn+F3' drücken (gilt für alle F-Tasten).

Im Web fand ich viele Hinweise, dass man das im BIOS einstellen können soll. Aber mein BIOS hat keine solche Einstellung. Und ausserdem hat es vorher (mit openSUSE 42.3) auch einwandfrei funktioniert.

Weiß jemand Rat?

Klaus

"pavucontrol" wurde anscheinend defaultmäßig nicht installiert.

Nachdem ich das installiert und darin unter "Configuration" "Digital Stereo (HDMI) Output" habe, funktioniert es!

Vielen Dank!!

Klaus

"pactl list sinks" liefert

Eine "/etc/asound.conf" gibt es nicht (auch nicht auf dem alten System).

Was es gibt (identisch auf beiden Systemen) ist eine "/etc/asound-pulse.conf":

Eine "~/.asoundrc" gibt es nicht (meine Home-Directory ist in beiden Fällen das Gleiche).

Ich war heute leider gezwungen, meinen Arbeitsrechner neu zu installieren (Leap 15.0, war vorher 42.3).

Leider funktioniert die Tonausgabe über HDMI jetzt nicht mehr.

Mit 'aplay -l' erhalte ich zwar

Aber wenn ich mit YaST versuche, den Sound zu konfigurieren, sehe ich nur "Sunrise Point-H HD Audio" und nichts mit "Intel" oder "HDMI".

Mit Leap 42.3 hat das prima funktioniert (bis auf das Problem von hier, das sich aber durch Abwarten und Updates irgendwann von selber erledigt hat. Zumindest ging damals der Ton, aber jetzt geht momentan gar nichts :-(.

Kann mir hier jemand weiterhelfen?

Klaus

Die ~/.inputrc war auch schon vorher da, enthielt aber immer nur Kommentare.

INPUTRC wurde und wird in /etc/profile gesetzt:

was sich durch den Update auch nicht geändert hat.

Wenn ich ~/.inputrc lösche, dann funktioniert es wieder wie vorher.

Merkwürdig, aber zumindest kann ich jetzt wieder arbeiten.

Danke für die Hilfe.

Klaus

Anscheinend muss man in ~/.inputrc jetzt

reinschreiben, damit das funktioniert.

Ich hasse Leute, die sowas Grundlegendes kaputtmachen...

Klaus