Beiträge von infinity

Ich rate doch sehr davon ab auf mp4 zu setzen. MKV ist und bleibt das worauf man setzen sollte. Unterstützen auch alle Fernseher problemlos und wird auch weiterentwickelt. Es ist der Standard, seit Jahren. Du wirst auch mit MKV keine Probleme haben, die mit MKV als Container zu tun haben. Eher mit codes... diese sind aber dieselben bei mp4, sprich: Wirst eher durch mp4 Probleme bekommen, als jemals bedingt durch mkv.

Ich persönlich kann mit 8000kbit/s völlig leben bei FullHD:

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format-Profil                            : High@L4
Format-Einstellungen für CABAC           : Ja
Format-Einstellungen für ReFrames        : 5 frames
Codec-ID                                 : V_MPEG4/ISO/AVC
Dauer                                    : 1h 28min
Bitrate                                  : 7 943 Kbps
Breite                                   : 1 920 Pixel
Höhe                                     : 1 040 Pixel
Bildseitenverhältnis                     : 1,85:1
Modus der Bildwiederholungsrate          : konstant
Bildwiederholungsrate                    : 23,976 (24000/1001) FPS
ColorSpace                               : YUV
ChromaSubsampling/String                 : 4:2:0
BitDepth/String                          : 8 bits
Scantyp                                  : progressiv
Bits/(Pixel*Frame)                       : 0.166
Stream-Größe                             : 4,92 GiB (72%)
verwendete Encoder-Bibliothek            : x264 core 142 r2389 956c8d8
Kodierungseinstellungen                  : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1,00:0,00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=2pass / mbtree=1 / bitrate=7943 / ratetol=1,0 / qcomp=0,60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20,0 / qblur=0,5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1,40 / aq=1:1,00
Default                                  : Ja
Forced                                   : Nein
colour_range                             : Limited
colour_primaries                         : BT.709
transfer_characteristics                 : BT.709
matrix_coefficients                      : BT.709

Zitat von CvH

Dann guck dir mal x265 an.
Meine FHD Filme sind im Schnitt 1-2gb bei 1920x1080

da er einen Raspberry Pi hat, wird x265 nicht so das Richtige für ihn sein.

Zitat von groovyg

Tag zusammen

Erstmal: Klasse Plugin! Benutze es schon seit der ersten Version auf Kodi 16.1 Android 4.2.2.

Seit gestern aber komisches verhalten, und zwar startet das Plugin gar nicht erst, wenn ich auf swiss IP stelle und dns4me nutze, bis gestern lief das tadellos. Ziemlich genau bis 19:30 Uhr, dann war schluss. Ohne läft es nach wie vor problemlos. Nun ist die grosse Frage: Liegt es an Zattoo, am Plugin oder am SmartDNS provider? Falls jemand ähnliches beobachtet hat und eine Lösung kennt bitte melden

Nenne mal deine Plugin version... Bei mir geht es noch problemlos mit der aktuellen 1.0.5 Version von Zattoo HiQ (PureVPN scheizer IP)

Du brauchst dich damit auch nicht beschäftigen. Es ist eine 1:1 Weiterentwicklung des OpenELECs was du bereits kennst. Das Team hat einfach den Namen geändert und sich von dem Hauptbetreiber getrennt. OpenELEC ist nun, meines Wissens nach, vielmehr eine schlechte und ungetestete Kopie von LibreELEC. Die Entwickler vom damaligen OpenELEC sind alle im LibreELEC boot. Die Installation ist bei LibreELEC zudem auch einfacher geworden:
Einfach das LibreELEC SD Creator tool herunterladen und loslegen: https://libreelec.tv/downloads/

Es ist zudem auch alles kompatibel. Könntest wahrscheinlich sogar direkt von OpenELEC auf LibreELEC updaten (ich würde allerdings vorher meine SD-Karte backuppen, für den Fall der Fälle). LibreELEC wird jedenfalls 100%ig stabiler und zuverlässiger funktionieren, als OpenELEC... bis OpenELEC wieder alle bugfixes von LibreELEC (schlecht)kopiert.

