Beiträge von eminga

Im aktuellen OSMC-Testbuild ist das offizielle Kodi-Repo broken, deshalb können die Abhängigkeiten nicht installiert werden. Soll wohl im nächsten Testbuild gefixt werden. Wenn du nicht solange warten willst, kannst du die Abhängigkeiten von Hand installieren. Deinem Log entnehme ich, dass script.module.pyxbmct fehlt, das kannst du hier herunterladen, installieren und es dann nochmal probieren: http://mirrors.kodi.tv/addons/krypton/script.module.pyxbmct/

Wenn wieder eine Abhängigkeit nicht erfüllt ist, auch diese von Hand installieren und das ganze solange fortsetzen bis alle Abhängkeiten erfüllt sind. Die Addons findest du hier: http://mirrors.kodi.tv/addons/krypton/

@bugmenot2014 hat einen funtionierenden HLS-Stream verlinkt. Den einfach in eine m3u-Playlist einfügen (im Live-TV-Forum gibt's einige Beispiele wie die m3u aussehen muss) und mit dem IPTV-Simple-Addon abspielen.

Noch einfachere aber unelegante Lösung: Eine Textdatei anlegen, in der die URL steht und mit Dateiendung .strm abspeichern. Dann einfach in Kodi die Datei auswählen.

Mir ging es nur um den Fall, dass der VPN-Client des Routers selbst benutzt wird. Wenn ich richtig informiert bin, unterstützt die Fritz!Box allerdings nur reines IPSec.

Wenn der VPN-Client auf einem Gerät in deinem LAN läuft, beispielsweise wie im Eingangspost auf einem Raspi, kann ein Router prinzipiell nichts weiter machen als die Pakete weiterzuleiten.
Kurze (vereinfachte) Erläuterung warum: Nehmen wir den SSH-Client auf deinem Raspi als Beispiel. Der kann unter Nutzung von TCP auf Port 22 erreicht werden. Das heißt, wer eine SSH-Verbindung aufbaut, schickt TCP-Pakete mit Zielport 22 und erhält TCP-Pakete mit Quellport 22. TCP-Pakete alleine bringen noch nicht viel, damit es auch beim gewünschten Host ankommt, braucht es noch IP-Pakete. In denen stehen die IP-Adressen von Sender und Empfänger (und noch ein paar andere Sachen) und das TCP-Paket wird als "Payload" hinten dran gehängt.
Das ganze funktioniert dann innerhalb des Heimnetzes ganz wunderbar, ist von außerhalb aber nicht erreichbar, da der Raspi eine private IP-Adresse hat. Wollte man das ganze von außerhalb erreichbar machen, müsste man im Router "Port Forwarding" konfigurieren. Dann könnte man von außen den Router kontaktieren, der schaut dann in das TCP-Paket hinein und sieht Zielport 22, ändert die Ziel-IP-Adresse auf die private IP-Adresse des Raspis und leitet das Paket weiter.
Läuft auf dem Raspi ein VPN-Client gibt es einen bedeutenden Unterschied: Die Pakete, die zwischen VPN-Client und VPN-Server ausgetauscht werden sind verschlüsselt. Verschickt der Raspi ein Paket über das Interface, das der VPN-Client angelegt hat, landen die Pakete erst mal beim VPN-Client. Der nimmt dann das ganze IP-Paket, verschlüsselt es und packt es in ein neues IP-Paket mit Ziel-Adresse VPN-Server. Dieses neue IP-Paket wird dann über das physische Interface gesendet. Sobald es beim VPN-Server angekommen ist, entschlüsselt er das eigentliche IP-Paket und versendet es an die Ziel-IP-Adresse. Analog in der Gegenrichtung.
Dein Heimrouter bekommt bei der ganzen Geschichte nur die IP-Pakete mit verschlüsselter Payload zu sehen. Er erkennt am Protokoll-Feld des IP-Headers, dass es sich beispielsweise um IPSec-Pakete handelt, die zu einer VPN-Verbindung gehören, und leitet eingehende Pakete an deinen Raspi weiter. Dort kommt das Paket am physischen Interface an, der VPN-Client entschlüsselt das eigentliche IP-Paket und gibt es über das neue virtuelle Interface aus. Erst hier ist also der Inhalt des IP-Pakets erkennbar und wenn es sich um ein TCP-Paket mit Zielport 22 handelt und iptables es nicht filtert, landet es eben beim SSH-Server.

Der Heimrouter hat also keine Chance unerwünschte Pakete zu filtern! Er kennt schlicht den Inhalt nicht.

Auch wenn man vom VPN-Anbieter eine private IP-Adresse zugeteilt bekommt, ist man übrigens nicht viel sicherer unterwegs. Klar, es kann einem nicht jeder Internetnutzer Pakete schicken. Andere Kunden desselben VPN-Anbieters womöglich aber schon und auf jeden Fall der VPN-Anbieter selbst. Und um wieder auf das Beispiel aus dem Eingangspost zurückzukommen: Niemand kann wollen, dass der VPN-Anbieter die Möglichkeit hat, root-Zugriff auf sein Gerät zu erhalten. Und genau das ist der Fall, wenn man einen VPN-Client auf einem Raspberry Pi mit OpenELEC/LibreELEC und aktiviertem SSH-Server (mit Default-Logindaten) ohne angepasste iptables-Regeln am laufen hat.

Deshalb gilt: Ein Gerät auf dem ein VPN-Client läuft, ist IMMER so zu behandeln als wäre es direkt mit dem Internet verbunden und entsprechend abzusichern.

Noch kurz zu den iptables-Regeln (ohne einer ausführlicheren Antwort von @Tuxino zu sehr vorgreifen zu wollen): Diese Regeln bewirken, dass am VPN-Interface ankommende Pakete grundsätzlich verworfen werden. Ausgenommen davon sind nur Pakete, die zu einer bestehenden Verbindung gehören.
Beispiel: Will jemand eine Verbindung zu deinem SSH-Server aufbauen, wird das Paket verworfen.
Baust du selbst eine Verbindung auf, beispielsweise indem du eine Internetseite aufrufst, wird das Antwortpaket nicht verworfen, da es zu einer bestehenden Verbindung gehört.
Wohlgemerkt gilt das ganze nur für das VPN-Interface, Pakete die an einem anderen (physischen) Interface ankommen, sind davon nicht betroffen, es ist also weiterhin möglich den SSH-Server über das Heimnetz zu erreichen.

Zitat von PVR-Fucker

Wenn du das denkst ist dir noch nicht ganz klar was der vpn auf dem router bewirkt

Na dann warte ich gespannt auf deine Ausführungen wie ein fieser Junge ganz einfach meinen Router kapern kann, wenn er die IP-Adresse kennt, die mir mein VPN-Anbieter zugewiesen hat.

Und wie @MaxRink schon sagt, behandeln "Consumer"-Router (Fritz!Box und Konsorten) solche VPN-Verbindungen in der Regel einfach wie ein WAN-Interface. Dass man sich beispielsweise mit einem Cisco-Router oder einem Router auf dem OpenWRT läuft selbst drum kümmern muss, das sicher zu konfigurieren (v.a. zum Schutz vor dem VPN-Anbieter, egal ob man nun eine private oder öffentliche IPv4-Adresse bekommt), ist hoffentlich jedem klar, der damit arbeitet.

Ein Router ist normalerweise eh schon direkt mit dem Internet verbunden und entsprechend abgesichert. Die Anzahl der Router auf denen ein SSH-Server läuft und der Admin-Account mit (unveränderlichen) Standardzugangsdaten zugänglich ist, hält sich hoffentlich in Grenzen.
Ich sehe nicht, wieso der VPN da plötzlich "Tür und Tor für die ganz fiesen Jungs" öffnen sollte.

Hier eine PHP-Funktion, die die URL zur m3u8 zurückgibt:

function eurosport($email = 'your@email.address', $password = 'yourpw') {
	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, 'http://www.eurosport.de/_wscommunityV8_/Community_V8.svc/LoginEurosport');
	curl_setopt($ch, CURLOPT_POST, 1);
	curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json'));
	curl_setopt($ch, CURLOPT_POSTFIELDS, '{"email":"'.$email.'","password":"'.$password.'","languageId":"1","siteId":"6"}');
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ch, CURLOPT_COOKIEJAR, '/dev/null');
	curl_exec($ch);
	curl_setopt($ch, CURLOPT_URL, 'http://www.eurosport.de/watch-eurosport-live.shtml');
	curl_setopt($ch, CURLOPT_HTTPGET, 1);
	curl_setopt($ch, CURLOPT_HTTPHEADER, array());
	$data = curl_exec($ch);
	curl_close($ch);
	preg_match_all('/(https?:\/\/[^\'\"]*\.m3u8[^\'\"]*)[\'\"]/', $data, $matches, PREG_PATTERN_ORDER);
	return $matches[1][0];
}

