Resyncs mit 1.6er Version

Beitrag von **chris2** » Freitag 11. Oktober 2002, 22:40

Hallo allerseits,

ich weiß, das dieses Thema schon tausend mal in diesem Forum behandelt wurde, deshalb bitte nicht gleich schimpfen, ich wäre für jeden Tip dankbar.

Da ich seit Tagen dieses Forum nach diesem Thema durchstöbere und mir Beiträge durchlese, die schon fast 1 Jahr alt sind, komme ich trotzdem auf keinen grünen Zweig.

Habe schon vieles versucht, wie z.B. das killen von Prozessen, bzw. wie von Dr. Nietsch beschrieben, das killen von sectionsd und neutrino, Dbox auf einer anderen, ebenfalls hochwertigen Antennenanlage probiert, usw... , treten bei mir bei der 1.6er Version bei fast allen Sendern innerhalb einer einer Minute bis zu 30 Resyncs auf (egal welches streaming-prog.)

Habe auch gelesen, das bei älteren Versionen dieses Problem nicht so extrem war (kann ich nicht nachvollziehen, beschäftige mich erst ca. 3 Wochen damit). Möglicherweise ist die Dbox durch zusätzliche Features in den neuen Versionen stärker belastet ???

Ich habe 3 verschiedene 1.6er Images zum Testen auf die Box geflasht, eines davon bringt deutlich weniger Resyncs, trotzdem sehr störend, wenn alle paar Minuten das Bild und der Ton aussetzt.

Habe die Nokia 2xI auf 90er Spiegel mit Spaun-Aktiv-Multiswitch, Signalanzeige bei der Box Vollausschlag, 3com905 Netzwerkkarte extra neu gekauft, wird auf einem XP2200 gestreamt, OS: neu installiertes WinXP Pro

Wie bereits erwähnt, bin ich für jeden zusätzlichen Anhaltspunkt äußerst dankbar.

mfG

chris2

Beitrag von **PeterB** » Samstag 12. Oktober 2002, 03:03

Hallo,

auch wenn ich nun gelyncht werde, aber WinXP halte ich für solche Aufgaben weniger geeignet (meine persönliche Meinung halt).
Guck mal ob wirklich nur TCP/IP für die NIC installiert/aktiviert ist und die NIC keine Autoconnections im Netzwerk während der Aufnahme versucht.

Solltest du ein VIA System haben, aktuelle VIA Treiber installieren, aber ohne Blockmodefunktion und im BIOS die SMART Funktion der HD deaktivieren.

Schraube mal die Pufferung der Daten beim Schreiben auf HD runter.

Nachgucken ob DMA Funktion für die HD gesetzet ist, nennt sich ja nun Schreibcache (wie in W2k)

.

Die NIC sollte einen eigenen IRQ haben.

Beitrag von **chris2** » Samstag 12. Oktober 2002, 06:33

danke für die tips!

welches os verwendest Du?
die IRQ es werd ich abchecken, habs übrigens auch noch mit einem Notebook mit Pentium3 1200Mhz probiert (mit interner Netzwerkkarte, ebenfalls XP), genau gleiches prob.

mfG

chris2

edit: hab jetzt das F1 Qualifying mit Tuxvision gestreamt, das funktioniert besser als ngrab oder wingrab, nach einer Stunde KEIN resync, kurz wingrab probiert, nach 5 Minuten 3 Resyncs. Gibts dafür eine Erklärung?

Beitrag von **PeterB** » Sonntag 13. Oktober 2002, 19:33

Hallo Chris,

verwenden tue ich Win2k SP3, aber der Rechner ist eh nur fürs Capturen/Streamen aufgebaut (intel BX P3-800MHz).

Hmmm ich vermute mal einen Task in XP oder ne Einstellung die im Hintergrund nach einer Zeit einen Überlauf provoziert und somit die Grab.DLL aus den Tritt bringt, sodaß der Datenstrom auch einen Überlauf als Folge initiert und das Grabprogramm eben ReSyncen muß. ReSync bedeutet ja das der Datenstrom abbricht und der Puffer nicht mehr ausreicht und sich somit beide Ströme wieder verschrieben.

