Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - franky

361
Alle von mir vermissten libs liegen in diesem Ordner.

Sie sind aber definitiv nicht mehr, wie bei der 5.4, Bestandteil des xorg-intel Paketes.
Durch den Vergeleich der Pakete bin ich ja erst auf die Idee gekommen, dass die libs in der 5.5 fehlen könnten.
Und dort wo sie bei der 5.4 noch waren, sind sie auch nicht mehr. :-\

Für mich stellt sich halt noch die Frage, ob sie bei der 5.5, wie vermutlich vorher als Bestandteil des xorg-intel Paketes der 5.4, mit den für Intel-VAAPI passenden Abhängigkeiten gebaut wurden.
Von den Open-GL-libs aus Mesa ist ja nur noch i965_dri.so Bestandteil von xorg-Intel.
Die anderen, von mir vermissten GL-libs aus mesa kommen irgend woanders her.
Könnten sie dann, wenn sie zu unterschiedlichen Zeiten in unterschiedlichen Paketen gebaut wurden, aus unterschiedlichen Mesa-Versionen stammen und nicht mehr zusammen passen?

Es muss ja einen Grund geben, weshalb "modesetting" nicht mehr funktioniert und eine andere, evtl. für VAAPI nicht passende, OpenGL-Version (3.0 anstatt 4.5) verwendet wird.

362
Hallo Claus,

ich glaube, ich habe den Grund für die Probleme von Kodi mit VAAPI sowie das Problem mit "modesetting" gefunden.
In der 5.5 fehlen unter /usr/lib wichtige OpenGL-libs (mesa), wie z.B. die libGL.so, libEGL.so und libglapi.so.
Außerdem die DRM-Libs wie z.B. libdrm.so und libdrm_intel.so.
Im Paket xorg-intel der 5.4 sind diese enthalten.

Bei der 5.5 fehlen sie im Paket xorg-intel und somit im System.
Enthalten sind jedoch, wie bei der 5.4, die Kernel-Module plus Firmware und die Xorg-Module libglamoregl.so, libglx.so, intel_drv.so.
Sowie die DRI-Module i965_dri.so (mesa) und i965_drv_video.so (libva)
Der VDR mit softhddevice kommt anscheinend ohne die fehlenden GL- und DRM-libs aus und kann VAAPI nutzen.
Bei Kodi verursachen die fehlenden libs anscheinend das Problem mit VAAPI.

Vermutlich würde mit diesen jetzt fehlenden libs auch  "modsetting" wieder richtig funktionieren.

Hast Du eine Idee, weshalb die libs im Paket xorg-intel der 5.5 fehlen?

363
Der Restart von Xorg hat anscheinend nicht gereicht.
Nach einem Reboot der 5.4 läuft jetzt auch Kodi mit "intel" anstatt "modesetting".
Und die VAAPI Beschleunigung in den Player-Einstellungen ist auch vorhanden.

364
Bei der 5.4 fehlt im letzten Abschnitt der /etc/X11/xorg.conf.d/30_intel.sh die "intel" Zeile.
Kann ich die einfach einfügen?

Update: Ich hab mich mal getraut und die Datei 30_intel.sh analog zur 5.5 angepasst.
             Zur Not gibt es ja bei MLD die genialen snapshots.
             VDR funktioniert mit "intel", aber Kodi stürzt ab.

365
x86 Systeme (PC) / MLD 5.5 auf NUC10i3FNH?
« on: October 03, 2020, 17:48:03 »
Hallo Kemmerle,

teste mal nicht die 5.5 sondern die 5.4 stable oder testing.
Die 5.4 testing hat derzeit das besser funktionierende Kodi 18 im Paket kodi-stable dabei.

Die 5.5 hat mit den Intel-Treibern noch Probleme.

Einen CoreI der 10ten Generation habe ich mangels HW bisher noch nicht getetestet.
Intel CoreI Systeme bis zur 8ten Generation haben bei mir mit MLD 5.4 aber super funktioniert.

Was verwendest Du eigentlich bei dem Nuc für DVB-HW?
Oder willst Du Sat-IP verwenden?

366
Hallo Claus,

ich habe jetzt mal für den Grafiktreiber die Variante "modesetting" getestet.
Damit funktioniert VAAPI überhaupt nicht.
Beim VDR kein Bild und auch kein Menü aber Ton.
Ich hab mal den VDR-Loglevel auf 3 erhöht und da sieht man, dass keine vaapi-Ausgabe gestartet wird.

