TVheadend frisch compiled unter Debian 10 (PROXMOX CT), Transcoding Fehler,

ice77

Hallo Leute,

ich habe aktuell einen Intel NUC 8i5 unter Proxmox laufen. Hierauf läuft u.a. ein Debian 9 Container mit einem stock tvheadend. Die Installation ist nun schon Wochenlang in Betrieb und tut was sie soll.

Aber:

Einzig das fehlende Transcoding bei der Stock Version (HTS Tvheadend 4.2.8-36~g5bdcfd8ac) hat mich dazu bewegt, ein Debian 10 in einen Proxmox Container zu installieren und die 2 Sundtek DVBS2 Sticks durchzureichen um über vaapi das Transcoding nutzen zu könnnen. TVHeadend funktioniert, jedoch schmeisst TVheadend jetzt Fehler die ich ohne Hilfe nicht mehr gefixed bekomme.

facts:
* Debian 10
* HTS Tvheadend 4.3-1867~g2a7cb68bc-dirty
* 2x Sundtek DVBS2 USB Sticks
* DSL 16k - 1MBit Upload, Zugriff über VPN (Fritzbox) mit Kodi

Folgende Fehlermeldungen werden geworfen:

Bash

2020-05-17 20:47:05.973 [   INFO] subscription: 0008: "192.168.178.204 [ dfs | Kodi Media Center ]" subscribing on channel "kabel eins", weight: 100, adapter: "Sundtek DVB-S/S2 (VI) #0 : DVB-S #0", network: "DVB-S Netzwerk", mux: "12544.75H", provider: "ProSiebenSat.1", service: "kabel eins", profile="transcoding", hostname="192.168.178.***", username="***", client="Kodi Media Center"
2020-05-17 20:47:05.997 [   INFO] transcode: 0002: 02:MPEG2VIDEO: ==> Using profile vaapi
2020-05-17 20:47:05.997 [   INFO] transcode: 0002: 03:MPEG2AUDIO: ==> Copy
2020-05-17 20:47:05.997 [   INFO] transcode: 0002: 04:TEXTSUB: ==> Filtered out
2020-05-17 20:47:06.457 [  ERROR] libav: AVHWDeviceContext: No VA display found for device: /dev/dri/renderD128.
2020-05-17 20:47:06.457 [  ERROR] vaapi: failed to create a context for device: /dev/dri/renderD128
2020-05-17 20:47:06.499 [  ERROR] libav: AVHWDeviceContext: No VA display found for device: /dev/dri/renderD128.
2020-05-17 20:47:06.499 [  ERROR] vaapi: failed to create a context for device: /dev/dri/renderD128

Scheinbar hatten schon viele mit Transcoding ihre Probleme und ich hab hier und da gelesen, man sollte doch das Docker Image unter OMV laufen lassen. Das könnte ich tun... OMV4 läuft auch in einer Virtuellen Maschine auf dem Server, jedoch müsste ich mich neu einarbeiten, wie die DVBS2 Sticks dann statt durch den Container in die Virtuelle Maschine wandern. Es hat schon jemand probiert, mit dessen Anleitung ich die Sundteks in den Container durchgereicht habe, hierfür eine virtuelle Maschine zu nutzen... und das hat nicht fehlerfrei funktioniert.

Was könnte ich jetzt probieren (bis auf die Docker Geschichte die ich eigentlich vermeiden will... da das selbst kompillierte TVH ja bis auf vaapi sauber läuft)

Danke schonmal

ice77

ice77

Wenn ich jetzt über den LiveTV Player von TVH gehe, bekomme ich für eine kurze Zeit sogar ein fast flüssiges Bild von HD Sendern. Die Normalen wie Pro7 etc ... die werfen den obigen vaapi Fehler

Bash

