Kenaschon Posted May 1, 2014 Share Posted May 1, 2014 Hallo zusammen, nachdem wir keine Satschüssel mehr haben, sind wir auf Entertain von T-Online umgestiegen. Jetzt habe ich auch Entertain to go mit dabei. Läuft auch soweit im DVBViewer, aber ich habe immer mehr oder weniger viele "Störungen" im Bild. Welcher Codec ist wohl am Besten? Grüße und Danke Manfred Quote Link to comment
dbraner Posted May 2, 2014 Share Posted May 2, 2014 Mal unabhängig vom Decoder: Du kannst im DVBViewer per Entertain to go alle Sender anschauen? Also nicht nur die ÖR sondern auch die privaten (RTL, PRO7 usw)? Auch in HD? Ich dachte immer, die seien verschlüsselt. zum Codec: welchen setzt Du denn momentan ein? Ich würde es mal mit den üblichen Verdächtigen (LAV) probieren. Wenn es Dir nicht zu viel Aufwand ist, auch mal PowerDVD. Vielleicht liegt es ja auch nicht am Codec sonder irgendwo im Netzwerk. Hier wären mehr Infos hilfreich: DSL-Anschluss Bandbreite, WLAN?, Ethernet 100 MBit oder 1 GBit? Quote Link to comment
Kenaschon Posted May 10, 2014 Author Share Posted May 10, 2014 Hallo, RTL ist dabei. Es gibt ja fertige Senderlisten für den DVBViewer. Das komische ist, wenn ich zb. 3sat über den VLC media player schaue ist alles flüssig und es gibt keine Probleme. Selbst wenn ich Das Erste in HD über den VLC media player schaue ist alles ok. Sogar gleichzeitig, also das Erste in HD im VLC media player (alles flüssig) und im DVBViewer RTL (mit Klötzchen). Wenn ich 3sat im DVBViewer schaue, habe ich nur Störungen und Klötchen. Codec sind z.B. diese installiert: ffdshow, LAN Video Decoder, ATI MPEG Video Decoder, MPC - Video decoder, und noch ein paar andere. Egal was ich einstelle, es wird nicht besser sondern nur bei einigen gibt es nur ein grünes Bild. Netzwerk ist ein "1 GBit" Netz. Grüße Manfred Quote Link to comment
Griga Posted May 11, 2014 Share Posted May 11, 2014 http://www.DVBViewer.com/griga/DVBSource%20D/DVBSource.html#PropertyPage Werden bei dir Discontinuities (Diskontinuitäten) hochgezählt? Quote Link to comment
Kenaschon Posted May 11, 2014 Author Share Posted May 11, 2014 Jepp. Jedesmal wenn es eine Störung gibt, geht der Zähler höher. Grüße Manfred Quote Link to comment
Griga Posted May 11, 2014 Share Posted May 11, 2014 Dann hat das nichts mit Decodern zu tun. Der vom DVBViewer empfangene Transportstream ist bereits gestört. Wenn es mit VLC klappt, kann man andererseits davon ausgehen, dass die Daten noch in Ordnung sind, wenn sie deinen PC erreichen. Die Frage ist also: Wo und wodurch gehen sie kaputt? Von Interesse wäre, wie das mit der Analyzer- und Preview-Funktion in TransEdit aussieht. Kennst du das Programm bereits? Falls nicht, siehe Mitgliederbereich und Anleitung. Gibt es da auch Störungen? Quote Link to comment
Kenaschon Posted May 11, 2014 Author Share Posted May 11, 2014 (edited) Habe mir das Programm jetzt mal angeschaut. ???? Ist mir im Moment zu hoch. Wie bekomme ich die IPTV Sender dort eingestellt? Grüße Manfred Nachtrag: Ich habe jetzt mal die IP-Adresse von RTL eingegeben. 239.35.20.10 Port 10000 Im rechten Fenster von Transedit. Dann auf Analyze geklickt. Dort im Feld H.264 Video in der Spalte Missing läuft die Zahl auch hoch. Die Datenrate beträgt dort 2.30 Mbps. Hilft das ein wenig? Grüße Manfred Edited May 11, 2014 by Kenaschon Quote Link to comment
Griga Posted May 11, 2014 Share Posted May 11, 2014 Dort im Feld H.264 Video in der Spalte Missing läuft die Zahl auch hoch. Die Datenrate beträgt dort 2.30 Mbps.Hilft das ein wenig? Ja. Es schließt aus, dass die Fehler durch eine Wechselwirkung mit Video/Audio-Wiedergabe entstehen. Außerdem ist TransEdit so handlich, dass ich im Gegensatz zu einem Monstrum wie dem DVBViewer leicht Testversionen (eventuell mit Debug-Code) hochladen kann. Ich muss jetzt erst mal überlegen, ob es damit eine Möglichkeit gibt, das Problem weiter einzukreisen. Wie häufig treten die Missing Packets auf? Ständig oder in bestimmten zeitlichen Abständen? Quote Link to comment
Kenaschon Posted May 11, 2014 Author Share Posted May 11, 2014 Die treten ständig auf. Macht es Sinn alles zu deinstallieren und wieder zu installieren? Grüße Manfred Quote Link to comment
Griga Posted May 11, 2014 Share Posted May 11, 2014 Macht es Sinn alles zu deinstallieren und wieder zu installieren? Erst mal nicht. Es könnte sein, dass es irgendeine Besonderheit bei den RTP-Headern gibt, mit der der DVBViewer und TransEdit nicht klar kommen - der Transportstrom muss ja vor der Weiterverarbeitung von dieser Netzwerk-Protokollschicht befreit werden. Das beste ist womöglich, TransEdit den ganzen Kram mitsamt RTP-Header aufzeichnen zu lassen. Dann kann man da mal reingucken. Aber das muss ich erst coden - ich melde mich hier wieder, wenn es so weit ist. Gibt es sonst jemand, der Entertain to go mit dem DVBViewer empfängt und das Problem auch hat oder nicht hat? Quote Link to comment
Griga Posted May 14, 2014 Share Posted May 14, 2014 (edited) So, im Anhang befindet sich eine TransEdit-Testversion mit zusätzlichem Debug-Code. Es handelt sich um eine eingeschränkte Version - der Analyzer und Exportfunktionen sind deaktiviert - aber Scannen geht, und auch die Preview-Funktion, wenn bereits eine DVBViewer-Installation vorhanden ist. Vorgehensweise: - TransEdit_Test.exe im DVBViewer-Installationsordner speichern (im selben Ordner wie DVBViewer.exe). - Nach dem Start eine IPTV-Transponderliste erzeugen, falls noch nicht vorhanden. Entweder durch manuelle Eingabe von Adressen in eine neue leere Liste (siehe File -> New List -> DVB IPTV), wie wohl bereits von dir durchgeführt, oder eine M3U-Datei mit den Entertain-Adressen in TransEdit importieren, indem man sie einfach mit der Maus ins TransEdit-Programmfenster zieht. Mit einer Internet-Suche wird man schnell fündig. - Auf der rechten Seite des TransEdit-Hauptfensters eine (funktionierende) Adresse auswählen und auf "Scan Selected" klicken. Daraufhin erscheint das Scanner-Fenster und zeigt die Suchlauf-Ergebnisse an. Nach Auswahl eines Eintrags und einem Klick auf Preview sollte TransEdit den Sender wiedergeben - wahrscheinlich mit den bekannten Störungen. - Info -> Configuration Folder aufrufen (öffnet ein Explorer-Fenster) und TransEdit beenden. In dem Konfigurationsordner sollte sich eine Datei namen TransEdit_Test.txt mit dem Log befinden. Diese Datei hier bitte anhängen - eventuell gezippt, falls sie zu groß geworden ist. Und dann schauen wir mal, ob daraus irgendwas hervorgeht. Edited May 15, 2014 by Griga Anhang entfernt Quote Link to comment
Kenaschon Posted May 14, 2014 Author Share Posted May 14, 2014 Hallo, so habe alles nach Anleitung gemacht. Hier die TransEdit_Test.txt Datei. Wenn du eine längere Laufzeit benötigst, bitte melden. Bin mir jetzt nicht sicher ob das wichtig ist, aber die Störungen im Bild treten in den Bereichen am stärksten auf die sich verändern. Also z.B. ein "Testbild" hat kaum Störungen, dafür ist ein Spielfilm kaum zu erkennen. Grüße Manfred TransEdit_Test.txt Quote Link to comment
Griga Posted May 15, 2014 Share Posted May 15, 2014 (edited) Die gute Nachricht ist: Es bleibt spannend An den RTP Headern liegt es nicht. Zwar haben sie eine variable Größe, was etwas ungewöhnlich ist, aber das behandelt TransEdit laut Log richtig. Ich habe dort nur einen HInweis auf fehlende Daten gefunden. Kurz nach dem Start des Streams fehlt ein Paket mit ca. 1300 Bytes, danach nicht mehr. Allerdings habe ich das Loggen auf 100 Einträge beschränkt, damit die Datei nicht unversehens mehrere MB groß wird. Womöglich gab es danach weitere fehlende Pakete, die nicht mehr erfasst wurden. Deshalb eine weitere Testversion im Anhang, die gezielt nach fehlenden Paketen Ausschau hält (nicht TS-Pakete wie der TransEdit Analyzer, sondern UDP-Pakete auf Netzwerk-Ebene). Sie erkennt Lücken, indem sie einen Zähler in den RTP-Headern im Auge behält. Also mit der neuen Testversione 4.0.7.2 die gleiche Prozedur wie zuvor. Überprüfe auch, ob die Wiedergabefehler immer noch auftreten, wenn du im Scannerfenster die Preview aufrufst. Ich habe nämlich ein paar Kleinigkeiten auf Verdacht geändert. Vielleicht hilft das schon. Edited May 15, 2014 by Griga Anhang entfernt Quote Link to comment
Kenaschon Posted May 15, 2014 Author Share Posted May 15, 2014 Ich habe dir mal drei Dateien erzeugt. ZDF und WDR sind normale Programme. Leider keine wirkliche Veränderung Eins Plus ist ein HD Kanal gewesen. Das Bild ist kaum zu erkennen. Grüße und Danke für die schnelle Suche. Manfred ZDF-Info-TransEdit_Test.txt WDR-TransEdit_Test.txt eins plus HD-TransEdit_Test.txt Quote Link to comment
Griga Posted May 15, 2014 Share Posted May 15, 2014 (edited) Hmm, das bestätigt meine Vermutung. Schon auf Netzwerk-Ebene gehen ständig Daten verloren. TransEdit kriegt überhaupt nicht alle Daten zu sehen, oder mit anderen Worten, sie gehen nicht in TransEdit verloren. Fragt sich warum. Wenn die Wiedergabe im VLC komplett störungsfrei ist, muss es auch irgendwie anders gehen. Hast du in dem PC zufällig zwei LAN / WLAN Adapter in Betrieb? Was du noch probieren kannst: TransEdit beenden und die Datei TransEdit.ini mit einem Texteditor öffnen. In der Sektion [Hardware] gibt es einen Abschnitt für das virtuelle IPTV-Gerät. Da sollten Einträge stehen wie Name.x=IPTV Network DeviceTunerType.x=4IPTVNid.x=0IPTVBuffers.x=7 Das x hinter dem Punkt steht hier für die laufende Gerätenummer und ist eine Ziffer ab 0... das hängt von deiner Konfiguration ab. Füge in dem Abschnitt einen Eintrag hinzu, der so aussehen sollte: IPTVRecvBuf.x=0 mit der gleichen Nummer für x wie bei den anderen Einträgen. Er bewirkt, dass die Empfangspuffergröße auf Betriebssystem-Standard gesetzt wird. TransEdit verwendet ansonsten den Wert 4096, der 4096 kB = 4 MB entspricht. Damit die Maniupulation wirkt, brauchst du die neue Testversion unten - in der vorherigen hatte ich einen Fehler übersehen, der das Lesen des Wertes aus der TransEdit.ini verhindert (die Gerätenummer wurde nicht erfasst). Edited May 16, 2014 by Griga Anhang entfernt Quote Link to comment
Kenaschon Posted May 15, 2014 Author Share Posted May 15, 2014 Jepp, im Rechner sind zwei Netzwerkkarten. Eine "Onboard" Karte und eine Steckkarte (ist aber deaktiviert). Kann aber auch raus. Neue Einstellung und Version getestet. Datei im Anhang. Grüße Manfred TransEdit_Test.txt Quote Link to comment
Griga Posted May 16, 2014 Share Posted May 16, 2014 (edited) ist aber deaktiviert Wenn sie auf BIOS- oder Treiberebene deaktiviert ist, sollte sie keinen Einfluss haben. Neue Einstellung und Version getestet. Bringt nichts. Werfe die Zeile IPTVRecvBuf.x=0 bei geschlossenem TransEdit wieder raus (einfach löschen). So langsam gehen mir die Ideen aus... ich habe aber den IPTV-Teil probeweise auf eine andere Code-Bibliothek für Internet-Zugriff umgestellt. Vielleicht kann die es besser. Die neue Testversion schreibt kein Log mehr, da klar ist, woran es liegt. Nur leider nicht, was man dagegen tun kann. Einfach mal probieren: Edited May 18, 2014 by Griga Anhang entfernt Quote Link to comment
Kenaschon Posted May 16, 2014 Author Share Posted May 16, 2014 Hallo, wirklich besser ist das auch nicht. Bin ich denn der einzige mit dem Problem, oder schaut keiner über den DVBViewer IP-TV? Hilft dir eine "was auch immer" Datei vom VLC-Player weiter? Grüße Manfred Quote Link to comment
Griga Posted May 16, 2014 Share Posted May 16, 2014 Bin ich denn der einzige mit dem Problem, oder schaut keiner über den DVBViewer IP-TV? Habe ich mich auch schon gefragt. Rückmeldungen ähnlicher Art sind mir nicht bekannt. Ich kann es nur testen, indem ich den VLC lokal eine TS-Datei als UDP / RTP streamen lasse. Das funktioniert problemlos. Ebenso bei einem Betatester, der IPTV in einem professionellem Umfeld verwendet. Du kannst es ja mal zum Vergleich mit einem lokalen Stream probieren. Dazu im VLC Medien -> Stream anwählen -> mit Hinzufügen eine TS-Datei auswählen, also z.B. irgendeine DVBViewer-Aufnahme -> auf Stream klicken -> Next -> RTP / MPEG Transportstream auswählen -> Hinzufügen -> als IP-Adresse z.B. 239.0.0.1 eintragen - > Next -> Transkodierung aktivieren aus -> Next -> Alle Elementarstreams streamen ein -> Stream. Dann in TransEdit in deiner IPTV-Transponderliste einen Eintrag mit 239.0.0.1 als Adresse und 5004 als Port ergänzen. Und das sollte dann störungsfrei funktionieren. UDP als Protokoll ist im Prinzip immer verlustträchtig, da es im Gegensatz zu TCP keinen Rückkanal zum Server gibt, über den fehlende Pakete erneut angefordert werden. Dass die Aussetzer bei dir so extrem auftreten, lässt jedoch vermuten, dass besondere Umstände außerhalb von TransEdit eine Rolle spielen. Auf jeden Fall kommt der Stream schon reichlich kaputt in TransEdit an. Ich kann mir nicht vorstellen, was der VLC anders macht, um das zu vermeiden. Man könnte in TransEdit noch an der CPU-Priorität drehen, mit der der Teil ausgeführt wird, der den Stream empfängt - dazu in der TransEdit.ini den Eintrag Priority.x auf 2 setzen (funktioniert nur mit der letzten Testversion), oder ich könnte TransEdit noch einen zusätzlichen eigenen Puffer verwenden lassen, habe aber Zweifel, ob das was nützt. Quote Link to comment
Derrick Posted May 16, 2014 Share Posted May 16, 2014 Wird die reihenfolge der datagramme eingehalten? ich nehme an, dass das überprüft wird, aber zur sicherheit frage ich es einfach Quote Link to comment
Griga Posted May 16, 2014 Share Posted May 16, 2014 Hmm, gute Frage - den Aspekt habe ich bislang nicht bedacht. Wenn man sich die Logs anschaut, sieht es so aus, als ob der Continuity Counter (Modulo 65536) in den RTP Headern teilweise rückwärts läuft. Das Log gibt die Differenz zum Sollwert an, wenn es eine Abweichung gibt. Ich hatte das gesehen, aber angenommen, dass es an einem Fehler im Debug-Code bei Überträgen liegt. Das muss ich noch mal überprüfen... Quote Link to comment
Derrick Posted May 16, 2014 Share Posted May 16, 2014 Datagramme können sich unterwegs überholen, da sie verschiedene wege nehmen können. Bei RTP sollte allerdings am ende die richtige reihenfolge wiederhergestellt sein. Das RTP-Protokoll stellt eine Ende-zu-Ende-Verbindung mit Echtzeitübertragung her und unterstützt Unicast-Verbindungen aber auch IP-Multicast. Es erkennt und korrigiert fehlende, doppelte oder in falscher Reihenfolge empfangene Datenpakete Quote Link to comment
Kenaschon Posted May 16, 2014 Author Share Posted May 16, 2014 Was mich halt eben so wundert ist, das ich sogar die HD Programme ohne jegliche Störungen im VLC-Player anschauen kann und im DVBViewer schon die normalen Programm schwierig sind. Grüße Manfred Quote Link to comment
Griga Posted May 16, 2014 Share Posted May 16, 2014 Datagramme können sich unterwegs überholen, da sie verschiedene wege nehmen können. Bei RTP sollte allerdings am ende die richtige reihenfolge wiederhergestellt sein. Ich denke, das ist die Erklärung für die hier geschilderten Probleme. Zunächst einmal hat man in der Hinsicht keine Unterstützung von Windows bzw. Winsock zu erwarten: http://tangentsoft.net/wskfaq/intermediate.html UDP is an “unreliable” protocol: the stack does not make any effort to handle lost, duplicated, or out-of-order packets. UDP packets are checked for corruption, but a corrupt UDP packet is simply dropped silently. Es gibt Hinweise, dass es im VLC früher das gleiche Problem gab, aber dass dann ein Programmteil ergänzt wurde, der UDP/RTP-Pakete in die richtige Reihenfolge bringt. Siehe z.B. hier: https://forum.videolan.org/viewtopic.php?f=2&t=27287 Die dort angeführte Einstellung "RTP reordering timeout" finde ich allerdings in der aktuellen VLC-Version nicht. Ich nehme an, damit ist die Zeit gemeint, die der VLC maximal bei Lücken im Datenstrom wartet, ob fehlende Pakete nachträglich eintreffen. Wie auch immer - eine kurzfristige Abhilfe ist im DVBViewer wahrscheinlich nicht möglich, da dazu erst ein entsprechender Algorithmus gefunden / erfunden, integriert und getestet werden muss. Also kein Fix, der sich von heute auf morgen durchführen lässt. Ich werde über die Sache nachdenken, kann aber nicht sagen, wann eine Lösung vorliegt. Quote Link to comment
Derrick Posted May 16, 2014 Share Posted May 16, 2014 Das würde allerdings einiges erklären, obwohl doch bisher einiges an IPTV funktionierte, oder nicht? Beim lokalen streamen innerhalb eines LANs tritt das problem natürlich nicht auf. Allerdings ist es ziemlich shocking, wenn es so ist. Denn dann steht was drauf, was nicht drin ist. Alles wo RTSP im DVBViewer drauf steht, wäre dann einfaches UDP und das strippen der rtp-header reiner ballastabwurf. Quote Link to comment
dbraner Posted May 17, 2014 Share Posted May 17, 2014 Ein Protokoll wie RTSP zu verwenden löst ja nicht das Problem, dass sich Pakete im Netz überholen oder verloren gehen können. In UDP gibt es weder Flow Control noch Packet Sequencing. Wenn man das haben möchte, muss man TCP verwenden. Bei UDP bleibt es dem Empfänger überlassen, die Pakete in die richtige Reihenfolge zu bringen, üblicherweise durch Buffering. Bei Packetloss hilft das natürlich nicht. Daher wird bei modernen Streamingarchitekturen im IPTV Umfeld eine Retransmission Technik verwendet, d.h. wenn ein Client feststellt, dass Pakete fehlen, kann er diese beim Server erneut anfordern (natürlich nur ein gewisses Maß). Wie auch immer: der DVBViewer muss zumindest das Reordering implementieren, um die UDP Pakete in die richtige Reihenfolge zu bringen. Das erneute Anfordern verlorener Pakete dürfte schwierig zu implementieren sein, da die entsprechenden Schnittstellen der IPTV Anbieter nicht dokumentiert sind. Quote Link to comment
Derrick Posted May 17, 2014 Share Posted May 17, 2014 Es geht um RTP. Hier mal aus der Sat>IP protocol specification: The SAT>IP protocol makes use of:- UPnP for Addressing, Discovery and Description,- RTSP or HTTP for Control,- RTP or HTTP for Media Transport. Für RTP gilt: Sequence Number Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen. Dieser teil scheint im DVBViewer nicht (richtig) implementiert zu sein. Quote Link to comment
Griga Posted May 17, 2014 Share Posted May 17, 2014 Beim lokalen streamen innerhalb eines LANs tritt das problem natürlich nicht auf. Aber schon WLAN ist dafür offenbar anfällig. Ich erhalte bei SAT>IP bzw. Streamen von TV über WLAN in größeren Zeitabständen Diskontinuitäten, wenn das RTSP-Gerät für UDP / RTP konfiguriert ist. Server ist der Recording Service, der Client TransEdit. Bislang dachte ich, es wären Paketverluste. Jetzt wollte ich es genauer wissen. Das folgende Log spricht eine deutliche Sprache: 11:30:07 ReceiveData Discontinuity: 47307, 47308, 1 11:30:07 ReceiveData Discontinuity: 47309, 47307,-2 11:30:07 ReceiveData Discontinuity: 47308, 47309, 1 Der erste der drei Zahlenwerte ist die erwartete (= auf die zuletzt eingetroffene folgende) Sequence Number aus dem RTP Header, der zweite die tatsächliche, und der dritte die Differenz. Wie man sieht, kommt hier Paket 47307 nach 47308 an. Daneben gibt es gelegentlich auch wirkliche Paketverluste. Mit TCP passiert das nicht. Quote Link to comment
Derrick Posted May 17, 2014 Share Posted May 17, 2014 Hmm, bei WLAN könnte das vielleicht durch ein internes link layer enstehen, das verluste durch wiederholung versucht zu reparieren. Weiss ich aber nicht. Wenn alle datagramme denselben weg nehmen, sollte sich eigentlich an der reihenfolge nichts ändern dürfen. Quote Link to comment
Griga Posted May 17, 2014 Share Posted May 17, 2014 Wenn alle datagramme denselben weg nehmen, sollte sich eigentlich an der reihenfolge nichts ändern dürfen. Habe ich auch gedacht, aber die Wege des Herrn bzw. seiner Daten sind unergründlich... hier geht das über WLAN zu einem vorsintflutlichen Telekom-Router, und von dort aus über LAN zum Client PC. Quote Link to comment
dbraner Posted May 17, 2014 Share Posted May 17, 2014 Ich zitiere mal: There are lots of reasons why a network element might drop a packet or send it out of order. The most common reason is queue overrun. Many IP implementations have a maximum number of packets they will hold waiting to process. If they receive another packet (from another machine or from code on the same machine), they will often discard it. It is even possible for packets to be dropped or delayed by the wires connecting machines, due to attempts by multiple machines to transmit on the wire at the same time. When that happens, none of the packets may get through, and the sending machines may or may not attempt to retransmit. Quote Link to comment
Griga Posted May 18, 2014 Share Posted May 18, 2014 @Kenaschon: Bist du noch online? Im Anhang die Testversion 4.0.7.4. Damit sollte es bei dir deutlich besser gehen. Sie bringt Pakete in die richtige Reihenfolge. Bei meinem WLAN hat es jedenfalls die gewünschte Wirkung, d.h. es beseitigt die meisten Diskontinuitäten. Die Version schreibt auch wieder ein Log. Bitte das Ergebnis anhängen. TransEdit_Test_4_0_7_4.zip Quote Link to comment
demerzel Posted May 19, 2014 Share Posted May 19, 2014 Hab bei mir auch T-entertain mit dabei, nutze es allerdings aktuell nicht. Hatte aber vor längerer Zeit mal eine Senderliste importiert (noch ohne Privatsender) und das klappte hier problemlos. Habs grade noch mal probiert. Keine Aussetzer oder so. Auch die HD-Kanäle gehen. Nur beim umschalten gibts ganz kurz etwas gewürfel. Allerdings läuft hier alles über Lan. Quote Link to comment
Kenaschon Posted May 20, 2014 Author Share Posted May 20, 2014 So, da bin ich wieder. Die normalen Kanäle funktionieren jetzt super. Die HD Sender haben noch immer Probleme. Ich habe dir mal verschiedene Log-Dateien erstellt. Grüße Manfred das erste HD TransEdit_Test.txt HR normal TransEdit_Test.txt NDR HD TransEdit_Test.txt ndr normal TransEdit_Test.txt wdr normal TransEdit_Test.txt zdf neo HD TransEdit_Test.txt Quote Link to comment
Griga Posted May 20, 2014 Share Posted May 20, 2014 Da geht tatsächlich noch etwas schief in einem Fall, der bei den hiesigen Tests nicht auftrat. Macht aber nichts - die nächste (korrigierte) Testversion unten Außerdem gibt noch eine weitere Ursache für Störungen. Gelegentlich tauchen ungewöhnlich große Datenpakete auf, an die sich TransEdit erst anpassen muss, und dabei geht eine Ladung verloren. Das kannst du selbst beheben, indem du unter Settings -> Hardware für das IPTV-Gerät "Buffered TS Packets" auf 8 setzt. TransEdit_Test_4_0_7_6.zip Quote Link to comment
Kenaschon Posted May 23, 2014 Author Share Posted May 23, 2014 Hey, die Version ist richtig gut. Bei den HD Programmen läuft alles rund als auch bei den normalen Programmen. Keinerlei Klötzchen mehr im Bild. Dann steht jetzt wohl eine neue Version an, richtig? Grüße und Danke für die super schnelle Hilfe. Manfred 3sat HDTransEdit_Test.txt ZDFneo HD TransEdit_Test.txt NDR TransEdit_Test.txt RTL TransEdit_Test.txt Quote Link to comment
Griga Posted May 23, 2014 Share Posted May 23, 2014 Bei den HD Programmen läuft alles rund als auch bei den normalen Programmen. Schön. Vielen Dank für deine Mitarbeit. Deine Kraut & Rüben-Streams waren ein ideales Testobjekt. Wenn der DVBViewer die packt, kann ihn in der Hinsicht nichts mehr erschüttern Dann steht jetzt wohl eine neue Version an, richtig? Eine DVBViewer GE-Version mit der Verbesserung ist schon oben: http://www.DVBViewer.tv/forum/topic/8569-DVBViewer-ge/?p=408837 Da du keine Sat-Schüssel mehr hast, ist der DVBViewer GE vielleicht für dich interessant, weil er Internetradio vollständig integriert: http://www.DVBViewer.tv/forum/topic/54513-internet-radio-mit-dem-DVBViewer-ge-35/ Den DVBViewer GE kannst du zusätzlich zum DVBViewer Pro installieren (ReadMe in der DVBViewer GE ZIP lesen!). Ein Bugfix-Release des DVBViewer Pro wird es womöglich um Pfingsten herum geben. Ein genauer Termin steht noch nicht fest. Quote Link to comment
Kenaschon Posted May 23, 2014 Author Share Posted May 23, 2014 Schön. Vielen Dank für deine Mitarbeit. Deine Kraut & Rüben-Streams waren ein ideales Testobjekt. ....... Ist bei meinem Stream etwas nicht in Ordnung? Falsche Einstellung? Grüße Manfred Quote Link to comment
Griga Posted May 23, 2014 Share Posted May 23, 2014 Nein, ist schon ok. Die Datenpakete kommen nur ziemlich extrem durcheinandergewürfelt bei dir an an, obwohl der Server sie garantiert in der richtigen Reihenfolge abgeschickt hat. Sowas kann im Internet passieren, je nach dem, wie die Daten geroutet werden. Und auch lokal über WLAN ist das möglich, wie ich inzwischen gelernt habe (obwohl ich noch nicht verstanden habe, warum genau). Ist bei dir zusätzlich WLAN im Spiel? Normalerweise sorgt in solchen Fällen das TCP-Protokoll für Ordnung, d.h. der Windows Protokoll-Stack sortiert die Daten. Bei IPTV handelt es sich jedoch um das wesentlich anspruchslosere UDP-Protokoll, darin eingeschachtelt RTP (kannst du alles bei Wikipedia nachschlagen...), und dann liegt es in der Verantwortung der Anwendung, die Pakete in die richtige Reihenfolge zu bringen. In der Hinsicht gab es im DVBViewer noch Verbesserungsbedarf. Quote Link to comment
Kenaschon Posted June 13, 2014 Author Share Posted June 13, 2014 Mir ist noch etwas aufgefallen. (Hat nichts mit dem Problem weiter oben zu tun. Da ging es ja über Netzwerkkabel) Ich wollte auch auf meinen Handy IP-TV schauen. Nur so zum Spaß. Das läuft ja alles über W-LAN. Ging erst überhaupt nicht. Alles grün und total zerhackt. Dann habe ich mal in meiner Fritz-Box gestöbert. Es ist eine 7270. Dort im Menü "WLAN" Untermenü "Funkkanal", gibt es eine kleine Box, in der man einen Haken setzten kann. Dieses kleine Kästchen nennt sich "WLAN-Übertragung für Live TV optimieren". Und siehe da - IP-TV über WLAN geht. Ganz ohne Probleme. Grüße Manfred Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.