[Eingestellt] Zattoo PVR Client für Kodi 17

    Zitat von indri

    @vel2000; sorry, aber ich denke ich glaube mehr an FernetMenta als an Dir.

    wie ich das verstehe, die Kernaussage wäre: Es liegt NICHT am Videoplayer!

    Tja, up to you.
    Nichtsdestotrotz liegt er (ihr beide) völlig falsch.

    Zitat von rbuehlma

    Du kannst das Addon deinstallieren, und die URL zum HLS-Stream direkt an Kodi übergeben. Die Verzögerung hast du dann immer noch. Bitte spiel
    das mal durch und behaupte dann immer noch dass es am (deinstallierten)
    Addon liegt.

    Und wenn Du das hier ^^ wie schon öfter vorgeschlagen, einfach mal testen und nicht permanent ignorieren würdest, wüsstest Du auch warum FernetMenta falsch liegt.
    Aber die Kodi-Devs schieben bekanntermaßen immer gern die Schuld von sich weg... (auf FFmpeg z.B.). :sleeping:

    PS: Ich habe einige Seiten vorher eine kleine Anleitung gepostet, wie man KODI als "Stream URL Lieferant" nutzt, das Video aber in einem anderen Player abspielt.
    Und das funktioniert dann OHNE DIESE VERZÖGERUNGEN!

    @'vel2000
    Hallo, ich glaube Dir komplett, dass es mit den Umschaltzeiten bei anderem Play besser klappt.
    Wärst Du so nett zu erläutern, wie man standardmäßig unter Liberelec (bei mir Raspi2) das Addon anweist die Stream URL an einen anderen Player (welchen am besten und wie installieren?)
    zu übergeben? Ich hab leider keine Idee.
    Wenn die Umschaltzeiten dann in Bereich 1-3 Sekunden kommen wird man Dich hier bestimmt feiern! :)

    Wenn ja nur eine URL übergeben wird an Kodi wieso dauert das öffnen des Streams dann so lange bei Zattoo, und bei anderen Addons wie zb Youtube oder Twitch geht es fix? Das ist doch die eigentliche Frage. Es muss am Format bzw Codec oder so liegen, welche bei Zattoo anders sind als bei Twitch zb. Und DAMIT hat der Demuxer dann wohl Probleme.

    Oder liege ich da logisch gesehen falsch?

    Zattoo sendet in ihren Manifest-Files (m3u8) eine ganze Reihe von URLs für mehrere Sprachen und Bitraten. Ich könnte mir vorstellen, dass da das Handling von Kodi etwas unperformant ist und z.B. erst alle Streams durch testet. Das würde sich mit einem Netzwerk-Sniffer wie Wireshark leicht prüfen lassen.

    Allgemein wäre mein Ansatz zuerst mit einem Sniffer zu prüfen, was da abgeht, denn so ein langer Delay kann eigentlich nicht lokal entstehen.

    Zitat von mts280

    Gibt es eigentlich irgendwo Build Instructions für das plugin? Ich habe nach einigen Anleitungen versucht, das Plugin gegen die aktuelle Kodi master zu bauen, leider ohne Erfolg.

    Sollte das eigentlich möglich sein, und ich habe nur den korrekten (cmake-)Buildprozess nicht verstanden? Oder kompiliert die aktuelle Version des Plugins gar nicht gegen V18?

    für native builds siehe hier:
    native build readme

    für crosscompiling siehe hier:
    Crosscompile
    und hier für RPi2:
    Crosscompile RPi2

    Zitat von vel2000

    Tja, up to you.Nichtsdestotrotz liegt er (ihr beide) völlig falsch.

    Und wenn Du das hier ^^ wie schon öfter vorgeschlagen, einfach mal testen und nicht permanent ignorieren würdest, wüsstest Du auch warum FernetMenta falsch liegt.Aber die Kodi-Devs schieben bekanntermaßen immer gern die Schuld von sich weg... (auf FFmpeg z.B.). :sleeping:

    PS: Ich habe einige Seiten vorher eine kleine Anleitung gepostet, wie man KODI als "Stream URL Lieferant" nutzt, das Video aber in einem anderen Player abspielt.
    Und das funktioniert dann OHNE DIESE VERZÖGERUNGEN!

    @indri es liegt eindeutig nicht am Plugin, so wie vel2000 das auch schreibt und getestet hat. Aber Du kannst gerne mit FernetMenta das Thema weiter klären! ;)

    Zitat von rbuehlma

    dass da das Handling von Kodi etwas unperformant ist und z.B. erst alle Streams durch testet

    Genau so ist die Logik bei Kodi 17, die Beta 2 hatte da noch einen anderen Bug, dort wurden alle Streams des Manifestes zu gleich geladen was zu Bandbreiteneinbrüchen führte, es hatte sehr lange gedauert bis Menta dieses eingesehen hatte.

    Hauptsache man hat Spaß

    No Debug.log, no issue - Kein Support ohne Debug-log.

    CCR, The Band, Lynyrd Skynyrd, Led Zeppelin, Deep Purple .......

    I’m not going to complain that 2day they don’t make music like this anymore, I’m just grateful that it got made period.

    Mich würde interessieren, ob dieses Plugin auch mit den öffentlichen Rechtlichen von Zatoo ("Zattoo Free") zurecht kommt. Die sollen ja sozusagen als DVBT-2-Ersatz herhalten.
    Zattoo selbst konnte mir bisher allerdings noch nicht beantworten, wie diese Streams kodiert sind.

    Nach meinen Infos kann ein Pi ein DVBT-2 Stream nicht verarbeitet, weil ein H.256-codec fehlt. Falls Zattoo das DVBT-2 Signal praktisch "nur durchreicht", würde das auf dem Pi ja auch nicht gehen.
    Konnte das schon jemand von euch probieren?

    Zitat von MoonKid

    Mich würde interessieren, ob dieses Plugin auch mit den öffentlichen Rechtlichen von Zatoo ("Zattoo Free") zurecht kommt. Die sollen ja sozusagen als DVBT-2-Ersatz herhalten.
    Zattoo selbst konnte mir bisher allerdings noch nicht beantworten, wie diese Streams kodiert sind.

    Nach meinen Infos kann ein Pi ein DVBT-2 Stream nicht verarbeitet, weil ein H.256-codec fehlt. Falls Zattoo das DVBT-2 Signal praktisch "nur durchreicht", würde das auf dem Pi ja auch nicht gehen.
    Konnte das schon jemand von euch probieren?

    Ja, das Plugin geht auch mit einem "Zattoo Free" Account. Erst am Wochenende getestet.

    Zattoo liefert kein DVBT-2 "Signal" (= H.265 / HEVC Stream), sondern einen H.264 / AVC Stream.

    Zitat von rainman74

    @vel2000 Kodi 17 RC1 ist offiziell veröffentlicht! Könntest Du wieder eine APK mit diesem Build und dem aktuellen PVR.Zattoo 0.1.28 bauen? :thumbup:

    Kodi-17.1-RC1-Git2017-02-24-pvr_zattoo-0.1.28 (ANDROID)

    Link entfernt


    EDIT: Kodi hat etwas am Build System geändert, so das die Compiler Optionen angepasst werden müssen.

    Bereinigtes Build folgt nach Re-Compile und kurzem Test.

    @vel2000 Ich kann es auf einer Fire TV Box 4k und einem Samsung Galaxy Tab S2 bestätigen!

    So wie es auf die Schnelle scheint, klappt es mit dem Release nur, wenn die MediaCodecs aktiviert sind. Wenn ich beide MediaCodecs ausschalte, habe ich wieder das bekannte Delay von 6-9 sek.

    UPDATE: Mit dem aktuellen Win32 Nightly Build ist es ebenfalls unverändert bei 6-9 sek. Es geht nur in dem neuen Android-Build von Dir mit aktivierten MediaCodecs.

    Zitat von rainman74

    @vel2000 kann es sein, dass Dein Build im DEBUG-Modus kompiliert ist? Ich bekomme 10000 DEBUG Meldungen im Log obwohl der Debug-Modus gar nicht eingeschaltet ist...? ;)

    Ja, sieht so aus.
    Die haben scheinbar irgendwas am Build System geändert, denn ich habe ein "Release" gebaut, wie immer.
    Wenn ich nachher Lust und Zeit habe schaue ich mal drüber.

    EDIT: bei mir macht das keinen Unterschied, ob die Media Codecs an oder aus sind, ich werde aber noch ein anderes Gerät testen.

    Wäre super, dann poste ich mal zwei Logs, einmal mit und einmal ohne MediaCodecs. Ich kann es am Galaxy Tab S2 problemlos reproduzieren, am Fire TV geht es mal und mal nicht. Bei RTL scheint es immer zu gehen... Kann es sein dass die keine HLS-Streams mehr verwenden? Ich teste dann später mal ausführlicher...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden