RS 1.29 - Aufnahmen unstabil seit letztem Update

[MaM]

Also, ich benutze den RS nun schon seit einigen Jahren, ohne Probleme.

 

Als "Hardware" dient ein OctoNet 2/4 Sat->IP mit 4 Tunern.

 

Der Server, auf dem DVBViewer/RS läuft, dient auch als Fileserver für Homeverzeichnisse / Filme / Musik.

 

Wie gesagt, jahrelang keinen Stress. Ich konnte aufnehmen, die Filme (direkt aus dem Aufnahmeverzeichnis) vom LAN aus schneiden und die konvertierten (Handbrake) Endprodukte wieder zurück auf den Fileserver per LAN kopieren. Hat den RS überhaupt nicht gejuckt, selbst bei 4 oder gar 6 Aufnahmen gleichzeitig.

 

Nun, (wahrscheinlich seit 1.29, aber so genau kann ich es nicht sagen, da das Problem sich erst langsam heimlich hat eingeschlichen) ist die Kiste auf einmal eine Mimose geworden. Dauernd Fehler in den Aufnahmen, immer gleich so 200-300 Fehler innerhalb einer Sekunde. Danach geht stundenlang wieder alles gut.

Ich habe wochenlang rumgesucht, um die sporadisch auftauchenden Fehler einzukreisen, ich hatte selbst schon eine Horde von Krähen in Verdacht, die sich hier rumtummeln und sich auch die Schüssel setzen konnten.

Letztendlich stellte sich als Fehlerursache mal wieder der Mensch knapp 60cm vom Bildschirm entfernt heraus.

Wenn ich Filme wie bisher geschnitten habe, gab es eine kleine Chance, dass laufende Aufnahmen ein Empfangsproblem hatten. Wenn ich die fertigen Filme wieder auf den Server zurückkopiert habe, gab es dabei garantiert hunderte von Fehlern

 

Hmm, das ging doch alles jahrelang, und an den Kisten hatte sich (bis auf die regelmässigen Updates) nichts geändert ? ! ? ! ?

 

Ich hab dann noch tagelang nach Problemem im LAN gesucht, aber, da waren keine. Alle Switches melden keine Übertragungsfehler, der Core Switch hat 4*1Gb zum Server, bis zur Sat->IP Kiste sind es immer noch 2*1Gb gebündelt. Also am Übertragungsweg liegt es nicht...

 

Langsam der Verzweifelung ("Was hast Du getan, pöhser Puhbe???") nahe habe ich DVBViewer/RS auf einen anderen Server verschoben. Dort ist kein Filetransfer und er kann seine Filme auf einer separaten SSD aufnehmen. Trotz ein paar HyperV Gäste hat dieser Server nun wirklich nicht viel zu tun und gähnt so vor sich hin (und mit 8 Cores/4Ghz und 32Gb RAM hat er auch noch eindeutig "Luft nach oben" frei).

Seitdem sind die Aufnahmen besser geworden, allerdings existiert auch hier noch der Fehlerfaktor Mensch. Wenn ich bei laufender Aufnahme irgendetwas mache, und sei es nur per Webinterface einen neuen Timer einrichten, so gibt es einen EMPFANGSFEHLER!

 

Was muss ich noch tun, damit das alles wieder so fluppt, wie früher ???

[MaM]

Update: ich vergaß zu erwähnen: parallele Aufnahmen mit einer Dreambox sind natürlich fehlerfrei.

 

Und, dann fand ich in den Releasenotes noch: "

• Fix: Hardware: Diskontinuitäten mit Digital Devices-Karten bei sich überschneidenden Aufnahmen des selben Senders.

"

Leider ist es bei mir eben genau umgekehrt, vorher keine, nun ganz viele Diskontinuitäten bei Digital-Devices Karten (denn die stecken ja in diesem OctoNet Dingen drin).

[Derrick]

support.zips von allen beteiligten verdächtigen wären sicher erst mal voraussetzung, um sich ein bild zu machen

[MaM]

support.zips von allen beteiligten verdächtigen wären sicher erst mal voraussetzung, um sich ein bild zu machen

Nich schubsen, muß man ja ersma mitbekommen, dasset sowat jippt

 

Also hier dat Suppenort Dingens von dem Server...:

Edited June 1, 2014 by MaM

[Griga]

Kannst du beim DVBViewer Pro 5.3.1, den du auf dem selben PC hast, die Aussetzer auch provozieren, wenn er den Stream direkt vom Server (also nicht via RS) erhält? Für den Versuch müsstest du sein RTSP-Gerät unter Optionen -> Hardware entsprechend umkonfigurieren.

 

Lasse einfach die Wiedergabe im DVBViewer laufen und versuche, ihn durch die von dir beschriebenen Einflüsse zu stören. Ob es Aussetzer gibt, siehst du auf der Eigenschaftsseite des DVBViewer Filters (Discontinuity-Anzeige).

[Derrick]

Dein octopussy wird doch entweder vom einem multiswitch oder einem quad-lnb mit satsignalen versorgt. Vielleicht sind da ja ein oder 2 anschlüsse defekt. Wenn du so ein perfomantes netzwerk hast, könntest du alle 4 gleichzeitig einem stresstest in transedit unterziehen. Dazu dort 4 RTSP devices einrichten und 4 transponder gleichzeitig analysieren lassen. Missing packets sollte bei allen 0 sein.

 

