Beiträge von _Manfred_

Zum Thema VPN: Ich bin weg von dem Paradigma, dass ein Gerät alle Funktionen zur Verfügung stellt. Mit 'nem Banana PI und IPFire lässt sich relativ einfach ein stabiles VPN-Netzwerk errichten.
Hab früher den Zugriff auf meine E-Mail-Server sowie dem Owncloud-Server über nur über VPN berechtigt. Mittlerweile bin ich auf SSL-Verschlüsselung umgestiegen.
Vorteil von den Diensten auf unterschiedlichen System ist halt die Kapselung. Eine Umstellung eines System zieht andere Dienste nicht in Mitleidenschaft.
Ach ja, ich nutze VPN jetzt nur mehr um Remote meine Serverfarm zu administrieren.

Hol dir von
https://forum.kodi.tv/showthread.php?tid=298461
eine aktuelle Nightly. Ich persönlich verwende die 707 und kopieren die Datei ins Verzeichnis /storage/.update. Unter kopieren verstehe ich eine SSH-Verbindung. Dann führe den Befehl
curl -Ls http://nmacleod.com/public/libreelec/getwidevine.sh | bash
auf der Konsole aus. Dann hol dir die aktuellen Addons.

Ähm...
Hast du eine aktuelle Nightly von Kodi 18 aus Milhouse-Testing verwendet?

Zitat von Hitman333

also nach meiner erfahrung geht sogar 720p

RPI2 übertaktet oder PI3 standard/übertaktet?

Ich bin zwar jetzt kein OMV-Anwender, jedoch möchte ich dir den InLine Schnittstellenkarte - 4x SATA 6Gb/s - mit 4x SATA - PCIe 2.0 (PCI-Express), 76617E empfehlen. Klar gibt es Schnittstellenkarten mit mehr Ports, jedoch ist diese ideal für Braswell und Apollo Lake. Die Karte benötigt nur einen PCI-Express x 1 Slot.
Die Karte wird mal sicher seit dem Kernel 3.2 unterstützt. Eingebunden werden die Geräte als ganz normale SATA-Devices (/dev/sd[x]).

Ich hab mir von
https://forum.kodi.tv/showthread.php?tid=298461
ein Milhouse nightly für den RPI_2 geholt
nach 'nem Neustart
curl -Ls http://nmacleod.com/public/libreelec/getwidevine.sh | bash
auf 'der Console ausgeführt und mir von
https://github.com/Sandmann79/xbmc
das Repository von Sandmann geladen und dann aus diesem Amazon VOD installiert.
Nach 'nem erneuten Restart dann noch das Add-On konfiguriert.

Die Neustarts waren wichtig, sonst hatte ich auch merkwürdige Fehler.

Stell dir mal die Auswirkungen vor, wenn das WOL-Protokoll routingfähig wäre...

Ja, die Konfiguration von OSCAM kann spannend werden. In den neueren Versionen sind aber viele mögliche Konfigurationen bereits enthalten.

Im Verzeichnis /usr/lib/kodi/addons/inputstream.adaptive liegt eine Datei: inputstream.adaptive.so.2.0.3. Auf diese Datei wird von den zwei symbolischen Links inputstream.adaptive.so.18.0 und inputstream.adaptive.so verlinkt. Eigentlich von der unversionierten auf die 18.0 und diese dann auf die 2.0.3.

Wenn der Quellcode der Library vorliegen würde, könnte da geschraubt werden. Widevine will ja grad den Sourcecode nicht freigeben.

Deine Annahme - gleiche Qualität/gleiche Auflösung - dürfte so nicht ganz vorliegen. Der Stream wird nicht unterschiedlich stark komprimiert, sondern der Detailgrad der Qualität ändert sich. Ob dies nun für's Auge erkennbar ist, sein dahin gestellt.
Wenn ein MPEG2-Stream in H264 transkodiert wird, macht es eher mal keinen sichtbaren Unterschied ob jetzt als CRF 24 oder 25 verwendet wird. Die Dateigröße ist jedoch unterschiedlich.

RPI_2: Alles über 3 MBps ist mit der Standardeinstellung nicht möglich. Dem Anschein nach entschlüsselt/dekodiert die Widevine-Bibliothek nur in einem Thread.

Ich werde mich wahrscheinlich um einen Odroid C2 umsehen, hat hier schon jemand Erfahrungen?
Dürfte auch dem freundlichen Anbieter marketingtechnisch nicht grad ungelegen kommen. Auf einen Schlag werden Millionen Abspielgeräte untauglich.

