ggrab: Neue Version (0.20) mit neuen Features!

Beitrag von **boxi** » Mittwoch 8. Januar 2003, 22:59

petgun hat geschrieben:Eigentlich muesste bei mir jetzt Freude aufkommen, da ich weiss, dass ich meine Wette (streamen klappt bis Endes dieses Jahres fehlerfrei)gewonnen habe

hae???? also ich kann nichts von fehlerfreiem streamen erkennen... sowohl bei yadd also flash treten mehr oder weniger oft demuxer overflows auf...

Beitrag von **petgun** » Donnerstag 9. Januar 2003, 01:01

Hi,

boxi hat geschrieben: hae???? also ich kann nichts von fehlerfreiem streamen erkennen... sowohl bei yadd also flash treten mehr oder weniger oft demuxer overflows auf...

wir werden sehen. Woher kommen nach Deiner Meinung die demuxer-overflows (die ich auf meiner seriellen Konsole noch nie angezeigt bekommen habe)? Jetzt bin ich mir 100% sicher, das die _verbleibenden_ Resyncs, von mir aus durch die demuxer overflows, nix mit der CPU-Last/Hardware-Leistung der Box zu tun haben und ausschliesslich auf die fehlerhafte Software zurueckzufuehren sind...und genau das macht mich sicher, das ich meine Wette gewonnen habe!
Und wenn das hier die Jungs bis dahin (mehr als 11 Monate) nicht gefixt kriegen, werden es andere machen. Vieleicht kommt tonsel schon naechste Woche mit seinem Programm raus und dann schau 'mer mal wie's weitergeht.

