376

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

« on: October 03, 2020, 22:18:53 »

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.

377

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?

378

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

« on: October 03, 2020, 16:50:33 »

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.

379

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

« on: October 03, 2020, 13:26:22 »

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.

380

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

« on: October 03, 2020, 01:11:26 »

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.

381

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

382

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

« on: October 02, 2020, 12:42:32 »

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

383

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

« on: October 01, 2020, 22:20:45 »

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

384

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

385

Allgemein [ General ] / [5.5 unstable] Paket Aktualisierung schlägt fehl (x86 System)

« on: September 30, 2020, 15:55:35 »

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

386

Allgemein [ General ] / [5.5 unstable] Paket Aktualisierung schlägt fehl (x86 System)

« on: September 29, 2020, 13:07:11 »

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

387

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 0Ich 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.

388

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