Freetz Udpxy Entertain

Lord-Schaschlik

Neuer User
Mitglied seit
29 Aug 2005
Beiträge
71
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich setzte mich grade mit dem udpxy auseinander und versuche einen Entertainstream über http herzustellen. Ein direktes abspielen mittels des rtp-Links ist in VLC möglich. Ich habe udpxy in freetz integriert und gestartet. Leider funktioniert das Abspielen nicht. Meine Fritzbox hat die Adresse 192.168.10.1

Ausgeführt habe ich es mit folgendem Befehl: udpxy -p 4022
Der Prozess läuft auch. Link vom Status habe ich angehängt. Ich habe auch verschiedene Seiten im Internet gelesen, aber bin leider nicht weiter gekommen (z. B. http://www.onlinekosten.de/forum/showthread.php?t=141245)
Versuche ich den Stream mit der Adresse http://192.168.10.1:4022/udp/239.35.10.4:10000 zu starten passiert nichts.

Weiß jemand wie man udpxy auf der Fritzbox konfigurieren muss um einen HTTP-Stream zu ermöglichen? Liegt es an der Firewall oder am falschen Interface?
Sollte ja eigentlich nicht all zu schwer sein.
Bin leider mit meinem Latein am Ende.

Vielen Dank
 

Anhänge

  • udpxy.png
    udpxy.png
    35.7 KB · Aufrufe: 48
Ich habe heute weiter versucht eine Lösung zu finden. Lasse ich udpxy lokal auf meinen Ubuntu Rechner laufen, funktioniert es ohne Probleme (http://192.168.10.21:4000/udp/239.35.10.4:10000). Es ist aber keine Lösung für mich. Es muss eine Einstellung von Freetz sein. Ich bin noch auf folgende Seite gestoßen:
http://wiki.openwrt.org/de/doc/howto/udp_multicast
Dort ist beschrieben man soll folgende Firewalleinstellungen vornehmen:
config rule
option src wan
option proto igmp
option target ACCEPT
config rule
option src wan
option proto udp
option dest_ip 224.0.0.0/4
option target ACCEPT
Ich weiß nicht wie dies am besten innerhalb von Freetz umzusetzen wäre. Vielleicht hilft das weiter. Alternativ habe ich eine Openvpn bridge (Level2) eingerichtet. Der Multicasttraffic wird leider trotzdem nicht weitergeleitet. (Folgende Anleitungen habe ich genutzt: http://freetz.org/wiki/packages/openvpn).

Hat vielleicht jemand noch eine Idee?
 
Mangels Entertain-Anschluß kann ich die Vermutung nicht testen, aber Du willst imho den mcast-Traffic ja bei Dir auf 'dev lan' sehen (da wo der udpxy "seine Bindung" hat) und zwar als INPUT (auch wenn das kein iptables ist, Du weißt schon was ich meine).

Ich würde jedoch vermuten, der mcast-Traffic wird bei entsprechender igmp-Subscription aus dem LAN aber gar nicht erst durch den Stack der Box "nach oben gejagt" (die Box kann damit ja i.d.R. ohnehin nichts anfangen), sondern direkt "auf dem kurzen Dienstweg" ins LAN (genauer an alle eth-Ports mit einer Anmeldung für den betreffenden mcast) weitergeleitet.

Die Konfiguration der Netzwerk-Interfaces (und die Möglichkeit der Abfrage über /proc/kdsld/..., die meine Vermutung bestätigen könnte oder auch nicht) ist aber von Prozessor zu Prozessor unterschiedlich, Du müßtest mal etwas zur verwendeten Box sagen.

Jedenfalls würde meine Vermutung das Verhalten (im LAN kommt der mcast-Traffic an, auf der Box selbst nicht) erklären ... vermutlich könntest Du das nicht einmal über einen Packetdump prüfen, da bei aktiviertem igmp-snooping ja kein mcast-Traffic in Bridges eingespeist wird (das würde ja das igmp konterkarieren, wenn da plötzlich wieder an alle Interfaces in der Bridge dieser Traffic weitergegeben wird).

Vielleicht hilft es ja aber auch schon, den udpxy explizit an 'dsl' als mcast-Source zu binden, also: udpxy -p 4022 -m dsl

Keine Ahnung, ob es hilft ... aber schaden kann es auch nicht, der "normale" Weg eines Programms, sich an alle Interfaces zu binden, beinhaltet jedenfalls auf einer FB nicht das dsl-Interface.
 
Erstmal danke für die Hilfe. Hab es mit udpxy -p 4022 -m dsl versucht, leider ohne Erfolg. Das Paket ist Bestandteil in Freetz aber man findet dazu recht wenig. Aber genau dafür ist es doch gedacht. Hab wenig Lust dafür nen PI laufen zu lassen. Ist eine Fritzbox 7362 mit 6.20 Freetz Trunk. Ist das vielleicht noch eine Lösung http://freetz.org/wiki/packages/br2684ctl um den Multicast durchs VPN zu bekommen?
 
Problem besteht immer noch, vielleich hat jemand noch ne Idee. Schieb nochmal hoch
 
Das ist etwas unpraktisch im Forum, wie wäre es denn mit IRC (freenode/##fritzbox) ? Das geht bestimmt schneller ...

EDIT:
Ok, entweder IRC ist nicht Dein Ding oder Du willst nur nicht mit mir reden ... ;)

1. Um was für eine Box handelt es sich denn ? Die Frage zielt auf das Vorhandensein und den Ausbauzustand des proc-Interfaces für den (k)dsld ab, da lassen sich in Abhängigkeit von der Version einige Informationen aus /proc/kdsdl extrahieren.
Ok, gelesen ... 7362SL, das heißt dann ein VR9 und dort gibt das kdsld-proc-Interface schon einiges zum besten ...

2. Was ist das für ein Anschluß ? Teilt sich bei Dir das dsl-Interface der Box in internet und mstv auf ? Wie sieht die Ausgabe von showdsldstat aus ?

3. Wenn geteilt, wie sieht der Inhalt von /proc/kdsld/dsliface/mstv/ipmasq/mcgroups aus und zwar einmal mit einem laufenden MC-Stream im VLC auf einem Rechner im LAN und einmal mit einem über den udpxy "angezapften" Stream ? Dort müßten eigentlich die Multicast-Wünsche der LAN-Clients berücksichtigt werden und wenn der udpxy dort keinen Eintrag für die FRITZ!Box selbst als Ziel auslösen kann mit seiner Subscription, wird der MC-Stream auch nicht bei ihm ankommen.

4. Wenn nicht, ist das Interface eben 'internet', die Fragen/Tests aus 3. bleiben dieselben.

Ich bin zwar nach wie vor der Meinung, daß dort bei einer Subscription die Daten von der Protokoll-Engine quasi "in Hardware" direkt durchgeleitet werden und den Weg über den normalen IP-Stack gar nicht erst nehmen, aber das hängt natürlich auch vom Modell der FRITZ!Box ab, wie da der Prozessor aufgebaut ist. Einen ersten Eindruck von den verschiedenen Möglichkeiten der verbauten Prozessoren erhält man, wenn man sich die passenden Kernel-Quellen ansieht. Das sind ja alles Netzwerkprozessoren mit einem MIPS-Kern und keine "reinen" MIPS-Prozessoren. Da gibt es eben die Möglichkeit, schon in Hardware Pakete anhand bestimmter Merkmale in von der Firmware erstellten Tabellen an verschiedene Interfaces zu routen und somit den Prozessor von immer wiederkehrenden Aufgaben zu entlasten.

Das Entfernen/Hinzufügen von ATM-Headern oder VLAN-Tags erfolgt z.B. bei den meisten Paketen ohne Zutun der Firmware und mit "FASTPATH" können eben auch Pakete direkt von einem Interface zum anderen geleitet werden (bei der 7390 werden die dafür notwendigen Tabellen z.B. in ap2ap verwaltet). Das ist sicherlich bei moderneren Boxen häufiger im Einsatz als noch bei einer 7170 oder 7270 und vermutlich hat auch AVM im Laufe der Jahre bei den neueren Boxen selbst dazu gelernt und dabei mehr und mehr auf die Programmierung der Hardware-Funktionen der Prozessoren verlagert. Die TV-Playlist am Entertain- oder Vodafone-Anschluß ist ja auch nicht soo alt und die Prozessorbelastung durch zusätzliche TV-Clients oder parallele Aufnahmen am MR hält sich nach meinen Erfahrungen - die allerdings schon einige Jahre alt sind und nur ab und an im Bekanntenkreis aufgefrischt werden - auch in Grenzen und steigt nicht parallel zur Anzahl der durchgeleiteten MC-Streams.

Gerade bei der Durchleitung von Multicast-Streams wäre diese Vorgehensweise in meinen Augen auch nur logisch, denn was will die FRITZ!Box im Normalfall mit diesen Streams ? Da ist weder eine Address Translation erforderlich noch eine Zuordnung im Connection Tracking oder eine Prüfung durch die Firewall. Der Stream kann ganz simpel 1:1 (ggf. nach dem Entfernen einer ATM-Encapsulation) ins LAN weitergereicht werden auf den LAN-Ports, an denen per IGMP die entsprechende Subscription eingerichtet wurde. Den Rest dahinter übernehmen dann die Clients und ggf. dazwischen geschaltete Switches mit IGMP-Snooping. In der ganzen Konstruktion ist für die FRITZ!Box eigentlich nur eines zu machen, sie muß die entsprechenden Einträge in den Flow Routing Tables einrichten.

Wenn also der Multicast-Verkehr praktisch "um den IP-Stack herum" geleitet wird, bin ich mir nicht einmal sicher, daß es überhaupt - bei moderner Box mit aktueller Firmware - noch eine Möglichkeit gibt, den auch in der FRITZ!Box zu abonnieren. Deshalb die Frage, ob die Subscription im kdsld sichtbar ist und nur die Daten nicht ankommen oder ob nicht einmal die Subscription für die eigene Adresse der FRITZ!Box dort eingetragen wird.

Mit einem Rezept kann ich also nicht dienen, nur mit dem Angebot der Unterstützung bei der Suche nach der Ursache ... wenn Dir das Thema wirklich die Suche wert ist. Da ich selbst keinen Anschluß mit IPTV mehr habe, kann ich nichts selbst testen ... und was ich zugegebenermaßen nicht leiden kann, ist das Aufgeben, wenn es nicht auf Anhieb klappt. Dann sollte man es lieber von vorneherein bleiben lassen ... aus Deiner Nachfrage würde ich aber schließen, daß Dir das Thema wirklich wichtig ist.

Ich habe noch ein Diagramm (Blockdiagramm auf Seite 2) gefunden, was meine Ausführungen vielleicht etwas illustrieren kann. Da sitzt eben direkt hinter der "6-band DSL engine" erst einmal die "routing engine", die auch eine direkte Verbindung zum Gigabit-Switch im Prozessor hat.
 
Zuletzt bearbeitet:
Erstmal vielen Dank PeterPawn, ich werde die genannten Punkte mal durchgehen. War gestern Abend unterwegs und kann mich erst heute Abend wieder damit beschäftigen.
 
Zu 2) Ist ein IP Anschluss der Telekom. In der showdsldstat steht folgendes:

time: 2014-11-09 15:45:04
0: sync_dsl: VDSL (showtime)
maxspeed 51390000 10048000 51.39Mbit/s 10.05Mbit/s
actual 90488 3624 90.49Kbit/s 3.62Kbit/s
0.18% 0.04%
running (voip=0,tr069=0,tv=2,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled

0: name internet
0: sync_group: sync_dsl
0: iface ptm_vr9 PPPoE/26/dsl 34:31:c4:2c:f7:42 stay online 1 vlan 7 (voip) (prop: default internet)
0: IPv6: off
0: IPv6: error 3/0x3/0 2014-11-09 03:24:38 (disconnect prevention)
0: IPv4: native
0: IPv4: connected since 2014-11-09 03:24:38 (setup time 2 secs) (connect cnt 8)
0: IPv4: next disconnect 2014-11-10 03:23:23 (in 41899 secs)
0: IPv4: ip 91.43.219.20 peer 217.0.117.191 mtu 1492
0: IPv4: masqaddr 91.43.219.20
0: IPv4: dns 217.0.43.177 217.0.43.161
0: route 217.0.43.161/32 protocol dns
0: route 217.0.43.177/32 protocol dns
0: route 91.43.219.20/32 protocol iface
0: acname NBGR22-se800-B226E1910E02QC
0: RX bytes:370909299 pkt error:0 discard:0 filtered:15122 dropped:1025
0: RX pkts:258709 unicast:243224 multicast:15485 broadcast:0
0: TX bytes:180577378 pkt error:0 discard:0 filtered:0 dropped:4
0: TX pkts:449868 unicast:449860 multicast:0 broadcast:8

2: name mstv
2: sync_group: sync_dsl
2: iface ptm_vr9 RBE/18/dsl 34:31:c4:2c:f7:44 stay online 1 vlan 8
2: IPv6: off
2: IPv4: native
2: IPv4: connected since 2014-11-02 20:55:56 (setup time 0 secs) (connect cnt 1)
2: IPv4: disconnect prevention disabled
2: IPv4: ip 10.25.38.120 mask 255.255.192.0 gw 0.0.0.0 dhcp mtu 1500
2: IPv4: masqaddr 10.25.38.120
2: route 10.25.0.0/18 protocol iface
2: route 193.158.131.1/32 via 10.25.63.254 protocol dhcp
2: route 87.141.128.0/17 via 10.25.63.254 protocol dhcp
2: mc from wan 10.1.1.8
2: RX bytes:599533 pkt error:0 discard:0 filtered:0 dropped:16433
2: RX pkts:10438 unicast:667 multicast:9771 broadcast:0
2: TX bytes:54152 pkt error:0 discard:0 filtered:0 dropped:0
2: TX pkts:728 unicast:13 multicast:65 broadcast:650

Zu 3)
Wenn ich in /proc/kdsld/dsliface/mstv/ipmasq/mcgroups mit vi rein schauen finde ich keine Einträge. Kann mir nicht erklären wieso nicht. Weiß nicht ob man darauf keinen Zugriff hat.

Die Folgerung das vieles Hardwareseitig abgearbeitet wird kann ich nachvollziehen. Mir war auch nicht bewusst dass es so eine große Sache ist. Aber bin verwundert wenn das Paket udpxy angeboten wird es aber dann keinen Nutzen hätte. Versuche im Laufe der Woche noch etwas Zeit zu investieren.
 
Wenn ich in /proc/kdsld/dsliface/mstv/ipmasq/mcgroups mit vi rein schauen finde ich keine Einträge.
Einfach mit "cat ..." abfragen ... bei aktiver Mitgliedschaft in einer Multicast-Gruppe sollte dort (oder bei internet) eigentlich etwas zu finden sein, deshalb die zwei unterschiedlichen Szenarien bei einer Abfrage. Einmal mit einer laufenden Übertragung hinter der FRITZ!Box und einmal mit dem (nicht funktionierenden) Versuch des Zugriffs über udpxy, damit man da schon eventuelle Unterschiede sehen kann. Die Anzeige dort sollte mit dem durch die Firmware gesetzten Flow korrelieren ...

Aber bin verwundert wenn das Paket udpxy angeboten wird es aber dann keinen Nutzen hätte.
Das Paket hat wohl hier seinen Ursprung und wenn man sich die parallel dazu vom selben Autor bereitgestellten Pakete ansieht, hat er sie wohl auf einer 7170 angepaßt. Wenn dann niemand das Paket einsetzt und es sich so von Version zu Version bei neuerer Hardware "schleicht", kann so etwas imho schon einmal vorkommen.

Ich weiß auch nicht genau, was Dein geplantes Einsatzszenario ist und warum Du unbedingt die Umsetzung von Multicast- auf Unicast-Traffic haben mußt. Bei den meisten liegt es ja an der Netzwerk-Topologie, wo vorhandene Switches kein IGMP-Snooping beherrschen, dann aus dem Multicast-Traffic am Ende Broadcast machen und damit das Netz fluten.

Vielleicht (nur als Überlegung) ist da am Ende eine Änderung der Topologie doch der einfachere Weg bzw. den Betrieb des udpxy auf einem anderen Host hinter der FRITZ!Box hast Du ja offenbar im Griff.

EDIT: Wenn man sich die Historie des Pakets und die Zusammenhänge noch etwas genauer ansieht, stößt man auf ein älteres Paket "IP-TV", das offenbar nicht mehr vorhanden ist. Für dieses Paket war auch das Vorhandensein von iptables erforderlich und dann fängt das auf einmal auch wieder an, einen Sinn zu ergeben.
 
Zuletzt bearbeitet:
Auch mit CAT erfolgt keinerlei Ausgabe. An meinem Zweitwohnsitz (WG) habe ich lediglich einen DSL-Anschluss und da der DVB-T empfang sehr schlecht ist war mein Gedanke ich greif einfach auf das bestehendes Entertain am Erstwohnsitz zurück. Mein erster Ansatz war eine VPN-Bridge, aber selbiges Problem. Der VPN-Multicast wird trotz Bridge nicht weitergeleitet. Die Anleitung zum Einrichten der Bridge habe ich von freetz.org (http://freetz.org/wiki/packages/openvpn). Dann kam mir eben die Idee statt den Multicast ein http-Stream durch das Netzwerk zu schicken. Was grundsätzlich funktioniert, nicht aber direkt auf der Fritzbox.
 
Auch mit CAT erfolgt keinerlei Ausgabe.
Wenn das auch bei einem aktiven Multicast-Stream "durch die FRITZ!Box" so ist, steht da wohl nichts drin ... mangels IPTV auf der Providerseite kann ich nicht einmal definitiv sagen, was da wo stehen sollte. Komisch ist das zwar imho schon, aber ich weiß es nicht besser ...

Was grundsätzlich funktioniert, nicht aber direkt auf der Fritzbox.
Auch wenn das natürlich qualitativ nicht unbedingt vergleichbar ist ... kennst Du zattoo ? Wenn der DSL-Anschluß in der WG den Download des Streams schaffen würde, sollte er den höher komprimierten (aber dadurch eben auch matschigeren) Stream von zattoo ja erst recht schaffen.

Abgesehen davon müßtest Du den Stream in Originalgröße ja auch erst einmal wieder durch den Upload prügeln, dabei dann noch eine VPN-Encryption auf der FRITZ!Box vornehmen zu wollen, finde ich schon ambitioniert ... glaube aber ehrlich gesagt nicht daran, daß das die FRITZ!Box live packt (nicht mal eine 7490 mit Dual-Core bringt bei mir - vermutlich wegen der mangelnden Hardware-Unterstützung für Verschlüsselung - eine konstante volle Auslastung eines 10 MBit/s-Uploads an einem VDSL50-Anschluß in Ulm zustande, da geht nicht die Leitung, sondern die Box in die Knie).

Und ein MPG-Stream läßt sich nun mal prinzipbedingt nicht weiter zusammenschrumpfen ... da hilft nur eine Recodierung und das packt die Box definitiv nicht, bei der muß man schon aufpassen, daß man beim VPN komplett auf die Kompression verzichtet, da die auch nur unnötig Rechenzeit verbrauchen würde und der Effekt nahe 0 läge (u.U. sogar negative Folgen - also mehr Datenvolumen - haben könnte).
 
Schade dass ich das jetzt erst hier so mitbekommen habe.

Also ich habe ebenfalls IPTV (Entertain) und nutze udpxy 1. um die IPTV-Streams problemlos auch an allen WLAN-Clients (z.B. Smartphone o. Notebook im Garten) nutzen zu können (Multicaststreams per WLAN sind nicht immer problemlos) und 2. um per OpenVPN (per Routing/TUN-Device) auch von unterwegs nicht auf IPTV verzichten zu müssen.

Allerdings läuft bei mir der OpenVPN-Server nicht auf der FritzBox sondern auf einem separaten Server (der auch NAS ist, die FritzBox hat einfach zu wenig Rechenleistung um darauf auch noch OpenVPN performant genug laufen zu lassen) und auf diesem Server läuft verständlicherweise auch gleich udpxy anstatt auf der FritzBox (eine 7390).

Nun hatte ich (um für den Fall gerüstet zu sein, dass der Server mal nicht laufen sollte) in das Firmware-Image der 7390 (6.04) schon immer gleich udpxy mit integriert aber bis jetzt noch nicht den Versuch unternommen (bin bis jetzt davon ausgegangen dass das problemlos möglich wäre) udpxy auf der FritzBox zu starten.

Nun bin ich natürlich durch die negative Erfahrung des TE diesbezüglich neugierig geworden dem Problem auf die Schliche zu kommen, soll ja u.U. auch mal auf meiner FritzBox laufen können...

Also Peter, falls du Lust und/oder Zeit haben solltest dem auf den Grund zu gehen, ich bin bereit deine Befehle unter vollem Gehorsam auszuführen (frei nach dem bekannten Motto "The fun has just begun ..."). ;)

Fürs erste schon mal folgendes:
Code:
root@yyy:/var/mod/root# showdsldstat
time: 2014-11-11 00:13:24
0: sync_ata: ATA (showtime)
 manual       100000000   50000000  100.00Mbit/s  50.00Mbit/s
 maxspeed     100000000   50000000  100.00Mbit/s  50.00Mbit/s
 actual       17391336        680  17.39Mbit/s     680bit/s
                                        17.39%        0.00%
cpmacconfig:ata 7,8
running (voip=0,tr069=0,tv=2,ntp=0,ipv6=0,ipv4=0,vpn=0)
PPPoE Forward: disabled
VPN: root disconnected (last connect time -) 

0: name internet
0: sync_group: sync_ata
0: iface wan PPPoE/26/dsl XX:XX:XX:XX:XX:XX stay online 1 vlan 7 (voip) (prop: default internet) (prop6: default internet)
0: IPv6: automatic (ra)
0: IPv6: connected since 2014-11-02 21:53:28 (setup time 1 secs) (connect cnt 4)
0: IPv6: address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 valid 13913 prefered 1313
0: IPv6: prefix xxxx:xxxx:xxxx:xxxx::/56 valid 14103 prefered 1503
0: IPv6: mtu 1492
0: IPv6: dns 2003:180:2:6000::53 valid 14103 (dhcp)
0: IPv6: dns 2003:180:2::53 valid 14103 (dhcp)
0: IPv4: native
0: IPv4: connected since 2014-11-02 21:53:28 (setup time 1 secs) (connect cnt 5)
0: IPv4: disconnect prevention disabled
0: IPv4: ip xxx.xxx.xxx.xxxx peer xxx.xxx.xxx.xxx mtu 1492
0: IPv4: masqaddr xxx.xxx.xxx.xxx
0: IPv4: dns 217.237.149.205 217.237.151.51
0: route xxx.xxx.xxx.xxx/32 protocol iface
0: route 217.237.149.205/32 protocol dns
0: route 217.237.151.51/32 protocol dns
0: mc to wan 239.35.10.1 (Das Erste HD)
0: mc to wan 239.0.0.1 (unknown)
0: acname LEIA51-fttx
0: RX bytes:17322305671 pkt error:0 discard:0 filtered:4511 dropped:1810
0: RX pkts:14539345 unicast:14539345 multicast:0 broadcast:0
0: TX bytes:6116142988 pkt error:0 discard:0 filtered:0 dropped:7703
0: TX pkts:10469083 unicast:10469082 multicast:0 broadcast:1

2: name mstv
2: sync_group: sync_ata
2: iface wan RBE/18/dsl XX:XX:XX:XX:XX:XX stay online 1 vlan 8
2: IPv6: off
2: IPv4: native
2: IPv4: connected since 2014-11-02 21:53:28 (setup time 1 secs) (connect cnt 3)
2: IPv4: disconnect prevention disabled
2: IPv4: ip xxx.xxx.xxx.xxx mask 255.255.240.0 gw 0.0.0.0 dhcp mtu 1500
2: IPv4: masqaddr xxx.xxx.xxx.xxx
2: route xxx.xxx.xxx.xxx/20 protocol iface
2: route xxx.xxx.xxx.xxx/32 via xxx.xxx.xxx.xxx protocol dhcp
2: route xxx.xxx.xxx.xxx/17 via xxx.xxx.xxx.xxx protocol dhcp
2: mc from wan xxx.xxx.xxx.xxx
2: mc to wan 239.35.10.1 (Das Erste HD)
2: mc to wan 239.0.0.1 (unknown)
2: RX bytes:55090159952 pkt error:0 discard:0 filtered:0 dropped:3277
2: RX pkts:40111539 unicast:798 multicast:40110741 broadcast:0
2: TX bytes:139946 pkt error:0 discard:0 filtered:0 dropped:0
2: TX pkts:2005 unicast:17 multicast:1212 broadcast:776
MC-Error Log: 
 0: 2014-11-03 02:31:09: mc 239.35.10.5 (ZDF) from xxx.xxx.xxx.xxx ssrc 0xe60053e1 60.000sec 
 0: 3.544 mbit/s Jitter 2.339 ok 19436 dup 0 late 0 wrong 2 lost 5 maxlost 3 ds_crc 0
 1: 2014-11-03 02:32:09: mc 239.35.10.5 (ZDF) from xxx.xxx.xxx.xxx ssrc 0xe60053e1 60.000sec 
 1: 3.544 mbit/s Jitter 2.339 ok 19438 dup 0 late 0 wrong 1 lost 2 maxlost 2 ds_crc 0
 2: 2014-11-10 01:58:09: mc 239.35.10.2 (ZDF HD) from xxx.xxx.xxx.xxx ssrc 0xd9353d6e 60.000sec 
 2: 8.680 mbit/s Jitter 2.531 ok 47554 dup 0 late 0 wrong 1 lost 389 maxlost 389 ds_crc 0
 3: 2014-11-10 02:08:09: mc 239.35.10.2 (ZDF HD) from xxx.xxx.xxx.xxx ssrc 0xd9353d6e 60.000sec 
 3: 8.752 mbit/s Jitter 1.197 ok 47947 dup 0 late 0 wrong 1 lost 2 maxlost 2 ds_crc 0

"/proc/kdsld/dsliface/mstv/ipmasq/mcgroups" mit einem MC-Stream per VLC:
Code:
root@yyy:/var/mod/root# cat /proc/kdsld/dsliface/mstv/ipmasq/mcgroups
cat: can't open '/proc/kdsld/dsliface/mstv/ipmasq/mcgroups': No such file or directory

"/proc/kdsld/dsliface/mstv/ipmasq/mcgroups" mit einem udpxy-Stream per VLC (funktioniert natürlich nicht, udpxy habe ich vorher auf der FritzBox gestartet):
Code:
root@yyy:/var/mod/root# cat /proc/kdsld/dsliface/mstv/ipmasq/mcgroups
cat: can't open '/proc/kdsld/dsliface/mstv/ipmasq/mcgroups': No such file or directory

(Also kein Unterschied)
 
MC-Error Log:
0: 2014-11-03 02:31:09: mc 239.35.10.5 (ZDF) from xxx.xxx.xxx.xxx ssrc 0xe60053e1 60.000sec
0: 3.544 mbit/s Jitter 2.339 ok 19436 dup 0 late 0 wrong 2 lost 5 maxlost 3 ds_crc 0
1: 2014-11-03 02:32:09: mc 239.35.10.5 (ZDF) from xxx.xxx.xxx.xxx ssrc 0xe60053e1 60.000sec
1: 3.544 mbit/s Jitter 2.339 ok 19438 dup 0 late 0 wrong 1 lost 2 maxlost 2 ds_crc 0
2: 2014-11-10 01:58:09: mc 239.35.10.2 (ZDF HD) from xxx.xxx.xxx.xxx ssrc 0xd9353d6e 60.000sec
2: 8.680 mbit/s Jitter 2.531 ok 47554 dup 0 late 0 wrong 1 lost 389 maxlost 389 ds_crc 0
3: 2014-11-10 02:08:09: mc 239.35.10.2 (ZDF HD) from xxx.xxx.xxx.xxx ssrc 0xd9353d6e 60.000sec
3: 8.752 mbit/s Jitter 1.197 ok 47947 dup 0 late 0 wrong 1 lost 2 maxlost 2 ds_crc 0
[/CODE]
Was ist das für ein Protokoll ? Wo kommt das her ? So eines kenne ich bisher nicht ... daher die Frage (aber nur am Rande, s.u.).

"/proc/kdsld/dsliface/mstv/ipmasq/mcgroups" mit einem MC-Stream per VLC:
Code:
root@yyy:/var/mod/root# cat /proc/kdsld/dsliface/mstv/ipmasq/mcgroups
cat: can't open '/proc/kdsld/dsliface/mstv/ipmasq/mcgroups': No such file or directory
"/proc/kdsld/dsliface/mstv/ipmasq/mcgroups" mit einem udpxy-Stream per VLC (funktioniert natürlich nicht, udpxy habe ich vorher auf der FritzBox gestartet):
Code:
root@yyy:/var/mod/root# cat /proc/kdsld/dsliface/mstv/ipmasq/mcgroups
cat: can't open '/proc/kdsld/dsliface/mstv/ipmasq/mcgroups': No such file or directory
(Also kein Unterschied)
Das betreffende proc-Interface gibt es in voller Schönheit meines Wissens bisher nur bei VR9-basierten Boxen. Welche Angaben dort vorhanden sind, findet man mit einem
Code:
find /proc/kdsld -type f
heraus.
Ich bin auch gerne bereit, da mal mit Dir gemeinsam zu suchen ... aber bitte nicht böse sein, wenn das im Moment nicht paßt (und es Dir ja nicht pressiert, wenn ich das richtig verstehe).

Ich will mich nicht noch mehr verzetteln und habe noch genug andere Sachen auf dem Tisch (Freetz-Ticket 2499 würde ich zu gerne zu einem Abschluß bringen) ... mit meinem Modifizieren auf der Box für die 7390 komme ich auch nicht so richtig voran, weil da die 6490 dazwischen kam und ich mir das Spielen und Erkunden der Firmware nicht verkneifen konnte. Wenn ich jetzt nicht mal wieder etwas abräume, gehöre ich am Schluß zu den Leuten, die an zig Stellen etwas anfangen, aber nie etwas zu Ende kriegen. Und AVM bringt auch schon wieder neue Labor-Versionen für die 7490/7390, da muß ich dann immer mal meine eigene Inventur machen ... :hehe:
 
Was ist das für ein Protokoll ? Wo kommt das her ?
Das sollten die Entertain IPTV-Multicaststreams (RTP), welche ich zu diesem Zeitpunkt auch geschaut/aufgenommen habe (allerdings ohne Fehler dabei feststellen zu können), für ZDF "rtp://@239.35.10.5:10000" und ZDF HD "rtp://@239.35.10.2:10000" sein. S.h dazu auch:
http://grinch.itg-em.de/entertain/faq/allgemein/multicastadressliste/

Welche Angaben dort vorhanden sind, findet man mit einem "find /proc/kdsld -type f" heraus.
OK:
Code:
root@yyy:/var/mod/root# find /proc/kdsld -type f
/proc/kdsld/guestflt/devices
/proc/kdsld/guestflt/stats
/proc/kdsld/netiface/dsl/iproute/routes
/proc/kdsld/dsliface/mstv/ipmasq/forwards
/proc/kdsld/dsliface/internet/ipmasq/forwards
/proc/kdsld/dsliface/internet/ipsec/connections
/proc/kdsld/dsliface/internet/ipsec/assocs

... aber bitte nicht böse sein,
Natürlich nicht, nur die Ruhe...

(und es Dir ja nicht pressiert, wenn ich das richtig verstehe).
So ist es, bei mir eilt es nicht aber wie es beim TE aussieht weiß ich nicht... ;)

(Freetz-Ticket 2499 würde ich zu gerne zu einem Abschluß bringen)
Oh je, das ist immer noch nicht vom Tisch?
 
Das sollten die Entertain IPTV-Multicaststreams (RTP), [...] sein
Da haben wir uns mißverstanden ... die Frage zielte darauf ab, wo dieses Protokoll erzeugt wurde. Ist es vom udpxy auf dem NAS (meine derzeitige Vermutung) ?

Wie Du selbst siehst, ist das proc-Interface des kdsld beim Vx180 nicht sehr "gesprächig". Die aktiven MC-Subscriptions, die die FRITZ!Box zur Verteilung des eingehenden MC-Traffics auf die LAN-Ports bewegen, kriegt man wahrscheinlich so nicht heraus. Ich weiß auch nicht, ob die in den Support-Daten stehen ... vermutlich eher nicht, denn die Support-Daten speisen sich zu einem guten Teil ja auch aus genau diesen Interfaces.

Das Freetz-Ticket ist leider immer noch offen, auch wenn sich inzwischen zwei mögliche Fehlerpunkte herausschälen ... es gibt einfach zu wenige Tester, die diesen Fehler und eine Box haben, bei der sie auch mit dem Fehler eine Weile leben können und nicht sofort auf einen Workaround oder einen Downgrade als Lösung setzen (müssen).

Beim TE halte ich das Vorhaben (persönlich) für "neu zu durchdenken". Mein Einwand mit dem VPN für MPG-Daten im Upload war durchaus ernst gemeint ... schon bei den Privaten scheitert die Weiterleitung wegen des DRM und selbst wenn man nicht auf zattoo setzen will, die Öffentlichen kriegt man auch über deren Mediatheken als Live-Stream.

Insofern sehe ich (wieder persönlich) den Sinn der Übertragung in die WG nicht so richtig. Daß der Einwand beim VPN auch bei Dir gilt, sehe ich natürlich auch ;) ... da kann dann nur noch das Argument des Tunnelns irgendwelcher Hotel-Paywalls zählen.