2020-05-17 23:43:00.238 [   INFO] subscription: 0047: "HTTP" subscribing on channel "ZDF HD", weight: 100, adapter: "Sundtek DVB-S/S2 (VI) #1 : DVB-S #0", network: "DVB-S Netzwerk", mux: "11362H", provider: "ZDFvision", service: "ZDF HD", profile="webtv-vp8-vorbis-webm", hostname="192.168.178.***", username="***", client="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"
2020-05-17 23:43:10.239 [WARNING] subscription: 0047: service instance is bad, reason: No input detected
2020-05-17 23:43:10.239 [   INFO] mpegts: 11362H in DVB-S Netzwerk - tuning on Sundtek DVB-S/S2 (VI) #0 : DVB-S #0
2020-05-17 23:43:10.250 [   INFO] subscription: 0045: "epggrab" unsubscribing
2020-05-17 23:43:10.872 [   INFO] subscription: 0047: "HTTP" subscribing on channel "ZDF HD", weight: 100, adapter: "Sundtek DVB-S/S2 (VI) #0 : DVB-S #0", network: "DVB-S Netzwerk", mux: "11362H", provider: "ZDFvision", service: "ZDF HD", profile="webtv-vp8-vorbis-webm", hostname="192.168.178.***", username="***", client="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 01:H264: ==> Using profile webtv-vp8
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 02:MPEG2AUDIO: ==> Using profile webtv-vorbis
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 03:MPEG2AUDIO: ==> Filtered out
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 04:AC3: ==> Filtered out
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 05:MPEG2AUDIO: ==> Filtered out
2020-05-17 23:43:11.068 [   INFO] transcode: 000F: 07:DVBSUB: ==> Filtered out
2020-05-17 23:43:11.240 [   INFO] mpegts: 12515.25H in DVB-S Netzwerk - tuning on Sundtek DVB-S/S2 (VI) #1 : DVB-S #0
2020-05-17 23:43:11.467 [   INFO] libav: AVCodecContext: v1.7.0
2020-05-17 23:43:11.510 [WARNING] libav: AVCodecContext: Increasing reorder buffer to 2
2020-05-17 23:43:12.279 [   INFO] subscription: 0049: "epggrab" subscribing to mux "12515.25H", weight: 4, adapter: "Sundtek DVB-S/S2 (VI) #1 : DVB-S #0", network: "DVB-S Netzwerk", service: "Raw PID Subscription"

Alles anzeigen

Die CPU Nutzung ist auch niedrig (6%). Kann aber sein, dass er einen Core von den 8 stark auslastet... aber auch hier wären wir weit weg von den möglichen 100% single Core Auslastung

ice77

Hat da keine ne Idee? Oder ist in den Sommermonaten einfach weniger los im Forum

darkside40

Versuch es doch einfach mal mit dem Docker.
Das Transcoding funktioniert nur wenn das Zusammenspiel von Treiber, ffmpeg sowie TVH richtig funktioniert.
Beim Docker weiss man wenigstens das ffmpeg und TVH richtig compiliert sind.

Ausserdem ist ein Docker wesentlich Ressourcen schonender.

ice77

Hallo darkside40

Wenn man einen Proxmox Server am Laufen hat, ist eine Containerisierung eigentlich extrem ressourcenschonend und wunderbar zu administrieren.

Ich habe unter Proxmox alles in LXC Containern laufen, außer OMV4. Das hat eine Virtuelle Maschine spendiert bekommen. Hierin laufen gedockert noch Nextcloud, Plex und andere Dienste (auch fehlerfrei...) - kann mich nicht wegen Docker beschweren, jedoch ist es für mich deutlich weniger transparent. Wenn ich ehrlich bin, wüsste ich nicht mal ob ich in regelmäßigen Abständen das "docker image" erneuern müsste. Nextcloud aktualisiere ich von Hand... aber die Docker Installation hab ich seit dem Einrichten vor einem Jahr nicht mehr angefasst.