Ich habe es mal als beispiel vorgemacht. Zwar habe ich kein achtarmiges monster sondern nur 2 USB satkarten, aber in transedit habe ich 2 RTSP devices eingerichtet und so 2 transponder vom RS zum analyzer gestreamt

Edited June 7, 2014 by Derrick

[MaM]

Kannst du beim DVBViewer Pro 5.3.1, den du auf dem selben PC hast, die Aussetzer auch provozieren, wenn er den Stream direkt vom Server (also nicht via RS) erhält? Für den Versuch müsstest du sein RTSP-Gerät unter Optionen -> Hardware entsprechend umkonfigurieren.

 

Lasse einfach die Wiedergabe im DVBViewer laufen und versuche, ihn durch die von dir beschriebenen Einflüsse zu stören. Ob es Aussetzer gibt, siehst du auf der Eigenschaftsseite des DVBViewer Filters (Discontinuity-Anzeige).

Also das ist zwar ein netter Vorschlag, aber leider kein praktikabler.

Das ist nun mal ein Server, der steht in der Garage und der hat auch keinen Bildschirm oder so. Der DVBViewer ist nur darauf, damit man den RS installieren kann und die Lizenz eingibt.

Es schaut niemand Fernsehen an dem Dingen, es ist nur für (bislang absolut stabile) Aufnahmen da.

Und, ja, bei den Aufnahmen zeigen die Webseiten dann reichlich Discontinuties an, wenn ich so Daten hin und herschiebe :-(

 

Aber nur auf dem jeweiligen Server. Im Moment hab ich ja den einen nur zum Aufnehmen und lagere die Filme dann auf den anderen zum Abspielen aus. Da kann ich dann schmerzlos Gigabytes hin- und herbewegen, ohne dass eine laufende Aufnahme dadurch behindert wird. Die Kisten hängen natürlich am selben LAN und sogar am selben Switch.

Edited June 1, 2014 by MaM

[MaM]

Dein octopussy wird doch entweder vom einem multiswitch oder einem quad-lnb mit satsignalen versorgt. Vielleicht sind da ja ein oder 2 anschlüsse defekt. Wenn du so ein perfomantes netzwerk hast, könntest du alle 4 gleichzeitig einem stresstest in transedit unterziehen. Dazu dort 4 RTSP devices einrichten und 4 transponder gleichzeitig analysieren lassen. Missing packets sollte bei allen 0 sein.

Bezweifle ich allerdings stark. An dem Switch hängen noch diverse Receiver und den Leuten, die hier dauernd vor der Glotze hängen, wären Störungen bestimmt schon aufgefallen. Aber, ich werd den Octopus trotzdem mal stressen, der hängt mit knapp 1m Kabel direkt am Mast an dem auch der Multiswitch klebt... (glaub ich haber trotzdem nicht, die Störungen sind wild über alle 4 Receiver verteilt, laufen mehrere Aufnahmen parallel, sind auch immer ALLE gleichzeitig gestört).

 

Irgendwo hab ich inzwischen gelesen, dass es irgendwo eine neue Einstellung bei 1.2.9 (bzw 5.3.1) geben soll, um die Netzwerkpuffer für das Device zu konfigurieren. Leider finde ich den Hinweis nicht mehr wieder, da stand was von "standard ist nun 100ms"... (nichts hat meine Kiste mehr frei als CPU Power und RAM :-) also: hoch mitte Puffer!)

 

Update: ich bin wohl zu blöd für den Transedit. Mit dem Teil kann ich nur lokal installierte TV Karten (hab hier noch eine Terratec S7 an meinem Arbeitsplatz) auswählen. Der Octopode is aber ein SAT->IP Server im LAN und Netzwerkgeräte kann man nicht hinzufügen (oder, wo ist der Knopf dafür geblieben ???) Also nix mit Stresstest...

Edited June 1, 2014 by MaM

[Derrick]

 

Update: ich bin wohl zu blöd für den Transedit. Mit dem Teil kann ich nur lokal installierte TV Karten (hab hier noch eine Terratec S7 an meinem Arbeitsplatz) auswählen. Der Octopode is aber ein SAT->IP Server im LAN und Netzwerkgeräte kann man nicht hinzufügen (oder, wo ist der Knopf dafür geblieben ???) Also nix mit Stresstest...

Der knopf ist doch da.. -> settings -> hardware -> add -> RTSP network device

 

Ich habe zur deutlichkeit noch ein 3. device hinzugefügt, das auf einem anderen PC an einen weiteren server sitzt.

Edited June 7, 2014 by Derrick

[MaM]

Der knopf ist doch da.. -> settings -> hardware

 

Ich habe zur deutlichkeit noch ein 3. device hinzugefügt, das auf einem anderen PC an einen weiteren server sitzt.

ööh, von welcher Version reden wir? Ich hab mir eben 3.9.5 runtergeladen und das ist die Hardware Liste LEER (am Server) bzw. zeigt mir meine USB Karte an (Workstation). Keine Möglichkeit ein Netzgerät einzurichten...

 

Deine sieht irgendwie gaaanz anders aus... wohl der geheime Eichkater ?

Edited June 1, 2014 by MaM

[Derrick]

you're living in the past Geh mal weiter runter in die betaabteilung

[MaM]