Allerdings scheint Kodi nicht wirklich mit dem Stream zurechtzukommen. Mit Kodi 16 startet er erst gar nicht und mit Kodi 17 ist nur das Video zu sehen, der Ton fehlt. Keine Ahnung ob man da von Seiten des Addons was machen könnte oder ob dazu tiefere Änderungen in Kodi notwendig wären.

EDIT: Das Tonproblem wurde in Nightly 20161026 gefixt. Damit funktioniert der Eurosport-Stream in aktuellen Nightlies und ab der kommenden Beta 5.

Zitat von LuxSide

Das ist der richtige Link für RTL2YOU

Mal schauen, ob du um 15:30 Uhr auch noch dieser Meinung bist

Ah, dann neue Spekulation: die alte Version des Addons greift die Streams von der SkyGo-Startseite ab, die neue von der EPG-Seite^^

Bin selbst auch noch auf der alten Version, glücklicherweise interessiert mich das Schalke-Spiel auch nicht. Dann würde ich dir mal zu einem Update raten, @amaterasu

Bei mir funktioniert Buli 2 im Kodi-Addon im Moment auch nicht.
Spekulation ins Blaue: Das Addon greift die Links zu den Streams von skygo.sky.de ab und da Sky hier scheinbar den Link zu Buli 2 vergessen hat, funktioniert der Sender nicht.