Ne Erklärung wäre es (bei TuxVision) - da der Datenstrom eh schon ordentlich gepuffert wird, kann er auch einfacher abgegriffen (gespeichert) werden.

Wäre jetzt meine Erklärung dazu...

die images vom 04. und 07. okt. lassen ein streamen ohne resyncs zu.

mit wingrab elite 0.7i geht es einwandfrei.

resyncs treten bei mir nur auf, wenn der videostream 6500 kbits/s überschreitet. ich habe das z. b. nur bei titel abspännen, wenn kleine weiße schrift überschwarzen hintergrund liegt und durchläuft (rolltitel).

ansonsten geht das streamen 1a mit den obigen images.

...und bei Sportübertragungen in der ARD... Gestern waren's über 7MBit/s, da kommt die Box sofort aus'm Tritt und irgendwann schmiert sogar der Muxer ab (Muxer Panic).

Was mich wundert: Macht man einen FTP-Transfer zur Box, dann kommt man auf unglaubliche 8,5MBit/s, es scheint also evtl. noch etwas Spielraum zur Optimierung des Streamings zu sein (Noname-Karte mit Realtek-100MBit-Chip).

Bei bis zu 6,5MBit/s gibt's bei mir (Philips-Box) auch keinerlei Probleme, außer mit TuxVision, das erzeugt häßliche Artefakte, allerdings auch schon bei wesentlich niedrigeren Datenraten. Und das trotz Athlon XP 1700+/ 512MB.

Beitrag von **chris2** » Montag 14. Oktober 2002, 20:05

also ich vermute mittlerweile das die resyncs auch sehr stark vom Imagefile abhängen.

Habe zum Bsp. ein 1.6er mit Kernel rc1 2.4.19 probiert, da entstehen 2-5 syncs in 2 Stunden.

Mit dem Kernel 2.4.19 final mit gleichem Sender und gleicher Auflösung laufen die syncs extrem durch bis zum Abbruch.

mfG

chris2

ähnliche probleme hier... egal was ich mache (1.5er, 1.6er images, neue cdks, alte cdks, patched cdks, übern 100mbit switch oder per crossover, 2,4ghz cpu oder 1,2ghz, scsi platten oder nicht) ... egal was, ich bring die resyncs nicht weg. datenrate liegt bei ca. 3-4mbit, die signalqualität von der 120cm schüssel ist einwandfrei. mit dem 1.6er image scheints ein wenig besser zu gehen, nur hab ich keine ahnung was ich noch machen könnte, auch verschiedene prozesse killen hilft nix

Hallo,
ich bin auch gerade hier am forschen....
Meine Ergebnisse bisher:
Ngrab und Wingrabz liefern bei mir etwa gleiche Ergebnisse:
bis ca. 5000 kBit/s läufts einigermassen gut mit einigen Resyncs/Std (2-10). Drüber wirds dann merklich schlechter. Interessant ist hier zu beobachten, daß jedesmal wenn über das Netz ein Retransmit gemacht wird, die Programme aus dem Tritt kommen. (Die Retransmits kann man auf der box unter /proc/net/snmp sehen)

Bei Tuxvision habe ich bis ca. 5000 kBit/s keine Resyncs, aber eine Asynchronität von Ton und Bild (bis zu 5 Sekunden).

Ich hab dann mal n kleines Programm geschrieben, was auf der Box kontinuierlich CPU und Netz monitort (Benötigt selber so 5% CPU). Ergebnis hier: Wenn nicht gestreamt wird, läuft die Box mit ca. 90 % Idle Time. Wenn jetzt gestreamt wird, geht die Idle-Time ca. auf 5 % bei 5000 kBit/s. Hier sollte also eigentlich bit 5500 oder 6000 kBit/s kein Problem sein.

Ich habe dann mal das Streamen mit Linux versucht (qbops und grab). Ergebnis hier: bis zu Datenraten von über 5000 kBit/s treten keine Resyncs (und auch keine Retransmits) auf.

Vorläufiges Zwichenergebnis:
Mein Windoof Rechner (XP mit XP1800+ CPU) scheint es (bei 5% CPU-Auslastung) nicht zu schaffen, die Daten rechtzeitig vom TCP-Stack zu holen. Vielleicht Treiberfehler o.ä. Ich werde hier mal versuchen, den Netzwerkkartentreiber auszutauschen und mit der TCP-Window-Size zu spielen.

