Dynamite und Tuner abschalten

Könnt ihr bei vnsiserver mal das Debug-Log aktivieren? Dazu muss man es neu übersetzen und -DDEBUG übergeben.

apt-get source vdr-plugin-vnsiserver
cd vdr-plugin-vnsiserver-<version>
(Patch anwenden)
dpkg-buildpackage -tc -uc -us
(usw.)

Patch:

diff --git a/debian/rules b/debian/rules
index 976041c..356997f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,8 +1,12 @@
 #!/usr/bin/make -f


 #DH_VERBOSE=1
+MAKE_OPTIONS = DEBUG=1


-.PHONY: override_dh_strip override_dh_auto_install
+.PHONY: override_dh_auto_build override_dh_strip override_dh_auto_install
+
+override_dh_auto_build:
+       dh_auto_build -- $(MAKE_OPTIONS)


 override_dh_strip:
        dh_strip --dbg-package=vdr-plugin-vnsiserver-dbg

Wichtig ist, dass da ein TAB vor dem dh_auto_build in der letzten Plus-Zeile steht, rules ist ja ein Makefile.

Lars.

TXL
Das mit der 10-Sekunden-Verzögerung bis zum Bild hängt wohl damit zusammen, dass vnsi aus irgend einem Grund keine PAT/PMT empfängt und deshalb die PIDs aus der channels.conf nimmt. Solange keine PIDs bekannt sind, kann es auch nichts an xbmc weiterreichen. Die PAT/PMT sollte aber relativ häufiger kommen (ich glaube, ca. alle 500ms), deshalb ist anzunehmen, dass da einfach noch gar keine vernünftigen Daten kommen - warum auch immer.

Lars.

Das Glaub ich aber nicht, weil mit streamdev hab ich genau das gleich Problem da dauert es dann auch ca 10 Sekunden. das mit dem vnsi debug log kann ich mal testen, eig verwende ich xvdr das vnsi hatte ich nur an um zu schauen ob es da genau so auf tritt. Ich dann auch sonst nochmal en Auszug posten mit xvdr aber das sollte sich ja nicht wirklich ändern.

Oder kann das auch irgendwie mit meiner Sat Anlage und dem Mutliswitch DISEQC zusammen hängen? Das ist das einzige was ich anders habe als Meikel dann er hat ja nur 1 Satellit.

Es kann ja sein, dass streamdev auch zufällig 10 Sekunden auf PAT/PMT wartet, bevor es die Kanal-PIDs nimmt. Da hab ich jetzt nicht reingesehen.
xvdr kann ich mir auch noch mal ansehen, ob es was anderes macht, wird aber heute nichts mehr.

Lars

Alles klar dann mach ich wenn ich Zeit hab das gleich nochmal und Poste das wieder den Auszug aus dem syslog. Was es mit den PAT/PMT aufsich hat versteh ich nicht ganz aber das geht wahrscheinlich tiefer in die Materie.

In der PAT stehen die PIDs des TS, wo sich die PMT befindet. Und in der PMT ist pro Kanal vermerkt, welche PIDs zum Kanal gehören und was für ein Typ dahinter steckt. Einfach mal in der englischen Wikipedia bei MPEG2 transport stream nachlesen, ist kein unnütes Wissen.

In einem TS sind pro Transponder ja mehrere Programme drin, deshalb muss ein Receiver wissen, welche Daten es da extrahieren muss, um alles zu einem Programm zusammen zu bekommen.

Lars

Gibt es eigentlich neue Erkenntnisse zu diesen Thema/Problem?

Zitat von vdr-freak

Gibt es eigentlich neue Erkenntnisse zu diesen Thema/Problem?

+1
Wäre auch brennend an einer Lösung interessiert. Wie kann ich unterstützen?

cu
Markus

Tut mir leid, ich hatte noch gar keine Zeit, da weiter nachzuschauen.

Lars.

