Beiträge von Wanninger

Meine ganzen Tests bis Dezember waren allesamt auch mit einem Vanilla VDR 2.3.8 - ohne irgend welches zusätzliches Gedöns, also nur

mit einem gepatchten streamdev (client und server). Ich habe es mit unterschiedlichsten Kombinationen über Wochen hinweg ausprobiert,

und war zu mindestens 99,9% zufrieden.

Beim Thema MLD sieht es leider nicht mehr ganz so spitze aus.

In der X86-64 Variante treten sporadisch mal Probleme auf - also vllt. so 95% - warum auch immer...

Die RPI Varianten sind derzeit leider nicht testbar, da sich scheinbar, in der MLD-5.4 Testing nach der Version vdr-2.3.8.214.42-214.43, irgend

welche Bugs eingeschlichen haben, die jegliches Testen unmöglich machen. Außerdem ist die aktuelle streamdev client/server Variante im

RPI Zweig vorübergehend nicht mehr gepatcht.

Bleiben also nur die MLD -5.4 Testing Varianten für X86-xx Hardware als Testobjekte.

Sicherheitshalber hab ichs vorhin nochmal mit vanillas probiert, und das geht immer noch einwandfrei.

Werd's auch nochmal in Kreuzkombination probieren: MLD-Server-->Vanilla-Client und Vanilla-Server-->MLD-Client

-Wanninger

...thank you very much for that hint.

I changed all RID=1 entries to RID=100, and it seems to work fine.

Haven't realized yet, that your plugin already supports tuner preselection by transmitting the RID.

-Wanninger

Hallo,

in meiner channels.conf sind Kanäle mit RID=1 enthalten.

Mit diesen Kanälen gibt es Tuningprobleme, in Verbindung mit dem vdr-plugin-satip.
Dabei ist es egal, ob ich den DD Octopus Net oder minisatip als Server verwende.
(Mit vtuner/satip gibt es keine Probleme mit RID=1)

Bei Verwendung des DD Octopus Net kommt im Fehlerfall diese Meldung:

Feb 20 18:29:57 (none) user.err vdr: [13523] SATIP-ERROR: Connect failed [device 0]
Feb 20 18:29:57 (none) user.err vdr: [13523] SATIP-ERROR: Detected invalid status code 400: rtsp://192.168.100.131/ [device 0]

Beim minisatip sieht es so aus:

Feb 20 18:29:57 (none) user.err vdr: [13523] SATIP-ERROR: Connect failed [device 0]
Feb 20 18:29:57 (none) user.err vdr: [13523] SATIP-ERROR: Detected invalid status code 404: rtsp://192.168.100.106/ [device 0]

also nur ein kleiner Unterschied im status code.

Kennt das jemand, und/oder gibt es dafür Abhilfe, ausser der, die RID wieder auf 0 zu ändern?

Gruß

-Wanninger

Hallo Zusammen,

in meiner channels.conf verwende ich den RID Parameter, um Mehrfacheinträge von Kanälen in verschiedenen Gruppen nutzen zu können.

Mir ist dabei aufgefallen, dass Kanäle mit RID=1 nicht aktualisiert werden. Gleichlautende Kanäle mit RID=0 werden vom VDR schon aktualisiert. (Parameter .../DVB/Kanäle aktualisieren/"Namen und PIDs")

Ist das richtig so, ein Bug, oder ein Nutzerfehler?

Kann man das irgendwie anpassen/ändern?

Danke und Gruß

-Wanninger

Nachtrag:

Genauer gesagt, wird bei zwei gleichen Kanälen, die sich nur durch die RID unterscheiden, nur der Erste der beiden Kanäle in der channels.conf, aktualisiert.
Der zweite Eintrag bleibt unberührt. Unabhängig vom Wert der jeweiligen RID.

Hallo,

seit einigen Wochen habe ich den Effekt, dass auf einigen Astra Transpondern, im TS-Stream PES Längenangaben enthalten sind,
die sowohl bei direkter Wiedergabe sowie auch bei Wiedergabe von entsprechenden Aufnahmen, starke Artefaktbildung verursachen.

Als Wiedergabeplugin vernde ich in erster Linine immer den xineliboutput/vdr-sxfe. Bei diesem tritt die Artefaktbildung extrem stark auf.
Abgeschwächt tritt es auch beim softhddevice Plugin auf.