EDIT: Wobei, hier ist Buli 2 samt Schalke-Spiel korrekt aufgeführt: http://www.skygo.sky.de/guide/epg/defaultsection/165.html

Auf dem Sender wird gerade nichts gesendet: http://www.skygo.sky.de/#panel-3

In Kodi 16.1 mit Confluence-Skin, "Settings level" mindestens Advanced:
System->Settings->System->"Internet Access"->"Internet connection bandwidth limitation" auf gewünschten Wert einstellen. Dann wird i.d.R. der Stream mit der höchsten Bitrate, die noch unter dem Schwellenwert liegt, ausgewählt.

Alternativ direkt in der m3u:
Mit dem "b"-Parameter lassen sich die Bitrates der verfügbaren Streams eingrenzen. Angenommen man möchte nur Streams bis zu einer Bitrate von 2000 kbit/s ausgeliefert bekommen, dann wird aus
http://abc.xyz/123.m3u8 => http://abc.xyz/123.m3u8?b=0-2000
oder falls schon Parameter an der m3u8 angehängt sind
http://abc.xyz/123.m3u8?xx=1 => http://abc.xyz/123.m3u8?xx=1&b=0-2000

Wenn du mit noip nicht zurecht kommst, kannst du es mal mit duckdns.org probieren. Das ist zuverlässig und einfach zu nutzen. Eine Anleitung für einen Technicolor-Router gibt es auch, gut möglich, dass die auch mit deinem Modell funktioniert: https://www.duckdns.org/install.jsp

Ich kann das Problem mit den Youtube-Livestreams (HLS) bestätigen (auch wenn ich zum Aufruf der Livestreams meistens nicht das Youtube-Addon sondern den IPTV Simple Client in Verbindung mit einen PHP-Skript verwende).

Mit Kodi 16 und SPMC funktionieren sie tadellos, mit Kodi 17 unter Linux und Android dauert es erst mal ewig bis der Stream lädt und nach ein paar Sekunden stoppt er auch schon wieder.

Danke für den Hinweis! Ich hab den Punkt zur Anleitung hinzugefügt.
Ich hatte davor schon ein paar andere Pakete installiert, da wurde xz-utils wohl als Abhängigkeit mitinstalliert.

@membrane Der EPG, den du ins Addon gepackt hast umfasst nur heute und morgen. Du müsstest dein Addon also spätestens übermorgen nochmal updaten.
Ich hab das Skript auf meinem VPS grade umgestellt, sodass ab jetzt der komplette EPG ausgeliefert wird. Dank gzip ist die Datei eh grade mal ~50% größer.
Sorry für die Umstände!

Oder du verwendest eine Bluetooth-Fernbedienung, beispielsweise die deines FireTV Sticks.

Der EPG, der im Addon mitgeliefert wird wurde am 06.08. generiert, seitdem haben sich einige EPG-Einträge geändert.
Eine Alternative ist der stündlich aktualisierte EPG, dessen Link in der Datei url.txt steht: Olympia 2016 im Livestream

Was übrigens auch möglich ist, ist direkt eine URL zum Logo in der m3u anzugeben. Wer Wert darauf legt, kann sich z.B. in der Google-Bildersuche ein Olympialogo suchen, das ihm/ihr gefällt (idealerweise im png-Format und nicht zu groß) und in der m3u jeweils tvg-logo="olympia.png" durch tvg-logo="http://abc.de/xyz.png" ersetzen.

Generell ja, man kann nur eine Playlist angeben. Von @vdr.tuxnet gibt es allerdings ein Addon, das mehrere Playlists unterstützt: [Kodi 17] pvr.iptvsimple - Multiple Playlists <- Update 09.07

Zitat von membrane

Bist du auf Github? Wenn mein Account wieder geht kannst du gerne das EPG als Pull Request übermitteln.

Nein, aber ich habe gerade nen Cronjob auf meinem VPS eingerichtet, der den EPG regelmäßig aktualisiert. Der Link zum generierten EPG steht in der url.txt des Startposts.
Wenn du möchtest, kannst du den gerne verwenden.