Archiv für den Monat: Mai 2018

Amazon Prime Video und Netflix auf dem Raspberry Pi

Um einem nicht so smarten TV ein wenig Grips einzutreiben, bietet sich ein kostengünstiger Raspberry Pi mit dem Media Center KODI an. Es empfiehlt sich aus Performance-Gründen ein Raspberry Pi 3.

Es sind allerdings ein paar Sachen zu beachten, wenn man auch Netflix und Amazon Prime Video schauen will, weswegen ich hier einmal zusammentragen will, was ich dafür konfigurieren musste.

KODI, LibreELEC und NOOBS

Zunächst einmal ist zu beachten, dass die für Amazon und Netflix nötigen Add-Ons nur mit der neuesten Version 18 von KODI laufen und die aber nicht auf dem „normalen“ Raspbian-Betriebssystem. Es ist daher angezeigt, LibreELEC zu installieren. Mit dieser Linux-Distribution kann man nicht viel anderes machen als KODI laufen zu lassen, das aber dafür gut. LibreELEC kann zunächst wie die meisten anderen Raspi-Betriebssysteme ganz bequem über NOOBS installiert werden.

„Milhouse 9.0“-Builds

Für die Amazon- und Netflix-Plugins braucht man die neueste Version. Hierzu geht man nach dem ersten Hochfahren von KODI aus auf die LibreELEC-Einstellungen und stellt unter „System“ die Aktualisierungen auf manual und bei den benutzerdefinierten Kanälen die URL http://milhouse.libreelec.tv/builds/master/RPi2 ein (auch wenn man einen Raspi 3 hat). Unter Update-Kanal stellt man dann auf „Milhouse 9.0“ und wählt dann unter „Verfügbare Versionen“ einen der aktuellen Nightly-Builds aus.

Achtung, diese sind nicht immer so stabil! Versionen vom Mai liefen bei mir nicht so gut, jetzt habe ich mich mehr oder weniger willkürlich für die Version 0421 vom 21. April entschieden und damit läuft es gut.

Amazon Prime Video

KODI ist nur nicht viel ohne Add-Ons. Viele gute offizielle Add-Ons findet man im gewöhnlichen Repository, nicht so die Netflix- und Amazon-Plugins. Dazu installiert man zuerst aus dem normalen Repository ein neues Repository, nämlich „Kodinerds“. Das findet man unter All Repositories ➜ Add On Repositories ➜ Kodinerds Add-ons und vom Kodinerds Repository installiert man dann wieder zwei andere Repositories, nämlich erst mal „Sandmann79s Repository“ für die Amazon-Add-Ons und das „Netflix“-Repository für das Netflix-Add-On (siehe zu Netflix unten).

Bei den angebotenen Amazon-Add-Ons scheint das internationale „Amazon VOD“ besser zu funktioniert als das andere, das nur für Deutschland gedacht ist. Letzteres lädt die Playlisten des eigenen Accounts in eine lokale Datenbank, was aber unnötig lange dauert.

Für die Wiedergabe von DRM-geschützten Material, die es von Amazon oder Netflix kommt, braucht man die „Widevine“-Libraries. Das Amazon-Plugin installiert die automatisch, das dauert aber etwas.

In den Einstellungen des Add-Ons sollte man noch bei der Wiedergabemethode „Input Stream“ einstellen. Ein gültiger Prime-Account ist natürlich Pflicht, die Zugangsdaten gibt man auch in den Einstellungen des Add-Ons ein.

Netflix

Bei Netflix hat bei mir die Installation aus dem Repository nicht funktioniert, daher habe ich die aktuelle Version des Netflix-Add-Ons von Github heruntergeladen („Clone or download“ auswählen und als ZIP runterladen, siehe Anleitung) und in KODI über „Installation aus ZIP“ installiert. Damit das funktioniert, muss man evtl. in KODI noch die Installation von Add-Ons aus Fremdquellen explizit zulassen. Über die Samba-Dateifreigabe von KODI/LibreELEC findet das ZIP-File den Weg auf die SD-Karte des Raspi. Auch für Netflix ist selbstverständlich ein gültiger Login erforderlich.

Podcasts

Zu beachten ist noch, dass die Version des beliebten „Apple iTunes Podcasts“-Add-On (das keinen iTunes-Account braucht, sondern nur so heißt, weil es die Liste der Podcasts von Apple zieht) aus dem KODI-Repository nicht mit dieser Konfiguration läuft. Im KODI-Forum wird erklärt, wie man das Add-On trotzdem zum Laufen bekommt.

Alternativ kann man aber seine Podcasts auch anders über KODI abspielen. Man trägt dazu die URL des RSS-Feeds seines Podcasts über Musik- bzw. Video (je nachdem, ob es ein Audio- oder Video-Podcast ist) als Quelle ein, allerdings nicht beginnend mit „http://“, sondern mit „rss://“.