Wenn ich ein bereits aufgenommenes Video (mit Artefaktbildung bei der Wiedergabe) mit dem TS-Doctor untersuche, und die PES Angaben
bereinige, dann ist die erneute Wiedergabe sofort einwandfrei.

Kennt das jemand, bzw. gibt es da irgend welche Infos/Abhilfe dazu?

Vielen Dank und Gruß

Wanninger

Danke für den Tip!!!!!

Mein Fehler - zu doof - Sorry für die Belästigung!

Ich habe zum Testen der SatIP Funktionalität, alle nicht benötigten Plugins vorübergehend deaktiviert.
Und da war auch (versehentlich) der streamdev-serer mit dabei, und den habe ich wohl übermerkt...

Jetzt geht's wieder - Danke nochmals

Hallo Zusammen,

ich habe ein Problem mit der aktuellen vdr-plugin-vdrmanager und vdrmanager app Kombination.

Bis jetzt (und das schon seit Jahren) läuft diese Kombi absolut problemlos, solange ich mit der
vdr-plugin-vdrmanager Version auf v0.12 oder max v0.14 vom Dezember oder Anfang Januar bleibe.

Fehlerbeispiel:

Mein aktuelles System ist ein yaVDR 0.6 mit allen Updates (im Testing Zweig).
Testing deshalb, weil ich die aktuellen updates zu minisatip und und dem satip vdr Plugin
mitnehmen möchte.

Die hier verwendete Version des vdr-plugin-vdrmanager scheint mit dem aktuellen Android Plugin (V12.30)
nicht so recht zu wollen.
Ich bekomme immer einen Fehler, wenn ich versuche einen Livestream oder auch eine Aufnahme zu streamen.

Vielleicht hat jemand einen Tip für mich.

Danke und Gruß

Hei FataMorgana,

Ich kämpfe auch schon seit Längerem mit dem gleichen Problem herum.

Den yaVDR 05.64 verwende ich schon seit Jahren, und es gab Anfangs überhaupt keine Probleme mit der Videoausgabe über vdr-sxfe in einer vmware Sitzung.
(Natürlich zu langsam und ruckelig, aber als Kontrollbildschirm, und um evtl. mal schnell einen Film zu schneiden, war es allemal gut genug.)

Dann kam - irgendwann zwischen Ende 2013 und Anfang 2014 - ein Update, und seit dem läuft das vdr-sxfe Frontend nicht mehr.

Zur Kontrolle, einfach vom Original ISO image neu installieren - und ganz wichtig, noch keinen Update machen - und damit läuft das sxfe Frontend noch.
Wenn dann das dist-upgrade gemacht wird, tritt genau der beschriebene Effekt auf.

Möglicherweise läuft es unter der VirtualBox noch, aber unter vmware oder ESXi läuft es definitiv seit dem besagten update nicht mehr.

Was ich noch gesehen habe, ist eine Abprüfung auf Betrieb in der VirtualBox, aber nicht auf Betrieb in der vmware. Möglicherweise hängt es damit zusammen.

Probier's aus, in der vmware ist das ja überhaupt kein Akt, und Du wirst sehen, dass ich Recht habe.

Gruß Günter

Hallo zusammen.

ich habe zu diesem Thema zwar schon einige Threads hier gelesen, aber keines davon trifft meines Erachtens auf mein Problem zu.

Nach einer frischen Installation 0.5a in eine VM im ESXi 5.1 läuft alles wie gewohnt.
Ich stelle dann auf vdr-sxfe frontend ein, Tastatur, Channels usw. läuft alles einwandfrei.
Auch ein Umstellen des Frontends, z.B. auf headless oder softhddevice geht ohne Pobleme.
Das Ganze ist auch reboot fest.

Dann mache ich das empfohlene Update mit apt-get update und dist-upgrade.
Das läuft auch sauber durch, und dann kommt der reboot.

Nach dem Neustart kommt als Erstes schon mal kein Frontend mehr.
Xorg läuft aber, und ich kann auch mit der Maus Programme wie Firefox oder Terminal starten.
Wenn ich dann im WEBIF das Frontend umstellen möchte, bekomme ich, egal wohin, immer
nur eine Fehlermeldung. (Meldung: Fehler beim speichern der Daten)

