FritzBox 6490 DVB-IP Problem - Jetzt wirds angegangen

[Flole]

Macht es mehr Sinn diesen Timeslot zu verkleinern oder die Anzahl der zu sendenden Pakete zu erhöhen? Kommt beides ja irgendwie aufs gleiche raus, oder sehe ich das falsch? Eventuell passiert vieles auch gar nicht im cableinfo selbst, libavmcsock wäre vielleicht auch mal nen blick Wert. Ich bin zumindest schonmal den Teil des Verbindungsaufbaus durchgegangen und hab die variablen mal versucht vernünftig zu bezeichnen um den überblick zu behalten.

 

[fesc]

Die laenge des timeslots is denke ich fix.
Ich hatte nur gehofft dass man es schafft durch Verringerung des paketintervalls, und damit die max. Laenge des 20-pakete bursts, mehr bursts in einen timeslot bekommt.

Edit:
Die laenge des timeslots is ja vorgegeben wann neue Daten im Speicher liegen. Die werden ja immer in ~30K haeppchen ge"mmap"ed() und dann als (maximal) 20 pakete a 1.3 K verschickt.

 

[Flole]

Wenn man die binary editiert ist nix mehr fix, da kann man ändern was man will. Der Timeslot kann größer und kleiner gemacht werden wie man lustig ist. Es wird warscheinlich einmal eine 20 Paket beschränkung geben und einmal dieses inter-packet-delay. Also ist die Konsequenz das beides verändert werden muss, einmal das delay zwischen den paketen und einmal die maximale anzahl der Pakete. Ich vermute das ist noch ein überbleibsel von dem DVB-C Wlan repeater, der kann ja nur 2 Sender und um da zu verhindern das der das Netzwerk flutet wird warscheinlich sowas da eingebaut worden sein.

Auch Edit: Das heißt dann ja aber, das eine Änderung überhaupt keinen Sinn macht weil gar nichts neues im Speicher liegt, oder? Also werden die 4 HD Streams nicht schnell genug in den Speicher geschrieben? Der Speicher hat doch eine bestimmte größe und eigentlich sollten die 20x1.3K doch dafür sorgen das der gesammte Speicher versendet wird, oder? Also wo liegt da genau das Problem? Scheinbar ja nicht der cableinfo sondern der "Befüller" des speichers ist nicht schnell genug. Oder sehe ich das jetzt völlig falsch?

 

[fesc]

Klar, man muss es nur finden .. ich habe schon eine halbe nacht binary gepatcht und dachte jedesmal "jetzt hab ichs".
Z.B. stehen in den Datenstrukturen fuer timercb_add (der 5. parameter ist ein pointer der an die callback funktion uebergeben wird) Konstanten (5000) die eine zeit (0,5ms .. ?) darstellen koennten.
Parameter 3 und 4 sehen auch nach Zeitinformationen aus (mann muss ltrace aendern dass es 5 parameter ausgibt ..).
Hat aber alles nix veraendert (ausser das es bei krass anderen Werten scheppert).

Beiträge zusammengefügt - HabNeFritzbox

Nein. Bei 2 streams wird halt 2 mal mmap gemacht, und die dann max. 40 pakete innerhalb des timestots verschickt. Bei 4 streams waeren es dann wohl 4 bursts, habe ich aber nicht getestet.

 

[Flole]

Achso, ja macht Sinn. Aber so ganz hab ich immer noch nicht verstanden wo du das Problem vermutest: Wird nicht schnell genug ge"mmap"ped, werden nicht alle Daten ausgelesen oder geschieht das senden einfach nur zu langsam?

Edit: Und den Wert den du mal mit dem Debugger auf 1 gehalten hast ist nur für das inter-packet-delay, oder? Also den zu ändern wird warscheinlich nicht wirklich helfen, da die 20 pakete dann zwar schneller versendet werden, am ende dann aber gewartet wird bis der timeslot abgelaufen ist. Oder wird der timeslot durch die anzahl der pakete multipliziert mit dem inter-packet-delay festgelegt? Also hat sich da was dran geändert als du mit dem Debugger aktiv warst, oder gab das ne Flut mit anschließender Ebbe an Paketen?

Edit2: Was hälst du denn von sub_80507F5(int a1) als busy wait loop? Der fragt ruft time(0) ab, prüft ob time(0) kleiner ist als dword_8071304 + a1 und durchläuft dann sub_80507D6() was mir nach einem busy wait aussieht. Kann aber auch falsch sein, und time() wird noch häufiger im code verwendet.

 

[Flole]

In dem kodinerds Forum gibt es auch mehrere betroffene. Ich habe dort einmal auf diesen Thread hingewiesen, und auch dort noch einmal gesagt das sich alle betroffenen unbedingt bei AVM melden sollten. Die gehen leider immer noch von einem Einzelfall aus.

