1

x86 Systeme (PC) / 5.5 Unstable: Neuinstallation mit NetInstall Standard-Image schlägt fehl

« on: October 12, 2023, 17:43:55 »

@claus
Aufgrund der Probleme von kaiserdom bei der Installation von 5.5 Unstable habe ich seit Langem auch wieder mal eine Neuinstallation getestet.
Ich habe mir dazu das aktuelle Standard-Image für "64bit PC" heruntergeladen
MLD-5.5_netinstall_2022.11.12-183+1465_amd64

Bei der Installation ist mir schon aufgefallen, dass beim Schritt System Aktualisierung ein Fehler gemeldet wird.
Die Installation wird aber ohne weitere Fehler abgeschlossen.
Im install.log ist dann auch diese Meldung zu finden:

Code: [Select]

==Aktualisiere System==
Get:1 http://www.minidvblinux.de/download/5.5/files unstable InRelease [2.430 B]
Fetched 2.430 B in 0s (9.530 B/s)
Reading package lists...
Reading package lists...
Building dependency tree...
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 eventlircd : Depends: libc6 (>= 2.28-~19) but 2.28-~18 is installed
 irkeytable : Depends: libc6 (>= 2.28-~19) but 2.28-~18 is installed
 rc-core : Depends: libc6 (>= 2.28-~19) but 2.28-~18 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
====== failed ======
Nach einem Reboot mit der Installierten MLD 5.5 unstable am TV dann aber kein TV-Bild sondern wieder das WebIF.
Unter System werden dann auch keine Pakete für GPU und DVB-Treiber angezeigt und auch alle Pakete für den VDR fehlen.
Aufgrund des "broken install" können also offensichtlich die benötigten Pakete nicht nachgeladen werden.
Auch im WebIF unter Pakete ist eine manuelle Paketinstallation mit dem Hinweis auf den "broken install" nicht möglich.
Erst nach einem 'apt --fix-broken install' konnte ich die benötigten Pakete nachinstallieren.

Ich habe den Test sowohl mit einem Intel- als auch einem nVidia-System gemacht.
Beim System mit der Intel-GPU lief das System nach der manuellen Installation aller benötigten Pakete ohne Probleme.
Beim nVidia-System hatte ich jedoch auch erst mal die Kopfzeile von Softhddevice (fehlender Paramerter -f von shd), was kaiserdom schon in einem andern post beschrieben hatte.
Ich musste auch immer den VDR nach einem Neustart manuell über das WebIF restarten, da am TV immer erst mal das WebIF angezeigt wird.
Da hilft auch kein Speichern der Auswahl VDR unter Konfiguration - Programme im WebIF.

Bei der 5.5 Unstable wurde ja im Februar 2023 der Kernel mit allen davon abhängigen Paketen sowie der VDR mit seinen Plugins Upgedatet.

Könnte es sein, dass das Image und die darin enthaltenen Paktete vom Nov. 2022 zu alt sind, was dann zu Versions-Konflikten mit den neueren Paketen führt, die nachinstalliert werden müssen?

2

Allgemeines [ General ] / Claus alles Gute zum Geburtstag!

« on: September 20, 2023, 13:06:47 »

Hallo Claus,

ich wünsche dir alles Gute zu deinem Geburtstag.

Gruß
KLaus

3

x86 Systeme (PC) / MLD 5.5 x86 testing und unstable: System Setup mit surf funktioniert nicht

« on: November 21, 2022, 00:37:45 »

Hallo,

ich habe dieses WE mit den aktuellen NetInstall Images von testing und unstable einge Neuisnstallations Tests gemacht.
Eigentlich sollte da ja am Ende des Bootvorganges mittels surf das SystemSetup angezeigt werden.
Es erscheint aber nur die graphische Oberfläche mit dem MLD Schriftzug.
Mit der rechten Maustaste kann ich dann zwar über Apps das SystemSetup auswählen, aber es passiert nichts.
XTerm kann ich starten.

Da die Systeme per Ethernet mit dem Lan verbunden waren, konnte ich das WebIF die weiteren Konfiguration vornehmen.
Problematisch ist das halt, wenn das System auf WLan angewiesen ist.

Auf meinen Produktiv Systemen mit dem aktuellen Stand der 5.5 testing bzw. unstable lässt sich das SystemSetup über das OSD auch nicht starten.
Wenn man das SystemSetup im OSD unter System auswählt wird der VDR beendet und startet aber gleich wieder ohne zu surf mit dem SystemSetup zu wechseln.

Gruß
Klaus

4

x86 Systeme (PC) / MLD 5.5 x86, testing: Keine Aktulisierung von Paketen möglich

« on: November 04, 2022, 12:40:15 »

Hi,

ich wollte heute mein System im Wohnzimmer, das mit 5.5 testing läuft, nach längerer Zeit wieder mal aktualisieren.
Wenn ich im WebIf auf "Pakete" - "Aktualisierungen" gehe, erhalte ich folgende Fehlermeldungen.