SMB dürfte mehr Overhead als NFS haben.
Vor Jahren konnte ich über WLAN und SMB Filme nicht ordentlich abspielen. Nach dem Umstieg auf NFS klappte dann das Abspielen ohne Ruckler.

@CvH fallst du ebenso unter dem Namen im TVHeadend Forum angemeldet bist. Ich finde es genial, dass du dich für den VAAPI-Support engagierst.
Ich bin im Moment nicht mehr so von den RPIs überzeugt. Widevine ist seit längeren nicht mehr nur für das Descramblen zuständig, sondern nun auch für's Decodieren. Beim RPI dürften mit Widevine gesicherte Full-HD Inhalte nicht mehr abspielbar sein.

Samba oder genauer das SMB Protokoll V1 ist in den heutigen Tagen so 'ne Sache. Mit dem Protokoll wurden viele Firmen für Tage lahm gelegt.

Für den Bereich der Daten verwende ich Owncloud. Abgesichert via SSL-Zertifikat wird ja der zugrunde liegende Webserver - in meinem Fall Apache. Bei den PCs wird ein vernünftiger Client angeboten, jedoch für die mobilen Clients ist bei mir FolderSyncPro im Einsatz. Der eigene Mobil-Client kann (so zumindest Stand Anfang letztes Jahr) nicht ohne erhebliche Verrenkungen den Ablageort auf eine SD-Karte wechseln. Ich synchronisiere mittels WEBDAV in der Nacht, zugelassen nur mit WLAN-Verbindung. Ein Umstieg auf Nextcloud ist aufgrund des Wechsel des Hauptentwicklers/Gründers und sein Open Source Gedanke geplant.
Im Bereich E-Mail, Kontakte, Kalender ist bei mir Communigate Pro im Einsatz. Ist der bessere und performantere Exchange Server. Communigate Pro ist bis zu fünf Benutzer frei von Lizenzkosten, kann aber nicht ohne weiteres mit einem AD umgehen. Dürfte im privaten Umfeld jedoch nicht das K.O.-Kriterium darstellen. Zur Synchronisiation mit mobilen Clients wird auf die Exchange-Funktionalität von Android zurückgegriffen. Bei LineageOS funktioniert auch die Kalenderfreigabe eines anderen Benutzers. Bei der Implementierung von Samsung klappt dies einfach nicht. Für Outlook wird eine Messaging-API ebenso kostenfrei angeboten.
Zarafa habe ich auch noch im Einsatz, aber nurmehr weil ein paar Clients nicht in meiner unmittelbaren Umgebung wohnen. Sonst hätte ich die längst umgestellt. Zarafa ist halt sehr sensibel und extrem langsam.
Aus Gründen der Systemabschottung verwende ich für Owncloud und Communigate Pro eigene Maschinen. Diese sind bei mir paravirtualisiert mit XEN. Ob nun die Systeme auf einem RPI lauffähig sind, kann ich nicht sagen. Ich benutze als Unterbau J4205 und J3700 Hardware.

Zitat von CvH

NAS "per Hand" installieren und warten macht doch keiner mehr, dafür gibt es spezialisierte NAS Betriebssysteme die das allemal besser machen als der "normale" Benutzer. Außerdem wer hat schon Zeit und Lust sein NAS zu pflegen, das soll bei den allermeisten einfach nur funktionieren und möglichst leicht zu Administrieren und Erweiterbar sein.

O_o wirklich ? Die haben eine Idle (ohne HDDs) von ca 8-10Watt - da müsstest du schon 12+ HDDs dran haben um die Watt Zahl zu erreichen

ne wirklich nicht ein OMV zu Kodi zu zwingen ist weder Kodi noch OMV zuträglich. Alternative Ubuntu + Kodi und dort Raid per Hand einrichten. Kodi unter Debian ist so oder so immer ein "Akt" durch Debians alte Pakete.Oder unRaid und LE als VM laufen lassen - soll wohl auch gut gehen.