Ich hab mir heute mal das Projekt minisatip angeschaut und werde nun einmal das nötige Wissen sammeln um eventuell das Projekt auf die 6490 anzupassen.

An dieser Stelle schon einmal eine Frage an PeterPawn: Wie kann man die ganzen Downstream-Kanäle am einfachsten freigeben? Momentan laufen bei mir diverse Downstream-Manager Prozesse (/usr/sbin/downstream_manager) sowie diverses anderes Docsis-zuständige Zeug auf dem ARM. Wenn ich nun auf mehr als 4 Transponder aufrüsten möchte, müsste ich die ja warscheinlich freigeben sodass ich die Tuner ebenfalls nutzen kann. Eine "halbierung" auf 12 Prozesse würde mir auch erstmal reichen, 16 Tuner sind ja auch mehr als genug. Wenn ich das richtig weiß hattest du irgendwo mal erwähnt das sowas möglich ist, nicht aber wie. Ist das eine Konfigurstionsdatei, oder ist das irgendwo in einer binary statisch eingestellt? Es gab glaub ich aber mal Provider-Boxen die diese 4 extra-Kanäle genutzt haben, kann aber auch sein das ich da was falsch verstanden habe.

 

[PeterPawn]

Wenn ich das richtig weiß hattest du irgendwo mal erwähnt das sowas möglich ist, nicht aber wie.

Ich wüßte meinerseits nicht, wo ich das geschrieben habe (bei der 6490 halte ich mich generell zurück, aber gerade hier bezweifle ich ja - siehe weiter vorne - generell, daß man dem Demuxer so einfach zusätzliche Tuner unterjubeln kann ... das müßte mir erst mal jemand zeigen; in der Praxis oder im Source-Code) ... außer das war mal ganz, ganz am Anfang, als es um Überlegungen bzw. die Frage ging, ob man aus einem Tuner der 6360 (also beim Puma5) auch den "raw content" eines kompletten TS (also eines "channels") irgendwie abgreifen und selbst demultiplexen könnte. Da hatte AVM dann auch mal etwas in der Richtung als "Experiment" auf irgendeiner Messe gezeigt - daraus wurde dann die 6490 und (vermutlich als Spinoff) der DVB-C-Repeater.

Ich weiß also nicht, wie man auf dem ARM-Core dem "docsis_manager" einen Tuner vorenthalten könnte - ich würde hier auch vor irgendwelchen Versuchen erst einmal klären, ob man dem Demuxer überhaupt mehr als vier Streams "ans Herz legen" kann (m.E. geschieht das in "tsi_map" in der "/etc/platform_config/ce2600.hcfg").

Wenn die Tuner gar nicht direkt in den Speicher schreiben können (was ich für sehr wahrscheinlich halte, weil die Speicherbandbreite durchaus begrenzt ist und auch die "Daten-Tuner" wohl eher direkt die Pakete für das CM anhand der MAC bereits ausfiltern werden, bevor sie irgendwo im Speicher für die AES-Entschlüsselung landen), dann bringt es ja auch nichts, wenn man "freie Tuner" hat, aber der Demodulatir/Demuxer gar nicht hinterherkommt, die Daten von mehr als vier TS in den Speicher zu schreiben - wenn er das überhaupt für vier TS schafft, denn die beobachteten Dropouts schon bei zwei HD-Streams sprechen da ja eigentlich dagegen.

Ich glaube auch nicht, daß es tatsächlich "wahlfreie Verbindungen" zwischen jedem Tuner und dem (TV-)Demuxer gibt ... ein Daten-Tuner muß ja nicht direkt nach PIDs im TS filtern können, daher gehe ich davon aus, daß der Demuxer für die TV-Programme schon "speziell" ist. Wenn das tatsächlich ein FPGA sein sollte, könnte allerdings dessen Firmware (irgendetwas wird ja in "/etc/platform_config/ce2600.hcfg" als Firmware in den Demuxer geladen) solche Beschränkungen vorgeben (oder auch nicht) ... ich glaube aber auch nicht, daß man dort dann irgendwie (sinnvoll) eingreifen kann.

 

[Flole]

Wenn ich mich richtig erinnere war das sogar eine Frage von mir wo es darum ging den Modemteil der FritzBox komplett abzuschalten. Ist auf jeden Fall schon etwas länger her.