you're living in the past Geh mal weiter runter in die betaabteilung

Aber, ich bin doch immer der Brave

Beta nur nach Anweisung

 

Ok, nun habbich also ein paar Devices (3 auf meiner WKS, der Server braucht gerade die 4. für ne Aufnahme).

 

Wat nu?

 

(ich bin wohl wirklich zu doof, ich schaffe es nicht, mehr als ein "Analyze" Fenster aufzumachen)

Edited June 1, 2014 by MaM

[MaM]

Also ok, ich hab dann mal mit EINEM Receiver gemessen, das "Ergebnis" war allerdings vorhersehbar.

 

Bild 1: MAN tut NIX am PC -> 0 Fehler

 

 

Bild 2: MAN kopiert einen Film vom LAN auf den PC (und SCHWUPPS gehen die Fehlerzaehler hoch)

 

 

Allerdings wurde die gleichzeitig auf dem Server laufenden Aufnahme NICHT gestört.

 

Also ist immer nur der PC betroffen, auf dem lokal aufgenommen wird. Aber, wie gesagt: FRÜHER GING DAS!!!

 

[MaxB]

hmm, ich habe hier auch mal folgenden Belastungstest des RS 1.29 durchgeführt:

1.) TransEdit analysiert 4 TS mit QAM 256 (~ 200MBit Netzwerklast, 2 Tuner intern im Server, 2 Tuner sind von der O-NET DVB-C)

2.) der Client kopiert sich parallel einen Film aus dem Aufnahmeverzeichnis des RS (~ 60MBit Netzwerklast)

3.) der RS nimmt währenddessen von Das Erste HD die Sendung "Sportschau live - DTM / Rudern / Reiten" auf

4.) der Intel RAID-Controller vom Server prüft gerade das RAID-System auf Fehler

=> keine Diskontinuitäten bei der Aufnahme...

 

Mehr fiel mir für das gepostete Problem gerade nicht ein , ich könnte auch noch schnell ein paar Client-PC's anwerfen und dort zappen, aber das war ja nicht als Voraussetzung erwähnt...

 

Edit/Nachtrag: Screenshot zugefügt

Edited June 1, 2014 by MaxB

[MaM]

Mehr fiel mir für das gepostete Problem gerade nicht ein , ich könnte auch noch schnell ein paar Client-PC's anwerfen und dort zappen, aber das war ja nicht als Voraussetzung erwähnt...

Nee nee, schon gut

Danke für den Test, hilft mir leider erstmal nicht weiter. Wie schon eingangs erwähnt, das ging alles jahrelang gut, und bis auf die Updates hat sich nichts geändert. Aber von heute auf morgen gings dann bei starken LAN Aktivitäten in die Hose. Übrigens, hatte ich nicht so deutlich gesagt, ist aber wichtig: die aufgenommene Datei vom RS auf den Client zu kopieren stört ihn nicht, erst, wenn man die Daten wieder auf den RS zurückschreiben will, bricht er ins Essen. Lesen stresst ihn wohl nicht genug.

 

Ich hab schon alle Switches abgesucht, ob irgendwo aus Versehen "Flow Control" abgeschaltet wurde, nö, natürlich nich...

 

Im Moment (nach Umzug auf den "freien" Server) kann ich ja erstmal damit wieder leben, nachdem man weis, was man NICHT tun soll, kann man es ja vermeiden und somit wieder heile.

 

Ich wollte nur demnächst noch 4 Tuner hinzufügen, und dann sollten beide Server wieder einwandfrei funktionieren.

 

Ich werde mal ein wenig mit den neuen Parametern "Empfangspuffer" und "Reordertimeout" spielen. Hat jemand ne Idee für eine sinnvolle Steigerung (verdoppeln? verzehnfachen?) ?

Irgendwie hatte ich die Hoffnung, dass hier einer sagt: "JAAA, die sind neu bei 1.29/5.3.1, da waren vorher gaaaanz andere Werte hartverdrahtet...", aber springt ja niemand drauf an

[MaxB]

Ich wollte nur demnächst noch 4 Tuner hinzufügen, und dann sollten beide Server wieder einwandfrei funktionieren.

 

Wenn ich bei den 4 Tunern eine "Empfehlung" aussprechen darf: nimm interne DD-Tuner und keine weitere O-NET, die internen Tuner laufen erheblich stabiler... Apropos O-NET, welche Softwareversion hast Du dort im Einsatz?

[MaM]

 

Wenn ich bei den 4 Tunern eine "Empfehlung" aussprechen darf: nimm interne DD-Tuner und keine weitere O-NET, die internen Tuner laufen erheblich stabiler... Apropos O-NET, welche Softwareversion hast Du dort im Einsatz?

Interne Tuner kommen nicht wirklich in Frage, dafür hätte der Server keine Slots frei und ausserdem gibt es demnächst ein paar Sat->IP Klienten, die direkt mit dem O-Net reden wollen. Manche Leute sind halt zu faul, um Strippen zu ziehen :-)

 

O-Net ist Version 1.0.21 vom Januar oder so. Ich drück zwar fast täglich auf "Check Update", aber da kam nie was ausser "no update available.

(und vom Januar bis April ging es ja noch stressfrei, an dem Teil hat sich nix geändert)