Bei meiner Dreambox (eigentlich nur eine Vu+ Ultimo) macht das dann auch wieder einen anderen Sinn, da kann man dann erstens die Privaten (die nicht immer einen Live-Stream haben) auch empfangen und (mit ein wenig Bastelei) auch weitere Programme. Aber auch da mußte ich eben schon feststellen, daß der BCM7413 als Krypto-Prozessor nun nicht unbedingt geeignet ist (das Decrypten des TS mal außen vor gelassen, das läuft in Hardware) und eine VPN-Verbindung zur Box bei gleichzeitigen Aufnahmen von den anderen zwei Tunern (auch nur in SD) aber ganz ganz sicher zur "Klötzchenbildung" (bei den Aufnahmen und beim Live-Bild per VPN) führt, das mithin also einfach keine gute Idee ist.
Auch eine 6360 (Puma5 mit ARMv6-Kern 400 MHz) ist da nur wenig hilfreich ... ein Intel-Quadcore im PC schon eher. Wenn man das schon per VPN durch die Gegend schicken will, sollte man dann auch die schwächste mögliche Verschlüsselung benutzen (angenommen, Stärke und Ressourcenverbrauch korrelieren), gerade genug, daß man sich nicht der "öffentlichen Verbreitung" schuldig macht ... ansonsten sollten die MPG-Daten keiner besonderen Geheimhaltung bedürfen und auch die Lebensdauer einer "Ladung" auf dem Mobilgerät dürfte steigen, wenn man den zusätzlichen Aufwand einer guten Verschlüsselung (nur für diesen konkreten Einsatzzweck selbstverständlich) vermeidet.
 
