Beiträge von HelmutB

Die Audsgabe von "xkbcomp $DISPLAY" ist die komplette Tastaturbeschreibung der aktuellen Konfiguration des X-Server. Also nicht nur "symbols" sondern auch alle anderen Eigenschaften wie layout, keycodes, types usw. die sonst in eigenen Dateien in den Unterverzeichnissen von /usr/share/X11/xkb definiert sind. Deshalb funktionierte sie unter "symbols" nicht (man könnte sie aber editieren und dann mit "xkbcomp <name> $DISPLAY" neu laden -zumindest lt. man-page - ich habe es noch nicht selbst versucht).

Wie man hier sieht

xkb_symbols "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)" {

    name[group1]="English (US)";

wird tasächlich als Basis von einer US-Tastatur ausgegangen, sie hat aber dann doch die deutsche Tastaturbelegung, also wird sie noch irgendwie modifiziert - vielleicht mit "setxkbmap".

Ich weiß nicht wie es bei Suse gemacht wird, aber ich glaube es gibt eine Datei "/etc/X11/xorg.conf.d/00-keyboard.conf" und "/etc/X11/xdm/Keyboard.map" die erklären könnten aus welcher Datei in "symbols" die deutschen Belegung tatsächlich herkommt.

Helmut

Hast du schon versucht deine Einstellungen direkt in von X11 verwendete xkb Tasten-Zuordnunsgdatei einzutragen?

(Bei Gentoo liegen diese unter /usr/share/X11/xkb/symbols

Die bei mit von X11 erkannte Tastatur und das Layout sind:

gentoo2 ~ # setxkbmap -query

rules: evdev
model: pc105
layout: de
variant: nodeadkeys
gentoo2 ~ #

Jetzt kann ich in der Datei "/usr/share/xkb/symbols/de" (layout) im Abschnitt "xkb_symbols "nodeadkeys"" z.B. die Taste Umlaut-O zu einem zweiten Umlaut-A machen - wie hier.

..

//key <AC10> { [ odiaeresis, Odiaeresis, doubleacute, doubleacute ] };

key <AC10> { [ adiaeresis, Adiaeresis, asciicircum, asciicircum ] };

key <AC11> { [ adiaeresis, Adiaeresis, asciicircum, asciicircum ] };

..

(die Änderung wird erst nach einem Neustart von X wirksam).

Etwas ausführlicher und mit Erklärung der Key <XXXX> Bezeichnungen hier: Enhancing_an_X_keyboard_layout

Helmut

An emergency exit occurs only when a recording fails.

That would be e.g. if selecting the channel fails or the signal is lost.

And some CAMs stop decrypting and data transfer completly if too many programs are selected at the same time

Helmut

Hier gibt es einen Patch für den T230C V2, allerdings ist dieser nicht einmal im neuesten Kernel 4.19.3 enthalten.

Da hilt im Augenblick nur selbst bauen.

dvbsky: Add support for MyGica T230C v2

Im Kommentar: "Tested with various DVB-T2 HEVC and DVB-C channels."

Helmut

Edit: Ich sehe gerade das der Patch aus 2 Teilen besteht.

Dieser Patch ist auch notwendig: si2168: Set TS clock mode and frequency

War die Datei ~/.inputrc schon vor dem Update vorhanden?

Readline nimmt (nur) den ersten Treffer von:

1) dem Dateinamen in der Shell Variablen INPUTRC

2) ~/.inputrc

3) /etc/inputrc

Wenn man als normaler User aber keine anderen Einstellungen braucht als sie in /etc/inputrc schon definiert sind, kann die Datei ~/.inputrc auch gelöscht werden.

Helmut

I don't see any loaded plugin in your log.

In my log it looks like this (after "found n locales" and before "loading .......conf"):