Nutch und Solr einrichten

Wer selber Suchmaschinenbetreiber werden und dem Großen G Konkurrenz machen will, kann das mit dem Webcrawler Nutch und dem Suchserver Solr tun. Leider ist das Tutorial von Nutch nicht ganz so deutlich, enthält ein paar unnötig komplizierte Sachen und zudem in einer nicht ganz logischen Reihenfolge.

Das hier gezeigte Vorgehen wurde mit Ubuntu 16.04 getestet, sollte aber genau so mit anderen Linuxen oder macOS funktionieren.

Unter Windows laufen die Nutch-Skripte nicht. Da das eigentliche Nutch selbst aber genau wie Solr in Java implementiert ist, ließe sich das mit Cygwin lösen. Die Frage ist nur, ob man das auch will…

Für die Beispiele wird davon ausgegangen, dass sich Nutch im Verzeichnis „apache-nutch-1.14“ und Solr im Verzeichnis „solr-6.6.3“ jeweils direkt unterhalb des Home-Verzeichnisses befinden.

Wer möchte, kann das Nutch-Tutorial parallel öffnen. Ich orientiere mich hier am Stand des Tutorials vom Mai 2018 und weise jeweils auf Stellen im Tutorial hin.

1. Voraussetzungen: Java und Solr

Siehe Abschnitt Requirements im Tutorial.

Nutch 1.14 setzt Java voraus. Von mir wurde Nutch mit Java 1.8 getestet.

Ant ist nicht nötig, wenn Nutch als Binary geladen und nicht selbst kompiliert werden soll.

Damit Nutch die gecrawlten Webseiten direkt zum Indexieren an Solr weiterreichen kann, muss die passende Solr-Version laufen. Nutch 1.14 läuft mit Solr 6.6

Die Installation von Solr ist denkbar einfach, es ist lediglich ein Archiv herunterzuladen und zu entpacken.

(Im Tutorial wird Solr erst später erwähnt, es ist meiner Ansicht nach aber empfehlenswert, schon an dieser Stelle Solr zum Laufen zu bringen und zu testen.)

2. Nutch herunterladen

Siehe Option 1 im Abschnitt Install Nutch im Tutorial.

Die Installation von Nutch läuft erst mal fast genau so: Downloaden von http://nutch.apache.org/ und in ein Verzeichnis nach Wahl entpacken.

Siehe nun Verify your Nutch installation im Tutorial.

Aus dem Nutch-Verzeichnis heraus sollte jetzt ein „bin/nutch“ schon funktionieren und Nutch sollte zumindest mal ein Lebenszeichen von sich geben.

Wenn Nutch wie oben angegeben ins Verzeichnis „apache-nutch-1.14“ entpackt wurde, sind folgende Befehle einzugeben:

cd apache-nutch-1.14/
bin/nutch

Es sollte eine Meldung erscheinen, die die möglichen Nutch-Kommandos auflistet.

Achtung: An der /etc/hosts herumzufummeln, wie es im Tutorial steht, sollte im allgemeinen nicht notwendig sein!

3. JAVA_HOME setzen

Wir sind immer noch bei Verify your Nutch installation im Tutorial.

Möglicherweise ist die Umgebungsvariable JAVA_HOME nicht gesetzt. Ob das so ist, erfährt man durch Eingabe von

echo $JAVA_HOME

Wenn nichts ausgegeben wird, war JAVA_HOME nicht gesetzt. Dann ist unter Ubuntu (oder Debian) folgendes zu tun:

export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")

Damit beim nächsten Neustart des Terminals die JAVA_HOME gleich gesetzt ist, empfiehlt es sich, diese Zeile ans Ende der .bashrc im Home-Verzeichnis anzufügen:

cd

echo 'export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")' >> .bashrc

Unter macOS setzt man die JAVA_HOME wie folgt auf den korrekten Wert (Achtung, die Angabe im Nutch-Tutorial stimmt für neuere macOS-Versionen nicht!):

export JAVA_HOME=$(/usr/libexec/java_home)

Bei macOS würde man die JAVA_HOME wohl eher in der .profile setzen:

cd

echo 'export JAVA_HOME=$(/usr/libexec/java_home)' >> .profile

4. Crawler-Properties

Wir sind im Tutorial nun bei Customize your crawl properties.

Der Crawler meldet sich bei den Web-Server, die gecrawlt werden, mit seinem Namen. Es ist aber standardmäßig nichts voreingestellt. Ohne dass wir hier etwas konfigurieren, verweigert Nutch seinen Dienst.

In die Datei apache-nutch-1.14/conf/nutch-site.xml muss folgendes rein (der fette Teil ist neu):

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
<property>
<name>http.agent.name</name>
<value>Der Test Nutch Spider</value>
</property>
</configuration>