Erst einmal wieder danke für eure Hilfe. Mit den 10Mbits und dem VPN muss ich dir widersprechen. Hatte das Problem mit einer 7390, seit dem Wechsel auf die 7490 bei meinen Eltern hab ich bei 90% CPU Auslastung volle 10 Mbit durch das VPN (TUN). Dort steht auch noch ein VU Sat Receiver und ne NAS, kann den Upload voll nutzen. Hab aber hier am Standort zu wenig Download um diesen Weg zu gehen. Komm hier vielleicht auf 4-6 Mbit was locker für den Entertain Stream reichen sollte. Ein Entertain SD Kanal hat in etwa 3 Mbit und damit deutlich weniger als ein SD Sat-Stream. Auch die Privaten SD Sender sind nicht DRM geschützt. Zattoo überzeugt mich nicht wirklich.


Wie macht man eigentlich die Code-Hervorhebung?
Hier die Ausgabe von find /proc/kdsld -type f
root@fritz:/var/mod/root# find /proc/kdsld -type f
/proc/kdsld/guestflt/devices
/proc/kdsld/guestflt/stats
/proc/kdsld/nqos/fastrecv
/proc/kdsld/nqos/appls
/proc/kdsld/nqos/results
/proc/kdsld/nqos/wanset
/proc/kdsld/nqos/localset
/proc/kdsld/nqos/lanset
/proc/kdsld/nqos/earlyset
/proc/kdsld/nqos/earlyrecvhook
/proc/kdsld/neigh/ip6addr
/proc/kdsld/neigh/ipaddr
/proc/kdsld/neigh/ethaddr
/proc/kdsld/neigh/devs
/proc/kdsld/netiface/dsl/datapipe/ipv4chain
/proc/kdsld/netiface/dsl/datapipe/ipv6chain
/proc/kdsld/netiface/dsl/datapipe/global
/proc/kdsld/netiface/dsl/iproute/routes
/proc/kdsld/dsliface/mstv/datapipe/ipv4chain
/proc/kdsld/dsliface/mstv/datapipe/ipv6chain
/proc/kdsld/dsliface/mstv/datapipe/global
/proc/kdsld/dsliface/mstv/ipmasq/global
/proc/kdsld/dsliface/mstv/ipmasq/forwards
/proc/kdsld/dsliface/mstv/ipmasq/mappings
/proc/kdsld/dsliface/mstv/ipmasq/addresses
/proc/kdsld/dsliface/mstv/ipmasq/pcpinfo
/proc/kdsld/dsliface/mstv/ipmasq/pcpitems
/proc/kdsld/dsliface/mstv/ipmasq/pcp44
/proc/kdsld/dsliface/mstv/ipmasq/mcgroups
/proc/kdsld/dsliface/mstv/ripv2/config
/proc/kdsld/dsliface/mstv/etherarp/neighbour
/proc/kdsld/dsliface/internet/datapipe/ipv4chain
/proc/kdsld/dsliface/internet/datapipe/ipv6chain
/proc/kdsld/dsliface/internet/datapipe/global
/proc/kdsld/dsliface/internet/ipmasq/global
/proc/kdsld/dsliface/internet/ipmasq/forwards
/proc/kdsld/dsliface/internet/ipmasq/mappings
/proc/kdsld/dsliface/internet/ipmasq/addresses
/proc/kdsld/dsliface/internet/ipmasq/pcpinfo
/proc/kdsld/dsliface/internet/ipmasq/pcpitems
/proc/kdsld/dsliface/internet/ipmasq/pcp44
/proc/kdsld/dsliface/internet/ipmasq/mcgroups
/proc/kdsld/dsliface/internet/ipsec/connections
/proc/kdsld/dsliface/internet/ipsec/assocs
/proc/kdsld/dsliface/internet/ripv2/config
/proc/kdsld/dsliface/internet/gre4/config
/proc/kdsld/dsliface/internet/gre4/servers
/proc/kdsld/dsliface/internet/gre4/tunnels
 