Wenn ich mit den "modesetting" Treibern das 1080p Video in Kodi abspielen möchte, bleibt es bei einer CPU-Last von fast 100% stehen.
Im Kodi-Log sieht man, dass Kodi überhaupt keinen passenden Treiber findet.
NOTICE: GL_VENDOR = VMware, Inc.
NOTICE: GL_RENDERER = llvmpipe (LLVM 7.0, 256 bits)
NOTICE: GL_VERSION = 3.1 Mesa 18.3.6
NOTICE: GL_SHADING_LANGUAGE_VERSION = 1.40

Mit den "Intel" Treibern schaut das wenigstens so aus:
ERROR: (VDPAU) unable to init VDPAU - vdp_st = 0x1.  Falling back.
NOTICE: GL_VENDOR = Intel Open Source Technology Center
NOTICE: GL_RENDERER = Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
NOTICE: GL_VERSION = 3.0 Mesa 18.3.6
NOTICE: GL_SHADING_LANGUAGE_VERSION = 1.30
Wobei man sieht, dass Kodi nach VDPAU sucht, aber weder VDPAU noch VAAPI findet.
Beim VDR sieht man dagegen mit Loglevel3 auch die vaapi-Meldungen in den "System Meldungen".

Bei 5.4 auf dem N3150 schaut das im Kodi-Log so aus:
NOTICE: VAAPI::Close - closing decoder context
NOTICE: GL_VENDOR = Intel Open Source Technology Center
NOTICE: GL_RENDERER = Mesa DRI Intel(R) HD Graphics 400 (Braswell)
NOTICE: GL_VERSION = 4.5 (Core Profile) Mesa 17.1.10
NOTICE: GL_SHADING_LANGUAGE_VERSION = 4.50

Unter 5.4 mit den "modesetting" Treibern findet also auch Kodi VAAPI.
Dann wird offensichtlich erst die VAAPI-Option in den Player-Einstellungen angezeigt und dann auch verwendet.

Erkennt Kodi beim Start kein VAAPI, wie derzeit bei der 5.5,  wird die Option auch nicht angezeigt.
Verwendet wird dann der OpenGL Treiber ohne VAAPI-HW-Beschleunigung, was dann die höhere CPU-Last verursacht.

Das Problem bei der 5.5 scheint also wirklich nicht alleine an Kodi zu liegen, sondern primär an den Intel-Treibern.
Wobei vermutlich neben den Intel-Grafik-Treibern und libva-intel-driver auch Mesa (OpenGL und DRI) eine Rolle spielt.

367
Hallo Claus,

ich habe momentan die 5.4 auf dem N3150 und die 5.5 auf dem i3-7100 laufen.

Laut vainfo läuft vaapi auf beiden Systemen. Nur die Version der 5.5 ist wesentlich aktueller.
MLD 5.4 auf N3150:
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) CherryView - 1.7.3

MLD 5.5 auf i3-7100:
vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake - 2.3.0

Im VDR Log des 5.4 Systems steht diese Info zu VAAPI:
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0

Beim i3 mit MLD 5.5 fehlt die Info im VDR-Log

Die CPU-Last auf dem 5.5er System beim Abspielen eines 1080p Videos (SerusTV-Aufnahme) im VDR liegt bei ca. 10%.
Das gleiche Video in Kodi abgespielt erzeut eine CPU-Last von über 50%
In der 5.5 wird also von softhddevice offensichtlich VAAPI verwendet, aber eben nicht von Kodi.

Ich habe auch schon in den Xorg-Logfiles gesehen, dass das Laden der Intel-Video-Treiber bei der 5.5 anders abläuft, als bei der 5.4

Ich werde als Nächstes mal deinen Vorschlag testen unter 5.5 auch wieder auf Laden der Intel-Treiber via modesetting umzustellen.

368
Ich war unterwegs und konnte erst jetzt kurz testen.

