Was ich beweisen kann 
Immer so negativ…tztz 
Einstellungen geht wieder und EPG Darstellung…wie lange musste man noch auf die Behebung warten? 
Mit Zurück hätte ich ja ein “Bildschirmrecording” gemacht, sperren sie ja aber auf Android 
Auch komplett daneben, generell diese Funktion zu verhindern.
Geht es noch per 
Gerät?
Ja, da geht es.
Aber um deine Frage zu beantworten, wir pilotieren gerade eine AndroidTV App. Ob und wann die Freigabe erfolgt ist noch nicht final.
1 „Gefällt mir“
Der „MagentaTV@Samsung“ App Test ist gestartet. 
Jup Installation lief reibungslos
Erinnert mich stark an die magenta tv app auf dem Fire tv
Ich kann erst heut Abend, bin schon sehr gespannt.
@crunchips Wird wohl daran liegen das man versucht auf allen Plattformen/Geräten ein einheitliches Design/Aussehen hinzubekommen 
Läuft es Flüssig? Vor allem die TV Streams?
Bitte zum MagentaTV @ Samsung Test nur im geschlossenen Labor-Bereich posten!
1 „Gefällt mir“
Alles klar.
Vorweg, das wird sich mit dem Release der neuen iOS und Android Apps ändern. Dann sind alle wieder gleichauf.
Da steigen wir jetzt ein bisschen in die System Architektur und die Streamingprotokolle ein.
Früher haben wir als Streamingprotokoll HLS eingesetzt, heutzutage nutz man überwiegend DASH. Alle alten Client basieren aktuell allerdings noch auf HLS daher produziert unser Headend aktuell nativ HLS Streams.
Die Systemkette sieht (etwas vereinfacht) also aktuell so aus
Satellitt (Signalzuführung) > Encoder > Packager > HLS Streams
diese Streams erhalten die Mobile Apps aktuell, sowie die Webapp. Alle legacy Clients quasi.
Für die neuen Geräte FireTV, MTV Stick verwenden wir bereits DASH welches sich aus dem HLS Strom Transpaketieren lässt.
Daher sieht die Kette wie folgt aus:
Satellitt (Signalzuführung) > Encoder > Packager > HLS Streams > Transpaketierer > DASH Streams
Du erkennst sofort den einen zusätzlichen Schritt der natürlich ein bisschen Zeit benötigt was den Unterschied auslöst.
Und in mehr oder weniger naher Zukunft wird es dann wieder einfacher: Dann fällt der letzte Schritt weg und die Packager liefern direkt DASH Streams. Tatsächlich wird uns das sogar 2 Schritte sparen.
Eine Verzögerung gegenüber dem Sat Stream wird es aber weiterhin geben, schon alleine durch die 6 Sekunden Segmente, die der Client lädt. Diese müssen natürlich erst mal bereitgestellt werden. Und da wir leider immer noch keine Zeitmaschine haben (der Delorian ist gerade beim Waschen), dauert diese Bereitstellung genauso lange, wie das Segment ist: 6 Sekunden. On Top kommt die Verarbeitungszeit bei den einzelnen Stationen.
https://telekomhilft.telekom.de/t5/Fernsehen/Diskussionsthread-zum-MagentaTV-Stick/m-p/4416130#M376505
1 „Gefällt mir“
Bedeutet, der Versatz HLS zu DASH verschwindet, wenn komplett auf DASH gesetzt wird?
Du meinst Versatz vom Stick zur App? Davon würde ich schon ausgehen. Es werden ja alle Apps neu gebaut, ich schätze die funktionieren dann sehr ähnlich zum Stick und wenn sie die gleiche Quelle haben, sollte der Zeitversatz auch ähnlich sein. Ganz gleich bekommt man es aber nicht hin, da die Fragmente und Playlists nur alle x Sekunden aktualisiert werden und je nachdem ob man am Anfang oder Ende so eines Intervalls einsteigt ergibt sich ein Versatz. Also selbst 2 Sticks oder Apps nebeneinander dürften höchstens durch Zufall synchron laufen.
Jup, meinte ich. Unter “neue Geräte” zählte ich für mich die App aus dem Beta Test zu Samsung. Da ist der Versatz eben sehr deutlich, ohne da hier weiter darauf einzugehen.
Da schreibst Du hier eigentlich schon zuviel …
Denke auch, dass die sich wie der Stick verhält. Prinzipiell wäre aber auch denkbar, dass es Unterschiede im Caching gibt. Bei DASH/HLS gibt es verschiedene Ansätze den Stream wiederzugeben. Wie gesagt gibt es da einmal die Fragmente, die zur Zeit glaub ich 6 Sekunden lang sind. Dazu kommt die Downloadzeit für das Fragment - die im Schnitt nicht länger als 6 Sekunden sein darf - das führt zu Unterschieden bei gleicher Software von bis zu 12 Sekunden. Die unterscheiden sich aber jedes Mal aufs Neue, wenn man umschaltet, je nachdem wie alt das Fragment zum Zeitpunkt des Downloads schon war.
Und dann kommen noch clientspezifische Einstellungen dazu. Die Fragmente sind in Playlists, diese enthalten mehrere Fragmente, damit der Client puffern kann. Da ist dann die Frage, wieviel Puffer genehmigt er sich. Wenn der eine Client am Ende der Playlist anfängt und der andere weiter vorn, dann ist der Erste zwar zeitlich weiter hinten, dafür flexibler, wenn mal ein Fragment länger als 6 Sekunden im Download braucht. Und das braucht man dann für die automatische Anpassung der Qualität - das soll ja unbemerkt passieren, geht aber nur, wenn noch etwas Puffer ist, um zu erkennen, dass die Bandbreite nicht mehr reicht und dann das kleinere Profil zu laden. Da würde ich spontan aber eher erwarten, dass die Clients für stationäre Geräte wie TV, Stick und FireTV vielleicht 2 Fragmente cachen, Apps für Smartphones dagegen eher mehr. Dann müsste es aber eigentlich umgekehrt sein.
Dazu kommt dann wohl das angesprochene umpaketieren. Wobei ich gefühlt gesagt hätte, dass das dann in dieser Verarbeitungskette gar nicht mehr den großen Einfluss hat 
Ist aber natürlich denkbar, dass man da immer ein Fragment hinten dran ist.
Aber das müsste man sich halt mal im Detail anschauen. Bei Gelegenheit vielleicht mal wieder die URLs für HLS und DASH Playlist mitschnüffeln, da müsste man ja sehen wieviel die hinten dran sind. Vorausgesetzt die Fragmente haben ein einheitliches Namensschema - denn reinschauen ist nicht, sind verschlüsselt
1 „Gefällt mir“