Code: [Select]

E: Problem parsing dependency 21
E: Error occurred while processing network (NewVersion2)
E: Problem with MergeList /var/lib/apt/lists/www.minidvblinux.de_download_5.5_files_dists_testing_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

Keine Aktualisierungen verfügbar.
Nicht nur, dass keine Aktualisierungen mehr angeboten werden, unter "Systeme Pakete" und "VDR Plugins" werden auch keine Pakete mehr angezeigt.
Es können also weder Pakete installiert noch deinstalliert werden.
Auch unter "System Information" werden die aktuell installierten Pakete nicht mehr angezeigt.
Ich werde das noch mal auf einem anderen System mit 5.5 testing ausprobieren.

Gruß Klaus

5

x86 Systeme (PC) / MLD 5.5 x86, unstable: Upgrade auf Kernel 5.15.76 schlägt fehl

« on: November 03, 2022, 16:41:12 »

Hallo,

seit heute wird ja bei der 5.5 Unstable aufgrund des neuen Kernels 5.15.76 die Akualisierung aller vom Kernel abhängigen Pakete angeboten.
Ich habe das Dist-Upgrade auf zwei Systemen getestet und bei beiden hat es leider aufgrund von Paketkonflikten nicht funktioniert.

Bin dann erst mal wieder per Snapshot auf den Stand vor dem Upgrade-Versuch zurrück.
Dann habe die Pakete network-wireless-drivers und dvb-dddvb, welche die Konflikte verursacht hatten, deinstalliert.
Danach lief das Dist-Upgrade problemlos durch.

Beim anschließenden Installationsversuch von network-wireless-drivers gibt es die folgenden Meldungen:

Code: [Select]

Install network-wireless-drivers
Unpacking network-wireless-drivers
trying to overwrite '/lib/modules/5.15.76.205.8/kernel/net/mac80211/mac80211.ko', which is also in package network-drivers 0-10+5.15.76.205.8
E: Sub-process /usr/bin/dpkg returned an error code (1)Das Modul mac80211.ko hatte ja erst kürzlich bei Kernel 5.15.74 den gleichen Konflikt verursacht.

Beim Paket dvb-dddvb sieht das so aus:

Code: [Select]

Install dvb-dddvb
Unpacking dvb-dddvb
trying to overwrite '/lib/modules/5.15.76.205.8/kernel/sound/core/snd-pcm.ko', which is also in package alsa 1.1.8-47+5.15.76.205.8
E: Sub-process /usr/bin/dpkg returned an error code (1)Ich hab jetzt erst mal das Paket dvb, das ja auch den ddbridge Treiber für die CineS2 enthält, installiert.

Gruß
Klaus

6

x86 Systeme (PC) / MLD 5.5 unstable x86: Konflikt zwischen network und network-wireless-drivers

« on: October 27, 2022, 18:54:23 »

Hallo,

derzeit gibt es anscheinend einen Konflikt zwischen den Paketen network und network-wireless-drivers.
Aufgrund dieses Konfliktes hatte ich Probleme bei der Systemaktualisierung über das WebIF.
Geholfen hatte dann erst mal der Snapshot vor der Systemaktualisierung.
Nach der Deinstallation von network-wireless-drivers lief dann die Systemaktualisierung durch.
Leider lässt sich danach network-wireless-drivers nicht mehr installieren.

Install network-wireless-drivers
Unpacking network-wireless-drivers
trying to overwrite '/lib/firmware/rt2860.bin', which is also in package network 0-81+5.15.74.205.5
E: Sub-process /usr/bin/dpkg returned an error code (1)
faile

Daher funktioniert bei dem NUC jetzt natürlich kein WLan mehr.
Da ich das System auch per Ethernetkabel mit dem Lan verbinden kann, ist das nicht so schlimm.
Es wäre aber trotzdem schön, wenn ich auch wieder WLan nutzen könnte.

Gruß
Klaus

7

Entwicklung [ Development ] / [MLD 5.5] Problem mit evmaps nach Kernel- und somit eventlircd-Update

« on: February 06, 2021, 17:35:22 »

Hallo Zusammen,

ich habe schon wieder mal ein FB-Problem.

Dank des neuen irkeytable Paketes konnte ich eine bisher nie richtig funktionierende FB/IR-Empfänger Kombination (TeVII S660) komplett neu anlernen.
Sehr störend war dann aber eine vorhandenen tevii_s660.evmap, die für den VDR teilweise völlig sinnlose Remapping-Einträge enthält.
Dadurch werden einige sinnvoll zugeordnete Tasten komplett unbrauchbar (KEY_MENU und KEY_OK) oder einer falschen Funktion zugeordnet.
Nach Entfernen aller Mapping-Einträge in dieser evmap hatte die FB genau so funktioniert wie angelernt.

Nach dem Kernel-Update 5.10.13 von heute hat die FB wieder nicht mehr richtig funktioniert, weil beim Kernel-Update über das Update von eventlircd die alte tevii_s660.evmap eingespielt worden ist.

Alternativ könnte man, wenn eine individuell erstellte rc-keymap vorhanden ist, die dazugehörige und nicht mehr benötigte evmap komplett löschen.
Bei einem Kernel-Update gibt es aber das gleiche Problem, wie bei einer angepassten evmap.

Selbst bei USB-Empfängern mit Standard-Keymap, wie meine X10-RF und MCE-IR-Empfänger, kann man ja jetzt falsch zugeordnete Tasten über das WebIF komfortabel neu zuordnen.
Auch hier ist eine vorhandene evmap überflüssig oder evtl. sogar störend.

Ein weiteres Beispiel, wo jetzt das Anlernen der FB im WebIF funktioniert, ist mein Streamzap USB-IR-Empfänger mit FB.
Für diesen musste ich vorher manuell eine individuelle rc-keymap (nach Vorlage /lib/udev/rc_keymaps/streamzap) erstellen und über rc_maps.cfg aktivieren.
In diesem Fall funktioniert die Tastenzuordnung ohne evmap nur über eine individuelle rc-keymap und bei einem Kernel-Update passiert nichts.

Ein anderer Fall ist mein "Topseed" USB-IR-Empfänger mit dazugehöriger Cyberlink-Fernbedienung.
Dieser Empfänger funktioniert mit eventlircd aber nicht mit ir-keytable, d.h. die einzige Möglichkeit Tastenzuordnungen anzupassen ist eine evmap.
Es ist auch eine topseed.evmap  vorhanden, die von eventlircd verwendet wird, leider waren fast alle Remapping-Einträge unbrauchbar.
Meine mit Hilfe von evtest manuell angepasste und funktionierende evmap wurde beim letzten Kernel-Update ebenfalls überschrieben.
Somit funktionieren nach dem Kernel-Update wieder viele, auch wichtige FB-Tasten, nicht mehr.

Ich hätte daher eine Idee.

Wäre es nicht möglich, alle derzeit in /etc/eventlirc.d/ vorhandenen evmaps in einen Unterordner (z.B. /etc/eventlirc.d/example) zu verlagern?
Somit gäbe es unter /etc/eventlirc.d/ keine aktiven und evtl. störenden evmaps mehr.

Passen die Tastenzuordnungen für eine Fernbedienung nicht, können diese in den meisten Fällen über das WebIF und eine individuelle rc-keymap angepasst werden.
Wird doch mal eine evmap benötigt, kopiert man die entsprechende Beispiel-evmap nach /etc/eventlirc.d/.
Dort kann sie individuell angepasst werden und wird bei einem Kernel-Upgrade wenigstens nicht mehr überschrieben.

8

x86 Systeme (PC) / [MLD 5.5] X10 FB - Andere Belegung für Menü-Taste nach Upgrade von irkeytable

« on: February 03, 2021, 23:21:18 »

Hallo Claus,

mit dem neuen Paket irkeytable hat sich leider doch ein kleiner Bug eingeschlichen, der die X10 FBs betrifft.

Nach dem aktualisieren eines MLD 5.5 Systems mit mit X10 Empfänger und einem Reboot, hat sich beim Drücken der Menütaste nicht das Hauptmenü sondern das Submenü "Aufzeichnungen" geöffnet.
Stattdessen wurde das Hauptmenü mit der Taste "Rec TV" auf meiner kleinen Pollin X10-FB geöffnet.

Der zur FB gehörende X10-Empfänger (Vendor/Product-ID 0bc7:0006) ist eine or2x-Variante.
Er verwendet daher die rc-keymap /etc/rc-keymaps/rc-medion-x10-or2x.
In dieser keymap aus irkeytable 2021.01.29-14.14 wurden gegenüber der alten Version KEY_MENU und KEY_PVR vertauscht.
Aus bisher 0x001b = KEY_MENU wurde 0x001b = KEY_PVR und aus 0x0018 = KEY_PVR wurde 0x0018 KEY_MENU.

Als Sofortmaßnahme habe ich die neue keymap durch die alte Version aus dem Paket irkeytable 1.16.3-14.8 ersetzt.

Ich habe dann aber gesehen, dass in der neuen keymap auch Zuordnungen korrigiert und 4 Codes zusätzlich aufgenommen wurden.

Bei folgenden Codes gab es noch Änderungen, die ich aber alle sinnvoll finde:
0x0000 = KEY_Mute         ==> KEY_MUTE (so korrekt, auch wenn KEY_Mute funktioniert hat)
0x0006 = KEY_AUDIO (User5) ==> KEY_MODE (= Lirc.Audio = Tonspuren-Menü)
0x0026 = KEY_FORWARD       ==> KEY_FASTFORWARD (Korrektur -> Mapping in evmap überflüssig)

Diese Codes wurden zusätzlich aufgenommen:
0x0019 = KEY_PROG4
0x0030 = KEY_CHANNEL
0x0039 = KEY_FN
0x003a = KEY_PROG3

Ich kenne außer der kleinen Pollin-Variante nur eine weitere ähnliche Kompakte X10-or2x-FB, deren 48 Tasten alle mit der alten keymap (49 Codes) funktioniert haben.
Die große Medion FB und die Digitainer FB hätten zwar mehr Tasten, passen aber von der Tastenbelegung nicht zur or2x keymap.
Daher habe ich keine Ahnung, für welche FB die zusätzlichen Codes passen könnten.
Vermutlich wurden noch fehlende Codes, die das Kernel-Modul rc-medion-x10-or2x bereitstellt, mit aufgenommen.
Letzendlich stören diese zusätzlichen Keys aber auch nicht.

Die beiden anderen X10-keymaps rc-medion-x10 und rc-medion-x10-digitainer verwenden unverändert 0x001b = KEY_MENU und 0x0018 = KEY_PVR.
Soweit mir bekannt ist, gibt es X10-Empfänger mit diesen keymaps aber ebenfalls mit Vendor/Product-ID 0bc7:0006, wie meine or2x-Variante.

Daher ist es vermutlich sinnvoller, direkt in der rc-medion-x10-or2x die vertauschten Keys zu korrigieren, als diese in der 03_0bc7_0006.evmap zu remappen.

Gruß
Klaus

9

Allgemein [ General ] / [MLD 5.X - x86_64] Neuer Sundtek SkyTV Dual funktioniert nicht

« on: December 07, 2020, 13:59:09 »

Hallo,
ich habe mir den neuen Dual-USB Receiver vom Sundtek angeschafft, bekomme damit aber einfach kein TV-Bild.
Ich habe mich übers Wochende schon intensiv mit dem Problem beschäftigt.

Ich wollte den Dual-Receiver eigentlich bei meinen MiniPCs (wie Asus-PN40 und Nuc-8i3) alterantiv zu SatIP verwenden.
Auf diesen Systemen mit installierter MLD 5.5 habe ich Sundtek zuerst getestet und dazu dvb-sundtek installiert.
Mit angeschlossenem Sundtek und installiertem Treiber sowie deaktiviertem SatIP aber leider kein TV-Bild.
Im VDR-Menü werden jedoch 2 Tuner und davon einer mit grünen Balken angezeigt.

Im Internet hatte ich gelesen, dass die neuen Sundtek Receiver (auch der Ultimate VIII) evtl. Probleme mit USB 3.0 haben.
Daher habe ich den Receiver auch auf meinem Intel i3-System mit MLD 5.4 testing und eingebauter CineS2 getestet.
Dazu CineS2 ausgebaut und den Receiver an einem der 4 "echten" USB 2.0 Ports angeschlossen und dvb-sundtek Paket installiert.
Nach einem Reboot auch wieder kein TV-Bild im VDR-Menü aber wieder zwei Tuner, davon einer als DVB-S2 mit grünen Balken.
Danach habe ich auf diesem System sowohl die 5.4 testing als auch die 5.5 mit den aktuellen Net-Inst Images neu installiert.
Der Dual-Tuner wird nicht automatisch erkannt und nach dem nachinstallieren der Sundtek-Treiber wieder kein TV-Bild.
Gleicher Zustand, wie bei den bereits vorher installierten MLD-Systemen.

Ich habe mir dann mal bei per SSH mit mediaclient einige Infos abgefragt.
Mit mediaclient -e sieht man, dass der Treiber den SkyTV Dual erkannt hat:

Code: [Select]

**** List of Media Hardware Devices ****
device 0: [             Dual S2]  DVB-S/S2, REMOTE-CONTROL, DVB-S/S2
  [INFO]:
     STATUS: STANDBY
  [BUS]:
     ID: 1-8
  [SERIAL]:
     ID: U201009191038
  [DVB-S/S2]:
     FESTATUS: ACTIVE
     LNBVOLTAGE: ENABLED
     LNBSUPPLY: USBPOWER
     LNBSTATUS: OK
     FRONTEND: /dev/dvb/adapter0/frontend0
     DVR: /dev/dvb/adapter0/dvr0
     DMX: /dev/dvb/adapter0/demux0
  [REMOTECONTROL]:
     INPUT0: /dev/mediainput0
  [DVB-S/S2]:
     FESTATUS: STANDBY
     FRONTEND: /dev/dvb/adapter1/frontend0
     DVR: /dev/dvb/adapter1/dvr0
     DMX: /dev/dvb/adapter1/demux0   
Ausgabe von mediaclient  --frontendinfo=/dev/dvb/adapter0/frontend0

