Hallo zusammen,
ich suche Hilfe bei einem merkwürdigen Streaming-Problem, das sich sehr spezifisch auf Jottacloud Video (HLS) zu beziehen scheint.
Jottacloud-Videos ruckeln/puffern immer wieder (Video hängt kurz, lädt nach, stockt).
Parallel laufen andere Downloads/Verbindungen über die gleiche Strecke gefühlt normal bzw. mit voller Bandbreite → wirkt eher wie Jitter/Peering/Routing oder ein CDN-/Segment-Thema.
Während des Stockens z. B. auf video-v2.jottacloud.com (185.179.128.55):
Andere Tests zeigten teils 1–2% Loss und Spikes (bis ~581 ms) zu Jottacloud-IPs, je nach Host.
tracert -4 jfs.jottacloud.com (185.179.129.35) zeigt Route aus dem Telefónica-Netz Richtung UK/Colt (u. a. Hop wie edge7.lon1.neo.colt.net) und danach Richtung Lyse/Jottacloud-Netz.
Pathping zeigt an Zwischenhops hohe „Loss“-Werte (ICMP-Rate-Limit?), am Ziel aber 0% – trotzdem korrelieren die Latenzspitzen zeitlich mit dem Ruckeln.
Jottacloud liefert HLS-Segmente als .ts, z. B.:
https://video-v2.jottacloud.com/segment/<token>/hd/segment_921.ts
Während es ruckelt, treten sporadisch HTTP 404 bei einzelnen Segmenten auf:
Ich kann im DevTools-Tab „Antwort“ teils nichts sehen (bei 404 ist die Payload quasi leer).
Danke vorab!
ich suche Hilfe bei einem merkwürdigen Streaming-Problem, das sich sehr spezifisch auf Jottacloud Video (HLS) zu beziehen scheint.
1) Setup / Rahmenbedingungen
- Anschluss: o2 Mobilfunk als DSL-Ersatz
- Router: FRITZ!Box 6860 5G
- Modus: 5G SA (absichtlich kein 5G NSA; bei NSA dauern Telefonate länger wegen Fallback auf LTE/VoLTE)
- Client: Windows 11 PC, Chrome
- IPv6: in Windows deaktiviert (Tests daher IPv4)
2) Problem
Jottacloud-Videos ruckeln/puffern immer wieder (Video hängt kurz, lädt nach, stockt).
Parallel laufen andere Downloads/Verbindungen über die gleiche Strecke gefühlt normal bzw. mit voller Bandbreite → wirkt eher wie Jitter/Peering/Routing oder ein CDN-/Segment-Thema.
3) Messungen / Beobachtungen
Ping
Während des Stockens z. B. auf video-v2.jottacloud.com (185.179.128.55):
- ping -n 300 video-v2.jottacloud.com
0% Paketverlust, aber Latenzspitzen (bis ~410 ms), Ø ~66 ms, Minimum ~36 ms.
Andere Tests zeigten teils 1–2% Loss und Spikes (bis ~581 ms) zu Jottacloud-IPs, je nach Host.
Traceroute
tracert -4 jfs.jottacloud.com (185.179.129.35) zeigt Route aus dem Telefónica-Netz Richtung UK/Colt (u. a. Hop wie edge7.lon1.neo.colt.net) und danach Richtung Lyse/Jottacloud-Netz.
Pathping
Pathping zeigt an Zwischenhops hohe „Loss“-Werte (ICMP-Rate-Limit?), am Ziel aber 0% – trotzdem korrelieren die Latenzspitzen zeitlich mit dem Ruckeln.
Chrome DevTools (Netzwerk)
Jottacloud liefert HLS-Segmente als .ts, z. B.:
https://video-v2.jottacloud.com/segment/<token>/hd/segment_921.ts
Während es ruckelt, treten sporadisch HTTP 404 bei einzelnen Segmenten auf:
- 404, ~0,6 KB, TTFB ~3,9 s (danach hängt Playback)
Normale Segmente: - 200, ~484 KB, Dauer ~11 s, TTFB ~8,3 s
Ich kann im DevTools-Tab „Antwort“ teils nichts sehen (bei 404 ist die Payload quasi leer).
VLC / curl
- Browser kann die .m3u8 mittlerweile wieder abspielen, aber VLC spielt dieselbe m3u8 nicht (öffnet, lädt kurz, dann nichts – keine Fehlermeldung).
- curl -L <m3u8> unter Windows scheitert mit:
CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - ... keine Sperrprüfung für das Zertifikat ...
→ wirkt wie OCSP/CRL-Erreichbarkeit / TLS-Validierung über die Strecke (Browser offenbar tolerant/anders).
4) Konkrete Fragen
- Klingt das eher nach Routing/Peering/Jitter im o2-/Telefónica-Transit Richtung Jottacloud (UK/Colt) oder eher nach Jottacloud/CDN, weil 404 auf Segmenten eigentlich „Server-seitig“ ist?
- Welche Tests würdet ihr empfehlen, um das sauber einzugrenzen?
- WinMTR/MTR auf Host/IP?
- parallele Downloads von den Segment-URLs?
- DNS-Tests (1.1.1.1 vs 8.8.8.8 vs o2 DNS)?
- anderes Endgerät/anderer Browser?
- Warum spielt VLC die .m3u8 nicht ab, wenn Chrome es kann? (User-Agent? TLS/OCSP? fehlende Header/Token-Handling?)
Danke vorab!