BM²LTS - Intel VAAPI/NUC-Lösung mit NetCeiver & OctopusNet

Hallo cinfo,

o.k. das Kopieren der i965_drv_video.so und des vainfo hab ich jetzt wie oben beschrieben erledigt. Damit bekomme ich jetzt die passende vainfo Anzeige mit Version 0.38. Sehr schön.

Es gibt noch einige andere Programme neben vainfo in /usr/local/bin (avcenc, h264encode, jpecenc, loadjpeg, mpeg2vaenc, mpeg2cldemo) - die hab ich im System an keiner anderen Stelle gefunden. Hab sie erst mal in /usr/local/bin gelassen, und nicht nach /usr/bin kopiert. Richtig?

Ich bekomme jetzt aber beim Start von vdr-sxfe den Fehler: "fe_xine_init: xine_open_video_driver("vaapi") failed"

Warum klappt der fe_xine_init nicht?

• Weil die Libs libva-dev, libva-drm1, libva-egl1, libva-glx1, libva-tpi1, libva-wayland1, libva-x11-1 und libva1 noch auf Version 1.4.1-1 sind, und evtl. nur eine alte vaapi Version unterstützen? (wo stecken die Lib´s drin, d.h. welches Paket muß ich wahrscheinlich neu bauen?)
• Deutet der fe_xine_init Fehler darauf hin, daß ich ein aktuelleres Xine Paket brauche?
• Wie kann ich das weiter eingrenzen?

Meine xine- Stände:

m.f.G.
Michael

Hallo cinfo,

ich hab auf meinem NUC System zwei getrennte Linux-Systeme. Nachdem ich mein BM2LTS zerschossen hatte (und es jetzt nochmal neue aufsetzen müßte), hab ich erst mal auf der Jessie Partition versucht, den aktuellen Intel Treiber zu generieren und zum Laufen zu bekommen (bei Standard Jessie ist ja VAAPI etc. noch in einer älteren Version drauf).

Das mag ja jetzt auch mein Problem sein. Die Libs libva-dev, libva-drm1, libva-egl1, libva-glx1, libva-tpi1, libva-wayland1, libva-x11-1 und libva1 sind bei mir noch auf Version 1.4.1-1 (VA-API 0.36?). Der Intel Treiber und die libva sind jetzt selbst generiert mit 1.6.0pre2 (VA-API 0.38).

m.f.G.
Michael

Hallo cinfo,

bin das Wochenende mal wieder etwas dazu gekommen, den Fehler weiter einzugrenzen ...
Da ich mit dem selbst Generierten Intel-Treiber nicht auf die Beine gekommen bin (immer wieder X-Server Abstürze), habe ich jetzt den aus dem Repo von SOliver genommen (debian.oppserver.net). Damit hab ich jetzt einen va-api Stand von 1.6.0, also ganz nahe an dem von Dir oben erwähnten aktuellsten Stand ...

root@Intel-NUC:~# vainfo
libva info: VA-API version 0.38.0
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_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Broadwell - 1.6.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      ....

Die X-Server Abstürze bekomme ich noch immer, wenn ich vaapi starte (egal ob ich den vdr-sxfe oder wenn ich - wie heute mit mpv ausprobiert - einen Mediaplayer aufrufe, der vaapi nutzt) ...
In meiner Xorg.0.log.old finde ich jetzt auch die Ursache: einen Segmentation fault ...