Statt „Der Test Nutch Spider“ sollte man natürlich selber irgendeinen Namen wählen.

5. Solr konfigurieren

Wir überspringen einiges im Tutorial und gehen nun direkt zu Setup Solr for search.

Im Tutorial wird als zu Nutch 1.14 zugehörig die Version Solr 6.6.0 angegeben. Im Test funktionierte es aber auch mit 6.6.3. Mit Solr 7 dagegen könnte es Probleme geben.

Die von Nutch gecrawlten Webseiten sollen in einen eigenen Solr-Core. Zum Setup des Schemas für diesen Core nehmen wir die Standard-Beispielkonfiguration von Solr und kombinieren sie mit einer schema.xml, die von Nutch geliefert wird.

Die Schritte im einzelnen:

1. Das Configset basic_configs kopieren und neu nutch nennen.

Update!

Das Configset heißt a Solr 7 „_default“ und nicht mehr „basic_configs“. Wenn Ihr bei den Befehlen unten das entsprechend ersetzt, funktioniert die Anleitung auch noch mit Nutch 1.16 und Solr 7.

2. Die managed_schema im Configset nutch löschen.

3. Die schema.xml von Nutch ins neue Configset nutch kopieren.

Noch ein Update!

Im Nutch-Tutorial ist im Abschnitt „Setup Solr for search“ eine alternative schema.xml verlinkt, am besten die „most recent schema.xml“ verwenden und die im Configset „nutch“ ersetzen.

4. Solr starten

5. Einen neuen Core unter Verwendung des soeben erstellen Configsets einrichten.

Die Befehle dazu:

cd
cd solr-6.6.3/
cd server/solr/configsets/

cp -r basic_configs nutch

cd nutch/conf

rm managed-schema

cd

cp apache-nutch-1.14/conf/schema.xml solr-6.6.3/server/solr/configsets/nutch/conf/

cd solr-6.6.3/

bin/solr start

bin/solr create -c nutch -d server/solr/configsets/nutch/conf/

6. Nutch klar machen zum Crawlen

Wir springen nun im Tutorial zurück zu „Create a URL seed list„.

Wenn man das Web crawlen will, muss man irgendwo anfangen. Diese Startseiten kommen in die Seed List.

Den Teil des Tutorials, wie man an eine schöne Seed List kommt, in dem man z.B. eine Liste von Webseiten von dmoz herunterlädt, ignorieren wir hier mal, wir machen das von Hand und setzen unsere Lieblingswebseite als Startpunkt.

Die Schritte im einzelnen:

1. Unterhalb von apache-nutch-1.14 ein Verzeichnis urls anlegen

2. Darin eine Datei seed.txt anlegen und da drin einfach eine Liste von URLs eintragen.

Konkret:

cd

cd apache-nutch-1.14/

mkdir urls

cd urls

echo 'http://hs-furtwangen.de/' > seed.txt

Jedenfalls sollte man das so machen, wenn die Webseite der Hochschule Furtwangen die Lieblingswebseite ist.

Den Regex-URL-Filter (siehe Tutorial) lassen wir so er ist. Wir müssten den ändern, wenn wir z.B. nur die Unterseiten einer Homepage crawlen und indexieren wollen, ohne externe Links zu verfolgen.

Den ganzen Abschnitt „Using Individual Commands“ überspringen wir mal getrost. Die Befehle, die dort stehen, sind zwar schön, wenn man mal sehen will, was im einzelnen passiert, aber zu kompliziert.

7. Crawl starten!

Wir gehen im Tutorial direkt zu Using the crawl script.

Den Aufruf des Crawl-Skripts ist im Tutorial erklärt, aber wir können selber das Skript von einem eigenen Skript aus starten, das direkt schon die gewünschten Parameter enthält. 🙂

Ich gehe hier davon aus, dass, wie hier im Beispiel, der Solr-Server auf dem selben Rechner läuft, der Core nutch heißt und die Seed-Liste dort liegt, wo wir sie in Schritt 4 gerade angelegt haben. Außerdem sind hier jetzt mal 50 Iterationen eingestellt. Das ist viel! Man kann den Crawl-Vorgang aber ruhig zwischendurch abbrechen.

cd

cd apache-nutch-1.14/

echo 'bin/crawl -i -D solr.server.url=http://localhost:8983/solr/nutch -s urls crawl 50' >> crawl.sh

chmod +x crawl.sh

./crawl.sh

8. Die Ergebnisse begutachten

Schon während der Crawl läuft, können wir in der Admin-Oberfläche von Solr den Index abfragen. Spätestens jetzt empfiehlt es sich, sich mit dem Schema des neuen Cores vertraut zu machen, um anschließend ein schönes Frontend programmieren zu können.

Viel Spaß!