Zitat von gmh007

@infinity Jupp, das hab ich ebenso festgestellt. hatte mal den Test gemacht, was denn rausgekommen wäre, wenn ich in RipBot eine MKV als Quelle eingebe und als ausgabe wieder MKV

= Kein Unterschied zum MP4

Ha auch nie gesagt, dass MP4 besser sei. Is ja wie du schon sagst ebenfalls ein Containerformat. Ich hab nur gesagt, dass die Originalen Codecs in vielen MKVs auf den alten schwachen RPIs nicht liefen und ich irgendwann bei MP4 gelieben bin.

Die RPis haben seit der ersten version dieselbe Video-Dekoder-Einheit in der Hardware, daher ist es egal ob alter/schwacher RPi, oder neuer. Ich vermute es waren einfach komische codec-einstellungen (Profil), die für die Probleme sorgten. Oder du hast damals zufällig eine fehlerhafte MKV Version erwischt... ich meine mich zu erinnern, dass es mal ein mkv release gab, das Probleme verursachte.

Zitat von gmh007

Die jetzt wieder umwandeln bringt eh nix solange ich das gleche Programm verwende. Da könnte ich genauso gut auch die Dateiendung abändern

Dateiendung einfach abändern ist zwar nicht so ganz die beste Lösung, aber im Prinzip hast du recht. Du bräuchtest die Dateien nicht neu transkodieren (dauert mehrere Stunden), sondern einfach mit MKVtoolnix neu muxen (dauert ein paar minuten). Durchs neu-Muxen werden die Tonspuren/Videospuren/Kapiteleinträge/Untertitelspuren einfach vom MP4 Container in den MKV Container umverpackt. Es wird bei diesem Vorgang der Codec also nicht angetastet. Im Übrigen kannst du mit folgendem Programm immer den Codec und alle Daten checken:
Mediainfo
Ich schätze aber ohnehin, dass dein hier beschriebenes Problem eher eine Ausnahme war, und nicht bei all deinen Dateien vorkommen wird.[/quote]

Zitat von gmh007

Du meinst also man sollte nen Qualiverlust sehen können anhand der Bitrate? Mir ist im vorher nacher Vergleich noch nie was aufgefallen. Weder beim Abspielen noch im Standbild. Ging bislang davon aus, da er ja die Auflösung unverändert lässt (Hoch oder rutnerskalieren würde auch gehen), dass der Platzgewinn von einem anderen Codec kommen würde, falls der Film nur 5 - 10% an Dateigröße reduziert wird, [...]

Ja klar würde man den Unterschied in der Regel sehen, wenn man die Videospur eines Films testweise in 10.000kbit/s einer 5.000kbit/s gegenüberstellt. Aber man erkennt es vielleicht halt nicht in allen Szenen. Du würdest es höchstwahrscheinlich bei sehr dunklen Szenen (Kerzenlicht oder Mondlicht) erkennen, dass da leicht beleuchtete Objekte nicht ganz sauber von dem Rest abgegrenzt sind. Aber wenn du einen 15.000 vs 10.000 Film vergleichst, wirst du nicht unbedingt einen Unterschied feststellen können. Die Codecs sind höchstwahrscheinlich (zu 98% sicher) in allen Fällen H.264, also mit x264 kodiert, unterscheiden sich dann halt nur in Bitrate und Profil und evtl. Farbtiefe.

Du musst dir das alles wie damals beim MP3-Durchbruch vorstellen. Auf der CD waren 3 min lange Tracks in *.wav ca 30MB groß. Als MP3 konntest du dann 128kbit/s wählen, was man durchaus schon deutlich raushörte (aber halt nicht unbedingt am in-ear-Kopfhörer unterwegs), dann nimmt man 192kbit/s und schon hört man kaum einen Unterschied zur CD und hat trotzdem nur 5MB große Dateien im Vergleich zu den 50MB der CD oder den 3MB der kleinen 128kbit MP3. Du hast hier halt quasi den 128kbit vs 192kbit MP3 Fall... man kann es sehen/hören, aber man muss nicht.

