Probleme mit MVP und vomp-Plugin

Das ist das typische Problem bei billigen Switches und einer Änderung des Netzwerktypes (hier von 1 GBit auf 100 MBit). Eine Möglichkeit wäre den VDR auf 100 MBit zu setzen. Ansonsten Window size im Client varieren.

Andere Möglichkeiten sehe ich nicht.

Marten

Hallo MartenR

Ich habe ein änliches Problem wie TEDDYXXL. Zur Erläuterung:
vdr per r8169 - CAT5 - Surecom EP-808AG 8-port Gigabit Ethernet Mini Switch - CAT5 - Surecom EP-808AG 8-port Gigabit Ethernet Mini Switch - Windows Client per USR 997902A(r8169x)
Wobei jedoch keine Gigabit-Verbindung zwischen den beiden Switches zustande kommt (ca.50m Kabel teiweise mit ungeschirmten Stromkabel parallel - eine neue Verkabelung ist gerade in Arbeit.)
Auch ein temporärer Anschluß des WinClients an den OnBoard 3COM-NIC (Asus A7N8X Deluxe) hat keine Veränderung gebracht.
Die Verbindung hat bei genauer Analyse gezeigt das keine Pakete verloren gehen, deshalb nehme ich an dass, das Netz in Ordnung ist.

Zu deiner Erläuterung im vorangehenden Post: Ich habe per ethtool -s eth0 speed 100 duplex half autoneg off die NIC des vdr gedrosselt und in Windows ebenfalls auf 100Mbit full duplex geschaltet, deshalb sollte der Medientyp nicht mehr geswitcht werden, was auch laut Switchanzeige so ist.

Trotzdem habe ich ein ähnliches Problem wie TEDDYXXL. Bei bandbreitenschwachen Sendern tritt das Problem später auf als bei Bandbreitenintensiven (ARD, ZDF, Premiere...). Zuerst hat der Ton kurze Aussetzer, welche immer mehr zunehmen, bis schließlich auch das Bild zu ruckeln beginnt. Ich habe bereits alternativ MiniDVBLinux0.6 probiert, der selbe Effekt. Ich habe auch bereits versucht die auf der Hauppauge-HP angeführten Reg-Patches anzuwenden. Weiters habe ich die aktuellste DX9cFebruar2007 drauf. Die Vompversion 0.2.5 und 0.2.6 reagiert ident. Auch die Veränderung des TCP-Size hat keine Besserung gebracht. Der verwendete Codec ist der von Ahead Nero 6.0. Könnte eventuell ein falscher Splitter die Ursache sein (Wenn nötig könnte ich auch einige Screenshots des DirectshowFilterManagers0.5 mailen oder posten.), oder wird das vom Vomp for Windows-Client erledigt. Aufgefallen ist mir auch dass die Verzögerung zwischen der Anwahl des Live-Programms und dem Start des Streams unterschiedlich lang ist. Ist das Normal?

Ich bin nun am Ende mit meinem Latein und bitte inständigst um Hilfe.

Danke

dvtosvcd

dvtosvcd
Leider habe ich da keine weitere Idee.
Zu deinen Fragen, der Splitter ist Vomp intern daran kann es nicht liegen.
Das die Sender unterschiedlich schnell starten ist klar, da Vomp eine festgelegte anzahl an Bytes vorher puffert, ist die Bitrate höher starte Vomp damit schneller.

Vorher weist du das keine Pakete verloren gehen?

Es gibt im Code allerdings ein bis zwei Angriffspunkte gegen Ruckeln, die könnten wir mal durch gehen. Dazu brauche aber ein genaueres Bild.
1) Wie lange dauert es bis es ruckelt?
2) Tritt es zuerst in Szenen mit viel Bewegung auf?
3) Was für Computer sind die Beteiligten? Speicher
? CPU, Taktrate? etc.

Marten

MartenR

Danke für die rasche kompetente Antwort.

Erst mal zur Beantwortung deiner Fragen:

>Vorher weist du das keine Pakete verloren gehen?
An dieser Netzwerkstrecke hängen mehrere PC's und Thin-Clients bzw. NAS und ich hatte noch nie Probleme. Diese Schlußfolgerung kann natürlich falsch sein, da das TCP/IP-Protokoll ziemlich stabil läuft. Beim Streamen siehts da schon anders aus (Packet-Resend). Sollt ich etheral mal installieren (obwohl ich es nicht gerne mache da, dass so tief ins System eingreift) oder auf einem weiteren Rechner am Switch mal ?WAS? loggen?

>1) Wie lange dauert es bis es ruckelt?
Ein aktueller Test gerade auf ARD hat die ersten Aussetzer in einem Abstand von ca. 5 Sekunden nach etwa 40 Sekunden gebracht bis schließlich nach 60 Sekunden der Ton nur noch geruckelt hat. Bei Premiere1 hatte ich gerade überhaupt nur einen weißen Bildschirm obwohl es gewaltig Traffic auf dem NIC gibt. Nach dem Schließen des Vompclients läuft der Prozess immer noch und ich muß diesen im Taskmanager killen. Jetzt habe ich auf dem selben Kanal Erfolg gehabt. Das Ruckeln vom Audio beginnt schon nach ca. 30 Sekunden und nimmt ständig zu bis auch das Bild ins Stocken gerät (Die Insel läuft gerade). Aktuell habe ich unter TCP recieve window size 4096 stehen. Auch mit 2048 ist kaum ein Unterschied festzustellen. Bei ZDF hats ab Beginn bei Fußball-UEFA-Pokal geruckelt. Auch das Videobild kommt entsprechend früher zum Stottern. Kabel1 mein neues Leben: das Audiozappeln beginnt erst nach ca. 1 Minute. VOX Groupies forever: Das erste Audioruckeln kam erst nach 1 Minute. Das Video ruckelt erst nach ca. 2 Minuten.