Mit den 10Mbits und dem VPN muss ich dir widersprechen.
Gerne, das ist eine Erfahrung, die ich - nicht mit MPG-Daten, sondern mit ebenfalls schon komprimierten Backups - wirklich anders gemacht habe ... aber ich habe auch bei der 7362SL nicht sofort richtig geschaltet (7362SL < 7390, also schwächer, ist ja falsch), der VR9 darin ist ja vermutlich derselbe wie in der 7490 (2x333MHz), läuft der auch DualCore oder ist ein Kern abgeschaltet (cat /proc/cpuinfo) ? Damit ist dann ein Stream von 6 MBit/s sicherlich machbar (meine 7390 geht dabei aber auch schon in die Knie) ... mit Optimierungen der VPN-Verbindung (keine Kompression und einfachste Verschlüsselung) bei DC-VR9 wohl sogar noch ein wenig mehr.

Auch die Privaten SD Sender sind nicht DRM geschützt.
Das ist jetzt wirklich neu (und interessant) für mich. Als ich noch Entertain hatte (allerdings waren da die Privaten auch noch grundverschlüsselt im Kabel), war alles außer den Öffentlich-Rechtlichen bei (T-Com-)Entertain mit MS-DRM (die Receiver liefen mit Windows CE, machen sie m.W. heute auch noch) versehen, was am Ende bewirkte, daß ein Wechsel der T-Online-Kennung schon mal dazu führte, daß man alte Aufnahmen von diesen Sendern auf der HDD auch nicht mehr sehen konnte.