Bei meiner Multimediakiste habe ich grad den Stromverbrauch im "Leerlauf" gemessen und komme auf 36 Watt. In dieser sind 4 Festplatten, 16 GB RAM, eine dual DVBSky 952 TV-Karte sowie zwei Smartmäuse verbaut. Auf dieser Kiste laufen halt TVHeadend zum Fernsehen sowie Aufnehmen inklusive Subskriptions, Kodi um ein Bild auf 'nen Fernseher zu bekommen, Ampache zum Transkodieren-On-the-Fly, normalerweise ein Python-Skript um die aufgenommenen MPEG 2-TS-Streams in H264 zu transkodieren und versorge halt vier Clients mit Live-TV, Aufnahmen und Filme in HD und bevor ich's vergesse - ein Linux-Desktop läuft auch drauf. Wenn ich Kodi starte werden aus den 36 Watt gleich mal 38 Watt und so weiter.
Bei meiner Systemkiste sind 16 GB RAM, ein Inline SATA-Controller und 6 Festplatten verbaut. Auf dieser laufen in XEN paravirtualisiert 11 Systeme (Nagios, 2 x Zarafa, 2 x Communigate Pro, 2 x Webserver, Odoo, WSO2 EMM, eigener Server mit einem PostgreSQL-Datenbankmanagementsystem zum Entwickeln von Anwendungen, Owncloud, Nextcloud). Leerlauf ist da jetzt eher selten angesagt. Da will ich ungern den Stromverbrauch messen, da diese Kiste alle 3 - 6 Monate mal neugestartet wird. Muss mich da mit knapp 20 Personen abstimmen.
Diese speziellen Umgebungen sind halt in keinem NAS-System implementiert. Aufgebaut sind die Systeme auf RAID1-Verbünde mit je nach Anforderung an die Performance WD Black oder Blue/Red-Platten. Die Wartung ist jetzt so 'n Thema. Um alle meine 17 Systeme Up-to-Date zu halten ist 'n bissl Zeit notwendig. Mit neuem Kernel sind da schnell vier Stunden vergangen. Sicherheitsrelevante Updates laufen eh unattanded. Im Gegensatz zu der Installation meines DNS-Servers mit der Konfiguration der DNS-Zonen im Jahr 2003 ist diese Vorgehensweise eh schon äußerst zeitschonend.

Ich kann die Probleme mit RPI_2, Libreelec 8.0.2 und TVheadend 4.3.280 auf 'ner separaten Maschine bestätigen. So ein bis zwei mal in der Woche gibt's 'nen Freeze beim Fernsehen (SAT-Betrieb). Nachdem ist seit September mit Seminararbeit und Abschlussarbeit - neben einem Job als Datenbankadministrator/-Entwickler und Programmierer - hab ich die Ursache noch nicht hinterfragt. Ich öffne eine JuiceSSH-Sitzung und tippe shutdown -r now ein. So kann ich bequem im Bett bleiben. Die Crash-Logfiles hatte ich mal kurz überflogen.

Ich bin ein absoluter Fan von Debian. Bei mir laufen mehrere Kisten jeweils mit mdadm und lvm. Mittels mdadm hab ich mehrere RAID1 Volume Groups erstellt und mit lvm dann die Partitionen angelegt. Dies stellt keine große Hürde da. Irgendwie durcheinander komme ich bei deiner NAS-Kodi-Lösung. Auch gibt es für Kodi Debian-Repositories um sich nicht mit dem Kompilieren beschäftigen zu müssen. Richtig viel Zeit kann mit der Grafik unter Linux draufgehen. Wenn du nur ein NAS möchtest und du etwas Zeit zum Einarbeiten in Linux hast, dann wär Debian schon was für dich. Ansonsten rate ich dir davon ab. Eine andere Frage stellt sich mir bei deiner Hardware. Ich verwende bei meinen Kisten J3700 und J4205 Prozessoren und komme pro Kiste auf 65 Watt im 24/7 Betrieb. Alte Hardware mit Leistungsreserven kann seitens der Stromrechnung schon ins Geld gehen.

Zitat von Givemethedownload

Ok, wusste ich nicht.
https://forum.kodi.tv/showthread.php?tid=298461
Von hier laden?
Dann setz ich mich nochmal drann

Yop, ab Version 628. 628 und 630 wurden schon erfolgreich getestet.

Es sind jedoch noch manuelle Schritte notwendig.
Wie beispielsweise die DRM Überprüfung in der default.py auskommentieren.

Der NUC enthält einen J3455 Prozessor. Ein Apollo Lake Prozessor mit einem "defekten" LSPCon DP zu HDMI Konverter. Unter Windows ist die gewünschte Audio-Ausgabe möglich miitels Firmwareupdate auf Version 1.66. Leider gibt es noch kein Update für Linux.

Den aktuellen Status kannst du im Thread Apollo Lake im Kodi Forum verfolgen. Folgend der Link dahin:
https://forum.kodi.tv/showthread.php…dp+to+hdmi+chip
Da kann auch ein Milhouse nichts daran ändern.