Hinzu kommt, dass ich DVBS2 Sticks nutze, die ich endlich vom Proxmox in den LXC Container durchgereicht bekommen habe. Das jetzt nochmal für die Virtuelle Maschine zu machen wären deutliche Aufwände :-(. Ich müsste vom Proxmox in die OMV VM und von dort weiter in den Docker. Ob das dann noch stabil läuft?

broda

Moin,

ich habe ein ähnliches Setup:
NUC mit proxmox und zwei Sundtek Sticks in einem debian 10 container mit tvh (build 4.3-1880~g2af3b9e2e).

Allerdings habe ich bisher kein Transcoding genutzt. Wenn Du mir sagst, wie ich das nutze kann ich das gerne bei mir testen.

ice77

Ich kann heute Abend gern mal die Details raussuchen. Den Debian10 LXC hab ich gestern gelöscht und diesen heute Nacht noch mal neu aufgesetzt und TVheadend über Git neu gezogen, per ./configure die nicht erfüllten abh. geprüft und so viel wie ich es hin bekommen habe über apt-get nachgezogen und dann per ./Autobuild.sh kompiliert. Hier findet er jetzt beide SAT Sticks... aber keine Sender... der Suchlauf bleibt erfolglos.

Der Container mit Debian 9 und Kodi aus dem Repo... läuft aber nur ein Stick wird hier aktiv... der andere funktioniert nicht, obwohl er richtig im System eingebunden ist.

Mich erschleicht die Vermutung... dass die Sticks von Sundtek doch eher eine "Bastelbude" sind

auch dmesg... zeigt merkwürdige Ausgaben
... blocking state...
promiscous mode...

?

Bash

[    8.573745] ZFS: Loaded module v0.8.4-pve1, ZFS pool version 5000, ZFS filesystem version 5
[    9.029967] audit: type=1400 audit(1590260865.780:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" pid=776 comm="apparmor_parser"
[    9.030284] audit: type=1400 audit(1590260865.780:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=778 comm="apparmor_parser"
[    9.030286] audit: type=1400 audit(1590260865.780:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=778 comm="apparmor_parser"
[    9.030618] audit: type=1400 audit(1590260865.780:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=774 comm="apparmor_parser"
[    9.030620] audit: type=1400 audit(1590260865.780:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=774 comm="apparmor_parser"
[    9.030622] audit: type=1400 audit(1590260865.780:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=774 comm="apparmor_parser"
[    9.032587] audit: type=1400 audit(1590260865.780:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/tcpdump" pid=777 comm="apparmor_parser"
[    9.035414] audit: type=1400 audit(1590260865.784:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default" pid=775 comm="apparmor_parser"
[    9.035416] audit: type=1400 audit(1590260865.784:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" pid=775 comm="apparmor_parser"
[    9.035430] audit: type=1400 audit(1590260865.784:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default-with-mounting" pid=775 comm="apparmor_parser"
[    9.060712] vmbr0: port 1(eno1) entered blocking state
[    9.060714] vmbr0: port 1(eno1) entered disabled state
[    9.061407] device eno1 entered promiscuous mode
[    9.071156] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
[    9.071689] new mount options do not match the existing superblock, will be ignored
[    9.401757] bpfilter: Loaded bpfilter_umh pid 914
[    9.402120] Started bpfilter
[   12.754701] e1000e: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[   12.754704] e1000e 0000:00:1f.6 eno1: 10/100 speed: disabling TSO
[   12.754784] vmbr0: port 1(eno1) entered blocking state
[   12.754785] vmbr0: port 1(eno1) entered forwarding state
[   12.754918] IPv6: ADDRCONF(NETDEV_CHANGE): vmbr0: link becomes ready
[   13.488864] EXT4-fs (dm-15): mounted filesystem with ordered data mode. Opts: (null)
[   13.839539] vmbr0: port 2(veth100i0) entered blocking state
[   13.839541] vmbr0: port 2(veth100i0) entered disabled state
[   13.839595] device veth100i0 entered promiscuous mode
[   13.863143] eth0: renamed from vethXMEfNO

Alles anzeigen

broda

Naja die Sticks laufen bei mir auf Linux (ubuntu, debian, Synology package, proxmox ct) schon seit Jahren richtig gut und stabil.

Mein Vorschlag wäre, erst einmal buster und die unstable version von tvh zu probieren. Wenn das läuft, kannst Du Dir "Dein" tvh selbst bauen.

Die Ausgaben kommen vom Netzwerk, sieht auch nicht ungewöhnlich aus. Klappt das Netzwerk im Container?
Was sollen die Sticks damit zutun haben?

synci

Habe auch Proxmox laufen und einen Debian Buster LXC Container für TVH 4.3-1880~g2af3b9e2e.
Habe allerdings keine Sundtek Sticks sondern eine CineS2 Karte.
Falls es Dir trotzdem hilft kann ich Dir gerne was ausprobieren.

ice77

Hallo Leute,

hatte gar nicht gemerkt, dass ich noch Antworten bekommen habe. Muss mal schauen, ob die Benachrichtigungen vom Board in den Spamfilter laufen.

Bin leider noch nicht weiter gekommen, da mein VPN heute Nacht ausgefallen ist. Eine Baustelle jagt die nächste. Sobald ich wieder Luft hab, gehe ich das "Problem" wieder an.

Welches Betriebssystem ist empfehlenswert für den Proxmox Container, wenn man das selbst Compilieren umgehen möchte (nicht dass sich auf diesem Weg noch weitere Fehler einschleichen).

Debian 9 oder lieber Ubuntu 18.04?
TVheadend aus dem Unstable Zweig ziehen? Würde hier das Transcoding schon out of the Box gehen?

Geht das überhaupt, wenn der Server an 1MBit Upload hängt, oder kann man das unter den Umständen eigentlich schon bez. Transcoding vergessen?

TVheadend frisch compiled unter Debian 10 (PROXMOX CT), Transcoding Fehler,

Jetzt mitmachen!

Tags