Zuerst habe ich das Update von kodi-stable vom 02.10.20 19:54 mit Kodi 18.8.0-2 eingespielt.
Leider auch dort in den Player-Einstellungen keine VAAPI-Option. :(

Wegen dem Post von mafe86 habe ich auch mal auf das Paket kodi mit Kodi 18.8-94.6 umgestellt.
Das ist jedoch schon vom 16.09.2020, es fehlt aber auch die VAAPI-Option.

369
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

370
Gut zu wissen. Danke für die Info.
Ich habe aber gestern Abend doch wieder komplett auf testing umgestellt.

371
Danke Claus!

Ich habs gerade getestet. Funktioniert bei mir wieder einwandfrei.

In diesem Zusammenhang mal eine Frage.
Ist es kritisch, stabel und testing Pakete einer Version zu mischen?

Ich hatte heute versuchsweise wieder auf stable umgestellt und VDR-Plugins installiert, was auch einwandfrei funktioniert hatte.
Somit hatte ich eine MLD 5.4 stable, die aber auch Pakete aus testing enthalten hat.
Darunter z.B. kodi-stable, das es derzeit unter 5.4 Stable gar nicht gibt.
Hat zwar Alles funktioniert, ich war mir aber unsicher, ob diese Mischung auf Dauer gut ist.

Ich vermute mal, es ist sicherer jetzt wieder komplett auf 5.4 Testing umzustellen.

Gruß
Klaus

372
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

373
Hallo Claus,

ich habe gerade auf einem RPI3 und einem Intel-Sytem die Paketliste aktuallisiert und es hat auf beiden wieder frunktionert.
Danke Claus!

Übrigens war vorher der Workaround von gr4vity mit vorstellen der Zeit um eine Minute nur dann erfolgreich, wenn man verhindert hat, dass der VDR die Systemzeit über Satellit korrigiert.
Neben ntp gibt es ja im VDR auch noch diesen Mechanismus zum Setzen der Systemzeit, der bei MLD für den ARD-Transponder aktiviert ist.

Gruß
Klaus

374
Hallo,

ich kann die Aussage von baltic nur bestätigen.

Gestern und auch heute funktionierte bei mir das Update auch nicht und auch eine Ausschalten von ntp mit Reboot bringt nichts.

Am Wochenende hatte das Update auf dem gleichen Intel-System aber einwandfrei funktioniert.

Einen Abhängigkeit vom ntp-Daemon, ob das Update der "package list" mal funktioniert und mal nicht, scheint es also nicht zu geben.

Auf meinem RPI3 mit 5.5 unstable funktioniert das Update momentan auch nicht.

Gruß
Klaus

375
x86 Systeme (PC) / [5.5 unstable] AMD Radeon mit softhddevice und vdpau
« on: September 09, 2020, 00:34:38 »
Danke für das neue mesa Paket.
Die libvdpau_radeonsi.so ist jetzt auf jeden Fall unter /usr/lib/vdpau vorhanden.
Leider habe ich noch kein TV Bild. Ton ist aber vorhanden.

Ein Log habe ich hochladen lassen. Der Upload Code lautet: 0ltkR6
Im xorg Logfile sieht man, dass kein vdpau-Modul geladen und somit keine Viedobeschleunigung aktiv ist.
Code: [Select]
[    21.249] [    21.399] (==) RADEON(0): DRI3 disabled
[    21.399] (==) RADEON(0): Backing store disabled
[    21.399] (WW) RADEON(0): Direct rendering disabled
[    21.399] (II) RADEON(0): Acceleration disabled
...
[    21.416] (II) Initializing extension GLX
[    21.416] (II) AIGLX: Screen 0 is not DRI2 capable

Bei dem anderen System mit der älteren Radeon, die den r600 Treiber nutzt, schaut das so aus:
Code: [Select]
[    28.155] (II) RADEON(0): [DRI2] Setup complete
[    28.155] (II) RADEON(0): [DRI2]   DRI driver: r600
[    28.155] (II) RADEON(0): [DRI2]   VDPAU driver: r600
....
[    28.171] (II) Initializing extension GLX
[    28.184] (II) AIGLX: Loaded and initialized r600
[    28.184] (II) GLX: Initialized DRI2 GL provider for screen 0
Ich habe die gleiche MLD-Installation auf diesem System gestartet und Bild und Ton.
Das Log von diesem System habe ich auch hochgeladen: cnkjvp

Schade, dass der Neubau von mesa incl. radeonsi nichts gebracht hat.
Evtl. müsste man auch xorg mit Treibern neu bauen, da es ja zwischen xorg und mesa Abhängigkeiten gibt.