Ich war bislang echt stolz auf das Teil, endlich mal jemand, der FlowControl + Qos im LAN beherrscht, das Dingen schneidet sauber die erforderliche Bandbreite raus (bisher jedenfalls, nun wohl nicht mehr so wirklich...)

[MaxB]

"Sat>IP" beherrscht der RS auch und die O-NET soll ja auch nicht weggeworfen werden aber da eh kein Platz in den Servern ist, brauchen wir nicht weiter diskutieren...

Meine bisherigen Tests haben jedenfalls ergeben, dass die O-NET zwar sehr schnell aber eben nicht fehlerfrei ist und meiner Meinung nach auch die Fehlerquelle bei Dir sein könnte! Besonders wenn Du den Traffic über den Switch der O-NET schickst...

Ich beobachte hier auch immer wieder mal Diskontinuitäten beim Tunen der O-Net und bin von der CI-Unterstützung (entschlüsselt max. 1 Service pro CI bzw. pro O-NET, die Rack-Version max. 2 Services bei 2 CIs und natürlich auch 2 ABO-Karten!) auch sehr enttäuscht...

Was an der aktuellen Beta 1.0.25 alles geändert wurde kann ich leider auch nicht sagen, da DD keine Newsletter mehr an die Betatester schickt und auch in einem anderen Forum mit separatem DD-Betatester Bereich nicht mehr antwortet.

In meine(r/n) Konstellation(en) wird jedenfalls vom RS zu 99,9% mit den internen DD-Karten aufgenommen und das CI steckt natürlich auch dort (MTD kann dort 4 Services mit einem CI und einer ABO-Karte) und das läuft wirklich sehr stabil. Die Sat>IP-Tuner stehen hauptsächlich den Zappern (ich habe 3 Kinder...) zur Verfügung oder hier auch mal etwas extremeren Belastungstests.

[MaM]

"Sat>IP" beherrscht der RS auch und die O-NET soll ja auch nicht weggeworfen werden aber da eh kein Platz in den Servern ist, brauchen wir nicht weiter diskutieren...

Na ja, bislang war bei mir eben diese O-NET "rock-solid" und hat absolut KEINE Aussetzer gehabt. Deshalb habe ich inzwischen die ganzen USB Tuner (Terratec S7) ins Regal gepackt, sie waren unzuverlässiger.

Der CI Slot geht inzwischen? Wußte ich nicht, aber, wie man daraus ableiten kann, brauche ich auch gar nicht. Hier gibts kein Pay TV.

 

Für mich viel wichtiger war der versprochene IPV6 Support, denn eigentlich gibts hier kein V4 mehr, nur "Altgeräte" laufen in solchen Dummynetzen.

