Der Patch ist nur fürs mcli-Plugin, dieses implementiert ja das VDR-Device. Die Abfrage der Signalstärke ist VDR-seitig bereits vorgesehen.
Ich hoffe nur, dass die Anthra-Skin das nicht am VDR vorbei übers DVD-Devicefile per ioctl erledigt. In diesem Fall könnte ich nichts machen.
Grüße
Holger
Hier kommen noch zwei Patches: der eine beseitigt einen potenziellen Deadlock-Bug in bestimmten Konfigurationen (tritt bei mir auf einem speziellen Rechner unter 0.5 auf).
Patch Nummer zwei rüstet Reel-unabhängige Funktionen zum Abfragen der Signalstärke nach Art einer DVB-Karte nach (funktioniert z.B. mit enigmaNG).
Merkwürdigerweise funktioniert die Signalstärke mit Anthra-Skin nicht - oder sind die Balken links unten dort nur eine Atrappe?
Eine Anmerkung noch zum Testen der Patches in Systemen mit sehr wenig Tunern: das Plugin verhält sich im Moment etwas zickig wenn diese knapp werden. Daher sollte man diese zweckmäßigerweise in den Pluginenstellungen limitieren. Ich bin ein paar mal drauf reingefallen...
Grüße
Holger
Kann man dir denn irgendwie eine kleine Anerkennung zukommen lassen? Hast du eine Amazon-Wunschliste oder sowas
Nein, habe ich nicht und ist auch nicht Sinn der Sache.
Zitat
PS.: kann man die Nutzung des Patches der Firma Reel irgendwie verbieten? Nach den frechen Kommentaren über "unternehmensfremde Belange" hier hätten sie's verdient...
Kann man natürlich nicht und sollte man auch nicht, denn wenn Reel seinen Sourcecode nicht offengelegt hätte, dann wäre eine Lösung ohne Hilfe von Reel ganz unmöglich gewesen...
Das war natürlich nicht ernst gemeint. Mir geht nur ewtas der Hut hoch, wenn ich als zahlender Kunde nach Investition einer vierstelligen Summe Sprüche von "betriebsfremden Belangen" lese.
Zum Thema Netceiver:
Ich denke, von der Architektur her könnte man die Aufgabe, mehrere Programme gleichzeitig zu empfangen und per Gigabit zu streamen, kaum besser lösen. Halbwegs robuste Mechanik, modulare Tuner, Backplane mit genug Bandbreite. Dann ein FPGA für die Massendaten, unterstützt durch eine (Soft-)CPU für flexible Metadatenverarbeitung. Zu guter letzt konfigurationsfreies IPv6-Multicast, um die Last auf den kopfstellennahen Kabel gering zu halten und gleiche Streams nicht doppelt zu übertragen. Leider hat das die Firma aus München wohl selber noch nciht so recht begriffen, was dort für eine potente (fast fertig entwickelte) Technik im Regal liegen hat. Denn ansonsten würde sie sie wohl aktiv vermarkten (und auch supporten). Habe letztens mal nach alternativen DVB-zu-IP Kopfstationen gesucht, da gibt der Markt nicht viel her...
Der USB-Stick-Lösung ist m.E. schwer im Nachteil, zumindest wenn mehr als zwei, drei Streams zu verteilen sind. Erstens haben die normalerweise verwendeten ARM-Hosts ohnehin schon arg an der Bandbreitezu knabbern, denn hier geht der volle Videodtenstrom durch, nicht nur die Metadaten wie beim Netceiver. Zweitens geht so wie ich das verstehe alles über Punkt-zu-Punkt-IP-Verbindungen. Sprich wenn 5 Leute die Tagesschau sehen, wird der gleiche Stream 5 mal verschickt...
Ich habe gestern Abend übrigens noch einen Bug gefunden, der in Verbindung mit einem superschnellen Frontend (wie z.B. softhddevice unter 0.5) zum Deadlock im VDR führen kann. Patch kommt demnächst, muss noch etwas testen.
Grüße
Holger
Habe hier gerade das gleiche Problem - allerdings mit einem ganz normalen VDR mit Frontend (softhd-Device). Der Hänger passiert reproduzierbar beim Kanalwechsel. Zuvor läuft der VDR für 0..30 Minuten komplett unverdächtig.
Leider habe ich im Moment leider auch keine Idee zum Eingrenzen des Fehlers.
Grüße
Holger
Und noch ein winziger Patch für precise...
Zumindest mit vdr-sxfe scheint die Sache zu laufen. Mit softhddevice knirscht es bei mir noch etwas im Getriebe, aber das ist ein anderes Thema.
Grüße
Holger
Im Attachment finden sich zwei Patches für die Reel-Version des mcli-Plugins.
Kurze Howto:
1. Reel-mcli-Plugin auschecken:
co svn co svn://reelbox.org/testing/src/vdr-plugins/src/mcli-12. Patchen
cd mcli-1
patch -p1 < /path/to/combined.patch3. Bauen wie üblich
Der Patch sollte mit allen aktuell existierenden VDR-Versionen außer 1.7.22 auf allen yavdr-Versionen grundsätzlich funktionieren. Getestet ist bislang nur 1.7.27 auf yavdr-0.4. Ein Test mit yavdr-0.5 ist in Arbeit. Die beiden anderen Dateien enthalten die gleichen Aenderungen nochmal als separate Patches.
Grüße
Holger
so, Problem ist gelöst - der Netceiver funktioniert hier dem ersten Vernehmen nach einwandfrei mit 1.7.27. Ursache: cDvbTransponderParameters::System() hat in 1.7.23 ihre Semantik geändert und gibt andere int-Werte zurück. Ein Patch ist in Arbeit.
Zuvor eine strategische Frage an das yavdr-Team: wie oben geschrieben, gibt es zwei aktuellste Versionen des mcli-Plugins. Die letzte von Baycom ist von 2011, danach hat Reel offenbar in Eigenregie weiter daran gebastelt und offenbar ein paar Bugs behoben (bis September 2012). Eine große Reel-Sonderwurst habe ich bislang darin nicht entdeckt.
Welches Schweinderl hätten's denn gern?
Grüße
Holger
PS.: kann man die Nutzung des Patches der Firma Reel irgendwie verbieten? Nach den frechen Kommentaren über "unternehmensfremde Belange" hier hätten sie's verdient...
Zitat
Ich kenne die DVB-Hintergründe aber nicht so gut, dass ich hier genaue Aussagen machen kann. Was bedeutet denn "LOCK"? Ist das ein Feedback vom Tuner zum VDR oder doch eher ein Befehl vom VDR zum Tuner?
Das ist ein Statusflag des Tuners, zeigt meines Wissens, dass das Tunen geklappt hat (siehe netcvdig.c:346)
Zitat
Mich nerven eher die regelmäßigen Rückfragen von meinem Bekannten. Noch ist er vom VDR an sich überzeugt und wollte eigentlich noch mehr VDR-System aufstellen und an den Netceiver hängen. Er hat seinen Netceiver bis auf Anschlag mit Dual-DVB-S2-Tunern aufgerüstet. Dementsprechend ist auch das Argernis über die Probleme groß. Anschaffen einer anderen Lösung wäre ja auch nicht gerade billig. Und den Netceiver wird er auch nicht mehr ohne großen Verlust verkaufen können.
Hier siehts so ähnlich aus - 4 doppelte DVB-S2-Karten in zwei Netceivern. Prinzipell lief alles gut mit yavdr 0.4 - bis zum Tag X, an dem yavdr 0.4 quasi im vollen Galopp auf den 1.7.22 gewechselt ist...
Nach einem Salto Rückwärts zum Backup ist das jetzt der neue Status quo, jegliche apt-gets sind nun verboten. Das ist aber wirklich keine tragfähige Dauerlösung, zumal neue/defekte Systeme auf dem Stand nicht ohne weiteres aufsetzbar sind.
Anschaffen einer anderen Lösung: gibts sowas? Habe noch nichts annähernd vergleichbares gesehen. Die USB-Stick-/Dockstar-Lösung kanns jedenfalls m.E. nicht sein, wenn ein stabiler (!!!) Dauerbetrieb mit mehreren Haushalten das Ziel ist...
Grüße
Holger
Ich bin mir da nicht ganz sicher, ob dieser Versatz hier wirklich die Ursache für das Problem ist. Was, wenn der übliche Workflow ist, dass der Netceiver bei Erhalt des "Lock-Befehls" selber noch auf maximale Feldstärke nachtunt?
Davon gehe ich aus. Je nachdem, ob das klappt, gibt es einen Lock oder nicht (zu weit weg?).
Meine Idee wäre, erst mal ein paar MLD-Pakete des 1.7.21 mit Wireshark zu capturen und einfach ein Replay zu machen. Damit müsste der Netceiver wieder tunen und der hängende 1.7.22 sollte plötzlich ein Bild bringen. Schließlich würde ich die von 1,7.22 und 1.7.21 generierten MLD-Pakete vergleichen und rückwärts nach der Ursache der Differenzen fahnden. Der Aufwand wäre gering und man sucht nicht völlig blind durch zig Changes (es sind eine Menge, wie der Diff zeigt).
Zitat
Grund, warum ich das bisher noch nicht gemacht habe: a) Habe selber keinen Netceiver. Betrifft den VDR eines Kumpels, der gute 30km von mir entfernt wohnt und b) habe ich selber nichtmal HD. Weder im VDR noch im TV. VDR für so einen Test ausleihen fällt flach, da das Ding im Einsatz ist. Halt leider mit grottig alter Software, weil kein Update möglich...
Rein von der Theorie her sollte es aber möglich sein, das Problem "in der Community" zu lösen, da der entscheidende Teil ja (lobenswerterweise) Open Source ist.
Mangels Alternative zum Netceiver wird es wohl im Worst-Case irgendwann darauf hinaus laufen, dass ich bei meinem Kumpel einen Rechner abstelle und mir darauf via SSH einen Remote-Zugriff einrichte...
Das können wir eventuell einfacher angehen. Ich habe zwei Netceiver und werde heute abend durch Umsortieren der Emfpangskarten einen mal vorübergehend aus dem "Produktivbetrieb" nehmen. KVM-Virtualisierer ist ebenfalls vorhanden. Ich werde heute abend mal zwei minimale Konfigurationen in je einer VM aufsetzen (1.7.21 und 1.7.22), Remotezugriff darauf könnte ich mir ohne weiteres vorstellen.
So langsam nervt das mcli-Problem und gehört gelöst 
Grüße
Holger
Habe gestern Abend mal wieder einen Blick auf die Sache geworfen und dabei folgende Erkenntnisse gewonnen:
- die gesamte MLD-Kanalbelegungunslogik sieht recht verbuggt aus, es gibt zig Registrierungen und Deregistrierungen für jede PID pro Sekunde (der alte VDR macht das aber auch schon so, ist also nicht das Problem)
- Reel hat eine aktuellere Version des mcli-Plugins im testing-Repo (einige Bugfixes klingen sinnvoll, Problem ist aber nicht gelöst)
- Reel arbeitet in testing mit 1.7.21, wird also erst beim nächsten Update des VDRs selbst darüber stolpern
- ab VDR 1.7.22 tunt der Netceiver um ein paar MHz daneben, das führt dann folgerichtig zum NO LOCK (je nach Modulation kann es auch zufällig einen Lock geben)
- ein 1.7.21 kann einen verhungerten 1.7.27 auf dem gleichen Kanal wiederbeleben, indem er diesen "richtig" tuned
korrektes Tuning von 3sat HD (1.7.21)
UUID <fe80::208:54ff:fe52:d7f1>:
slot 1.0, type DVB-S2, used: 12
LOCK , frequency 11347000kHz (1597.0MHz), position <19.2E>
strength ffff, snr 789c, ber 0002, unc 0000
NIMCurrent 108
RotorStatus 0, RotorDiff 0.0fehlgeschlagenes Tuning von 3sat HD (1.7.27)
UUID <fe80::208:54ff:fe52:d7f1>:
slot 2.1, type DVB-S2, used: 7
NO LOCK, frequency 11347000kHz (1598.3MHz), position <19.2E>
strength ffff, snr 0000, ber 0000, unc 0000
NIMCurrent 96
RotorStatus 0, RotorDiff 0.0Leider bin ich noch nicht besonders fit im DVB-API, werde mir die Sache in den nächsten Tagen aber mal vornehmen. Insbesondere ist mir noch nicht ganz klar, wie sich die MHz der ZF ( in Klammern) aus den kHz der Transponderfrequenz errechnet und warum gleicher Input zu offensichtlich unterschiedlichem Output führt. Bin für jegliche Tipps dankbar.
Grüße
Holger
Der anliegende Mini-Patch macht das Plugin bei mir wieder kompilierbar und lauffähig. Wenn ich die Release Notes vom vdr 1.7.26 korrekt verstehe, sollte dieser Fix auch inhaltlich in Ordnung sein. Allerdings habe ich kein CAM im Rechner, sodass jemand mit PayTV den Patch mal gegentesten müsste.
Grüße,
Holger
Habe heute nichtsahnend ein dist-upgrade gemacht - ups Bild schwarz. Eine kurze Suche nach dem mcli-Plugin bestätigte den Verdacht - gibts nicht mehr.
Wäre eine solche tiefgreifende Änderung (Features entfernen halte ich für eine solche) nicht eher im Rahmen von einem größeren Versionssprung sinnvoll?
Grüße
Holger
PS: mcli-addon gibts auf den ersten Blick auch nicht mehr.
Ich versuche gerade herauszufinden, woher beispielsweise der Wert der Variablen "var:user" kommt. Alle auf meiner Platte befindlichen .hdf-Dateien enthalten nichts der gleichen. Hat jemand einen Tipp?
Grüße,
Holger
ich kann sogar mit meinem ion2 endlich anthra (wow) flüssig betrachten, ohne das was hängenbleibt ...
das einzige was auffällt ist die laufschrift bei hud/opengl bzw. die dadurch schlechtere bildqualität.
Kann ich nicht bestätigen. Mit dem ION2 läuft das OSD hier nur mit HUD einigermaßen ruckelfrei. Leider führt das zu einem ziemlichen Totalschaden des Bildes - alle senkrechten und sich bewegenden Kanten zittern. Die Laufschrift ist nur die Spitze des Eisbergs. Xine wiederum führt früher oder später reproduzierbar zum Totalausfall mit >50% Framedrops auf HD-Sendern (z.B. ARD HD). Der einzige tolerable (aber nicht einwandfreie) Weg ist momentan xineliboutput ohne HUD aber mit nervigem OSD und gelegentlichen Segfaults / Buffer Overflows (etwa einer in 5h). Über die OSD-Ruckler hinaus läuft der Stream aber einwandfrei.
Grüße,
Holger
Ok, danke für die schnelle Rückmeldung. Das spart vergebliche Experimente. Ist die Sache irgendwo upstream bekannt bzw. in Arbeit?
Grüße,
Holger
Ich habe soeben seit langer Zeit mal wieder HUD mit xineliboutput aktiviert. Das letzte Mal, als ich das probiert hatte, war noch heftiges Tearing die Folge, das passiert jetzt zum Glück nicht mehr. Allerdings ist das Bild immer noch nicht perfekt - offenbar wird trotzdem immer noch mal ein alter Frame zwischendurch angezeigt. Sehr schön sieht man das bei schnellen Kamera-Schwenks - senkrechte Kanten zittern dabei.
Der ultimative Test ist aber N24. Im Non-HUD-Modus ist die Laufschrift perfekt ruhig, sobald aber HUD aktiv ist, ruckelt und springt sie durchs Bild. Ist das bei mir ein lokaler Effekt auf meinem ION2-System (Zotac ID-HD40) oder ein generelles Problem?
Grüße,
Holger
Hallo,
seit etwa einem Jahr habe ich parallel zu meinen ION330-Geräten eine Zotac ZBox im Einsatz, die einen ION2-Chipsatz hat. Bei ansonsten identischer Softwarebasis (yavdr 0.3 und yavdr 0.4 jeweils auf beiden Geärten) kommt es auf dem ION2-Gerät reproduzierbar zu heftigen Rucklern, sobald das OSD erscheint. Je nach Komplexität des OSDs ist das Stocken mehr oder weniger schlimm. Auf dem ION1 ist das Problem nicht feststellbar, selbst wenn man die gleiche Platte in den anderen Rechner hängt. Der Effekt ist unabhängig von den Versionen von xineliboutput und Nvidia-Treiber und tritt wie gesagt seit mindestens einem Jahr auf. Ich habe keine Log-Einträge finden können, die auf ein Problem hinweisen.
Prinzipiell ist das Problem durch Verwendung der HUD-Option behebbar, leider führt das zu anderen nervigen Effekten (unsaubere Laufschriften, zitternde Bildanteile).
Irgend welche Ideen, um das Problem einzukreisen?
Grüße,
Holger
ZitatOriginal von hsteinhaus
Hallo,
ein dist-upgrade auf den Stand von heute hat bei mir auf meinem Problemrechner (nForce 8300) eine spürbare Besserung gebracht, aber das Problem nicht vollständig beseitig - einzelne buffer overflows blieben, allerdings gab es keinen Neustart mehr.
Die Änderung von 9000H beseitigt das Problem jedoch völlig (seit 30 Minuten bislang 0 Overflows, vorher einen pro Minute).
Ich muss leider meine oben gemachten Beobachtungen widerrufen und das Gegenteil behaupten: die Umstellung auf TCP hat keinen Einfluss.
Hintergrund: die Play Buffer Overflow tritt (ausschließlich?) dann auf, wenn nach langer OSD-freier Zeit das erste Mal wieder ein OSD dargestellt werden muss. Dabei kommt es zu katastrophalen Rucklern im Videostream und machmal auch zu dem besagten Overflow. Ohne OSD-Aktivität läuft der Stream stundenlang fehlerfrei vor sich hin...
Das letzte update der der xine-Libs (Stand heute, 02.03.) hat ebenfalls keinen bessernden Einfluss, der Fehler ist aktuell auf einem ION2 (Zotac HD-ID40) gut reporoduzierbar. Das gesamte OSD ist auf diesem Rechner übrigens sehr hakelig und führt zu vielen Stream-Rucklern auf den HD-Sendern. Die exakt gleiche Software (Platte umgebaut) läuft auf dem AMD-nForce 8300 dagegen komplett ruckelfrei.
Grüße,
Holger
Die TT-1600 ist dafür bekannt, falsche Signalstärken mit bestimmten Treiberversionen anzuzeigen. Ansonsten liefen 3 von den Karten bei mir einwandfrei.
Erster Schritt zur Fehlerdiagnose: aufzeichen und die Aufzeichung ansehen. Kommt der "Blipp" immer an der selben Stelle, ist ein Emfpangsproblem/Kartenproblem. Ansonsten ists ein Wiedergabeproblem.
Grüße,
Holger