Zitat von gmh007

[...] und dass es bei Filmen mit großen Platzgewinn dadurch kam, dass da vielechht mehr als ein Codec verwendet wurde oder so!?! Zumindest dachte ich, dass das der Sinn eines Containerformats sei, dass man evtl. mehrere Codecs für unterschiedliche Hardware zur Verfügung stellt!?!

Naja,....dann werd ich aufs Konvertieren evtl. in Zukunft verzichten und eben ein paar größere Festplatten für kaufen müssen

Nein, also sowas wie mehrere Codecs für die Videospur innerhalb eines Films gibt es bislang meines Wissens nach noch nicht, würde auch keinen sinn machen, weil in dem Fall einfach ein neuer Codec eingeführt wird (bspw. H.265 HEVC), der dann halt die Algorithmen vieler älterer Codecs einfach kombiniert und neue Verfahren noch hinzufügt.
Der Sinn eines Containerformats ist das Verpacken: Ein Film besteht ja aus einer Videospur (glaub in MKV wären sogar mehrere möglich), einer oder mehrerer Audiospuren (die verschiedenen Sprachen), dann der Untertitelspuren, Kapitelspuren usw... Das alles muss ja in einem "Container" verpackt sein, damit da auch alles schön zusammenpasst und der Dekoder das schön geordnet und stets synchron auspacken kann. der Container ist quasi einfach ein Umschlag für alles. Für Unterschiedliche Hardware wird da eigentlich eher nichts in einem Container gemacht, außer vielleicht vorsichtshalber Tonspuren, die in unterschiedlichen Audio Codecs vorliegen, wie bspw. AC3(E) Dolby Digital (Plus) für 5.1 Raumklang und MP3 für Stereo, oder auch AC3 mit zwei Kanälen als Stereo.

Ich denke aufs Konvertieren musst du nicht verzichten... du solltest einfach darauf achten ein Profil zu nehmen, das die Raspberry Decoder-Einheit auch verträgt (sehe hier gerade, dass es wohl bis L4.1 gehen kann). Dann einfach MKV wählen und es sollte alles perfekt laufen.

Zitat von gmh007

ok, danke für den Tipp. Jedoch hatte ich das Gefühl, dass es anders sei.

Hatte in der Vergangenheit mit dem alten RPI1 probleme mit dem MKV weil ich nicht wusste welcher Codec verwendet wurde.
Das konvertieren mit RipBot ergab bislang immer einen Platzgewinn ohne Auflösungsverlust und der alte RPI kam damit besser zurecht.

Mit der neuen Hardware ist das anscheinend nicht mehr so das Thema auch die großen MKVs wiederzugeben, aber wenn man einmal dabei gewesen ist seine Sammlung über 1,2k Filmen umzuwandeln...dann steigt man aus gewohnheit nicht mehr um auf MKV

Bei einigen ausgewählten Filmen hab ich zum Teil einen Platzgewinn von 60% erreichen können dadurch. Auch das war historisch bedingt durch Platzmangel erwachsen..

Trotzdem danke für eure Hilfe!

Hmm.. das macht alles leider nicht ganz so viel Sinn. Du musst dir klar werden, dass MP4 ein Container ist, genauso wie MKV einer ist. In MP4 können verschiedene Codecs drin sein, genauso wie in MKV. MKV ist aber seit Jahren der Platzhirsch. MP4 hingegen ein von der Industrie und vor allem - glaub ich - von Apple eingesetzter Container. MKV hingegen ist jenem in jeder Hinsicht überlegen und vor allem DER Container, wenn es um Kodi und alle mögliche freie (non industrielle) Software geht. Ich würde an deiner Stelle deine bisherige Sammlung nicht umwandeln oder sowas, sondern ab jetzt einfach alles was neu reinkommt in einen MKV container packen.

Dass deine MP4 Dateien kleiner sind als deine MKV's ist kein Hexenwerk, hat auch nichts mit MKV vs MP4 zu tun, sondern einfach mit den Codec-Profilen, die du einsetzt. Deine MP4 Datei wird halt einfach eine Videospur mit 60% niedrigerer Bitrate (somit theoretisch 60% schlechtere Qualität) haben, was genauso mit MKV erreichbar ist, wenn du da denselben Codec mit demselben Profil samt Bitrate verwendest und in den Container reinsteckst. MKV ist dann am Ende bei denselben Randbedingungen bei einer 10GB Datei vielleicht 1 bis 4 MB kleiner oder so, weil es einfach weniger Overhead in seinem Header erzeugt.
Also merken: Im MKV container kann bspw. eine H.264 Videospur (bspw mit x264 codec enkodiert) drin sein, oder auch eine in VC1 oder H.265 enkodierte Spur. Im MP4 container kann es genauso sein, der müsste auch H.264 und H.265 und VC1 aufnehmen können.

ir-keytable reagiert ultraschnell! Wobei ich merke, dass es wohl mein (vom RPi2 benutztes) altes Harmony profil ist, das bei der OK taste nun komischerweise einen längeren Tastendruck braucht. @Merlin.KIS Setup ist da wohl etwas besser bzw. jungfräulicher. Also wenn ich nun ein neues Profil einrichte und damit rumspiele, sollte es wohl auch super hinzubekommen sein, da es offenbar bei mir nur einige Tasten betraf - folglich meine eigene Harmony Konfiguration/Optimierung mit den Repeats usw. wohl nicht mehr ganz zum Odroid passt.

Klasse! Pfleg das bitte mal ein. Da werden sich die Leute im Odroid Forum auch freuen, die da vor einer Weile diese kläglichen Probleme mit GPIO-IR hatten

EDIT: Gibt es nun eigentlich eine dauerhafte Lösung für ir-keytable? Also sodass man es nach dem Start alles Lauffähig hat und LIRC komplett ersetzen kann? Mir ist zudem noch etwas schleierhaft wie man die Tasten für IR-Keytable anlernt... ist es dann eine remote.conf statt lircd.conf?

Phuh, hast du dafür eine Referenz? Habs damals nur kurz dirty nachgemacht und sah, dass es nicht gut ging. Finde grade allerdings die damalige Anleitung nirgends

Zitat von Raybuntu

Hier ist ein Preview build das hoffentlich gpio ir receiver zum laufen bringt:
https://mega.nz/#F!N4wy2QYL!wJN6oZ0pRRoXQtMs8bQ0tA

GPIO IR funktioniert nun tatsächlich wieder! Du bist genial

Es ist jedoch leider (zumindest bei mir) noch unbenutzbar. Es reagiert träge und nach ein paar Tastendrücken dann für 5 Sekunden überhaupt nicht bzw. ich muss sekundenlang auf die Taste drücken, damit das Kommando auch ausgeführt wird. Welche Art von Log (welches SSH kommando) wäre da sinnvoll, um zu sehen was genau passiert?
Ich erinnere mich, dass ich ein ähnlich schreckliches Lirc-Ergebnis hatte, nachdem ich diesen udev-rules Hinweis von wrxtasy ausprobiert hatte:
https://forum.odroid.com/viewtopic.php?…art=200#p179208
Sollte eigentlich die (bis dahin ganz gute) Reaktionsfähigkeit verbessern, aber hatte genau das Gegenteil als Ergebnis. Kann es sein, dass diese Rules nun im LibreELEC Master drin sind, und deswegen solche Probleme zustandekommen?

In jedem Fall ist es nun nach mehreren Monaten immerhin tatsächlich lauffähig, danke vielmals!

Zitat von Oreider

Nutze eine Logitech Harmony und hab die Kombination schon ewig so. Solange es funktioniert hat, hab ich keine Notwendigkeit gesehen was zu ändern.

Gesendet von iPad mit Tapatalk

Wenns eine HUB-basierte Harmony ist, dann würde ich sogar vorschlagen lieber auf Bluetooth zu setzen. Kauf dir ein CSR 4.0 dongle für ein paar Euro und dann steuerst du das ding ohne jegliche Verzögerungen (egal wie schnell zu durch die Library blätterst). Das einzige Manko ist, dass man beim Kaltstart wohl meist so 20 Sekunden lang warten muss, bis die Bluetooth-Verbindung initialisiert ist. In diesem Fall kannst du den RPi weiterhin per IR an und ausschalten, da das Ein-/Ausschalten nicht von LibreELEC/OpenELEC interpretiert wird, sondern vom Microcontroller auf dem RemotePi Board selbst. Sprich: im Prinzip würde An/Aus per IR sogar funktonieren, wenn man den Kontakt des IR PINs zwischen RPi2 und RemotePi unterbrechen würde.

Ich selbst nutze schon eine Weile lang die oben beschriebene Kombi: IR des RemotePi zum An/Ausschalten, und Bluetooth zum steuern (Harmony 950 mit HUB).

Zitat von Slipass

[...]

Zweite Frage:
Um nicht jedes mal den Bootvorgang abzuwarten, würde ich die Odroid gerne in den Energiesparmodus schicken - analog wie in Windows der Bereitsschaftsmodus.
Soweit ich weiß, geht das nicht oder?

Welche Möglichkeit gibt es noch? Dauerhaft eingeschaltet lassen wäre keine Option, da ich einen Bildschirmschoner nach 1 Minute habe und die Bilder liegen auf einem Server.
Bleibt das Gerät nun dauerhaft eingeschaltet, würde ein ständiger Zugriff auf die HDD des Servers stattfinden.

Der Odroid C2 beherrscht seit August 2016 einen automatischen (sicheren) Shutdown per HDMI CEC. Zunächst einmal würde ich an deiner Stelle auf keinen Fall den TV USB-Port zum Versorgen des Odroids nehmen. Einfach ein normales 2A USB Netzteil verwenden. Dank dem Programmierer "kwiboo" ist diese Funktionalität im u-boot bootloader (für die infratot Fernbedienung) integriert. Und dank @Raybuntu ist das alles per HDMI CEC auch als Funktion in LibreELEC eingebaut.