Ich werde ein bischen weiterforschen aber....
Weis jemand, ob und wo der Sourcecode von streampes auf der Box bzw. von ngrab oder grab zu bekommen ist (Schlagt mich nicht, wenn der doch irgendwo im CVS ist und ich den übersehen hab)?

Gruß
Gandalf

----------------
Philips Box, Rechner XP und Linux, XP1800+

Hallo,

finde ich gut das man nicht alleine gelassen wird, bei diesem Probem

.

Muß aber gestehen, ich habe nur ReSyncs wenn über Kabel mal wieder ein Fehler kommt. Ansonsten keien ReSyncs, auch nicht bei einem Film von DirectKanal (da sind ja auch mal 7MBit und mehr möglich). Wo ich aber einen krasse ReSync Sammelung hatte, war beim Abspann von NoWayOut (Kameraflub über Pentagon und von unten nach oben scrollende, weiße MiniSchrift) Ergebnis Spitzen mit 10MBit - Peng

. Sowas gehört verboten

.

Wie gesagt ich arbeite mit W2k SP3 und mit einer uralten 3COM ISA 10/100MBit (515) NIC. Leider gibt es dafür keine W2k optimierten Treiber.

Bei den anderen vermute ich (besonders WinXP) irgendwelche TCP/IP Stack anfragen, die eben die ganze Sache aus den Tritt bringen (wie GandalfX es schon andeutete).

Genial wäre folgendes : Eine kleine Linux Distrubition welche "nur" fürs Capturen (nebenbei) auf den PC installiert wird. Somit (denke/hoffe ich) wären diese ReSync Probleme endlich Vergangenheit...

Beitrag von **zexma** » Donnerstag 17. Oktober 2002, 13:15

Mal ene dumme Frage:
Wie kommt "ihr" darauf, dass das Problem durch die Netzwerkkarte des (Client)-Rechners verursacht wird?

Für jede 10/100MBit Combi-(PCI)Karte ist ein konstanter Daten-Stream von i.d.R. weit weniger als 800kByte ( ~6400kBit) nen Klacks! Auch die Diskussion 3COM/Realtek etc.pp. ist IMHO sinnfrei. Auch die billigste Grabbeltisch "10/100 Realtek" schafft das problemlos in einem PCI-Rechner mit ener Taktfrequenz >= 200MHz(geschätzt). ISA is natürlich Driss!

IMHO ist der Flaschenhals (Resync-Problem) das Netz-Interface der dBox.
Und eine Prozessorlast von ~95% beim streamen (gemessen mit IMONC mit Router-Image, Routerfunktionalität deaktiv.) lässt nun mal keine Reserven für Lastspitzen.
Von daher ist es auch ziemlich sinnlos nach "..optimierten Treibern für WinXYZ od. LinuxUVW" zu suchen (Ein "fehlerfrei" laufendes Netzwerk vorrausgesetzt). Vorraussetzung ist ein vernüftiges BS (also =! Win9x) für ein(e) stabile(s) Basis/Netzwerk.

also =! Win9x

Also mit Win98 auf nem kleinen Vaio (PII 400) hab' ich schon syncfrei auf ne FireWire Platte (Die interne ist zu klein und zu lahm) gestreamt.

Beitrag von **zexma** » Donnerstag 17. Oktober 2002, 14:08

chkdesign hat geschrieben:
also =! Win9x
Also mit Win98 auf nem kleinen Vaio (PII 400) hab' ich schon syncfrei auf ne FireWire Platte (Die interne ist zu klein und zu lahm) gestreamt.

Ja, glaub eich Dir gerne. Fakt is aber:

zexma hat geschrieben:vernüftiges BS

und da gehört ein Win9x nicht zu

Also darf ich eure Beiträge nun so verstehen : W2k und WinXP sind eh nichts fürs Streamen oder für eine Netzwerkbasis und überhaupt ist nicht der Rechner schuld sondern die "unfähigkeit" der dBox bzw. der Programmierer von dem Projekt TuxBox? Sorry, aber so lesen sich eure Statements. Na dann Mahlzeit und viel Spaß bei den (bestimmt jetzt kommenden) HaufDruffMails

.

Fakt ist aber ist doch einst - bei den einen läuft es nahezu ohne Probleme und bei anderen, die die gleichen Komponeten haben inkl. fast identischer Installation gibt es Probleme. Was aber oftmals gerne dann als "Schwachsinn" abgetan wird. Nur glaube ich auch nicht, daß die Leute mit Probleme zu "Noob" sind, um mit ihren Maschinen umgehen zu können.
Auch glaube ich nicht das die Entwickler von dem Linux dBox System zu "Blauäugig" sind.

Gut vielleicht ist die dBox wirklich nicht das gelbe vom Ei, aber Sorry, warum wird dann so ein HeckMeck drum gemacht. Dann am besten einen Standalone DVD Writer angeschlossen und auch das öde Nachbearbeiten der Streams entfällt (also bei 480x576, AC3 etc.). Ja ja, ich weiß nicht jeder hat die Kohle, aber ähmmm was so manche in ihre Kisten stecken, um eben premiere zu streamen kommt dem manchmal gleich

.

Und Gandalf (wenn es Gandalf der Graue ist), hat schon in anderen Foren bewiesen was in im steckt, besonders bei Problemen.

Was mich noch interessieren würde, wer entscheidet denn hier ob eine Diskussion sinnfrei ist oder nicht? Finde ich etwas überheblich. Denn es hat sich schon mehr als einmal erwiesen, daß RealTek Karten und NICs mit RealTek Chips einige Macken hatten/haben, die ein vernüftiges Arbeiten im Netzwerk nicht ermöglichen - dazu gehören auch die netten "Grabeltischkarten". 3com hingegen machen mit ihren langen Bezeichnungen manchmal Probleme.
Und wenn man ein vernüftiges Mainboard hat, dann kann auch eine alte ISA NIC das Datenvolumen gut/schnell verarbeiten.

Just my 2 cent...

@PeterB
keine fremden Federn -> ich bin nicht Gandalf der Graue

Oki - dann ist meine Aussage diesbezüglich nicht zu gewichten

und da gehört ein Win9x nicht zu

Das liegt wohl mehr am Anwender als an der Software. 95 mag ja sein. Aber 98 läuft bei mir seit Jahren ohne Probleme und _ohne_ neuinstallation. Wenn ich so in Foren lese wie oft Leute ihr tolles XP neu installieren, dann zweifel ich echt. 98 würde ich jedem ME und XP vorziehen, sind doch nur resourcen-fresser.

Aber mal zum Thema. Normalerweise streame ich mit nem Win2000 (auch ein sehr gutes BS

) und einer 3com Karte und habe keine Probleme. Ich bin auch der Meinung, das wenn man so 0-10 syncs im Stream hat es nicht mit dem Clientsystem zu tun hat, sondern die Box Fehler macht. Oder der Stream sowieso nicht ganz ok ist. z.B. gibt es auf 13th Street viel mehr syncs als z.B. auf Premiere1 wo kaum welche auftreten. Da kann man nur vermuten dass dier Encoder bei PW auch unterschiedlich gute Streams machen. Kann auch sein dass mein Nachbar grad seinen Fernseher anschmeißt und dadurch das Kabelsignal kurzfristig nen Schaden aht, oder ein Vogel/Flugzeug über die Satsachüssel fliegt. Dem decoder der Box ist das egal, die schaut einfach über die Fehler drüber und man sieht es nicht. Der muxer von Wingrab ist da wohl etwas empfindlicher.

Beitrag von **zexma** » Donnerstag 17. Oktober 2002, 15:05

PeterB hat geschrieben:Also darf ich eure Beiträge nun so verstehen : W2k und WinXP sind eh nichts fürs Streamen oder für eine Netzwerkbasis und überhaupt ist nicht der Rechner schuld sondern die "unfähigkeit" der dBox bzw. der Programmierer von dem Projekt TuxBox?

Nein! Win9x hat eine ganz andere Architektur als NT/W2k/XP.
Wie der Volksmund schon sagt: "Win9x is enix"

Die Programmierer können wohl nix machen wenn die HW (=const.) am Limit ist.

Fakt ist aber ist doch einst - bei den einen läuft es nahezu ohne Probleme und bei anderen, die die gleichen Komponeten haben inkl. fast identischer Installation gibt es Probleme.