Danke und Gruß

Wanninger

o.k. ich werde denn mal weiter ermitteln, um so viele Fremdeinflüsse und eigene Probleme wie möglich ausschließen zu können.

Wenn ich wieder Neuigkeiten habe, die nicht direkt oder indirekt mit dem Empfangsequipment zu tun haben könnten, melde ich mich wieder.

Ist es dann besser einen neuen Thread zu starten, oder soll ich hier weiter machen?

DocViper

Das mit dem 522 hängt damit zusammen, weil ich Wohnhaus und Nebengebäude mit einer SAT Anlage versorge, und zwischen
dem letzten Multiswitch im Wohnhaus und dem ersten im Nebengebäude über hundert Meter Kabel liegen. Im Haus verwende
ich dafür die passiven Multiswitche, und im Nebengebäude die Aktiven. Damit kann ich die Pegel im ganzen System etwa auf
gleichem Niveau halten.

-Wanninger

Dieser Thread deshalb, weil er mein Problem, von allen die ich zu diesem Thema bisher gefunden habe, am deutlichsten beschreibt.

Die SAT Anlage möchte ich ausschließen, da ich die beteiligten Komponenten alle schon nach dem Ausschlussverfahren durch getauscht habe.
Und wieso sollte die SAT Anlage das ganze auch noch tageszeitabhängig beeinflussen?

Wie ich auch schrieb ist die S2-3200 am wenigsten empfindlich auf diese SNR Schwankungen.

Mir ist auch nicht klar, wieso es mit der Anlage zu tun haben soll/kann, wenn der Effekt nur mit zwei Tunern/Karten auftritt und mit nur einem nicht.

Bisher aufgefallen auf QVC, HSE24, Anixe

-Wanninger

Im Prinzip ja.

Wenn der Effekt aufgetreten ist, dann bisher immer nur wenn beide Tuner in Betrieb waren.
Auch ist es so, dass die cineS2 "scheinbar empfindlicher" auf SNR Schwankungen reagieren,
als z.B. die beiden S2-3200. Auch bei den S2-3200 konnte ich einen Abfall der SNR bisher
nur auf dem 2. Karte beobachten.
Wobei ich auch sagen muss, dass die S2-3200 deutlich weniger zu Artefaktbildung neigen,
als die cineS2.
Des weiteren ist es auch so, dass nicht alle VDR's zur gleichen Zeit diese Effekte zeigen.

Ich bin schon hergegangen, und habe drei Fernsehbilder zur selben Zeit mit Femon beobachtet,
und konnte dabei feststellen, dass der SNR Einbruch bisher nie (AFAIR) gleichzeitig auf mehreren
Monitoren zu beobachten war.

Es ist auch so, dass z.B. wenn der SNR konstant "schlecht" angezeigt wird dies i.d.R. noch keine
Artefaktbildung bewirkt. Wenn jedoch der SNR sprunghaft von grün nach rot und wieder zurück
wechselt, dann bekomme ich ein paar Sekunden später jede Menge Artefakte, allerdings auch
abhängig davon, wie schnell und häufig dieser Sprung stattfindet.

Was auch noch ein wenig sonderbar ist, ist die Tatsache dass diese Sprünge bisher eher nur spät
Nachmittags bis in die Abendstunden hinein zu beobachten waren/sind. Aber eigentlich nie auf
allen Systemen gleichzeitig. Ab spät Nachts/nach Mitternacht tritt der Effekt eigentlich auch nicht
mehr auf.

--Wanninger

Hei Leute,

dieser fred ist zwar schon über ein Jahr alt, aber bevor ich einen Neuen aufmache, versuche ich mich mal an diesen dran zu hängen.

Ich würde mal sagen dass ich genau das gleiche Problem habe. Nur ist es bei mir irgendwie noch ein wenig seltsamer.
Das Problem lässt sich bei mir an drei VDR's (zwei davon yaVDR05) nachvollziehen.

Einer ist eine ESXi5.0 VMware mit yaVDR05 und cineS2 V5, der Zweite ist ein "normaler" PC mit yaVDR05 und zwei TT-S2-3200 Karten, und der Dritte
ist ein LinuxMintKde13 Rechner mit ebenfalls einer cineS2 Karte drin.