[   312.015] (EE) Backtrace:
[   312.015] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7f0785169d46]
[   312.015] (EE) 1: /usr/bin/X (0x7f0784fb3000+0x1baf29) [0x7f078516df29]
[   312.015] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f0782a97000+0x35180) [0x7f0782acc180]
[   312.015] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f077eea1000+0xd1e0a) [0x7f077ef72e0a]
[   312.015] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f077eea1000+0xd256b) [0x7f077ef7356b]
[   312.015] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f077eea1000+0xd2c76) [0x7f077ef73c76]
[   312.015] (EE) 6: /usr/bin/X (DRI2SwapBuffers+0x1d0) [0x7f078513a700]
[   312.015] (EE) 7: /usr/bin/X (0x7f0784fb3000+0x188f3c) [0x7f078513bf3c]
[   312.015] (EE) 8: /usr/bin/X (0x7f0784fb3000+0x573f7) [0x7f078500a3f7]
[   312.015] (EE) 9: /usr/bin/X (0x7f0784fb3000+0x5b596) [0x7f078500e596]
[   312.015] (EE) 10: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f0782ab8b45]
[   312.016] (EE) 11: /usr/bin/X (0x7f0784fb3000+0x4590e) [0x7f0784ff890e]
[   312.016] (EE) 
[   312.016] (EE) Segmentation fault at address 0x18

Frage: Wie grenze ich solch ein Problem weiter ein? Warum crashed der Intel-Treiber (wie auch der von mir selbst generierte)? Ist meine xorg.conf zu "dünn" (wenn sie nur eine Device-Section hat, aber keine Screen- bzw. Monitor-Section)? Hab ich mit lightdm einen Windows-Manager der nicht geeignet ist?

m.f.G.
Michael

Hallo cinfo,

ja, das ist ein 64-Bit System. Der Befehl uname -a gibt folgendes aus: "Linux Intel-NUC 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) x86_64 GNU/Linux".

Siehst Du da etwas, was nicht zusammenpaßt?

m.f.G.
Michael

Hallo cinfo,

hab mir noch mal das bm2lts System frisch installiert, und mache gerade ein dist-upgrade um es auf aktuelle Version zu bringen.
Da mein Debian System partout nicht laufen will, und es scheinbar mit den X11 Einstellungen zusammenhängt, möchte ich meine
X11 Einstellungen (und die Versionen der Intel Treiber) mit denen aus Eurer bm2lts vergleichen

Meine Vermutung: Ich habe zwei oder drei Probleme die zusammenspielen:

• Mein LCD Monitor (mit dem ich das momentan teste) ist über einen DVI Adapter an den MiniDisplayPort angeschlossen.
  Dadurch werden die Settings für den HDMI Ausgang (den Standard-Monitor) in der xorg.conf ignoriert. Ich muß die pas-
  senden Settings für den Display Port finden ... (wie gebe ich die für den DP ein?)
  

  
  

• Mein LCD Monitor wird dann nach den Bildwiederholfrequenzen befragt (die er unterstützt), dabei sind natürlich nur 60Hz
  Frequenzen dabei (ich weiß nicht, ob das bei Debian Ärger macht). Es sieht aber danach aus, daß er bei bm2lts gut mit den
  50Hz Einstellungen in der xorg.conf klar kommt. Wenn man die Abfrage unterdrückt, scheint das zu laufen.
  

  
  

• Der Intel Treiber auf meinem Debian System (/usr/lib/xorg/modules/drivers/intel_drv.so) meldet in der Xorg.0.log, daß er
  den Chipsatz (Broadwell) nicht kennt (Zeile 86), und schaltet deshalb die Hardwarebeschleunigung ab (Zeile 189). VaInfo zeigt
  wahrscheinlich deshalb keine VaApi Funktionen an, bei Nutzung von Vaapi durch die Applikationen stürzt die Kiste ab ...

Da aber bm2lts auf meinem Rechner auf dem Monitor Videos darstellen kann, schließe ich einmal Hardwareprobleme aus.

Meine Fragen:

• Im /etc/X11 Verzeichnis sind verschiedene xorg.conf zu finden. Welche werden bei einem Broadwell-NUC System genutzt?
  

  
  

• Unter /var/log/ findet sich normalerweise eine detaillierte Xorg.0.log (die ich mit meiner vergleichen wollte). Leider ist dort
  nichts zu finden. Kann man diese Log-Datei irgendwie aktivieren? (sollte ähnliche Daten beinhalten wie die untere Log-Datei)