Dann wurde, nachdem die Privaten sich 2012 zur unverschlüsselten Verbreitung im Kabel verpflichtet hatten, auch das DRM bei Entertain gekippt ? Dann wäre ja das Aufzeichnen der Privatsender auch an einem Entertain-Anschluß wieder ohne weiteres möglich ... da ist dann etwas definitiv an mir vorbei gegangen.

Andererseits fällt mir jetzt auch auf, daß die Senderliste bei der FRITZ!Box bei anliegendem Entertain ja auch die privaten Sender enthält, den Schluß hätte ich also auch selbst ziehen können ...

Wie sieht es denn bei Dir aus ... ist nicht die Möglichkeit, den Stream per VPN direkt zu verschicken (warum willst Du den eigentlich in UC umsetzen, wenn Du ihn am anderen Ende des VPN-Tunnels ohnehin direkt empfangen willst) von einem Host hinter der FRITZ!Box eine Alternative ? Ein Einschalten per "Wake-on-LAN" zum Starten und ein Ausschalten am Ende per Skript sollte sich einfacher realisieren lassen, als eine Umleitung des MC-Traffics auf die FRITZ!Box 7362SL selbst. Ich will Dir das wirklich nicht mies machen, aber das mit udpxy auf der Box sehe ich sehr düster ...
Du kannst ja mal in den Quellen von AVM nach "Packet Accelerator" (meist auch als pa oder ppa in den Dateinamen zu finden) schauen, da werden die Flow Routing Tables verwaltet. Ob es mit dem vorhandenen igmp-Code überhaupt möglich ist, da einen kompletten MC-Stream auf den CPU-Port des Switches zu routen (so wie es auf einen LAN-Port erfolgt), weiß ich nicht. Allerdings könnte es natürlich mit einem direkten Aufruf des AVM-Treibers, der eine entsprechende Route hinzufügt, sicherlich funktionieren ... die Interface-Definitionen der AVM-Treiber in Form von Header-Dateien befinden sich in den Kernel-Sourcen im Pfad "linux-2.6.32/drivers/net/avm_cpmac/include", da kann man auch sehen, was geht und was nicht.