Code: [Select]

LinuxDVB API v5.10
Devicename: Sundtek DVB-S/S2 (VIII)
Current Mode: DVB-S/S2
Supported Delivery Systems:
  SYS_DVBS2
  SYS_DVBS
Mit mediaclient --lc sieht man, dass der VDR darauf zugreift.

Code: [Select]

**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
  2097 ... vdr
/dev/dvb/adapter0/dvr0:
  2097 ... vdr
/dev/dvb/adapter0/demux0:
  2097 ... vdr (13ed)
  2097 ... vdr (13ee)
  2097 ... vdr (13ef)
  2097 ... vdr (13f2)
  2097 ... vdr (13f1)
  2097 ... vdr (13f0)
  2097 ... vdr (0012)
  2097 ... vdr (0014)
  2097 ... vdr (0000)
  2097 ... vdr (0011)
  2097 ... vdr (0010)
/dev/mediainput0:
  No client connected
/dev/dvb/adapter1/frontend0:
  2097 ... vdr
/dev/dvb/adapter1/dvr0:
  No client connected
/dev/dvb/adapter1/demux0:
  2097 ... vdr (0012)
  2097 ... vdr (0014)
  2097 ... vdr (0000)
  2097 ... vdr (0011)
  2097 ... vdr (0010)
Aber mit mediaclient --tsscan=/dev/dvb/adapter0/frontend0 sieht man, dass eigentlich beim VDR keine Video-Daten ankommen können.

Code: [Select]

media scan tp: 0
Timed out after 1 seconds
Total found: 0 PMTs (incl. unknown 0x0000)
Scan finished after 0 packets (0 bytes)
Hier noch ein Auszug aus einem Massages-Log von heute, wo man sieht, dass der VDR die beiden Frontends erkennt und verwendet:

Code: [Select]

Dec  7 12:44:51 MLD user.info kernel: [    1.858259] usb 1-8: new high-speed USB device number 3 using xhci_hcd
Dec  7 12:44:51 MLD user.info kernel: [    1.985827] usb 1-8: New USB device found, idVendor=2659, idProduct=1802, bcdDevice= 0.00
Dec  7 12:44:51 MLD user.info kernel: [    1.985831] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec  7 12:44:51 MLD user.info kernel: [    1.985833] usb 1-8: Product: Dual S2
Dec  7 12:44:51 MLD user.info kernel: [    1.985836] usb 1-8: Manufacturer: Sundtek
Dec  7 12:44:51 MLD user.info kernel: [    1.985838] usb 1-8: SerialNumber: U201009191038
...
Dec  7 12:45:24 MLD user.debug vdr: [2097] detected /dev/dvb/adapter1/frontend0
Dec  7 12:45:24 MLD user.debug vdr: [2097] detected /dev/dvb/adapter0/frontend0
Dec  7 12:45:24 MLD user.debug vdr: [2098] video directory scanner thread ended (pid=2097, tid=2098)
Dec  7 12:45:24 MLD user.debug vdr: [2097] probing /dev/dvb/adapter0/frontend0
Dec  7 12:45:24 MLD user.debug vdr: [2097] creating cDvbDevice
Dec  7 12:45:24 MLD user.debug vdr: [2097] new device number 1 (card index 1)
Dec  7 12:45:24 MLD user.info vdr: [2097] DVB API version is 0x050A (VDR was built with 0x050A)
Dec  7 12:45:24 MLD user.info vdr: [2097] frontend 0/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (VIII)")
Dec  7 12:45:24 MLD user.debug vdr: [2100] frontend 0/0 tuner thread started (pid=2097, tid=2100, prio=high)
Dec  7 12:45:24 MLD user.debug vdr: [2100] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec  7 12:45:24 MLD user.debug vdr: [2097] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec  7 12:45:24 MLD user.debug vdr: [2101] device 1 section handler thread started (pid=2097, tid=2101, prio=low)
Dec  7 12:45:24 MLD user.debug vdr: [2097] probing /dev/dvb/adapter1/frontend0
Dec  7 12:45:24 MLD user.debug vdr: [2097] creating cDvbDevice
Dec  7 12:45:24 MLD user.debug vdr: [2097] new device number 2 (card index 2)
Dec  7 12:45:24 MLD user.info vdr: [2097] frontend 1/0 provides DVB-S2,DVB-S with QPSK ("Sundtek DVB-S/S2 (VIII)")
Dec  7 12:45:24 MLD user.debug vdr: [2102] frontend 1/0 tuner thread started (pid=2097, tid=2102, prio=high)
Dec  7 12:45:24 MLD user.info vdr: [2097] found 2 DVB devices
Daraufhin habe ich aus meinen DVB-Karten Fundus einen alten Sundtek SkyTV UltimateII ausgebuddelt.
Diesen habe ich zuerst mal auf dem Intel CoreI-System mit der installierten 5.4 testing ausprobiert.
Und mit diesem alten Sundtek-Stick hatte ich sofort ein TV-Bild.
Bei einer erneuten Neuinstallation auf USB-Stick wurde der auch von dvb-autodetect erkannt und nach abschlossener Installation hatte ich sofort ein TV-Bild.