Das der Demuxer/Demodulator es nicht schafft die Daten schnell genug zu speichern ist warscheinlich weniger das Problem, ich würde denke der anscheinend schlecht implementierte cableinfo ist da eher das Problem. Den hat jemand für SD Sender eingestellt (20 Pakete), das ganze dann mit einem HD Sender getestet und raus ging das da keine Probleme aufgefallen sind. Mit 4 SD Sendern gabs auch keine Probleme, also ab damit zu den Kunden. Irgendwie so wird das warscheinlich abgelaufen sein, 4 HD Sender hat warscheinlich niemand explizit getestet. Der Support behauptet das die das Problem nicht reproduzieren können, das scheint angesichts unserer Erkenntnisse ja ein Ding der Unmöglichkeit zu sein. Wenn die nicht irgendein Debug Build zum testeten genutzt haben wo eventuell der Code nicht durch einen Preprocessor oder durch den Compiler selbst "optimiert" wurde, muss dort ja zwangsläufig das selbe Problem auftreten.

Selbstverständlich muss ich beim minisatip Projekt erstmal einen Stream ans laufen kriegen, dann 4 und dann kann man mal schauen. Dennoch ist hier eine Fritzbox ein reiner TV Tuner, da kann ich also theoretisch einfach den ganzen Modem Teil abschalten, dann hängt das Ding auch nicht unprovisioniert im Netz rum.

 

[PeterPawn]

Der Modemteil der Box ist leicht "abgeschaltet" - da gibt es (auch in anderen Puma6-Modellen) ja die passenden Skript-Dateien von Intel ... wenn die nicht im "production mode" sind, wird auch das CM praktisch nicht gestartet, wobei das nicht damit zu verwechseln ist, daß auf dem ARM-Core dann gar nichts liefe.

Irgendjemanden hier hatte ich bei der 6360 mal ziemlich detailliert an diese Stelle herangeführt (aus dem Gedächtnis) - das ist bei der 6490 aber absolut analog (genauso wie bei anderen Geräten, z.B. eben dem Hitron 30360), denn das ist alles mehr oder weniger derselbe Code von Intel, der von AVM auch nur etwas anders gestartet wurde (und wird).

 

[fesc]

Das aufsetzen und handling der dvb "streams" wird in libbdvbif.so gemacht.
Cableinfo ruft periodisch di_recvpid_stream() auf. Dort werden die daten ge-mmap()ed, und es gibt einen callback zurueck nach cableinfo, wo dieser block dann per paket-burst rausgeschickt wird.

Es gibt so einige andere di_() funktionen deren Name eigentlich selbsterklaerend ist. Die werden alle explizit per dlsym() von cableinfo referenziert. Jemand mit viel Zeit könnte das wohl alles genau untersuchen, ich komme eher sporadisch dazu (vielleicht ist eine Petition an AVM doch schneller ..).

 

[Flole]

Der Fehler ist dann wohl leider in der dvb Library zu vermuten. Ich hatte mir die Symbole davon angeschaut und bemerkt das ich mein minisatip da ja relativ einfach ranschrauben könnte. Nur leider nützt das alles nichts, wenn ich die fehlerhafte Library dann auch benutze.

 

[fesc]

Der Fehler ist dann wohl leider in der dvb Library zu vermuten

Eher nicht. Das Aufteilen eines Blocks in Pakete und das Verschicken derselben wird ja von calbleinfo gemacht.
In der dvb library koennte man sich hoechstens ein mmap/munmap sparen (was relativ teuer ist), aber im Verhaeltnis zur gesamtlaenge eines Timeslots wohl eher vernachlaessigbar.

Ich werde bei Gelegenheit mal experimentieren ob man di_recvpid_stream() bzw. den callout umbiegen kann um das Versenden selbst zu machen.

 

[fesc]

Ich habe in meinem repository mal ein "proof of concept" fuer einen wrapper der libdvbif generiert. Ich dachte ich lade es mal hoch, da ich in naechster Zeit nicht weiter dazu komme.
Funktioniert soweit ganz gut, jetzt muss man hoffentlich (Freiwillige) nur noch den original callout durch einen eigenen ersetzen welcher die Pakete schneller rausschickt.

- cableinfo patchen (string libdvbif.so durch libdvbfi.so ersetzen)
- LD_LIBRARY_PATH setzen
- cableinfo neu starten

Fuer einen stream habe ich es getestet, nur beim stream schliessen scheppert es.

 

[MSN]

der wrapper ändert aber noch nichts oder hab ich was übersehen?

ps: ich hab nur 5 mal lesen müssen bis ich den unterschied in den namen erkannt hab

 

[fesc]

Nein, erst mal soll er ja auch nix ändern, nur zeigen dass die wrapper API richtig funktioniert .. im nächsten Schritt kann man jetzt versuchen my_cableinfo_callback() so zu ändern dass er nicht mehr cableinfo aufruft, sondern den Datenblock effektiver verschickt. Evtl. als bulk zu einer Art proxy der denn die rtp pakete generiert.

 

[Flole]