Ich weiß, daß dieser Vorschlag auf Anhieb erst einmal blödsinnig klingt ... aber ich würde tatsächlich mal versuchen, bei AVM nachzufragen, ob das Routing eines MC-Streams vom dsl-Interface zur CPU machbar ist mit ihrem Code (es geht hier ja um die Auswertung der igmp-Pakete und das ist wohl wieder CS). Mehr als eine dumme Antwort riskiert man schließlich nicht ...

Wenn die Antwort dann nicht "Wir bemühen uns ständig ... und haben Ihren Vorschlag weitergeleitet." ist, kann man weiter schauen. Ansonsten müßte man m.E. den udpxy so ändern, daß er nicht einfach eine MC-Subscription per igmp absetzt, der dann von der Firmware nicht richtig verarbeitet wird, sondern gleich selbst das Routing über einen Treiberaufruf passend ändert.
Dazu muß man aber eben erst einmal sehen, was da wirklich nicht klappt. Also als erstes einmal feststellen, wie es bei einem aktiven Host im LAN aussieht, was da in der FRITZ!Box bei den MC-Einstellungen passiert (daher das proc-Interface) und dann vergleichen, wie weit das mit einer Subscription auf der Box übereinstimmt oder ob da überhaupt etwas eingetragen wird.

Wie macht man eigentlich die Code-Hervorhebung?
Zwischen eckigen Klammern "CODE" als Beginn und "/CODE" als Ende.