Wenn dein TV HDMI CEC beherrscht (was so ziemlich alle TV's seit 2010 oder so können), dann kannst du in den HDMI CEC Einstellungen von LibreELEC/Kodi einfach auswählen, dass der Odroid in Standby gehen soll, sobald der Fernseher ausgeschaltet wird. Kannst da auch direkt mit einstellen, dass der C2 beim Einschalten des Fernsehers auch wieder hochfährt. Das Hochfahren dauert nur wenige Sekunden...jedenfalls mit Sicherheit schneller als der Fernseher nach dem Einschalten überhaupt ein Bild anzeigen kann. In diesem speziellen Standby Modus (aus dem man ihn per CEC und IR aufwecken kann) verbraucht der C2 so ca. 0,5W meine ich. Vielleicht auch etwas weniger. Er braucht hingegen wohl so 0,8W, sofern man den Odroid per MicroUSB Port mit Strom versorgt. Denn in diesem Fall muss man den Jumper neben dem MicroUSB Port drauf haben. Wenn man durch den Hohlstecker versorgt und den Jumper somit abnimmt, kommt man auf die 0,5W (oder etwas weniger) Verbrauch.

Also ich würde das mit dem HDMI CEC machen. Hast dadurch überhaupt keine Sorgen und das ding geht vollautomatisch an und wieder aus, und das auch noch blitzschnell.

Du könntest einfach eine neue remote.conf für deine Fernbedienung (und allen tasten) erstellen mit folgender Anleitung: http://forum.kodi.tv/showthread.php…1663#pid2291663
Einfach ab Punkt 2 beginnen.

Ansonsten wäre CEC wirklich eine Alternative. Du kannst einerseits CEC vom Fernseher bzw. mit dessen Fernbedienung nutzen (was die meisten ja machen). Oder sogar das eigene CEC vom Onkyo (mit der Onkyo Fernbedienung) zum Laufen bekommen:
- Beim Onkyo müsste CEC unter folgenden Voraussetzungen funktionieren:

1. https://www.reddit.com/r/Chromecast/c…rs_for_cecrihd/ das hier einrichten
2. Tx5Pro an Onkyo anschließen (in den HDMI port, den du mit der oberen Anleitung auf der Fernbedienung programmiert hast)
3. Im Receiver OSD/Home-Einstellungsmenü: RIHD aktivieren
4. Mal neustarten. Denke das sollte funktionieren.

Wenn du einen AV-Receiver einsetzt, der DD+ dekorieren kann, dann solltest du "Dolby Digital (AC-3)-Umwandlung einschalten: Ja" ausschalten. Diese Option wandelt alles was nicht dts oder ac3 ist in Dolby digital um, so dass es in kodi dekoriert werden muss. Evtl ist diese Umrechnung dann eine zu hohe CPU-Last. Evtl. Hast du das aber auch bewusst gemacht - in dem Fall wollte ich das dann für alle Fälle erwähnt haben.

Zitat von Merlin.KIS

Ich habe mir erlaubt ein kleines Addon zu schreiben,
das weder Kodi Callbacks noch ein Sh-Script benötigt.
service.odroidc2-3dautoswitch.zip

Wer vorab wissen möchte was das Addon so macht:

Python: default.py

import os, xbmc, json
class xbmcPlayer(xbmc.Player):
  def __init__(self, *args):
    pass
  def onPlayBackStarted(self):
    if self.isPlayingVideo():
      stereomode = ''
      try:
        info = json.loads(xbmc.executeJSONRPC('{"jsonrpc": "2.0", "method": "Player.GetItem", "params": { "properties": ["streamdetails"], "playerid": 1 }, "id": "VideoGetItem"}'))['result']['item']
      except RuntimeError:
        info = {}
      else:
        if 'streamdetails' in info.keys():
          sm = info.pop('streamdetails', {})
          try:
            stereomode = sm['video'][0]['stereomode']
          except (KeyError, IndexError):
            stereomode = 'non'
          else:
            if stereomode == '':
              stereomode = 'non'
      if stereomode == 'left_right':
        os.system("sleep 2 && echo '3dlr' > /sys/class/amhdmitx/amhdmitx0/config")
      if stereomode == 'top_bottom':
        os.system("sleep 2 && echo '3dtb' > /sys/class/amhdmitx/amhdmitx0/config")
if __name__ == '__main__':
  player = xbmcPlayer() 
  monitor = xbmc.Monitor()
  while not monitor.abortRequested():
    if monitor.waitForAbort(1):
      break

Alles anzeigen

@Merlin.KIS
Was für eine geniale und elegante Arbeit! Danke vielmals!! Das funktioniert wirklich perfekt :). Endlich ....!
Wäre klasse, wenn das in @Raybuntus Repo reinkäme oder in das Kodinerds Repo.

Zitat von hi2hello

[...]
Nachtrag:
Dass die Darstellung von 3D Content tatsächlich so anstrengend ist, wie zuvor hier im Thread bereits von @'maku00' beschrieben konnte ich bislang zwar ebenfalls feststellen, allerdings aus anderen Gründen: Helle Bereiche scheinen zu flackern, was aber nichts mit einer Änderung der Pixelgröße auf 1.03 o.ä. zu tun hat oder gar Abhilfe schaffen würde. Ich werde mal identische Filmdateien in punkto 3D-Darstellung auf Pi und Odroid C2 vergleichen. Auf dem Pi war mir das Flackern nicht aufgefallen. Feedback folgt.
[...]

Das Flackern müsste an deinem Fernseher liegen, bzw an dessen Schärfeeinstellung. Meiner hat das auch und es ist ein Philips aus dem 2012er LineUp. Das müssten sowas ähnliches wie Aliasing-Fehler der Bildbearbeitung deines Fernsehers sein. Ist es ein passiver TV? Meiner ist jedenfalls ein alter passiver und dessen Bildverarbeitung macht leider extrem viele Fehler, die dann durch die vertikal-halbierte passive Darstellung evtl. noch mehr zu tragen kommt. Ich muss mir wirklich mal langsam einen neuen TV zulegen :/. Aber wäre schon super, wenn du das mit einem Raspberry gegentesten könntest. Würde mich jedoch wundern, wenn der bei derselben Datei an derselben Stelle was anders machen würde.