Aber die aktuelle Version kennt gerade einmal "localhost", das wars dann... :-(

 

Allerdings ist der Support dieser O-NET doch wirklich etwas merkwürdig. Man kann die Updates nur von der Kiste selber aus laden, und wenn die aus irgendeinem Grunde keine Internetverbindung nach draussen hat, dann kommt nur die Standardantwort "kein Update verfügbar". Da kann man sich lange die Zähne dran ausbeissen und greift hinterher irgendwann zum Telnet..

[Derrick]

Also ok, ich hab dann mal mit EINEM Receiver gemessen, das "Ergebnis" war allerdings vorhersehbar.

 

Bild 1: MAN tut NIX am PC -> 0 Fehler

OhneAktivitaet.jpg

 

Bild 2: MAN kopiert einen Film vom LAN auf den PC (und SCHWUPPS gehen die Fehlerzaehler hoch)

MitCopy.jpg

 

Allerdings wurde die gleichzeitig auf dem Server laufenden Aufnahme NICHT gestört.

 

Also ist immer nur der PC betroffen, auf dem lokal aufgenommen wird. Aber, wie gesagt: FRÜHER GING DAS!!!

 

Da muss bei dir einer auf dem schlauch stehen. Ich habe einen vergleichbaren test gemacht. Gleichzeitig einen file vom remote server zum lokalen PC kopiert und einen mux von der satkarte (firedtvs2) auf dem remote server mit dem lokalen analyzer mittels RTSP device gecheckt. 0 disconties. DD habe ich nicht und werde ich vermutlich auch nie anschaffen

[MaM]

Also ok, nochmal alles auf Anfang....

 

Nachdem ich nun dieses Transedit Tool kennengelernt habe, und weis, wie man damit messen kann, alles nochmal auf Anfang.

 

Neuer, unbefleckter Rechner, DVBViewer 5.3.1 installiert (mit Quelle OctoNet), Transedit angeworfen, File Transfer gemacht, TAUSENDE VON FEHLERN (echt, 2666 Fehler innerhalb von 2sekunden, danach keine mehr)

 

DVBViewer 5.2.9 runtergeladen, drüberinstalliert (also Downgrade), Transedit angeworfen, File Transfer gemacht, KEINE FEHLER (zur Sicherheit noch 10 mal wiederholt, KEINE FEHLER!)

 

Also ist mein Posting hier falsch, der Recording Service hat gar nichts damit zu tun, sondern die 5.3.x Version ist bei mir absolut tötlich

 

Ich werd mal gleich den alten Server downgraden und probieren, aber ich bin da recht zuversichtlich.

 

Also, haben die Gurus irgendwelche Ideen, was 5.3 bzgl. LAN, oder DD, oder RTSP oder irgendwo in der Ecke anders macht, als zuvor?

 

Mir kommt es so vor, als wenn der Begin des Filetransfers 100% LAN Kapazität bekommt, der DVBViewer deshalb ausser Tritt kommt, da der Stream nicht mehr pünktlich eintrift. Nach ein paar Sekunden pendelt sich das dann wieder ein, aber der Schock am Anfang trifft ihn hart. Also wohl irgendwas mit Qos oder der Art... oder ne fehlende / falsche Socketoption...

Use the Source Luke! Please!

[Derrick]

 

Neuer, unbefleckter Rechner, DVBViewer 5.3.1 installiert (mit Quelle OctoNet), Transedit angeworfen, File Transfer gemacht, TAUSENDE VON FEHLERN (echt, 2666 Fehler innerhalb von 2sekunden, danach keine mehr)

Mir ist nicht deutlich, was der DVBViewer damit zu hat. Warum läuft der überhaupt bei diesem experiment? Wenn du allerdings gleichzeitig von verschiedenen seiten auf die hardware zugreifst, kommt es zu kollisionen. Vielleicht steh ich hier auf dem schlauch. Erklär's noch mal..

[MaxB]

Mir ist nicht deutlich, was der DVBViewer damit zu hat. Warum läuft der überhaupt bei diesem experiment? Wenn du allerdings gleichzeitig von verschiedenen seiten auf die hardware zugreifst, kommt es zu kollisionen. Vielleicht steh ich hier auf dem schlauch. Erklär's noch mal..

Dem Posting kann ich mich nur anschließen, auf meinem Server ist RS1.29 / DVBViewer Pro 5.3.0 installiert und an dem Client wo der Screenshot her stammt ist DVBViewer Pro 5.3.1 installiert...

[MaM]

Mir ist nicht deutlich, was der DVBViewer damit zu hat. Warum läuft der überhaupt bei diesem experiment? Wenn du allerdings gleichzeitig von verschiedenen seiten auf die hardware zugreifst, kommt es zu kollisionen. Vielleicht steh ich hier auf dem schlauch. Erklär's noch mal..

Offensichtlich kommen doch hier immer die Treiber des DVBViewers zum Einsatz, oder wer/was "spricht" mit dem RTSP Lan Device?

 

"Gleichzeitig von verschiedenen Seiten" passiert hier beim Testen ja gar nicht, ist in der Praxis aber sowohl normal, als auch erwünscht, als auch ist das SAT->IP Protokoll extra dafür entworfen. Das ist nun mal ein Pool von vier Tunern und zu denen können sich gleichzeitig beliebig viele Clients connecten. Die vier ersten kriegen einen vollen Tuner, weitere werden abgewiesen, oder, sofern sie einen schon vorhandenen Stream wünschen, auf eine Multicast Adresse umgeleitet.

 

Aber zum Test im Moment macht man es simpel, es redet immer nur EIN Klient gleichzeitig mit der Kiste und es ist nur EIN Tuner aktiv.

Und selbst im Realbetrieb kollidiert hier nix, Vier Tuner sind da, der DVBViewer belegt maximal 3 davon parallel, der vierte ist frei für so einen Miniclient, der an nem TV in irgendeiner Garage steckt und selten bis gar nicht an ist.

[MaM]

Dem Posting kann ich mich nur anschließen, auf meinem Server ist RS1.29 / DVBViewer Pro 5.3.0 installiert und an dem Client wo der Screenshot her stammt ist DVBViewer Pro 5.3.1 installiert...

Na ja, ich lag mit dem RS eben falsch, aber man kann ja keinen RS installieren, wenn kein DVBViewer auf der Kiste installiert ist (oder ???).

 

Nachdem ich jetzt auf der Testkiste den RS gar nicht erst mitinstalliert habe, der Fehler aber trotzdem da ist, kann es ja nur noch am DVBViewer (bzw. dem RTSP Treiber darin) liegen.

Also, kurzes Downgrade und siehe da: WEG IST DER FEHLER!

 

Was soll sich der arme MAM dabei denken?

 

a] RS ist nicht schuld

b] DVBViewer 5.3 macht irgendwas anders als 5.2.9 und das "anders" ist nicht gut für mich

 

Insofern habe ich aus Unwissenheit den Thread im falschen Forum eröffnet, sorry.

Edited June 1, 2014 by MaM

[Derrick]

Ich gehe doch noch mal zu deinem test aus post #13 zurück. Dort kopierst du einen file und hast gleichzeitig den analyzer von transedit über ein RTSP device aktiviert. Wo ist dort ein DVBViewer involviert? Das virtuelle device bezieht doch seine daten von deinem garagenserver ebenso wie der file transfer.

[MaM]

Ich gehe doch noch mal zu deinem test aus post #13 zurück. Dort kopierst du einen file und hast gleichzeitig den analyzer von transedit über ein RTSP device aktiviert. Wo ist dort ein DVBViewer involviert? Das virtuelle device bezieht doch seine daten von deinem garagenserver ebenso wie der file transfer.

hmm, ich gehe doch mal davon aus, dass transedit die entsprechenden Teile vom DVBViewer mitbenutzt ?

Oder ist das Teil autark?

(bis vorhin kannte ich das gute Stück ja gar nicht).

Arrrrrgh, gerade ausprobiert, das Teil läuft auch ohne installierten DVBViewer.

 

Dann versteh ich langsam gar nix mehr.

