Dort im HowTo unter Punkt 4.) Linux x86_64 ist doch alles beschrieben.
Die libwidevine aus dem dort verlinkten Chrome 55.0.2883.75, hat die md5sum:
186060dffef20c8df505f9f78a944d94 libwidevinecdm.so
abfragen kannst du dies mit
root@ubu-kvm-srv:~/.kodi/cdm# md5sum libwidevinecdm.so
und die spielt alle Livestreams.
Das ist genau der Fehler der mit allen libwideviecdm Libs größer 1.4.8.903, zusammen mit dem inputstream.adaptive Master und den SkyGo Livestreams und Maxdome, auftritt.
Du hattest mal geschrieben:
Es liegt nicht wirklich an der libwidevine mit skygo, sondern daran,
dass die neue libwidewine scheinbar schneller ist (beim lizenz-holen).
Das führt(e) dazu, dass schon mal vor "jetzt" gesprungen wurde, also in die Zukunft.
Aber mit Libreelec auf x86_64 und der 1.4.8.962 gibt es ja die Probleme mit den fehlenden Abhängigkeiten die LE nicht dabei hat, verwirrt die User ja noch mehr, deshalb sollte ja die 1.4.8.903 noch benutzt werden.
habe noch ein gerät frei.....
ich habe die widevinecdm 1.4.8.903 und mich an die anleitung für windows gehalten (post #5)! finde dort auch auf der gesamten ersten seite der howtos keine infos darüber, was es mit diesem [definition=12,3]debug.[definition='1','0']log[/definition][/definition] auf sich hat
Dann mal ein komplettes [definition='1','3']Debug[/definition].[definition='1','0']log[/definition] nach http://www.pastebin.com schieben, diesen Logsnips kann man gar nichts entnehmen und
einmal einen Livestream und einmal ein Serienevent starten.
ich weiß nicht, woran es bei mir liegt... habe die funktionierende wdm und auch den rest richtig befolgt...
Da gibt es nur zwei Möglichkeiten,
a.) falsche libwidevine lib, wenn die Livestreams nicht spielen, die anderen Streams schon
b.) wenn man sich an das HowTo gehalten hat, kann die Device Liste voll sein, obwohl dann ein Code 500 kommen würde und kein Code 404
Ich tippe in diesem Fall aber auf a.) und es wurde sich nicht ans HowTo gehalten und kein [definition='1','3']Debug[/definition].[definition='1','0']log[/definition] erstellt.
Ich habe mal eine Anleitung von @vdr.tuxnet gelesen wie man dies überprüft.
Hab gesucht aber leider nicht gefunden, vielleicht postet er es ja nochmals...
Hmm, ich habe keine Ahnung mehr wo ich dieses mal gepostet habe, im alten Chrome Browser konnte man die Version
über den Link chrome://plugins/ abfragen, im aktuellen Chrome gibt es den nicht mehr, benutzt man also die libwidevine diesem Chrome,
laufen die Livestreams nicht, aber auf alle Fälle bringt Chrome 55.0.2883.75 die richtige libwidevine, für Linux x68_64, Win/32 und OSX/64, mit,
für armV7(32 Bit), RPI 2/3, Odroid_C2, Wetek (Hub und WP2) und s905 Devices, benötigt man nur das Script.
So ist es aber auch im HowTo beschrieben, folgt man dem, treten die Fehler nicht auf.
Was muss ich hier machen?
Genau wie es da steht:
Bei einer ARM Plattform,
ARCH=arm ./getwidevine.sh
Bei einer x86_64 Plattform,
ARCH=x86_64 ./getwidevine.sh
30 ISt rum und es läuft noch
a) die haben es Zeitlich noch nichtgeschaft.
b)Oder sie nutzen es nur nicht mehr schalten es aber nicht ab
Ich tippe auf c) ... HLS wird in den nächsten Tagen abgeschaltet. Denn wieso sollte Zattoo Streams bereitstellen, die in keiner App mehr genutzt werden.
Ich gehe da mal von D.) aus,
Zattoo ist ja auch noch B2B Provider im Bereich Back-/Headend für OTT/IPTV, Second Screen wie M-net, EWE Tel., NetCologne und noch viele mehr, da wird es wohl noch ein paar Provider geben,
die ihre Player noch umstellen werden, jedenfalls nutzt keine, mir zugängliche, native Zattoo-Plattform mehr die HLS Streams.
...oder es ist gar keine Abschaltung von HLS beabsichtigt weil es dafür keinen technischen Grund gibt.
Technische Gründe werden es auch nicht sein, Bitmovin würde gerne jede Technik verkaufen die sie anbieten.
HTML5 Streaming bietet eben für die Content Mafia extreme Vorteile und die Rechteinhaber bestimmen was, wie gesendet/gestreamt wird,
da wird Zattoo zu gut wie keinen Einfluss haben.
In diesen Branchen gibt es Erfüllungsfristen, werden diese nicht eingehalten verschwindet schon mal der eine oder andere Sender von heute auf morgen, natürlich
habe ich keine Ahnung wie und ob die Fristen, in diesem Fall, gesetzt sind.
Auch betriebswirtschaftlich wäre es unsinnig, für Zattoo, an unnötigen/ungenutzten Technologien festzuhalten.
Aber solange es die HLS Streams noch gibt, muss man sich darüber nicht die Köpfe zerbrechen.
Dafür gibt es ja jetzt inputstream.adaptive, was gleichzeitig mpd und smoothstream handeln kann.
Adaptive kann zur Zeit dafür nicht verwendet werden, adaptive benötigt fileItem properties, diese
können für PVR Services noch nicht gesetzt werden, das kommt erst in den nächsten Monaten.
Ich tippe mal diese Info wurde schon in den letzten Tagen hier einmal gegeben.
Vielleicht könntest Du etwas hier anpassen?
Was soll ich dort anpassen, wvstream ist eine, recht alte Vorstufe.
Es ist aber gut möglich, dass einige Addons nicht mehr mit inputstream.mpd zusammen arbeiten, bei inputstream,mpd
ist die Entwicklung aber auch, seit 12/2016 zu ende, da kommt von Entwicklerseite nichts mehr.
Da musst du halt abwägen was dir wichtiger ist und wenn Agile in Master gemerged wird sind auch einige Änderungen
an pvr.zattoo nötig, deshalb wäre es wohl sinnvoller zattoo.dash gegen LE 8 und nicht gegen LE9 zu bauen, bei
LE8 - Krypton wird es keine API Änderungen mehr geben.
Das hat den Grund weil einige dann die Kodinerds binary repo für Odroid C2
Das Repo gibt es aber nicht mehr, da gab es ca.5 Downloads in 6 Monaten, dafür lohnte der Aufwand nicht.
Somit scheint der direkte Aufruf nicht möglich zu sein
Ich meine dies war schon vor einiger zeit geklärt worden, man kann der Amazon Prime Video AndroidTV App keine URLs übergeben,
schau mal nach, ich habe jetzt keine Ahnung mehr wer es genau gepostet hatte.
Versionskriege könnte man leicht umgehen wenn Kodi ein paar mehr Platformtags mitbringen würde, dann würden sich manche Probleme gar nicht stellen.
OSX hat drei davon
Linux, finde ich etwas weit gestreut.
Ist das nicht ein bisschen kontraproduktiv? Vor allem für Anwender welche sich damit nicht so beschäftigen und nur
auf aktualisieren drücken, weil ihnen eben eine aktualisierung angeboten wird?Wenn es wichtig sein könnte dass man explizit das Kodi Nerd Repo adaptive nehmen muss, dann muss beim aktualisieren dann auch
gewährleistet sein, dass man automatisch das Kodi Nerd Repo adaptive bekommt und nicht das Libreelec, oder?
Ich kann die Angelegenheit nur nach Kodi Nerds Way anbieten, der deckt die komplette Bandbreite an Plattformen ab, und ist auf
allen angebotenen Plattformen auch problemlos anzuwenden, wenn Distributionen ihre eigenen Weg beschreiten, was ja unter Linux
nicht ungewöhnlich ist, muss man die wohl aussperren, damit alles sauber weiter läuft, auf jede Distributions-spezifize Eigenart kann
ich nicht reagieren, das würde komplett den Rahmen sprengen.
Aber eventuell ist es auch an der Zeit die Bin Repos einzustellen, da Kodi 17.1 ja stable ist, normal sollten die Distributionen die nötigen libs
auch zur Verfügung stellen können.
Im libdev Repo auf Github gibt es nur die 1.0.8, LE versioniert aber noch eine Ebene tiefer auf 1.0.8.0 obwohl es die gar nicht gibt.
Deshalb liegt im Kodinerds Repo eine
<addon id="inputstream.adaptive" version="1.0.8.1" name="InputStream Adaptive" provider-name="peak3d">
die aber auch nur eine 1.0.8 ist, normal sollte diese dann genommen werden.
Das inputstream in LE hat die decrypter lib doch an der selben Stelle.
Hm komisch, ich hatte am Wochenende zwei Anfragen in der Pm Box, die hatten keinen lib Ordner in ~/.kodi/addons/inputstream.adaptive,
hat Milhouse den dann an anderer Stelle liegen ? Können auch seine Images gewesen sein, da habe ich nicht drauf geachtet.
Jedenfalls gibt es mit der 1.0.8 keine Probleme, dann muss es bei den Leuten noch an anderer Stelle ein Fehler sein, wenn es nicht der lib Ordner ist.
Was mich aber mehr interessiert: was ist denn mit der Version 1.0.8 inputstream.adaptive?
Da gibt es keine Probleme mit, ich tippe mal die Leute updaten nicht aus dem Kodi Nerds Bin Repo, sondern benutzen beim update, adaptive aus dem Libreelec .tar, da
ist dann natürlich der Decrypter nicht im lib Ordner und die symlinks laufen ins leere.
Aber man bekommt ja auch keine [definition='1','3']Debug[/definition].logs mehr, deshalb ist es alles nur Mutmaßung.
Wenn ich meinen Rasp3 neu installieren muss und dadurch auch das Plugin etc., wird dann wieder ein neues Gerät bei Sky registriert?
Du brauchst den RPI 2/3 normal nie neu installieren, bei Benutzung von Libreelc und einem Update via xxx.tar wird
dein Homeverzeichnis, nicht angetastet und dieses reicht völlig aus um Libreelec auf den neusten Stand zu bringen,
da du ja normal keine Schreibrechte auf die System Partition hast.
Bei einer Neuinstallation via xxx.img.gz löschst du ja alle Partitionen auf deiner SD Karte, auch deine Homepartition,
dann wird ein neues Gerät angelegt, also immer via xxx.tar updaten, inkompatible Addons deaktiviert Kodi automatisch,
damit sie den normalen Betrieb nicht stören.
Gibt es eine möglichkeit das Plugin auch unter Android (NVIDIA Shield TV) zu nutzen?
Auf dieser Plattform ist eine andere Vorgehensweise nötig, auch bereitet die Shield, aufgrund der AndroidTV Lizenz noch ein paar Probleme,
mal sehen was sich da noch ergibt.
Sollte man das autom. Update aktivieren? Laut diesem Post gab es ein Problem mit libwidevinecdm.so.
Automatische Updates kannst du aktivieren, da du die betreffende Lib, aus Urheberrechtsgründen dir selbst besorgen musst, die werden wir nie anbieten.
repository.kodinerds_RPi2-1.0.3
Ist das Binary Repo für den RPI 2/3, du brauchst das Kodi Nerds Addon Repo
Ein Binary Repo bringt dir die Plattform betreffenden Addons die nur für diese Plattform bestimmt sind, in diesem Fall für RPI 2/3,
das Kodinerds Addon Repo bringt dir die Plattform übergreifenden Addons mit allen Abhängigkeiten, die nicht nur für eine Plattform bestimmt sind.
Siehe Inputstream HowTo
Ist damit das repository.kodinerds_RPi2-1.0.3 gemeint?
das würde mich auch interessieren. Habe auch einen c2 und bin gerade auf diesen artikel hier gestoßen.
Von Kodinerds brauchst du nur das Addon Repo, @Raybuntu stellt die Binary Addon's, inputstream.xxxxx usw.,selbst zur Verfügung.