Ich hab momentan keine weitere Idee, was da passiert.
Wenn jemand mal bei Gelegenheit wie oben angegeben vnsiserver mit DEBUG betreiben kann, kann ich es ja vielleicht noch mal versuchen.

Lars.

Da ich proxmox verwende und die L4M an den yavdr guest durchgereicht wird, habe ich mir nochmal die Art des PCI Passthrough angesehen. Bislang kommt ja vor allem "pci-assign" zum Einsatz (was wohl über das Modul kvm läuft). Mit aktuellen Kernel Versionen (> 3.9) wird ja "vfio-pci" empfohlen (was über die iommu Module läuft). Ohne näher ins Detail gehen zu wollen, sagt man vfio-pci gewisse Vorteile nach.

In Bezug auf das hier diskutierte Problem konnte ich jedoch keinen Unterschied feststellen. Auch mit vfio-pci wachen die frontends nicht immer auf (frontend timed out). Wenn man das entsprechende frontend nochmals schlafen legt und wieder versucht aufzuwecken, geht es i.d.R. wieder (manchmal muss man dies auch zwei oder dreimal versuchen, bis das frontend aufwacht).

Weiter vorne im Thread war meine ich ja jemand dabei, der keine Virtualisierung verwendet. Insofern dies nur zur Vollständigkeit.

Nach längerer Zeit habe ich nun die Auto Idle Funktion des Dynamite Plugins nochmals aktiviert. Feststellen konnte ich, dass die Devices nach wie vor nicht immer korrekt aufwachen. Jedoch scheint der VDR jetzt anders darauf zu reagieren. Wenn nun ein Device für Aufnahmen nicht zur Verfügung steht, wird einfach das nächste Device aufgeweckt. In den letzten 10 Tagen konnte ich keine fehlerhafte Aufnahme festellen! Lediglich einmal hatte ich eine Situation in der Streamdev den Dienst verweigert hatte, weil ein Gerät nicht aufwachen wollte (hatte aber keine Zeit die Logs genauer zu durchleuchten).

Für mich erst mal ein wesentlicher Fortschritt, so dass ich Auto Idle zum weiteren Testen aktiviert lasse.
Da ich yaVDR stable verwende und eher unregelmäßig Updates einspiele, frage ich mich, ob das geänderte Verhalten des VDR durch die Updates erklärt werden kann!?

Kann ich mir kaum vorstellen. Der vdr in stable hat schon länger kein Update erhalten.
Wenn der Sommer nicht so schön wäre, hätte ich viel mehr Zeit, dynamite endlich mal zu überarbeiten.

Lars

Hi Lars.
Ich grabe das hier mal wieder aus. Würde gerne dynamite in den aktuellen 2.2.0 einbauen. Gibt es diesbezüglich mittlerweile nen Patch?

Gruß Patrick

Im unstable-Paket bei yavdr ist einer drin. Ich kann mal gucken, ob ich da einen für den vanilla-vdr am Wochenende fertig machen kann.

Lars.

Das wäre cool
Hab schon selbst versucht den aus dem 2.0.0 Patch zu basteln. Aber da bekomme ich Compiler Fehler.

Danke Dir
Gruß Patrick

Hi,
Im easyvdr ppa für vdr 2.2.0 hat Mango auch einen drin.
MfG Stefan

Gesendet von meinem HTC One mit Tapatalk 2

https://github.com/flensrocker…hes/opt-61_dynamite.patch

Das ist der von mir gepflegte Patch für das yavdr-Paket, der aber nicht 100% auf einen vanilla-vdr passt, da ja noch andere Patches in dem vdr-Paket drin sind.

Demnächst kommt einer für den vdr 2.2.0, dann aber an dieser Stelle: https://github.com/flensrocker…amite/tree/master/patches

Lars.

Danke. Ich seh den mir mal an. Denke damit komme ich dann klar.

Gruß Patrick

Patch ließ sich schonmal ohne Probleme einfügen
Mal sehen was der VDR nun im Test dazu sagt.