Kodi cache wird bei transcoding nicht benutzt

Hallo zusammen,

mein Server kann transcodieren und wenn ich über einen Browser gucke, funktioniert alles bestens. Ich habe aber 2 Raspberry Pi 3, die mit Kodi (LE 8.0.2) laufen und per WLAN bzw. Internet + WLAN verbunden sind.

Beide Bandbreiten reichen im Schnitt auf jeden Fall aus, um die eingestellte Bitrate abzuspielen. Bei der Wiedergabe kommt es jedoch häufiger zu Rucklern. Ich habe daraufhin probiert den Kodi Cache anzumachen. Wenn nicht transcodiert wird, wird der Cache auch wie erwartet gefüllt. Bei Transcoding passiert jedoch gar nichts und das RAM bleibt leer, egal ob die Wiedergabe gestoppt ist oder läuft. Ich vermute, dass die Übertragungsrate ab und zu unter die mögliche Geschwindigkeit sinkt und es so zu Rucklern kommt, weil kein Cache vorhanden ist. Könnte auch damit zu tun haben, dass Emby beim Transkodieren sehr viele kleine .ts-Dateien produziert und Kodi damit nicht umgehen kann?

Kennt jemand das Problem oder kann es nachstellen? Hat jemand vielleicht sogar einen Workaround? So ist Emby für mich leider über langsames bzw unstetiges Wifi kaum zu gebrauchen.

Viele Grüße

Kurzes Update:

Scheint damit zu tun haben, dass Emby sehr viele kleine .ts produziert und eine m3u8 Playlist, um die abzuspielen. Und dafür scheint Kodi kein caching zu unterstützen (bzw. cached wohl 8 Sekunden im Voraus bzw. bis zum Ende der Datei). Da die Dateien aber alle nur so 1 MB groß sind ist da nicht viel Cache vorhanden... Mal schauen, ob sich dafür noch ein Lösung findet.
Falls jemand Input dazu hat oder Erfahrungen, bin ich sehr dankbar.

Grüße

Zitat von bgx

+1 habe die gleiche Problematik und wäre froh wenn es da eine Lösung gäbe.

Habe mal probiert mich intensiver mit den Entwicklern auseinander zu setzen:
https://emby.media/community/inde…d/?fromsearch=1
Hat nicht so wirklich geklappt leider. Hatte nicht das Gefühl dass sie verstanden haben was ich will. Ich entnehme dem Thread dass es evtl mit Kodi 18 besser wird.
Wenn du noch was rauskriegst dann immer her damit.

Das größere Problem ist auch, dass es auf dem Pi3 extrem stark ruckelt sobald er einmal nicht „flüssig“ gestreamt hat. Das nervt sehr.

Zitat von BJ1

Wenn hier viele kleine .ts erzeugt werden, die von einer m3u8 abgespielt werden, sieht das Streaming sehr nach Apple HLS bzw. HDS aus. Dort wird der Stream in sogenannte Chunks verpackt (das sind die .ts) und per HTTP-Server jedem Client ausgeliefert. Der Vorteil bei der Sache: Man kann im Stream spulen oder pausieren, jeder Client bekommt seine individuelle angepasste Bitrate und Client/Server können sehr schnell auf veränderte Streamingumgebungen reagieren.

Das Cacheproblem gehört da m.M nach eher zu inputstream bzw. zum RTMP-Plugin.

Ah, scheint, dass du es etwas mehr Ahnung hast.
Ich glaube auch (steht ja auch im Thread), dass man über Inputstream hier was regeln könnte. Angeblich unterstützt das ja mittlerweile das Format. Müsste man nur im Emby Addon umbauen und ich kann das leider nicht. Hast du eine Ahnung wie man das vielleicht manuell testen könnte? Ich habe irgendwas von einem Header in der m3u im Kopf, der dann bewirkt, dass sich inputstream der Sache annimmt.

Grüße