Zitat von kodi-zombie

Mit diesem PVR Client kann man wunderbar aufnehmen. Ich finde nur nicht heraus wo diese Aufnahmen liegen. Werden die lokal gespeichert ? Oder bleibt das alles bei Zattoo auf den Servern ?

Das bleibt alles bei denen auf den servern. Ist quasi eine Cloudaufnahme, die du danach als stream gucken kannst. Finde das ziemlich elegant, da man somit seine Geräte nicht eingeschaltet haben muss und auch keinen lokalen Speicher dafür vorhalten muss.

Falls deine Frage darauf abzielte, wie man die Aufnahmen im Anschluss abspielen kann:
Abspielen kannst du deine Aufnahmen, indem du in der Senderübersicht (je nach Skin) nach links klickst und somit quasi das Kontextmenü für die Senderübersicht öffnest. Da ist dann der Punkt "Aufnahmen".

Verstehe ich nun nicht so ganz. Irre ich mich, oder lässt du Kodi nun als user "root" laufen? Wenn dem so ist, dann hast du doch genau das gemacht, weswegen du ursprünglich von LibreELEC weg bist? Oder meine Linux-Kenntnisse reichen nicht aus, um den Unterschied zu sehen.

Wir können ja nochmal den VPN Thread aufrollen, den ich vor vielen Monaten mal rausgehauen habe... Es sind einfach nicht diese VPNs, die ihr da ansprecht, welche ich eigentlich meine. Man kann es ja drehen und wenden wie man will. Aber der eigentlich Zweck für den VPNs ursprünglich vor vielen Jahren Entwickelt und eingesetzt wurde, ist heutzutage für fast alle, die erst in den letzten 2 Jahren mit VPNs dank netflix usw in Berührung kamen, ein völlig anderer. Die FritzBox als Beispiel zu bringen ist da ein unpassenderer Vergleich als Äpfel und Birnen

Ich kanns ja nochmal zusammenfassen: Bei einem VPN Anbieter wie bspw. PureVPN hat man einfach keine Kontrolle über die andere Seite, wodurch man als Neueinsteiger weder davor gewarnt wird, noch jemals mitbekommt, dass seine Android TV Box, sein Raspberry oder sein Smartphone teil eines Botnetzes wird. Ach ja doch.. man merkt es an seltsamen Abstürzen des jeweiligen Gerätes manchmal... Dabei will man doch einfach nur mal ne Schweizer IP oder sowas haben und denkt sich "whuhuuu... Die Schlagwörter "Sicherheit" und "Security" und "Privacy" kommen bei allen Anbietern mindestens 10 mal auf der Hauptseite vor. Im Übrigen gibt es bei Android meines Wissens nicht mal eine Möglichkeit mal eben den VPN Tunnel bei solchen Anbietern sicher zu machen. Iptables gibts da ja nicht.

OpenELEC/LibreELEC ist glaube ich vom Konzept her gar nicht in der Lage mal eben so ein änderbares Passwort umzusetzen. Es ist ja ein robustes Read-only System, daher kann man ja nicht auf der Systempartition sowas wie ein neues Passwort abspeichern. Mich stört es ehrlichgesagt auch sehr, weil das insbesondere in Verbindung mit einem VPN Dienst unheimlich gefährlich ist. Bei einer Diskussion im LibreELEC Forum hat einer erwähnt, wie er auf seinem Server einen logger installiert hat, welcher lauscht was aus dem Netz alles für login-anfragen so kommen: vor über einem halben Jahr (da war das LE Projekt selbst ja gradmal 6 Monate alt) kamen schon mehrere Anfragen mit der Kombination "user=root" und "passwort=libreelec".