2) Tritt es zuerst in Szenen mit viel Bewegung auf?
Ich konnte noch keinen Zusammenhang zwischen Bewegung und Ruckelwahrscheinlichkeit feststellen.

3) Was für Computer sind die Beteiligten? Speicher? CPU, Taktrate? etc.
vdr= Athlon XP2400(1800MHz@1500MHz) auf einem MSI KT2ComboL mit 128MBype+256MByte SD-RAM mt einer Hauppauge DVB-s 1.3 und einer Technisat Skystar 2.6 (NIC: Conrad-Gigabit=Realtek8169x).
WinClient = Athlon XP2600 auf einem Asus A7n8X Deluxe und 3x256MByte DDR-RAM (NIC: USR 997902=Realtek8169x - auch hier habe ich die Orginaltreiber von USR und die inf-gepachten Realtektreiber ausprobiert - oder 3COM 3C920B-EMB Integrated Fast Ethernet Controller - hätte hier noch die Möglichkeit den zweiten OnBoard-NIC zu testen = nforce2-Chip). Als Netzwerkadapter wird auch noch ein 1394-Firewireanschluß und der DVB-Treiber meiner Technisat Skystar 2 angeführt (Habe hier außer der Skystar 2 noch eine HVR-1100 für DVB-T eingebaut, welche unter Mediaportal 0.2.2.0 einwandfrei funktonieren.)

Was uns eventuell noch weiterhelfen könnte:
Da ich nach den mißglückten Versuchen schon ziemlich frustriert war und noch eine ungenutzte Lizenz von WatchTVpro Phoenix hatte habe ich den Mediaserver mal mit XP SP2 aufgesetzt. Der Einsatz von PES-Server, also einem Streamingserver, und dem dazugehörigen NetworkClient in der jeweiligen Demoversion hat ohne Probleme funktioniert. Auch nach stundenlangem Netzwerkstreaming ist die Verbindung nicht ein mal zusammengebrochen. Trotzdem ist dein Vompclient dem Windowstool um Welten vorraus (Der kann nur die Programme umschalten und hat nicht mal EPG). Der Test hat aber bestätigt dass das Streamen grundsätzlich möglich sein sollte (gleiche Konfiguration des Clients).

Grundsätzlich ruckelt's immer bzw. kommt gar kein Stream zustande wenn ich die vdr-r8169 auf 1Gbit lasse. Deshalb immer 100MBit half duplex fix.

Vielleicht habe ich hier wirklich eine blöde Kombination der Codecs?

Danke für deine Bemühungen und viel Erfolg.

dvtosvcd

Sieht eigentlich alles gut aus. Dann werde ich mal die Parameter durchprobieren. Dazu werde ich dir am Wochenende ein paar Versionen schicken mit geänderten Einstellungen in den Buffern und delays. Schickst du mir ein PN mit deiner EMailaddresse?

Marten

Hallo MartenR

Die PN ist bereits unterwegs.

Danke für die Bemühungen..

dvbtosvcd

MartenR

Ich habe jetzt das Problem in meinem Netzwerk behoben. Ich hatte einen Draht vom TP nicht richtig verbunden. Jetzt steht auch die Verbindung zwischen vdr - switch1 - switch2 - winclient als Gigabitverbindung zur Verfügung. Leider funktioniert das Abspielen vom Livesignal noch immer nicht. Ich habe aber am gleichen Switch testweise einen Athlon64 3500 mit Wndows XP 64bit angeschlossen und siehe da das Streamen vom Livesignal hat funktioniert. Jetzt hab ich meinen AtlonXP2600 komplett neu aufgesetzt. Nachdem das nichts gebracht hat habe ich noch PowerDVD6 aufgespielt - kein Erfolg. Ich glaube jetzt bin ich entgültig mit meinem Latein am Ende.

dvbtosvcd

@dvbtosvcd

Ich habe leider auch keine Ideen mehr. Vielleicht ist der Rechner zu langsam, so dass es intern Timing Probleme gibt, ich habe nur leider gerade keine Idee, wo ich da weiter ansetzen kann. Vielleicht geht die Uhr des Rechners auch zu falsch. (wird z. Zeit nicht synchronisiert)

Eineletzte Idee habe ich noch vielleicht sind die Probleme auch an einer anderen Stelle Testversion ist unterwegs.

Marten

MartenR

Vielen vielen Dank für die Hilfe! Ich habe das Problem nun behoben: Obwohl das Betriebssystem keine Konflikte anzeigte war hier scheinbar ein IRQ-Konflikt vorhanden. Nachdem ich nun den zweiten Onboard-Ethernet-NIC deaktiviert hatte kam es nicht mehr zum Absturz. Danach habe ich noch den Tipp von Muri (sysctl.conf-Ergänzung) angewandt. Mir ist nur aufgefallen das die Prebufferversion 2 bei mir wesentlich stabiler läuft. Jetzt funzts prima. Echt ein tolles Programm. Gratulation. Eventuell gibts auch bei zukünftigen Versionen den vergrößerten Buffer.

Nochmal D A N K E.

dvbtosvcd

Ich habe Chris mal vorschlagen den Wert zu erhöhen bzw. ihn konfigurierbar zu machen. Ab welcher Version das oder ob es überhaupt eingebaut weis daher nicht, mal sehen.

Marten