<Prognose>
Unabhaengig davon, werden Elminster,BSE, Tglynx/Flagg usw. UDP-Unterstuetzung in ihre Programme einbauen....und die Obi_one_man_show macht (vielleicht mit Unterstuetzung von der 'handvoll' Dev's die hier nach seiner Aussage noch dabei sind) den entscheidenden Rest ('Rest' bitte nicht abwertend auslegen)
</Prognose>

cu,
peter

--
Ich hasse diesen Römer namens Status Quo!
[Ray Bradbury: Fahrenheit 451]

Beitrag von **Gandalfx** » Freitag 10. Januar 2003, 08:50

@all
Damit keine Mißverständisse auftreten:
Ich habe nicht mit einer fertigen yadd getestet, sondern mit dem CDK rel_1_0_0 Stand von Mitte Dezember. Es hängt imho *nicht* mit Flash oder nicht Flash, sondern *nur* mit den Treiberversionen zusammen.

Nach einer kleinen Änderung in Streampes ist die Gesamtprozessorlast beim Streamen normal bei ca. 20%. Bei sehr hohen Datenraten gehts *maximal* bis auf 40 %.

Ich habe hier *keine* "dmxdev: buffer overflow". Wenn diese auftritt, bedeutet es, 1MB Daten werden verworfen, also so ca. 1-2 s. Diese hab ich *nur* bei zu hoher Prozessorlast mit Alexw-Image bei hohen Datenraten.

Bei mir passieren Fehler bei Datenraten > 5000 kBit/s im avia_gt_dmx.c (Version 1.139.2.1)

avia_gt_dmx: queue 0 overflow (count: 1)

Bei ARD bei stark schwankender Datenrate war es gestern so 1-2 mal alle 10 Minuten

Dieses bedeutet:
der 64 kByte Video-Puffer im avia-DMA-Bereich läuft über. Hierdurch werden in dieser Version dann immer 64 KB Daten verworfen.

Diese Fehlermeldung tritt im aktuellen Alexw (5.1.) *nicht* auf, da hier die Prüfung auf Überlauf des Puffers nicht drin ist (avia_gt_dmx.c Version 1.134). Wenn dieses Phänomen auch dort auftritt, kommt es zu Datenverfälschungen, da die Ringpufferzeiger die Füße etwas durcheinander haben.

Noch einmal:
bevor alle losrennen: Dieses ist mit DEM Releasestand und MEINER Philips-Box so.

Beitrag von **petgun** » Freitag 10. Januar 2003, 11:18

hi,
danke fuer die Analyse und die ausfuehrliche Erklaerung !!

> Nach einer kleinen Änderung in Streampes ist die Gesamtprozessorlast
> beim Streamen normal bei ca. 20%. Bei sehr hohen Datenraten gehts
> *maximal* bis auf 40 %.

Super! Wo und wie koennen wir an die geaenderte streampes-binary kommen?

>..habe hier *keine* "dmxdev: buffer overflow". ...

ich auch nicht

> der 64 kByte Video-Puffer im avia-DMA-Bereich läuft über. Hierdurch
> werden in dieser Version dann immer 64 KB Daten verworfen
>...da die Ringpufferzeiger die Füße etwas durcheinander haben

Gibt's dann zwangslaeufig einen Resync?
Ich bin zuversichtlich das ihr dass Ihr das auch noch fixen koennt!

Danke,
peter

--
Wir leben alle wie Robinson und warten auf Freitag

Beitrag von **Gandalfx** » Freitag 10. Januar 2003, 22:08

@all
Noch einmal verschiedene Konfiguationen gestestet:

*Mein* Ergebnis (System wie weiter oben beschriebem):

Mit tcp blockiert die Verbindung bei Last für einige Sekunden über ca. 6000 kBit/s trotz niedriger Prozessorlast. Hierbei läuft mir dann regelmäßig der dmxdev buffer über (mit 1MB) Folge: Fetter Resync.

Mit udp läuft das in Peakt bis über 9000 kBit/s Sekunde problemlos. Der Ddmxdev-Buffer ist hier kein Problem.

Unabhängig von udp und auch von der Prozessorlast hab ich bei Last über ca. 5000 kBit/s avia_gt_dmx Buffer Overflow. Diese fast immer auf Sendern mit ordentlich schwankender Datenrate wie ARD. Hier tritt so alle paar Minuten ein overflow auf, der bei den anderen grab-Programmen öfters zu einem Resync führt.

Da ich den Fehler innerhalb angemessener Zeit nicht finden konnte, werde ich auf die neue Treiberschnittstelle warten...

Also:
es bringt zur Zeit nichts, nur jetzt udp ins image zu brutzeln: Die CPU-Last geht zuwenig zurück (gerade im Hochlast-Fall).

Es geht erst vernünftig mit Treiberversion aus dem CDK, mit der ja auch Tonsel getestet hat!

Der avia_gt_dmx wird dann (so hoffe ich) später mit der Treiberschnittstelle beseitigt!

Bis dahin werde ich jetzt keine Optimierung der Optimierung durchführen und an der Stelle noch großes unternehmen.

Gruß
Gandalfx

Beitrag von **DieMade** » Freitag 10. Januar 2003, 22:17

@Gandalfx:

kann ich vollkommen nachvollziehen. Jetzt noch einen Fehler in den alten Treibern zu suchen würde Ressourcen an den falschen Stellen binden.

Also: abwarten und resync's flicken

Beitrag von **dboxP** » Samstag 11. Januar 2003, 01:30

[quote="Gandalfx"]@kleiner
neine, eigentlich brauchst du bei sserver überhaupt keine Parameter. Kandidat für Ärger ist allerdings n lokaler Firewall auf dem Rechner.

Jo, Firewall ist irgendwie ein Problem. Habe einen Router laufen, den ich eigentlich verwenden wollte, den sserver permanent laufen zu lassen.
Im dbox-Setup habe unter Aufnahme die IP des Routers angegeben, Port habe ich auf 4000 gelassen.
Wenn ich nun die FW abschalte (hab 'n skript dafür bekommen, kann leider keine näheren Angaben dazu machen), läuft die Aufnahme.
Bei aktiver FW kommt "error to connect to socket" - obwohl ich unter ALLOW_LOCAL_TCP Port 4000 frei habe???

Muss ich noch mehr freistellen? Auf die FW würde ich nicht gerne verzichten und runterfahren muss nicht sein, weil ich vom Wohnzimmer nicht an den Router rankomme.

Beitrag von **petgun** » Samstag 11. Januar 2003, 11:22

hi,

@GandalfX, Tonsel

> Es geht erst vernünftig mit Treiberversion aus dem CDK,
> mit der ja auch Tonsel getestet hat!

hmm...bedeutet dass, MKdvd funkt auch nur fehlerfrei mit den neuen Treibern, die der 'OttoNormalBoxi' ja nicht hat? Ich war der Meinung das funkt auch so fehlerfrei....waere sonst ja auch ein suboptimales Timing um ein neues Progamm vorzustellen dass erst richtig funktioniert wenn man die neuen Treiber hat...wann werden die fuer uns verfuegbar sein? Bei einem JFFS-only-Image koennte man jetzt schon testen, wenn sich einer von Euch erbarmt und die Treiber zum download anbieten wuerde, oder?

cu,
peter

PS:Die aktuelle YADD vom 8.Januar spielt bei mir bisher noch nicht...frueher gab's mal einen Image-Service, oder?

--
"Das beste Werkzeug ist ein Tand, in eines tumben Toren Hand."
(D. Düsentrieb)

Beitrag von **tonsel** » Samstag 11. Januar 2003, 12:29

Mit den Treibern aus den CVS habe ich getestet, weil ich ohne CVS keine Programme (udpstreampes.cpp) für die DBox übersetzen kann! Darüber hinaus sehe ich speziell unter Linux kein Problem darin eine YADD zu benutzen. Ich habe die notwendigen Programme beim Debug-enablen (Sept. 2001) einmal in die Boot-Scripts meines Linux Rechners installiert und seitdem startet die DBox halt mit Linux wenn der Rechner an ist. Und der Rechner läuft beim Streamen ja eh immer.

tonsel

P.S. bei mir ist im Flash immer noch die BN-Soft

Beitrag von **petgun** » Samstag 11. Januar 2003, 15:12

Hi,

@tonsel

< Mit den Treibern aus den CVS habe ich getestet, weil ich ohne CVS
> keine Programme (udpstreampes.cpp) für die DBox übersetzen kann!

..das war mir soweit klar...Du hast also auch eine YADD am laufen und kopierst Deine Kompilate nach cdkroot auf Deinem Rechner bzw. das CDK macht das automatisch, oder?

>bei mir ist im Flash immer noch die BN-Soft

..Du weisst also noch nicht genau ob Dein Programm genau so fehlerfrei ohne YADD zB auf einer BOX mit einem nicht so aktuellen geflashtem AlexW/cramfs ohne die neuen Treiber laeuft?

@GandalfX

....ich kaempfe immer noch mit der tagesaktuellen YADD von dieser Nacht, in der Annahme dann die neuste Version mit allen Aenderungen (auch Deine geaenderte streampes) zu haben..ist das richtig?

cu,
peter

--
"Es ist keine Schande nichts zu wissen,
wohl aber nichts lernen zu wollen!"

Beitrag von **Gandalfx** » Samstag 11. Januar 2003, 21:08

@petgun
Zur Erklärung, mit der CDK erzeugt man eine komplette yadd.

Mein udp-streampes ist nicht im aktuellen CDK, es ist erst bisher ein Test für mich, und noch nicht für die Allgemeinheit.

Mein streampes mit udp ist in *keiner* offiziellen Version enthalten. Welchen Stand von welchen Treibern Homar in seinen Yadds hat, weiß ich nicht! Da er alles zum Laufen bekommen muß, wird er nicht überall aktuelle Versionen benutzen können. Ist so ein Puzzle-Spiel, ingesamt eine komplett lauffähige Version zu bekommen.

Es ist als Source im CDK beim ggrab, ich kanns auch bis morgen als binary bei mir auf die Webseite setzen. Aber: Diskussionen über die Ergebnisse bzgl. CPU-Last usw. führe ich nur mit denjenigen, die mir genau sagen können, welche Dateiversionen sie von bestimmten Treibern haben...

Beitrag von **ARpheTon** » Samstag 11. Januar 2003, 23:36

dboxP hat geschrieben: Muss ich noch mehr freistellen? Auf die FW würde ich nicht gerne verzichten und runterfahren muss nicht sein, weil ich vom Wohnzimmer
nicht an den Router rankomme.

Wozu brauchst Du denn innerhalb Deines privaten Netzes eine Firewall? Die Firewall sollte doch nur zwischen Deinem Netz und dem Internet "filtern" !?

Beitrag von **dboxP** » Sonntag 12. Januar 2003, 13:46

ARpheTon hat geschrieben:
dboxP hat geschrieben: Muss ich noch mehr freistellen? Auf die FW würde ich nicht gerne verzichten und runterfahren muss nicht sein, weil ich vom Wohnzimmer
nicht an den Router rankomme.
Wozu brauchst Du denn innerhalb Deines privaten Netzes eine Firewall? Die Firewall sollte doch nur zwischen Deinem Netz und dem Internet "filtern" !?

Ich habe eine Version eines kommerziellen Routers. Der ist nun mal für Firmennetze gedacht, in denen Angriffe auf die FW abgewehrt werden sollen - so wurde mir gesagt.
Aber wie gesagt, Port 4000 ist frei. Nur wenn ich die FW abschalte, funktioniert ggrab. Ansonsten kommt "error to connect to socket".
Da die Jungs vom Router ggrab nicht kennen, komme ich auf der Seite nicht weiter.
Ich möchte halt sserver immer laufen haben, damit ich nicht extra eine
Windows-Büchse hochfahren muss.

Beitrag von **dboxP** » Montag 13. Januar 2003, 00:53

Also mein Problem ist z.Zt. gelöst. Ich habe auf der Firewall netzintern alles geöffnet. Für privat ist das noch ok. Aber eigentlich soll die FW auch von drinnen nur erlaubte Ports durchlassen.
Kann mir jemand einen Tipp geben, warum es nicht genügt, die Ports 4000 31338 zu öffnen?

Beitrag von **petgun** » Montag 13. Januar 2003, 11:54

Hi,

Gandalfx hat geschrieben: Zur Erklärung, mit der CDK erzeugt man eine komplette yadd.
Mein udp-streampes ist nicht im aktuellen CDK, es ist erst bisher ein Test für mich, und noch nicht für die Allgemeinheit.

danke fuer die Erklaerungen!

Welchen Stand von welchen Treibern Homar in seinen Yadds hat, weiß ich nicht! Da er alles zum Laufen bekommen muß, wird er nicht überall aktuelle Versionen benutzen können. Ist so ein Puzzle-Spiel, ingesamt eine komplett lauffähige Version zu bekommen.

hmm...ich dachte Ihr DEV's haettet immer den allerneusten Stand.

Aber: Diskussionen über die Ergebnisse bzgl. CPU-Last usw. führe ich nur mit denjenigen, die mir genau sagen können, welche Dateiversionen sie von bestimmten Treibern haben

ok, wenn ich nur wuesste welche Treiberversion ich verwende...??

cu,
peter

--
Gegen Langeweile hilft nur Neugier, gegen Neugier hilft nichts.

Beitrag von **Gandalfx** » Montag 13. Januar 2003, 13:25

@petgun
Hatte mich noch gar nicht Homars yadds beschäftigt. Scheint aber ganz einfach:

Die aktuellen yadd sind, sowie ich das sehe, wirklich Snapshots vom tagesaktuellen Head-Release.

Da kann man in dem Listarchive dann ganz einfach sehen, welches Release von welchem Treiber/Programm da ist.

Das heißt aber z.B. auch, das Streamen zur Zeit nur funktioniert, wenn man nicht gerade die gleiche Sendung sehen will... Halt momentaner Entwicklungsstand....

Beitrag von **petgun** » Montag 13. Januar 2003, 14:25

hi,

Gandalfx hat geschrieben: Die aktuellen yadd sind, sowie ich das sehe, wirklich Snapshots vom tagesaktuellen Head-Release.

und genau die wuerde ich auch gerne testen....bis jetzt hat noch keine der yadd's bei mir funktioniert...heute abend teste ich die von dieser Nacht...
Beeindruckend finde ich, das es alleine in diesem Monat schon 411 Aenderungen gibt....sorry, ich hatte keine Ahnung das ihr so aktiv seid! Vielleicht taete ein wenig Selbstdarstellung von Euch ganz gut...wenn man kein DEV ist, geht das alles am normalen User vorbei....find ich pers. ein wenig schade.
Gut faende ich, wenn's jeweils von dem letzten Release ein jffs-only image geben wuerde und die willigen Testuser die neuen Treiber usw. per ftp in's Image kopieren koennten....oder wuerde dass nicht klappen?

Das heißt aber z.B. auch, das Streamen zur Zeit nur funktioniert, wenn man nicht gerade die gleiche Sendung sehen will... Halt momentaner Entwicklungsstand...

...macht das Sinn playback abzuschalten?

cu,
peter

--

Glaube denen, die die Wahrheit suchen
und zweifle an denen, die sie gefunden haben. [AndrÃ© Gide]

Beitrag von **Gandalfx** » Montag 13. Januar 2003, 15:32

ich gehöre eigentlich nicht zu den Devs, die auf der Box entwickeln. Ich wollte eigentlich nur ne kleine Streaming-Applikation schreiben und taste mich gerade bis auf die Box vor.

Playback abschalten:
Macht so wenig Sinn, aber es ist eine Umstellung auf die offizielle Linux-TV-API erfolgt, die kann im Moment eine Pid nur entweder zum gucken oder zum streamen... http://tuxbox.berlios.de/forum/viewtopic.php?t=16655

jiffs-only Release: gehen schon, aber..........
das Risiko ist, jeder kopiert sich wild alles zusammen, und stellt dann Fragen, warum nix geht.

Und Treiber und Programme in einer solchen Umgebung in ein anderes Image zu kopieren, bringt immer das Risiko, daß es bestenfalls nur nicht läuft. Mein streampes, welches ich auf die Webseite gestellt habe, kann weder in nem 1.5 Basisimage, noch in der neuesten CDK-Head-Version (mir fällt gerade auf, dann auch nicht in Homars yadd) funktionieren, da muß ich ne andere Version rausgeben. Und schon schreibt mir einer erbost, daß der ganze Mist nicht läuft.

Beitrag von **petgun** » Montag 13. Januar 2003, 16:52

hi,

Gandalfx hat geschrieben:Playback abschalten:
Macht so wenig Sinn, aber es ist eine Umstellung auf die offizielle Linux-TV-API erfolgt, die kann im Moment eine Pid nur entweder zum gucken oder zum streamen... http://tuxbox.berlios.de/forum/viewtopic.php?t=16655

..ich versteh zwar nicht viel in dem DEV-Forum, werde da jetzt aber oefters mal reinschauen.

jiffs-only Release: gehen schon, aber..........
das Risiko ist, jeder kopiert sich wild alles zusammen, und stellt dann Fragen, warum nix geht.
Und Treiber und Programme in einer solchen Umgebung in ein anderes Image zu kopieren, bringt immer das Risiko, daß es bestenfalls nur nicht läuft.

ok, versteh ich, waere mir dessen aber absolut bewusst wenn ich an vordester Front teste.....wie waer's mit einem 'Test-Forum'?, wo ihr dann auch die entsprechenden Hinweise und Warnungen geben koenntet?

...Und schon schreibt mir einer erbost, daß der ganze Mist nicht läuft.

in einem Testforum sicher nicht "erbost"

cu,
peter

--
"Ob wir dann im langfrist - - äh - die Dinge wieder verändern, da muß ich
Ihnen ganz offen sagen, - äh - da müssen wir - äh - in Ruhe - äh - die Dinge
in - erörtern und behandeln." [Dr. Edmund Rüdiger Rudi Stoiber]

Beim make tritt folgender fehler auf mit versin 0.21

No Rule to make target 'pesstream.h', needed by 'slist.o'. Stop.

Was kann ich dagegen machen ?????

@kleiner,
sieht so aus, als hättest du die pesstream.h nicht im gleichen Verzeichnis.....

Gandalfx hat geschrieben:@kleiner,
sieht so aus, als hättest du die pesstream.h nicht im gleichen Verzeichnis.....

nicht im gleichen verzeichniss wie welche datei die anderen doch hab einfach alles in ein verzeichniss entpackt

Die Datei pesstream.h ist nicht im gleichen Verzeichnis wie Makefile und die anderen Files

Gandalfx hat geschrieben:Die Datei pesstream.h ist nicht im gleichen Verzeichnis wie Makefile und die anderen Files

ok des mit der psstream.h war mein fehler wollt male auf der fat partotion durchführen da hat die halt den namen psstr~1.h oder so ähnlich. hab dann die files auf die linux partition kopiert aber jetzt bringt er nach eingabe von make folgenden fehler gcc: list.o datei oder verzeichniss nicht gefunden. bei allen anderen *.o dateien ist da auch der fall werden alle aufgelistet. habe dann in der makefile den rm befehl bei clean auskommentiert mit # und es werden bei mir tatsächlich keine*.o Dateien bis zum abbruch erstellt. Hast Du nochmal nen Tipp z.B. wie ich mal versuchen kann die *.o Dateien von hand zu erstellen????

pack mal das Ganze unter Linux noch mal in ein leeres Verzeichnis aus. Dann sollte es gehen...

Tuxbox-Board

ggrab: Neue Version (0.20) mit neuen Features!

error to connect to socket

Problem beim make