Ja den minisatip könnte man da zum beispiel ranbauen. AVM will von mir mal wieder nen Haufen Informationen haben um den Fehler nachzuvollziehen..... Mein Link auf diesen Thread wo der Fehler ja haargenau beschrieben ist und sogar die Lösung vorgeschlagen wurde ist denen egal.... Naja sollen die sich halt selber die Mühe machen, mal schauen wer eher 4HD Streams sendet: Mein minisatip oder AVMs cableinfo

 

[fesc]

Ich habe den library wrapper etwas aufgebohrt, so dass er den dvb ts als UDP stream an einen anderen host schicken kann.
Cableinfo wird dann quasi nicht mehr bedient (nur noch ein pakete pro timeslot, damit es nicht haengt).

Wenn ich so einen HD stream verschicke ist die CPU last nur noch bei knapp 10% (statt 30%, kann man noch weiter optimieren).

Auf dem Zielsystem habe ich dvblast laufen, was den UDP stream wieder in RTP umwandelt und z.B. an VLC schickt. Ich denke das koennte auch z.B. tvheadend sein (kann das mit einem udp ts stream umgehen)?

Ist noch etwas roh, ich muss noch mehrere streams testen, und es stuerzt nach wie vor beim stream schliessen ab. Aber es geht vorwaerts.

 

[fesc]

Voila, es laeuft. 4HD streams von der fritzbox ohne Ruckler!

Auf der FB, folgendes script um die UDP TS streams auf einen externen Rechner zu forwarden:

export LD_LIBRARY_PATH=`pwd`
export UDEST0=192.168.0.40:9000
export UDEST1=192.168.0.40:9001
export UDEST2=192.168.0.40:9002
export UDEST3=192.168.0.40:9003
./cableinfo_p -f

Dann vier virtuelle interfaces anlegen (um das 1 stream pro Rechner Problem zu umgehen):

/sbin/ifconfig lan:20 192.168.20.1
/sbin/ifconfig lan:30 192.168.30.1
/sbin/ifconfig lan:40 192.168.40.1
/sbin/ifconfig lan:50 192.168.50.1

Das gleiche auf einem Windows PC: 4 virtuelle interfaces auf 192.168.20.2/30.2/40.2/50.2

Ein Linux Rechner (192.168.0.40) bekommt die TS streams auf ports 9000-9003, und schickt sie weiter an dem Windows Rechner:
Auf dem Linux rechner laeuft dvblast vier mal:

./dvblast -D 192.168.0.40:9000/udp -c cfg1&
./dvblast -D 192.168.0.40:9001/udp -c cfg2&
./dvblast -D 192.168.0.40:9002/udp -c cfg3&
./dvblast -D 192.168.0.40:9003/udp -c cfg4&

Die cfg files enthalten:

192.168.0.57:9000 1 *

(bzw. 9001, 9002, 9003) um die einkommenden UDP streams auf die entsprechenden ports nach 192.168.0.57 (Windows PC) weiterzuleiten.

Dort jetzt "nur" noch VLC 4 mal separat mit folgender URI starten (Diese VLC instanzen bekommen kein Bild).

rtsp://192.168.20.1:554/?freq=522&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=0,16,17,18,20,5110,5111,1270,1276,5112,5113,5114,5115,5116,5117,5118,5119

Das ist die URI der m3u files die man von der FB bekommt, wobei nur die IP addresse geändert ist. Das ganze muss man mit vier HD sendern machen, jeweis mit einer anderen IP aus dem jew. Subnetz.

192.168.0.40 bekommt jetzt die UDP streams, und schickt sie zurueck. Jetzt nochmal vier VLC instanzen, mit den Netzwerk URIs als Quelle:
rtp://@:9000
rtp://@:9001
rtp://@:9002
rtp://@:9003

CPU last auf Atom ist ca. 45%.
Das Setup ist mit Sicherheit VIEL zu kompliziert, aber das Ziel von 4 HD streams ist erstmal erreicht.. Den Rest ueberlasse ich erstmal den DVB/tvheadend Experten (kann das direkt einen UDP TS stream empfangen?).

Weiteres Optimierungspotenzial:

- Momentan schickt die library noch eines von 20 paketen an cableinfo. Das ist nötig damit dort kein timeout abläuft. Muss noch sehen wie ich das eliminiere.
- Die 20 Pakte pro Block werden einzeln mit sendto() geschickt. Mit einem grossen TCP/UDP burst des ganzen Blocks wird es nochmal wesentlich effektiver, aber damit kommt z.B. dvblast nicht zurecht.
- Die Vergabe der UDP destinations über setenv ist etwas poplig, aber mir ist auf die schnelle nichts besseres eingefallen.

 

[MSN]

super ergebnisse! mir ist nicht ganz klar, warum du immernoch 4 interfaces brauchst? du versendest doch nun selber oder?

 

[fesc]

Der rtsp request wird ja nach wie vor von cableinfo bedient, und dort gilt nach wie vor: ein stream pro IP.