....
gentoo2 vdr[10328]: [10328] no locale for language code 'ara'
gentoo2 vdr[10328]: [10328] loading plugin: /usr/lib/vdr/plugins/libvdr-ddci2.so.2.4.0
gentoo2 vdr[10328]: [10328] loading plugin: /usr/lib/vdr/plugins/libvdr-xineliboutput.so.2.4.0
gentoo2 vdr[10328]: [10328] loading plugin: /usr/lib/vdr/plugins/libvdr-osdteletext.so.2.4.0
gentoo2 vdr[10328]: [10328] loading plugin: /usr/lib/vdr/plugins/libvdr-femon.so.2.4.0
gentoo2 vdr[10328]: [10328] loading /etc/vdr/setup.conf
gentoo2 vdr[10328]: [10328] loading /etc/vdr/sources.conf
....

Helmut

I use this patch vdr-2-4-0-camtweaks-1.patch from here CAM-Tweaks für Multi Channel Decryption

to make MCD/MTD work with my "ordinary" (not Alphacrypt) CAMs.

And apply this patch from Klaus too: fix-channel-switch

Helmut

vdr-femon kann das frontend1 nicht öffnen, weil cDvbDevice::Frontend() immer 0 zurückgibt.

Dieser Patch holt die aktuelle Frontend-Nummer nun richtigerweise von cDvbTuner.

Das passt nun für vdr-femon, für die devices DVR, CA und DEMUX ist cDvbDevice::Frontend() allerdings nicht mehr zu gebrauchen.

--- a/dvbdevice.h.tbs2.h    2018-11-04 14:39:35.315052750 +0100
+++ b/dvbdevice.h    2018-11-04 17:21:37.362383899 +0100
@@ -189,7 +189,7 @@ public:
   cDvbDevice(int Adapter, int Frontend);
   virtual ~cDvbDevice();
   int Adapter(void) const { return adapter; }
-  int Frontend(void) const { return frontend; }
+  int Frontend(void) const;
   virtual cString DeviceType(void) const;
   virtual cString DeviceName(void) const;
   static bool BondDevices(const char *Bondings);
--- a/dvbdevice.c.tbs2.c    2018-11-04 14:39:35.318386065 +0100
+++ b/dvbdevice.c    2018-11-04 17:27:30.937135087 +0100
@@ -571,6 +571,7 @@ public:
   bool ProvidesDeliverySystem(int DeliverySystem) const;
   bool ProvidesModulation(int System, int StreamId, int Modulation) const;
   bool ProvidesFrontend(const cChannel *Channel, bool Activate = false) const;
+  int Frontend(void) const { return frontend; }
   int FrontendType(void) const { return frontendType; }
   const char *FrontendName(void) { return dvbFrontend->FrontendName(); }
   int NumProvidedSystems(void) const { return numDeliverySystems + numModulations; }
@@ -1869,6 +1870,13 @@ int DvbOpen(const char *Name, int Adapte
   return fd;
 }
 