Zum proc-Interface: Wie gesagt, bei VR9-Prozessoren ist das proc-Interface besser "ausgebaut", die Frage ist für mich eher, warum da bei aktivem Streaming "durch die Box hindurch" bei Dir keine MC-Subscriptions auftauchen.
 
Da haben wir uns mißverstanden ... die Frage zielte darauf ab, wo dieses Protokoll erzeugt wurde. Ist es vom udpxy auf dem NAS (meine derzeitige Vermutung) ?
Oh tschuldigung. In diesem Fall negativ, war mein PC mit dem ich ZDF geschaut habe. Sollte aber prinzipiell eigentlich kein Unterschied ausmachen ob udpxy auf dem NAS den Multicaststream anfordert oder ein anderer Client oder?

Ich weiß auch nicht, ob die in den Support-Daten stehen ... vermutlich eher nicht, denn die Support-Daten speisen sich zu einem guten Teil ja auch aus genau diesen Interfaces.
Hättest du dennoch Interesse an den Support-Daten?

Beim TE halte ich das Vorhaben (persönlich) für "neu zu durchdenken".
Ja, da muss ich dir recht geben. 10MBit/s könnten schon etwas knapp werden für Entertain HD-Streaming was auch noch in einen VPN-Tunnel verpackt werden muss. Selbst wenn die VR9-Box mit 90% Last die 10MBit/s schafft kommt ja dann noch udpxy hinzu und dann könnte es bei HD schon mal problematisch werden. Ich selbst habe schon (dank 50MBit/s im Upload) 3 HD Streams gleichzeitig an 2 verschiedenen Standorte (Verwandte/Freunde) nach extern gestreamt aber selbst 5 HD-Streams müssten noch möglich sein (habe ich allerdings noch nicht probiert).

BTW:
Das schöne am Glasfaseranschluss ist das der Multicasttraffic über VLAN8 im Gegensatz zum "normalen" Internettraffic über VLAN7 nicht auf die vertraglich vereinbarte Bandbreite geregelt wird.


Mein Einwand mit dem VPN für MPG-Daten im Upload war durchaus ernst gemeint ... schon bei den Privaten scheitert die Weiterleitung wegen des DRM
Einspruch ;), hat auch schon Lord-Schaschlik korrigiert. Jedenfalls ist das zumindest für alle privaten SD-Sender der ProSiebenSat.1 Media AG sowie der RTL Gruppe (also für alle relevanten privaten Sender) Geschichte (s.h. auch den Link aus Beitrag #14). Allerdings schaue ich persönlich zu 96-99% sowieso nur noch die ÖR.

und selbst wenn man nicht auf zattoo setzen will, die Öffentlichen kriegt man auch über deren Mediatheken als Live-Stream.
An die Qualität der SD und HD Entertain-Streams kommen die allgemein bekannten Onlineangebote nicht heran!

Daß der Einwand beim VPN auch bei Dir gilt, sehe ich natürlich auch ;)
In meinem Fall wäre das lediglich intern für die "unfallfreie" Nutzung der Entertain-Streams per WLAN (u.a. im Garten) ohne das der NAS-Server laufen muss. Für die Aufgabe als VPN-Server kommen FritzBoxen in meinem Fall definitiv nicht in Frage (auch die schnelleren VR9 basierten nicht), bei 50Mbit/s (oder gar 100Mbit/s bei Fiber 200) Uploadbandbreite können die diesbezüglich einfach nicht mehr mithalten...
Mein "Reserve OpenVPN-Server" (falls der NAS mal nicht läuft) ist übrigens auf einen WLAN-AP ausgelagert (mit 680MHz MIPS32 24Kc Prozessor), das läuft mit ca. 16-18MBit/s ausreichend schnell.