Mit mediaclient --tsscan=/dev/dvb/adapter0/frontend0 sieht man, dass mit dem UltimateII beim VDR (Das Erste HD eingestellt) Video-Daten (hier ARD-HD-Transponder) ankommen.

Code: [Select]

media scan tp: 0
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
PMT PID: 0x13ec
  Program Number: 0x283d
  TransportstreamID: 1019
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: Das Erste HD
    --> 0x0492 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x0498 (ISO/IEC 13818-6 type C)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x13ed (27)
    --> 0x13ee (ISO/IEC 11172 Audio)
    --> 0x13ef (ISO/IEC 11172 Audio)
    --> 0x13f0 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13f1 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13f2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13f4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x1434 (ISO/IEC 13818-6 type B)
PMT PID: 0x13f6
  Program Number: 0x283e
  TransportstreamID: 1019
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: arte HD
    --> 0x04f6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x04fc (ISO/IEC 13818-6 type C)
    --> 0x13f7 (27)
    --> 0x13f8 (ISO/IEC 11172 Audio)
    --> 0x13f9 (ISO/IEC 11172 Audio)
    --> 0x13fa (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13fb (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13fc (ISO/IEC 11172 Audio)
    --> 0x13fd (ISO/IEC 11172 Audio)
    --> 0x13fe (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x13ff (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x1400
  Program Number: 0x283f
  TransportstreamID: 1019
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: SWR BW HD
    --> 0x055a (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x09ac (ISO/IEC 13818-6 type C)
    --> 0x1401 (27)
    --> 0x1402 (ISO/IEC 11172 Audio)
    --> 0x1403 (ISO/IEC 11172 Audio)
    --> 0x1404 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x1405 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x1406 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x1436 (ISO/IEC 13818-6 type B)
PMT PID: 0x140a
  Program Number: 0x2840
  TransportstreamID: 1019
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: SWR RP HD
    --> 0x055b (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x09ac (ISO/IEC 13818-6 type C)
    --> 0x1401 (27)
    --> 0x1402 (ISO/IEC 11172 Audio)
    --> 0x1403 (ISO/IEC 11172 Audio)
    --> 0x1406 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x140e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x140f (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x1438 (ISO/IEC 13818-6 type B)
Total found: 4 PMTs (incl. unknown 0x0000)
Scan finished after 15 packets (2820 bytes)

Da ich bei beiden Sundtek-Receivern ansonsten die geleiche HW verwende, sollte es an der Sat-Anlage bzw. dem Antennenkabel nicht liegen, dass mit dem SkyTV-Dual beim VDR keine Video-Daten ankommen.
Und auch der in MLD verwendete Sundtek-Treiber funktioniert auf jeden Fall mit den älteren Sundtek Stick.

Eigentlich sollte der Treiber in der aktuellen MLD 5.4 testing und MLD 5.5 unstable so aktuell sein, dass auch die neuesten Sundtek-Receiver damit funktionieren.

Ich hätte zwar noch ein paar Ideen, komme an diesem Punkt nicht mehr weiter, da ich unsicher bin, wie ich das bei MLD am Besten umsetzte.
An den Konfigurations-Datein von MLD (z.B. /etc/sundtek.conf) hab ich daher bewusst nichts verändert.
Auch tiefergehende Kommandos von mediaclient um z.B. PID-Filter, Transmisson-Mode und DVB API Options (--setver=5.0) zu verwenden, habe ich mir bewusst verkniffen.

Evtl. hat ja jemand im Forum eine Idee, wie ich SkyTV-Dual doch zum Laufen bringen könnte.
Mittlerweile vermute ich aber, wenn es nicht am Treiber liegt, einen HW-Defekt bei der SkyTV-Dual.

10

x86 Systeme (PC) / [MLD 5.5] Mit Kernel 5.9.11 bringt Backup-Installieren immer Fehlermeldung

« on: November 30, 2020, 18:17:03 »

Hi,
ich habe auf MLD 5.5 Systemen seit dem Upgrade auf Kernel 5.9.11 ein weiteres Problem.
Das Erstellen eines bootfähigen Backup-Sticks mit Konfiguration-Backup-Installieren schlägt fehl.
Immer der letzte Schritt "UEFI Boot Eintrag für sdx1 hinzugefügen" scheitert.
Manchmal gibt es sogar einen  Segfault und das System ist nicht mehr erreichbar.
Durch Logging auf HDD konnte ich aber auch davon Logs sichern.
Ich habe das mittlerweile auf 3 Intel und einem AMD-System reprodizierbar festgestellt.
Gleichgültig, ob das laufende System auf SSD/HDD oder Sick installiert ist.

Bei allen Systemen funktioniert aber das Backup-Installieren mit Kernel 5-7-17 noch einwandfrei.

Von meinem Intel-System mit Celeron N4020 (MLD 5.5 auf interner SSD) habe ich mal die Install.log gesichert und am Ende auch die Eintäge aus messages zur Zeit der Backuperstellung angefügt.
Es sind 2 Logs mit gescheitertem Backup (Segfault-Absturz und nur Failed) sowie erfolgreich mit Kernel 5.7.17.
Habe die Logs als Zip gepackt angehängt.

11

x86 Systeme (PC) / [MLD 5.5] Nach Upgrade auf Kernel 5.9 funktioiert der serielle IR nicht mehr

« on: November 28, 2020, 23:20:55 »

Nach einem Aktualisieren aller geänderten Pakete mit neuem Kernel 5-9-11 und VDR 2.4.5 funktioniert meine FB nicht mehr.
Es ist ein Serieller IR am Com1, der vorher mit Kernel 5.7.17 und VDR 2.4.4 noch einwandfrei funktioniert hatte.
Mir war das schon vorher mit den Upgrades vom 05.11. mit Kernel 5.9.3 aufgefallen.
Da ich aber keine Zeit hatte, dem näher nachzugehen, bin ich per Snapshot zurrück auf Kernel 5.7 und FB war wieder OK.
Als ich gesehen hatte, dass dass es einen neuen Kernel gibt, hatte ich schon gehofft, dass es damit wieder funktioniert.
Aber leider wieder keine FB nach dem Upgrade.
Ich habe schon mit irw geschaut, ob Signale der FB ankommen.
Mit Kernel 5-7-17 kommen Signale bei irw an, aber mit Kernel 5.9 nicht mehr.
Hab Gestern auch schon MLD auf einem Stick komplett neu aufgesetzt, also gleich mit Kernel 5.9.11, und versucht Lirc neu einzurichten.
Aber auch ohne Erfolg.
Hatte auch schon die Idee bei installiertem lirc den eventlircd zu entfernen, was aber auch nichts gebracht hat.
Bei Kernel 5.7.17 mit gleichzeitig installiertem lirc und eventlirc hatte die FB ja auch funktioniert.

Wenn bei dem Upgrade sonst nichts am FB-Handling geändert wurde, würde ich auf den Kernel als Schuldigen tippen.

Ich habe jetzt noch mal das Upgrade durchgespielt und Logs hochgeladen.

Vor dem Upgrade noch mit Kernel 5.7.17 und funktionierender FB: GVSNpq
Nach dem Upgrade aber nur Restart des VDR (jetzt 2.4.5) aber noch alter Kernel aktiv - FB OK: amqB7o
Nach einem Reboot mit dann aktivem Kernel 5.9.11 - FB funktioniert nicht mehr: Kl4UP6

Gruß
Klaus

12

x86 Systeme (PC) / [MLD 5.5 unstable] kodi-stable Paket mit Kodi-18.7.1 ohne vaapi Support

« on: October 02, 2020, 15:26:54 »

Hallo,

beim testen von Kodi mit der 5.5 hatte mir Kodi 18.7.1 aus dem kodi-stable Paket am besten gefallen.
Auf einem System mit i3-7100 ist mir aber aufgefallen, dass HD-Videos, besonders 1080p, nicht ganz flüssig laufen.
Auf meiner BeeBox mit Celeron N3150 war das noch auffälliger.

Das kodi-stabel Paket mit der 18.7.1 habe ich auch in MLD 5.4 testing gefunden und daraufhin ausprobiert.
Auf beiden Systemen laufen die 1080p Viedeos damit total flüssig.

Den Grund habe ich in den Player-Einstellungen von Kodi gefunden.
Bei der Version aus der 5.4 testing gibt es die aktivierte Video-Option "Hardware Beschleunigung erlauben - VAAPI".
Bei Kodi unter MLD 5.5 unstable fehlt diese Option in den Einstellungen.

Ich hab mir dann beim Abspielen der Vdeos per putty/top die CPU-Last auf den Systemen angeschaut.
Beim Celeron N3150 liegt sie mit MLD 5.5 unstable bei 75 bis 80% und bei der 5.4 testing mit aktiviertem VAAPI bei ca. 20%.
Deaktiviere ich bei der 5.4 Version die VAAPI-Beschleunigung, steigt die CPU-Last von ca. 20% ebenfalls auf 75 - 80%.
Beim Core i3 ist es ähnlich nur dass die CPU-Last mit VAAPI bei 10% und ohne VAAPI bei über 50% liegt.
Für mich ein weiteres Indiz, dass bei der 5.5 die VAAPI Option tatsächlich komplett fehlt, d.h. diese Kodi-Version ohne VAAPI-Support gebaut wurde.

Im Downloadbereich ist mir aufgefallen, dass das Paket kodi-stable in der 5.4 und 5.5 zu unterschiedlichen Zeiten gebaut worden ist.
In der 5.4 testing mit funktionierender VAAPI-Beschleunigung stammt es vom 09.07.2020.
In 5.5 unstable wurde es am 16.09.2020 gebaut und laut Paket Historie wurden vorher am 07.09. die deps angepasst.
Evtl. ist ja dabei der VAAPI-Support verloren gegangen, was dann ja bei einem Neubau des Paketes in der 5.4 testing evtl. auch passieren könnte.

Gruß
Klaus

13

x86 Systeme (PC) / [MLD 5.4 testing] Installationsprobleme - keine Pakete mehr nachinstallierbar

« on: October 01, 2020, 15:31:31 »

Hallo,

bei der Neuinstallation der MLD 5.4 testing auf einem Intel-System schlägt das "Ausprobieren" fehl.
Ausgewählt hatte ich VDR mit satip-shd, was auf dem System schon mit der 5.4 stable und 5.5 unstabel einwandfrei funktioniert hat.
Sowohl lokal auf dem System als auch auf einem anderen System per WebIF (von dort kopiert) erhalte ich folgende Meldungen:

Vorbereiten ...
Downloading updates
Removing install-net
Removing live
Installation of live system completed.

Danach passiert aber nichts. Kein VDR wird auf dem System gestartet.

Geht man auf Pakete schaut der Status ganz normal aus.
Update package list
Downloading updates                   done

Unter "System Pakete" werden aber nur die installierten angezeigt und darunter findet sich kein vdr.
Die Liste lässt sich auch nicht auf "vollständig" erweitern.

Unter "VDR-Plugins" erhalte ich folgende Meldung:
E: No packages found
Mehr Informationen zu den Plugins sind im Wiki zu finden.

Ein "Installieren" macht dann auch keinen Sinn, da man kein System mit funktionierendem VDR erhält.

Auf das Problem aufmerksam geworden bin ich bei einer bereits installierten 5.4 testing, da ich keine VDR-Plugins mehr nachinstallieren konnte.
Da ich dieses System aber am Montag von 5.4 stabel auf testing umgestellt hatte, habe ich das Problem erst bei dieser Umstellung von stable auf testing vermutet.
Die Umstellung hatte ich gemacht, um das kodi-stable Paket mit Kodi 18.7 zu installieren, das bei 5.4 nur im Tesing-Repo vorhanden ist.
Die Umstellung lief am Montag aber ohne Probleme, alle relevanten Pakete wurden upgedatet und ich konnte auch kodi-stable aus dem Testing-Repo installieren.

Aus diesem Grund hatte ich dann die oben beschriebene Neuinstallation der 5.4 testing versucht.
Außerdem auch noch mal einen Test mit Neuinstallation der 5.4 stabel, die einwandfrei funktioniert hat, mit anschließender Umstellung auf testing gemacht.
Eine Umstellung von stabel auf testeing war aber heute nicht möglich, obwohl unter "Pakete" der Status wieder keine Fehler zeigt.
Es wurden keine Paket "Aktualisierungen" angeboten und unter "System Pakete" und "VDR-Plugins" wurden nur die installierten Pakete angezeigt.

Da scheint scheint es ein Problem mit dem Paketmanager der 5.4 testing zu geben.

Gruß
Klaus

14

x86 Systeme (PC) / [5.5 unstable] AMD Radeon mit softhddevice und vdpau

« on: September 07, 2020, 21:40:46 »

Hallo Zusammen,
ich bin gerade dabei MLD 5.5 auf verschieden Platformen zu testen.
Darunter sind auch verschiedene Syteme mit AMD Radeon GPU.

Auf einem Arctic MC001 mit eine älteren Radeon HD 5430 GPU lief softhddevice ootB.
Laut Xorg Log wird dabei der "VDPAU driver: r600", also die libvdpau_r600.so, verwendet.
Diese ist Bestandteil von Mesa.
Das Mesa Paket von MLD wurde also u.a. mit dem r600 Treiber gebaut.
Mit älteren Radeon GPUs, die den r600 Treiber nutzen, funktioniert MLD 5.5 also ohne Probleme.

Auf einem anderen Sytem mit AMD AM1 MB und einem Athlon 5350 mit integrierter Radeon HD 8400 GPU funktioniert die Ausgabe per softhddevice leider nicht.
Laut Log wird kein passender vdpau Treiber gefunden.
Diese GPUs verwenden den radeonsi Treiber, also libvdpau_radeonsi.so, der Bestandteil von Mesa ist.
Leider ist dieser nicht im mesa Paket von MLD enthalten.

Wäre es möglich, das mesa Paket der MLD auch mit dem radeonsi Treiber zu bauen?

Gruß Klaus