Interessanter Weise habe ich das Problem bei allen drei Systemen immer nur auf dem zweiten Tuner - soll heißen, die Karte, die VDR als 2 erkennt.
Auch bei dem VDR der die TT-S2-3200 Karten drin hat.

Wenn der Fehler auftritt, dann habe ich i.d.R. diese TS continuity errors und/oder bufferoverflows. Der Femon zeigt auf diesem Tuner (der ist dann 1,
weil femon bei 0 beginnt) immer kurz bevor der Fehler sichtbar wird, einen Abfall des SNR Balkens bis auf teilweise 0.
Die Kabel und Karten sind allesamt schon mehrfach zur Sicherheit getauscht worden, um Multiswitch, Kabel und die Karten selbst ausschließen zu können.
Ebenfalls habe ich inzwischen beginnend bei den orig. Kerneltreibern über linux-media-dkms vom August 2012 hin zu den gepatchten experimental Treibern
von Oliver Endriss, alles mögliche an Treibern ausprobiert, ohne dass sich etwas geändert hätte.

Fakt ist, dass auf allen drei Systemen, mit unterschiedlichster HW, der Fehler immer nur auf dem zweiten Tuner auftritt.
Wenn ich über Femon den Tuner auf 0 umschalte, oder über dynamite den zweiten Tuner deaktiviere, läuft HD zu 99,99% astrein durch.
Dieser Effekt tritt bisher nur bei HD auf. Irgendwie kann es ja nicht nur an den Karten liegen.

Ein paar interessante Punkte noch zum Schluss:

Wenn ich nur eine der beiden TT-S2-3200 im PC belasse, dann läuft es auch einwandfrei. Egal welche der Beiden. Ich hab's mit beiden probiert.
Ähnlich ist es bei den cineS2 PC's. Wenn der zweite Tuner über dynamite wieder aktiviert, und der erste Tuner deaktiviert wird, gibt es auch keine
Probleme.

Für meinen künftigen Wohnzimmer Zotac habe ich mir zwei TT-S2-3600 USB Adapter besorgt. Bei Betrieb von nur einem Adapter gibt es keinerlei
Probleme mit HD. Sobald jedoch beide angeschlossen sind, geht die Zickerei genauso wie bei Steckkarten an.

Ich habe es allerdings noch nicht mit mehr als zwei Tunern in einem System probiert. Könnte ich aber mal tun...

Alles etwas seltsam.

Bin für Hinweise jeglicher Art dankbar.

@Soulreaver: Wie sieht es inzwischen bei Dir aus? Immer noch Probleme, oder ist es gelöst?

Gruß Wanninger

Servus horchi,

es ist zwar einige Tage her, aber da ich meiner Meinung nach, genau das gleiche Problem habe,
wollte ich mal nachfragen ob Du inzwischen das Problem lösen konntest.

Bei mir tritt es nur auf, wenn ich von einem entfernten vdr die Bildausgabe mit vdr-sxfe auf meinen
lokalen PC her hole.

Wenn ich es direkt zum lokalen PC verbinde, kann ich kein Problem feststellen.

Viele Grüße

Wanninger

Hei,

ich habs auch mal probiert.

Definitiv läuft die 19829 ohne diesen lästigen Fehler.
Selbst bei mieser LAN/WLAN Verbindung.

Alle neueren die ich bisher getestet habe zeigten den Fehler.

Gruß

Wanninger

henfri

Das mit dem output buffer overflow Problem habe ich auch und bei mir
hängt es augenscheinlich von der Anzahl der vorhandenen Aufnahmen
im /video0 Verzeichnis ab.

Ich habe das Verzeichnis mal geleert, dann langsam wieder gefüllt und
immer wieder probiert was passiert wenn ich den XBMC starte.

Bei einem Wert von mehr als 242 Aufnahmen in /video0 passiert es.

pingpong

Der Start des XBMC und die Bedienung des vdr plugin ist bei dieser
Anzahl von Aufnahmen auch derart langsam, dass es fast nicht mehr
bedienbar ist. Es scheint so als ob das /video0 Verzeichnis immer wieder
aufs neue gescannt wird.

Gruß

-Wanninger