+int cDvbDevice::Frontend(void) const
+{
+  if (dvbTuner)
+     return dvbTuner->Frontend();
+  return frontend;
+}
+
 bool cDvbDevice::Exists(int Adapter, int Frontend)
 {
   cString FileName = DvbName(DEV_DVB_FRONTEND, Adapter, Frontend);

Auch beim aktuellen Patch und dem Astrometa-T2 beschwert sich cDvbDevice::SetPid() beim ersten Umschalten von Frontend 0/0 zu 0/1 - ich bin aber noch nicht dahintergekommen warum.

vdr[19125]: [19125] switching to channel 1 T-8232-101-14107 (ORF1)
vdr[19125]: [19263] device 1 TS buffer thread ended (pid=19125, tid=19263)
vdr[19125]: [19262] buffer stats: 0 (0%) used
vdr[19125]: [19262] device 1 receiver thread ended (pid=19125, tid=19262)
vdr[19125]: [19125] using frontend 0/1
vdr[19125]: [19125] ERROR (dvbdevice.c,2097): Invalid argument
vdr[19125]: [19125] ERROR: can't set PID 1070 on device 1
vdr[19125]: [19125] ERROR (dvbdevice.c,2097): Invalid argument
vdr[19125]: [19125] ERROR: can't set PID 1015 on device 1

Helmut

Nachdem ich erst jetzt wieder zum Testen komme habe ich nun auch kurz meinen Astrometa DVB-T/T2/C USB Stick angesteckt (mit dem 1.Patch).

Zitat von kls

+ //numModulations += fe->NumModulations(); // looks like in multi frontend devices all frontends report the same modulations

Das stimmt nur bei DVB-Karten wie von TBS mit nur einem Demodulator-Chip. Die zwei Frontends werden dann wegen der eigenständigen Tuner für SAT und Terrestrisch/Kabel angelegt.

Bei Astrometa ist es umgekehrt - hier gibt es nur einen Tuner, aber 2 Demodulator-ICs und diese 2 Demods haben unterschiedliche Fähigkeiten bei Deliverysystems und Modulation:

vdr[3731]: [3731] frontend 1/0 provides DVB-T with QPSK,QAM16,QAM64 ("Realtek RTL2832 (DVB-T)")

vdr[3731]: [3731] frontend 1/1 provides DVB-T,DVB-T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Panasonic MN88473")

Da numModulations derzeit aber eigentlich nur als "bool"-Wert genutzt macht es eigentlich keinen großen Unterschied.

Bei den Fehlermeldungen geht es allerdings drunter und drüber, z.B. auch in cDvbDevice::SetPid:

asus vdr[4424]: [4424] ERROR (dvbdevice.c,2108): Invalid argument

Auch vdr-femon hat Probleme:
vdr[4015]: [4015] FEMON-ERROR: virtual void cFemonOsd::Show() Cannot open frontend device

Ich habe es aber nur kurz ausprobiert und werde es heute auch noch mit dem 2.Patch versuchen.

Helmut

Zitat von kls

Seltsam, ich bekomme weder beim Öffnen noch beim Schließen der Frontends irgendeine Fehlermeldung.

Vermutlich liegt es an meiner Hardware/Treiber-Kombination. Ein Schließen des Frontends kann doch einige Aufraumarbeiten im Treiber hervorrufen. Und wie es aussieht dauert das bei mir manchmal etwas länger.

Aus 2.4.2. Digital TV frontend close()

"This system call closes a previously opened front-end device. After
closing a front-end device, its corresponding hardware might be powered
down automatically."

Helmut

Da das Umschalten zwischen den simulierten Frontends bei mir eigentlich wie geplant funktioniert hier nochmal zu Close/Open:

Das Ergebnis von Close() für Open() heranzuziehen bringt leider nichts da ja hier nur ein Filehandle geschlossen wird.

Die Hardware oder den Treiber berührt das nicht unbedingt.

Ich mache jetzt in DvbOpen() bei Bedarf (Fehler -EBUSY) mehrere Versuche mit einem kurzen cCondWait::SleepMs(10) dazwischen, und so gelingt es mit maximal 20ms Verzögerung das Frontend doch zu öffnen.

Genaueres kann aber vielleicht User TheTroll von hier VDR does not handle well TBS 5520SE multiple frontends sagen.

Oct 24 22:51:58 asus vdr[21876]: [21876] switching to channel 6 S19.2E-1-1051-28724 (arte)
Oct 24 22:51:58 asus vdr[21876]: [22017] osdteletext-receiver thread ended (pid=21876, tid=22017)
Oct 24 22:51:58 asus vdr[21876]: [21876] buffer stats: 0 (0%) used
Oct 24 22:51:58 asus vdr[21876]: [21876] --- DvbOpen --- frontend(0/1) : 20 ms
Oct 24 22:51:58 asus vdr[21876]: [21876] using frontend 0/1
Oct 24 22:51:59 asus vdr[21876]: [22016] device 1 TS buffer thread ended (pid=21876, tid=22016)
Oct 24 22:51:59 asus vdr[21876]: [22015] buffer stats: 202664 (3%) use

-- a/dvbdevice.c.tbs    2018-10-24 19:51:16.242309382 +0200
+++ b/dvbdevice.c    2018-10-24 22:45:41.025616785 +0200
@@ -1782,7 +1782,15 @@ cString DvbName(const char *Name, int Ad
 int DvbOpen(const char *Name, int Adapter, int Frontend, int Mode, bool ReportError)
 {
   cString FileName = DvbName(Name, Adapter, Frontend);
-  int fd = open(FileName, Mode);
+  int i, fd = -1;
+  for (i = 0; i < 100; i++) {
+      fd = open(FileName, Mode);
+      if (fd >= 0)
+         break;
+      cCondWait::SleepMs(10);
+      }
+  if (i)
+     dsyslog("--- %s --- %s(%d/%d) : %d ms", __func__, Name, Adapter, Frontend, i*10);
   if (fd < 0 && ReportError)
      LOG_ERROR_STR(*FileName);
   return fd;

Helmut

Also das Timing bei Close()/Open() ist leider doch nicht ganz gelöst - ein Wechsel zurück auf Frontend 0/0 und dann wieder auf 0/1 ist aber möglich.

ct 23 23:24:50 asus vdr[8525]: [8525] buffer stats: 0 (0%) used
Oct 23 23:24:50 asus vdr[8525]: [8525] ERROR (dvbdevice.c,1793): /dev/dvb/adapter0/frontend1: Device or resource busy
Oct 23 23:24:50 asus vdr[8525]: [8525] dvbopen: frontend 0/1:-1: Device or resource busy (dvbdevice.c:341)
Oct 23 23:24:50 asus vdr[8525]: [8525] using frontend 0/1
Oct 23 23:24:50 asus vdr[8525]: [8547] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1436)

Zitat von 9000H

genau deshalb gibt es Antennen Relais

Ich hbe kein Kabel-TV, deshalb habe ich mit solchen Dingen auch noch nie beschäftigt. Ist so ein Relais wirklich eine praktikable Lösung für den VDR?

Helmut

Zitat von 9000H

DVB-C + DVB-T2 geht das wahrscheinlich nicht ohne ein Relais oder entsprechende Filter

Ich bin jetzt nicht so der Spezialist, aber soweit ich weiß benutzen DVB-T/T2/C, ISDB-T und ATSC so ziemlich den gleichen Frequenzbereich - in etwa von 177 - 860 MHz. Daher würden sie sich ja, in ein Kabel zusammengeführt, gegenseitig überlagern.

Ich glaube eher, dass man nur Sat und *eines* dieser terrestrischen Standards zusammenführen kann.

Wenn dem so ist, könnte man es für die Erkennung von T/C verwenden - bei eine Karte die einen DVB-T2 Sender empfängt , kann man dann ausschließen, das sie auch ein DVB-C Signal bekommt - und umgekehrt genau so.

Helmut

Die TBS-6522 ist im Inneren ziemlich ident zur TBS-6590, nur ohne CI's. Sie hat dafür aber für alle 4 Tuner einen eigenen Antenneneingang.

Falls alle Kabel angeschlossen sind kann man dann bei beiden Adaptern zwischen Sat und T/C umschalten.

Helmut

Meine Karte hängt direkt am einzigen LNB, ohne Motor, Diseqc = 0.

Gehr eines der beiden Frontends gar nicht oder nur ein nachfolgendes Umschalten von 0/0 zu 0/1 oder umgekehrt?

Helmut

Hier der Patch - noch ohne Fehlerausgabe da bei mir Open() anscheinend immer funktioniert.

Helmut

Es kommt auch bei meinem schon älteren ION-330 doch relativ leicht zu einem Open() Fehler.

Könnte man es vielleicht Close() und Open() durch eine Abfrage eines Rückgabewerts von Close() "serialisieren" damit diese beiden Funktionen nicht paralell ausgeführt werden können? Ich versuche es einmal.

Helmut

Jetzt habe ich im gepatchten dvbdevice.c, nachgesehen. Zeile 1787 bezieht sich auf DvbOpen(), die beiden anderen auf GetSignalStrength und GetSignalQuality.

Der DvbOpen Fehler ist wahrscheinlich wegen der Simulation eines 2. Frontends entstanden - alle nutzen ja das gleiche Device und Open() war diesmal vermutlich schneller als Close().

Der Fehler ist bis jetzt nur einmal aufgetreten, im Übrigen funktioniert der Patch bei mir.

Helmut

Ich konnte es schon jetzt testen und das Umschalten zwischen den beiden Frontends (3Sat<->3Sat-HD) funktioniert bei mir zuerst 3 mal wie geplant, doch bei einem weiteren Umschalten kommt eine Fehlermeldung.

Oct 22 20:49:02 asus vdr[15773]: [15789] reading EPG data from /var/cache/vdr/epg.data
Oct 22 20:49:02 asus vdr[15773]: [15773] DVB API version is 0x050A (VDR was built with 0x050A)
Oct 22 20:49:02 asus vdr[15773]: [15773] frontend 0/0 provides DVB-S2,DSS with QPSK ("STV090x Multistandard")
Oct 22 20:49:02 asus vdr[15773]: [15773] frontend 0/1 provides DVB-S,DSS with QPSK ("STV090x Multistandard")
Oct 22 20:49:02 asus vdr[15773]: [15773] cTimeMs: using monotonic clock (resolution is 1 ns)
Oct 22 20:49:02 asus vdr[15773]: [15773] found 1 DVB device

Oct 22 21:04:20 asus vdr[15773]: [15773] switching to channel 5 S19.2E-1-1079-28007 (3sat)
Oct 22 21:04:20 asus vdr[15773]: [15906] osdteletext-receiver thread ended (pid=15773, tid=15906)
Oct 22 21:04:20 asus vdr[15773]: [15773] buffer stats: 0 (0%) used
Oct 22 21:04:20 asus vdr[15773]: [15773] ERROR (dvbdevice.c,1787): /dev/dvb/adapter0/frontend1: Device or resource busy
Oct 22 21:04:20 asus vdr[15773]: [15773] using frontend 0/1
Oct 22 21:04:20 asus vdr[15773]: [15792] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1430)
Oct 22 21:04:20 asus vdr[15773]: [15905] device 1 TS buffer thread ended (pid=15773, tid=15905)
Oct 22 21:04:20 asus vdr[15773]: [15904] buffer stats: 229548 (4%) used
Oct 22 21:04:20 asus vdr[15773]: [15904] device 1 receiver thread ended (pid=15773, tid=15904)
Oct 22 21:04:20 asus vdr[15773]: [15918] osdteletext-receiver thread started (pid=15773, tid=15918, prio=high)
Oct 22 21:04:20 asus vdr[15773]: [15917] device 1 receiver thread started (pid=15773, tid=15917, prio=high)
Oct 22 21:04:20 asus vdr[15773]: [15919] device 1 TS buffer thread started (pid=15773, tid=15919, prio=high)
Oct 22 21:04:20 asus vdr[15773]: [15773] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Oct 22 21:04:20 asus vdr[15773]: [15773] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1104)
Oct 22 21:04:20 asus vdr[15773]: [15773] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1170)
Oct 22 21:04:21 asus vdr[15773]: [15773] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1104)
Oct 22 21:04:21 asus vdr[15773]: [15773] ERROR: frontend 0/1: Bad file descriptor (dvbdevice.c:1170)

Im Anhang noch das ganze Log.

Helmut

Grrrrr - das ist natürlich richtig -also leider falscher Alarm.

Ich werde aber auf jeden Fall testen und das Ergebnis posten.

Helmut