m.f.G.
Michael

Nur als feedback für die Developer, habe heute versucht auf einem INTEL NUC NUC5CPYH die neue Version der Donation Cloud BM2LTS V2.83 zu installieren. Installation läuft normal ab aber nach dem reboot erscheint kurz das GRUB/ Ubuntu Auswahl fenster dann scanning BTRFS files, boot geht weiter und stopt (LEGACY BOOT), bildschirm dann schwarz. Jemand schon die Erfahrung gemacht?

Meine Idee war meine Netclients 2 dann später durch die NUCS zu ersetzen mit BM2LTS. Habe noch einen Server (Alter Intel Asus server) Testing am laufen unter BM2LTS V2.74 4TB Festplatte(Headless) der bisher ohne Probleme seine Arbeit verrichtet am externen Netceiver VLAN2 6xDVBS2. Da ich aber kein Zugang sehe auf ein OSD (Nur UBUNTU DESKTOP) weiss ich nicht wo ich Multiroom aktivieren kann.

Haupthardware ist noch eine AVG III 3 TB Aufnahmeserver und client (Factory REEL) + 2x Netclients 2 (Factory REEL) unter VLAN2 am besagten Netceiver.

-Was mir noch nicht klar ist, wird auf dem NUC system auch ein OSD (analog reelbox) sichtbar sein oder ist der Gedanke KODI als frontend zu nutzen?
-Ich habe bereits EasyVDr 2.2 und YAVDR 0.5 auf NUC zum laufen gebracht (MCLI PLUGIN/VLAN), bei beiden habe ich jedoch das Problem dass Ya und Easyvdr die Tuner vom Netceiver so belegen dass ich auf den AVG3/Netclients lange warten muss (Warten auf freien Tuner) beim umschalten, manchmal muss ich dort den VDR stoppen (EASY und YVDR) dann geht es wieder. Die Frage ist welche Einstellung in BM2LTS und im Factory REEL ist anders weil hier das Problem nicht auftaucht?

Gerne würde ich mich mit euch austauschen

Liebe Grüsse

Vento

Lieber Cinfo,
ja prozedere wurde gemacht über Konsole, konnte noch die Partition auf Maximum vergrössern, dann wieder die Meldung suche BTRS File, Bildschirm dann Dunkel. Nach reset dann die Meldung DRM __VLV_FORCE _WAKE GET *ERROR* TIMED OUT MEDIA FORCEWAKE Versuche noch ein Bild vom Screen anzuhängen. Scheint auch ein Problem mit Bluetooth zu geben. Vermutlich liegt das Problem nicht an BM2LTS sondern an der Hardware. Bios Update wurde bereits gemacht. Bei diesem NUC handelt sich um ein Celeron prozessor. Wollen ja eine möglichst kostengünstige Hardware gemäss Stephan. Wobei hier die Raspi2 unter Kosten/Nutzen immer noch Unschlagbar bleibt mit KODI.

Nun wenn man BMTLS2 Nuc mit Kodi als Frontend betreibt wird vermutlich VDR im Hintergrung funktionieren und das Netceiver Bild via VOMP/ VNSI oder XVDR an Kodi angebunden, KODI läuft aber direkt (ALPHA) auf jedem NUC und kann sich an jeden VDR (BM2LTS/ EASYVDR/ YAVDR) via XVDR / VNSI , ich verstehe dann nicht ganz den Umweg über BM2LTS einzig wenn man Server und Client in einem haben möchte. Sehe aber noch einen Nachteil bei den Umschaltzeiten von XVDR / VNSI im Vergleich zu einem VDR der Direkt am Netceiver zugreift via MCLI Plugin.

Bezüglich Option unter Route 66 VDR mit externem Netceiver an ETH 0.2, werde ich dort ein OSD sehen wie auf einem VDR oder lande ich imme auf dem UBUNTU desktop oder muss hier die Video Ausgabe anders eingestellt werden? Wenn ja wo?

Grüsse

Vento