Ist trotzdem so, seit dem Downgrade keine Fehler mehr. Versteh einer das, wer will... GRRRR...

 

(verzeih einem armen User, der nicht weis, welcher Teil dieser Software wozu gehört. Ich hatte nur gemerkt, dass der Transedit die Config eines vorhandenen DVBViewers mit einliest und daraus geschlossen, dass auch andere, mir unbekannte, Teile verwendet werden.)

Edited June 1, 2014 by MaM

[Derrick]

Aus schutzgründen ist eine lizensierte DVBViewer-installation für ein funktionierendes transedit erforderlich. Weiter wird der gemeinsame source filter fürs preview benutzt. Ansonsten ist das tool autark. Innerhalb der gemeinsamen installation wacht noch ein mechanismus darüber, dass nur ein familienmitglied auf eine karte gleichzeitig zugreifen kann.

[MaM]

Aus schutzgründen ist eine lizensierte DVBViewer-installation für ein funktionierendes transedit erforderlich. Weiter wird der gemeinsame source filter fürs preview benutzt. Ansonsten ist das tool autark. Innerhalb der gemeinsamen installation wacht noch ein mechanismus darüber, dass nur ein familienmitglied auf eine karte gleichzeitig zugreifen kann.

Aha, danke für die Erleuchtung...

 

Und der Recording Service ist auch autark ?

[Derrick]

Ja auch, obwohl wie du ja schon selbst bemerkt hattest, braucht er etwas hilfe vom DVBViewer z.b. für die senderliste, was imho eine änderung wert wäre

 

Wir verzetteln uns hier allerdings. Ich glaube jetzt übrigens eher an probleme auf deinem client-rechner.

 

Wenn ich bei laufender Aufnahme irgendetwas mache, und sei es nur per Webinterface einen neuen Timer einrichten, so gibt es einen EMPFANGSFEHLER!

Was eine neue version vom DVBViewer/RS damit zu tun haben könnte, weiss ich nicht. Es scheint in der letzten zeit nur schlimmer geworden zu sein, denn regelmässiger patient beim tsdoctor warst du ja auch schon vorher

 

Wichtig sind fehlerfreie aufnahmen und die scheinen dir ja mit dem neuen server zu gelingen

[MaM]

>Wir verzetteln uns hier allerdings. Ich glaube jetzt übrigens eher an probleme auf deinem client-rechner.

Isch habben gar keine Kleient!

Da ist nur ein Server zum Aufnehmen.

 

>Was eine neue version vom DVBViewer/RS damit zu tun haben könnte, weiss ich nicht. Es scheint in der letzten zeit nur schlimmer geworden zu sein, denn regelmässiger patient beim tsdoctor warst du ja >auch schon vorher

Das hat ja wohl nun GAR NICHTS mit dem Problem zu tun. Den Doc nehm ich nur zum Schnibbeln, nicht zum Verstümmeln, ääh "Reparieren" (und natürlich für meine berüchtigten "bunten Untertitel" :D ).

 

>Wichtig sind fehlerfreie aufnahmen und die scheinen dir ja mit dem neuen server zu gelingen

 

Na ja, nach Downgrade gelingen sie auch mit dem alten wieder, aber Du sagst ja, das hätte keine Auswirkungen...

 

Hier mal ne Stunde heute morgen mit zwei Receivern gleichzeitig (hab endlich den "mach mehr Fenster auf" Haken gefunden, den gabs in der alten Version ja auch nicht):

 

 

(na ja, 132 missings beim TTX, aber wer weis, ob die Inselaffen überhaupt TTX Seiten senden? alle anderen Zähler auf 0)

 

[Derrick]

 

Da ist nur ein Server zum Aufnehmen.

..in den vorangegangenen tests ging es um einen client, der von deinem garagenserver gespeist wurde.

 

 

na ja, 132 missings beim TTX, aber wer weis, ob die Inselaffen überhaupt TTX Seiten senden? alle anderen Zähler auf 0

..hat eine völlig andere ursache, die beim playout zu suchen ist. H.264_video_ts_packets kommen um mehrere grössenordnungen häufiger vor und da fehlt nix

[MaM]

..in den vorangegangenen tests ging es um einen client, der von deinem garagenserver gespeist wurde.

Nein nein, ich befürchte, Du hast den ganzen Aufbau nicht verstanden (oder ich hab mich nicht richtig ausgedrückt). Deshalb mal hier ein Bildchen, auf die wesentlichen Komponenten reduziert.

 

 

 

Also mit "Server" und "Client" kommt man leicht durcheinander. Hier ist aber immer dieser OctoNet "Server", alles andere ist Client. Also die Kiste in der Garage empfängt auch nur per LAN (und RS).

Es macht also keinen wesentlichen Unterschied, ob ich den TransEdit Test in der Garage anwerfe, oder auf "WKS", in beiden Fällen werden die Daten immer von OctoNet empfangen.

 

(die Grafik ist vielleicht etwas zu simpel, stell Dir da einfach noch ein paar Häuser mehr und 5 Switche mehr bei vor, effektive ist WKS sogar 3 Ebenen "weiter" entfernt als "Garage", wenn WKS also stabil empfangen kann, muss bei Garage auch alles ok sein, da dort alle Daten durchkommen).

[Griga]

Nein nein, ich befürchte, Du hast den ganzen Aufbau nicht verstanden

 