@Mercyful
Wieso werden von dem System nur 1GB genutzt? Es hindert dich doch niemand daran eine 8GB Karte zu nehmen? Zudem hängt der Speicherplatzbedarf natürlich von der Größe deiner Library ab. Hast du viele Filme, Serien Musik, dann brauchst du auch viel mehr als deine 1GB.

Ich könnte mir gar nicht vorstellen für mein MediaCenter raspbian mit kodi drauf zu installieren. ELEC ist sowas von robust und läuft out of the box.... Dann doch lieber OSMC nehmen, wenns unbedingt was anderes sein muss.

Die mit den aktuellste Optimierungen usw. ist eigentlich immer die Version von @Raybuntu:
http://forum.odroid.com/viewtopic.php?f=144&t=24753
Hier sind seine Downloads: https://github.com/Raybuntu/LibreELEC.tv/releases
Achte darauf, dass du die Krypton Versionen nimmst (Krypton8) momentan. Die Agile sind reine Testversionen (quasi nightlies) mit vielen Bugs und vor allem Darstellungsfehlern in der GUI.

Zitat von grappi

[...]

Allerdings konnte ich ein wahrscheinlich ähnlich gelagertes Phänomen zwei mal reproduzieren:
Wenn ich das 3D-Trigger SIgnal bei 2D Filmen gesendet habe ist der Odroid jedes mal komplett abgestürzt, wenn ich zur GUI zurück wollte.
Bei 3D-Filmen trat dies überhaupt nicht auf!

Jap, in meinem Fall kam es ja auch während des Abspielens von 2D Material zum Vorschein. War halt nur ein Test. Interessant, dass das dem System was ausmacht. Aber werde nun langsam wohl doch dauerhaft auf Krypton wechseln können mit deinem Workaround. Danke für die Mühe!

Zitat von Raybuntu

Ich tippe mal auf Kernel Panic was mich bei Amlogic nicht wundern würde.

Haha...

Also mit wrxtasys Nougat version verhält es sich genauso wie mit deiner normalen.

LibreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/edid
Rx Brand Name: ONK
Rx Product Name: TX-NR616
Manufacture Week: 0
Manufacture Year: 2012
EDID Verison: 1.3
EDID block number: 0x1
blk0 chksum: 0x4a
Source Physical Address[a.b.c.d]: 1.2.0.0
native Mode f1, VIC (native 255):
ColorDeepSupport b8
16 31 32 34 33 5 20 4 19 18 3 17 2 22 7 21 6 1
Audio {format, channel, freq, cce}
{1, 1, 1f, 7}
{2, 5, 7, 0}
Speaker Allocation: 1
Vendor: 0xc03
MaxTMDSClock1 225 MHz
ColorMetry: 0x3
SCDC: 0
RR_Cap: 0
LTE_340M_Scramble: 0
Rx 3D Format Support List:
{VIC FramePacking TopBottom SidebySide}
{ 16    0       1       1 }
{ 31    0       1       1 }
{ 32    0       1       1 }
{ 34    0       1       1 }
{ 33    0       1       1 }
{ 5     0       1       1 }
{ 20    0       1       1 }
{ 4     0       1       1 }
{ 19    0       1       1 }
{ 18    0       0       0 }
{ 3     0       0       0 }
{ 17    0       0       0 }
{ 2     0       0       0 }
{ 22    0       0       0 }
{ 7     0       0       0 }
{ 21    0       0       0 }
{ 6     0       0       0 }
{ 1     0       0       0 }
  DeepColor
checkvalue: 0x4aed0000

Frame Packing scheint überall deaktiviert zu sein. Auch bei deiner Krypton8 ist FramePacking überall = 0. DeepColor in der 43. Zeile ist jedoch neu dabei.

LibreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/disp_cap
480p60hz
576p50hz
720p60hz
1080i60hz
1080p60hz
720p50hz
1080i50hz
1080p30hz
1080p50hz
1080p25hz
1080p24hz

Im Vergleich zu deiner Krypton8 fehlen hier 480i60hz und 576i50hz