... da kann dann nur noch das Argument des Tunnelns irgendwelcher Hotel-Paywalls zählen.
Also ich nutze (und genau genommen nicht nur ich) von unterwegs mittlerweile fast nur noch die Entertain-Streams von meinem Anschluss, ab 6Mbit/s-Anschlüssen (zu Stoßzeiten möglichst nicht über die Telekom ATM-Plattform ;)) kann ich die SD-Streams nutzen (3,5-4,0Mbit/s) und ab 12-16Mbit/s auch HD-Streams (8-10 Mbit/s). Selbst die Qualität der Entertain SD-Streams ist um einiges besser als die anderen genannten IPTV Alternativen.

BTW:
Die genutzte Bandbreite der IPTV-Streams ist als Beispiel in Beitrag #12 bei der Ausgabe von "showdsldstat" im MC-Error Log erkennbar.

der VR9 darin ist ja vermutlich derselbe wie in der 7490 (2x333MHz), läuft der auch DualCore oder ist ein Kern abgeschaltet (cat /proc/cpuinfo) ?
Nicht nur vermutlich, es sind auch keine 333MHz sondern 500MHz und es sind auch beide Kerne aktiv ("cat /proc/cpuinfo" s.h. z.B [post=2015326]HIER[/post] und weiteres auch [post=2015453]DA[/post]):
  • 7312, 7320, 7330 (SL):
    MIPS32 34Kc (DualCore) @ 393MHz
  • 3272, 3370, 3390, 3490, 7272, 7360 (SL), 7362 SL, 7412 und 7490:
    MIPS32 34Kc (DualCore) @ 500MHz
  • 7340, 7390 und 7369:
    MIPS32 24KEc (SingleCore) @ 500MHz
  • 3270, 7240, 7270:
    MIPS32 4KEc (lahme Krücke, SingleCore) @ 360MHz

(die Receiver liefen mit Windows CE, machen sie m.W. heute auch noch)
Richtig, machen sie auch heute noch. Allerdings plant die Telekom wohl dies im laufe des nächsten Jahres zu ändern um gleichzeitig auch von der Mediaroom-Plattform (gehört übrigens mittlerweile nicht mehr Microsoft sondern Ericsson) weggehen zu können (im Netz wird von einer "Linux-Plattform" gemunkelt, was auch immer das heißen mag :confused:).

was am Ende bewirkte, daß ein Wechsel der T-Online-Kennung schon mal dazu führte, daß man alte Aufnahmen von diesen Sendern auf der HDD auch nicht mehr sehen konnte.
Interessant, allerdings habe ich auch noch nie einen Media-Receiver verwendet...

Dann wurde, nachdem die Privaten sich 2012 zur unverschlüsselten Verbreitung im Kabel verpflichtet hatten, auch das DRM bei Entertain gekippt ?
Das galt nicht nur für die TV-Kabelnetze sondern für alle Übertragungswege, z.B. auch für die IPTV-Angebote von Alice und Vodafone.

PS:
Wenn eine FritzBox als IP-Client läuft müsste ja udpxy darauf problemlos laufen oder?

[ot]
... es gibt einfach zu wenige Tester, die diesen Fehler und eine Box haben, bei der sie auch mit dem Fehler eine Weile leben können und nicht sofort auf einen Workaround oder einen Downgrade als Lösung setzen (müssen).
Am Anfang hatte ich das noch mitverfolgt, ist wirklich Schade das so wenig Aktivität seitens der Nutzer gezeigt wird um solche Problem zu lösen, aber ich will nicht meckern, müsste mich diesbezüglich auch selber an die Nase fassen... :oops:
[/ot]
 
Nicht nur vermutlich, es sind auch keine 333MHz sondern 500MHz und es sind auch beide Kerne aktiv
Ja, das kommt davon, wenn man - wie ich auf der 7490 - nicht richtig liest:
Code:
root@FB7490:~ $ cat /proc/cpuinfo
system type             : VR9
processor               : 0
cpu model               : MIPS 34Kc V5.6
BogoMIPS                : 332.59
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
ASEs implemented        : mips16 dsp mt
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

processor               : 1
cpu model               : MIPS 34Kc V5.6
BogoMIPS                : 249.85
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
ASEs implemented        : mips16 dsp mt
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available
Wenn die BogoMIPS für den ersten Prozessor nicht so unverschämt nahe an 333 gelegen hätten, hätte ich wahrscheinlich auch nicht so schamlos gerundet und daraus 333 MHz gemacht.

Wobei mich die o.a. Ausgabe auf meiner Box schon irritiert. Die BogoMIPS werden(wurden) meines Wissens (früher) immer beim Start des Systems ermittelt, wo ja noch kein Power-Management aktiv sein dürfte, das den zweiten Prozessor heruntertaktet. Ich habe auch keine Ahnung, ob der VR9 so eine Art "thermal throttling" hat, mit dem er heruntergetaktet wird, wenn es ihm zu heiß wird und der letzte Start war definitiv ein "warm boot". Aber komisch ist das in meinen Augen schon, daß da der zweite Prozessor nur ca. 75% des ersten schafft; ich dachte, die wären auch symmetrisch im VR9.

Wenn eine FritzBox als IP-Client läuft müsste ja udpxy darauf problemlos laufen oder?
Imho ja, da ja dann nicht der Traffic von A nach B auf dem "fast path" durchgeleitet wird. Der udpxy auf der Box fordert dann sicherlich ganz normal per igmp den Stream an und sollte ihn auch erhalten.
 
So, nach langer Zeit wollte ich mich mal wieder melden. Ich finde es immer nützlich für andere wenn man weiß wie das ganze nun gelöst ist. Also auf der Fritzbox per Openvpn-Bridge habe ich es nicht zum Laufen bekommen. Ich gehe wie beschrieben davon aus, dass die Multicaststreams dort nicht abgegriffen werden können. Ich nutze nun einen Raspberry PI B+. Dort läuft ein Openvpnserver der mit dem LAN gebrückt ist. Ich kann nun ohne Udpxy auf alle frei empfangbaren Entertainstreams per VPN zugreifen. Falls einer an der VPN-Config interessiert ist einfach Bescheid sagen.

Grüße und nochmal danke für eure Hilfe.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,694
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.