Das ist kein Widerspruch zu oben: es gibt überall Toleranzen. Ausserdem der Anwender-Faktor

(->PEBCAK)

Auch glaube ich nicht das die Entwickler von dem Linux dBox System zu "Blauäugig" sind.

Siehe oben. Bestimmt nicht. Hab eich auch nicht behauptet. Aber welcher Programmierer hat behauptet das es jemals fehlerfrei gehen wird?
Wenn der PPC/Netz-Interface der dBox am Limit dann nützen auch GBit Netzkarten oder GHz-Rechner nicht.

Gut vielleicht ist die dBox wirklich nicht das gelbe vom Ei, aber Sorry, warum wird dann so ein HeckMeck drum gemacht. Dann am besten einen Standalone DVD Writer angeschlossen und auch das öde Nachbearbeiten der Streams entfällt (also bei 480x576, AC3 etc.). Ja ja, ich weiß nicht jeder hat die Kohle, aber ähmmm was so manche in ihre Kisten stecken, um eben premiere zu streamen kommt dem manchmal gleich .

Also ich mache keinen HeckMeck. Ich habe eine alten Rechner (AMDK6-3/450,256MB, mit insg.200GB HDS) als Server mit W2k Adv.-Server. Da dieser sowieso immer läuft, macht der das streamen "nebenbei". Trotz allem ist das streamen "nur" ein angenehmes AbfallProdukt des Linux@dBox Projektes.

Was mich noch interessieren würde, wer entscheidet denn hier ob eine Diskussion sinnfrei ist oder nicht? Finde ich etwas überheblich. Denn es hat sich schon mehr als einmal erwiesen, daß RealTek Karten und NICs mit RealTek Chips einige Macken hatten/haben, die ein vernüftiges Arbeiten im Netzwerk nicht ermöglichen - dazu gehören auch die netten "Grabeltischkarten". 3com hingegen machen mit ihren langen Bezeichnungen manchmal Probleme.

Bitte richtig lesen:
--> war alles "IMHO" ("In My Humble Opinion" was soviel heisst wie: "Meiner bescheidenen Meinung nach"). Sind halt Erfahrungswerte.

Und wenn man ein vernüftiges Mainboard hat, dann kann auch eine alte ISA NIC das Datenvolumen gut/schnell verarbeiten.

Hat mit dem Mainboard weniger zu tun. ISA-Karten bremsen ein halbwegs aktuelles System gnandenlos aus (CPU Last, Interrupts etc.). Und das is efürs streamen nunmal denkbar ungeeignet. GHz-Rechner sind hier aber totaler overkill.

bei mir haben die resyncs ganz klar mit der datenrate des films zu tun.

liegt sie unter 5000, so habe ich keinen einzigen resync.

geht sie über 6500 raus, kommen für den zeitraum resyncs. die datenrate haut z. b. bei weißer kleiner rollschrift auf schwarzem hintergund voll nach oben. oder bei ZDF, wenn die 16:9 senden.

premiere sendet die filme auch verschieden. am 15.10. konnte man moulin rouge als mp2 datei mit 4150 GByte um 20:30 und als wiederholung danach mit 4050 GByte streamen. habe mich über den untschied schon gewundert, immerhin 100 MByte.

am 16:10 war es noch krasser, mitten in der nacht habe ich moulin rouge mit 4500 GByte gestreamt. dieses mal waren es auch sehr viel mehr resyncs, so 12 stück an 2-3 stellen in der mitte des films.

an den gleichen stellen waren es am tag vorher nur 6 resyncs. immer da, wo die datenrate nach oben haut.

der film hat also 500 MB mehr am 16.10. als am 15.10.

das zeigt doch deutlich, daß premiere "lastabhängig" komprimiert, je nach dem, was sonst noch so gesendet wird. gibts es viel sport und formel 1 nebenbei, geht die rate überall anders eben etwas runter.

premiere sendet also nach meiner meinung über "live on the fly" encoder und nicht einen vorher schön optimierten MPEG stream.

wirklich schade, daß die dbox 2 kein 100 MBit ethernet hat, das wäre es.

auf der anderen seite könnte man ein wenig noch rauskitzeln, wenn die prozessorlast das problem ist.