Ich befürchte, den hat bislang niemand wirklich verstanden. Die über mehrere Posts verteilte Beschreibung ist einfach zu chaotisch.

 

Die Grafik ist schon mal ein guter Anfang, aber es fehlt eine systematische (tabellarische, schrittweise, nummerierte...) Aufzählung der relevanten Sachverhalte. Von wo fließen die Daten über welche Zwischenstationen nach wo? Wo tritt das Problem auf? Wo wurde was downgegradet? Wo bestehen Testmöglichkeiten? Und so weiter...

[MaM]

Ist mein Setup wirklich so exotisch?

 

Das Ganze ist doch nix anderes, als ein Videorecorder für alle User im LAN.

 

* An den Multischalter angeschlossen ist so ein Digital Devices Octopus.net. Das Teil hat vier DVB/S2 Tuner und einen LAN Ausgang.

* in der Garage steht ein Rechner (ich vermeide jetzt mal das Wort "Server"), darauf läuft der Recording Service.

* Die User stellen über das Webinterface ihre Aufnahmewünsche ein.

 

* Nach der Aufnahme kommt der freundliche Admin, schneidet die Filme (an seinem Arbeitsplatz) zusammen (mit dem lieben TSDoc), konvertiert sie mit Handbrake in ein Format, dass im LAN so jeder abspielen kann und speichert die Ergebnisdateien wieder zurück auf die Kiste in der Garage (nur jetzt viel kleiner und handlicher)

 

* Die User greifen auf die konvertierten Filme entweder per SMB, per NFS, per DNLA (Mezzmo) oder (hmm, waren das alle Wege? ich glaub schon) per LAN oder WLAN zu.

(also NIEMAND ausser mir kommt direkt mit den TS Daten der Aufnahme zusammen, die User haben es immer nur mit MKV oder AVI zu tun)

 

------------------------------------

Das Problem:

Seit ein paar Wochen hat der RS Empfangsprobleme "Disconiuties", ich konnte es soweit hinstellen, dass die Probleme auftreten, sobald auf der Maschine zusätzlich größere Datenmengen geschrieben werden.

------------------------------------------

Abhilfe:

Als kurzfristige "Lösung" habe ich deshalb den RS auf eine andere Maschine verschoben, die weniger Stress hat. Dort ist das Problem zwar ebenfalls vorhanden, aber durch die geringeren Benutzeraktivitäten haut es eben nicht so oft negativ durch. Das ist aber nur um Zeit zu gewinnen um in Ruhe suchen zu können.

 

--------------------------------------

Test:

Da ich nicht wirklich gerne am Server rumkonfiguriere (dazu laufen auf der Kiste zu viele wichtige Dinge), hab ich zum Testen eben einen normalen Win7 Rechner genommen, bei dem kann man das Problem genauso darstellen ohne die Leute zu behindern.

--------------------------------------

 

Nun verstanden???

[Derrick]

 

Es macht also keinen wesentlichen Unterschied, ob ich den TransEdit Test in der Garage anwerfe, oder auf "WKS", in beiden Fällen werden die Daten immer von OctoNet empfangen.

Das macht sogar einen grossen unterschied. Dein testzugang war bisher doch immer die workstation (von mir client genannt). Das test-tool transedit ist von einem update nicht betroffen.

 

Wenn du jetzt machst, was @Griga bereits in post #5 vorgeschlagen hat, kommen wir ev. weiter. Allerdings würde ich weiter transedit statt des dvbviewers zur analyse nehmen.

 

In den einstellungen des virtuellen devices von transedit kannst du bei >server IP zwischen RS (garage) und und Octonet wählen. Also 1x über den RS und 1x direkt. Beim RS kannst du die verschiedenen versionen probieren. Weiter kannst du zwischen UDP und TCP wählen.

[MaM]

Hmm, ich habs ja nun gerade oben nochmal neu beschrieben. Ich will ja gar nicht vom RS laden, sondern nur der RS von OctoNet.

Deshalb ist es ziemlich egal, ob Garage oder Workstation vom OctoNet laden,

[MaxB]

Ich habe jetzt mal einen Test mit 4 laufenden Aufnahmen und gleichzeitiger Kopie einer großen Datei auf den RS-PC gemacht => keine Diskontinuitäten.

 

Bitte beachten: Die Datei wird mit ca. 104 Mega Byte/s auf den RS-PC geschrieben, was einer Netzwerklast von ca. 800 MBit entspricht. Die O-NET ist bei mir ebenfalls zum Aufnehmen aktiv, dies sollte zumindest grob Deiner Netzwerkstruktur ähneln...

 

=> Ich vermute ein Performance Problem innerhalb deiner Netzwerk/Server Struktur. Oder die im RS-PC eingebaute Festplatte kommt mit dem Schreiben der Daten einfach nicht hinterher. Mein Datenlaufwerk ist ein Raid 5 mit 4 Festplatten, was ist bei Dir als Datenlaufwerk vorhanden?

 

[MaM]

>Ich habe jetzt mal einen Test mit 4 laufenden Aufnahmen und gleichzeitiger Kopie einer großen Datei auf den RS-PC gemacht => keine Diskontinuitäten.

Danke für die Arbeit, ja, sniff, so war ich bislang auch gewohnt (heul, heul... )

 

>Bitte beachten: Die Datei wird mit ca. 104 Mega Byte/s auf den RS-PC geschrieben, was einer Netzwerklast von ca. 800 MBit entspricht. Die O-NET ist bei mir ebenfalls zum >Aufnehmen aktiv, dies sollte zumindest grob Deiner Netzwerkstruktur ähneln...

Ja, das entspricht sogar genau meiner Struktur, Du kannst die lokalen Karten weglassen und nur vom O-NET aufnehmen, dann ist es 100% identisch.

 

>=> Ich vermute ein Performance Problem innerhalb deiner Netzwerk/Server Struktur. Oder die im RS-PC eingebaute Festplatte kommt mit dem Schreiben der Daten einfach >nicht hinterher. Mein Datenlaufwerk ist ein Raid 5 mit 4 Festplatten, was ist bei Dir als Datenlaufwerk vorhanden?

 

Tscha, das wäre zu simpel, da hätte ich hier keine Frage gestellt.

Im "Originalserver" sind nur vergleichsweise "lahme" 4Tb WD-Black Platten drin, Filme und Musik sind keine "wichtigen" Daten, sowas kommt nicht aufs Array. Aber die Platten schaffen auch lockere 110Mb/s konstant, für ne Videoaufnahmen schon viel zu flott.

Da ich auch sowas vermutetet (zumal die Platten langsam voll werden, da hat der Defragmentierer schon reichlich Arbeit und die Suche nach freien Blöcken dauert merklich länger als bei einer leeren Platte) hatte, hat das derzeitige "Ausweichgerät" nur SSDs, davon eine 120Gb allein für den RS. Die schafft laut meinen Tests konstant 440Mb/s beim Schreiben.

Netzwerk sind jeweils 4*1Gbit/s Realtek Karten in einem PCIe 4x Slot. jeweils 3 sind gebündelt, die vierte ist immer der Managementzugang. Man kommt natürlich trotz Bündel nie über die 110Mb/s, da jede Verbindung immer nur auf ein und demselben Port abläuft. Intern haben die Kisten dann jeweils noch nen 10Gbit/s Pseudoswitch für die VMs.

Aber der RS läuft immer (und als einzige Anwendung ausser HyperV überhaupt) auf der realen Maschine.

 

Nein, leider kann ich Performanceprobleme wohl ausschließen, den Jungs mangelt es weder and Ram, CPU, LAN noch Disk.

 

Also weitersuchen...

[MaM]

Also, ich glaube, ich bin ein Stück weiter (falls es jemanden interessiert).

 

Ich weis zwar immer noch nicht wirklich, wo der Fehler auf einmal herkam, aber zumindest konnte ich ihn nun eingrenzen und durch geeignete Gegenmaßnahmen sogar total eleminieren (man kann nun also wieder lustig Dateien hin- und herschieben, oder andere böse Dinge im LAN machen, ohne, dass auch nur ein Paketchen verloren geht (Finger kreuz, aber nach 3 Stunden Dauer- und Härtetest bin ich guter Hoffnung).

 

Die relativ triviale Lösung hier bestand aus einer Gruppenrichtlinie zu QoS (für die Nicht-LAN-ianer: Quality of Service, also der Bevorzugung von bestimmten Paketen im LAN), die auf alle Windows Rechner wirkt.

a] alle Pakete "normal" Level

b] Pakete von OctoNet mit Priorität 63 (Maximum)

 

Allen Switchen auf dem Weg die Richtlinie auch beigebracht und AUF EINMAL GEHTS WIEDER WIE GESCHMIERT!

 

Auch Filetransfers sind nicht wirklich langsamer geworden, so 100-110Mb/s sind weiterhin drin. Allerdings merkt man deutlich den Unterschied, ohne Richtlinie rast ein Filetransfer immer ungebremst los, füllt das ganze LAN und wird dann langsamer bis die richtige Übertragungsgeschwindigkeit erreicht ist.

Mit Richtlinie ist es andersrum, der Transfer startet deutlich langsamer und kämpft sich langsam ans Maximum hoch.

Dadurch gibt es nicht diesen "Schock", der immer zu Paketverlusten geführt hat.

 

So weit so gut, nur erklärt das nicht, warum das früher ging, auch ohne diese Einstellungen.

"Dammals", als ich den Sat->IP Server angeschafft habe, hatte ich verschiedene Modelle einiger Hersteller durchgetestet, alle hatten irgendwelche Verluste, nur der OctoNET lief total stressfrei.

Deshalb hab ich den dann behalten und die anderen wieder zurückgeschickt.

Ich bin also davon ausgegangen, dass das Teil diese nötigen Einstellungen fest eingebaut hat (deshalb hat es auch einen "managed" Switch, den es aber nur selber managed und den User nicht an die Einstellungen ranlässt), und hab mich nicht mehr drum gekümmert.

 

Komischerweise geht es auf einmal nicht mehr, das letzte Update von dem Teil war aber im Januar... ?!?!?! SEEEHR mystisch.

 

Noch ne Frage an die DVBViewer Gurus hier: ich gehe mal davon aus, dass der RTSP Teil vom DVBViewer/RS/TransEdit NICHT irgendwelche QoS Richtlinien setzt? Oder ???

 

(mal für heute abend/nacht so diverse Aufnahmen programmiert, mal gucken, was rauskommt)

Edited June 2, 2014 by MaM