man könnte ja ein reines stream image bauen, ohne zusätzlichen balast und wo alle prozesse aufs notwendigste begrenzt werden.

ich weiß nicht, ob die DEVs da bock zu haben, aber ich würde es echt gut finden.

Beitrag von **zexma** » Donnerstag 17. Oktober 2002, 16:27

Frankieboy hat geschrieben:am 15.10. konnte man moulin rouge als mp2 datei mit 4150 GByte um 20:30 und als wiederholung danach mit 4050 GByte streamen.
...
am 16:10 war es noch krasser, mitten in der nacht habe ich moulin rouge mit 4500 GByte gestreamt. dieses mal waren es auch sehr viel mehr resyncs, so 12 stück an 2-3 stellen in der mitte des films.

Schon interessant: Du hast also auf Premiere Direct mind. 3x "moulin rouge" geordert?!

Entweder Du hast zuviel Geld oder.....

Trotz allem ist das streamen "nur" ein angenehmes AbfallProdukt des Linux@dBox Projektes.

schmuh.fuer mich der hauptgrund fuer linux.als wenig gucker und klassiker streamer ganz wichtig.tja, haett ich auch nen emu drauf koennt ich mir auch die taegliche droehnung direct geben...

nomad

also ich glaub nicht, dass die probs beim streamen was mit der qualität des windows tcp/ip stacks zu tun haben, bzw. mit der geschwindigkeit mit der windows die daten verarbeitet

1. wenn ich meinen rechner unter linux boote und dort versuche zu streamen, krieg ich ähnliche ergebnisse (resyncs en masse)
2. 4000kbit/s sollten nicht gerade eine herausforderung für ein relativ neues system sein, ganz egal ob nun der write cache der hdd ein oder aus ist.
da gibt es nur eine sache, die mich irritiert: wenn es die dbox schafft, einen film einfach _perfekt_ auf den tv zu bringen, dann sollte also rein vom antennensignal kein problem vorliegen -> von daher: kein problem
selbst wenn die datenrate hochgeht (bis jetzt maximal 5000kbit/s bei mir), sollte das ein 10mbit ethernet interface noch immer schaffen.
wieso also produzieren die muxer am pc dann resyncs frage ich mich? kann es echt sein, dass die "zu empfindlich" sind wie einer das schon vermutet hat?
würde mich echt brennend interessieren, eher weniger aus dem interesse heraus streamen zu können, sondern aus technischer sicht. ich hab meine probleme damit, was zu akzeptieren, was logisch gesehen einwandfrei bei so gut wie jedem funzen sollte

jep, auch wenns am tv gut aussieht, muss der stream nicht intakt sein.der eingebaute mpgdecoder hat wohl eine hoehere toleranz als z.b. wingrab.

so wie ich das sehe liegt es einfach am bescheidenen Netzwerkinterface der Box, 10 MBit halb-duplex taugt halt nichts. Selbst mit einem Profi-100 MBit-Switch dazwischen sind ständig Collisions auf der Leitung zur Box, während der Switch ja ohne Probleme einige MB puffern kann (und muß um sie mit 100 MBit zum PC zu bringen). Selbst für die letzte Gurke von PC ist das bisschen Traffic kein Problem, aber für jedes empfangene Datenpaket schickt der PC ein Acknowledge zur Box zurück - wenn diese dann gerade ein neues schickt gibt es eine Kollision, dann eine Pause und den Retransmit. Dementsprechend wird's ab ca. 5 MBit schwierig und es hagelt resyncs beim streamen.

Ich habe an meiner Box mal LEDs an den Ethernet-Chip (MB86961) gelötet, wie erwartet hagelt es schon bei nierigen Datenraten Collisions.

Beitrag von **chres** » Samstag 19. Oktober 2002, 11:43

Leuchten deine Dioden denn auch, wenn du, wie z.B. schon weiter oben angemerkt wurde, per FTP auf die Box zugreifst und dabei erstaunliche Übertragungsraten erzielt werden (bei mir ca. 950KByte/s von und zur Box). Das ist mal wesentlich mehr als 5MBit/s und trotzdem geht's. Und FTP-Übertragungen laufen genauso über UDP und TCP Pakete, die auch bestätigt werden wollen.

chres