Kannst du das "Handling" im Bezug auf kodi präzisieren? (Also ohne: Windows bootet ewig, braucht nen Virenscanner und schreit dauernd nach Updates?)
Beiträge von fritsch
-
-
Sowas von komplett falsch ...
-
Zitat
Da kommt einem aber gleich die Frage auf, wieso es keine Windows/OpenELEC TV Geräte gibt :).
Die gibt es wie Sand am Meer. Die ganzen NUCs / zotac / chromebox Kisten werden gekauft und mit OpenELEC / LibreELEC betrieben. Alleine der chromebox thread im kodi forum hat mehr als 1,2 Million Views mehr als doppelt so viele wie der vergleichbare Shield Thread.Edit: Ach, du meinst TVs an sich. Ob man diesen Schluss ziehen kann, bin ich mir ziemlich unsicher. Nur weil Android oder Tizen drauf steht, heißt das noch lange nicht, dass man die Hardware so nutzen kann, wie man das gerne möchte. Die Android API (Audio und Video) ist bisher so unglaublich rückständig, dass es fast weh tut ... aber wie gesagt, Android ist auf dem Vormarsch, ob es deshalb die beste Plattform für Kodi ist, nur weil viele Leute es kaufen, möchte ich stark bezweifeln, denn in der Tat gibt es von vielen Millionen Usern niemanden der sich darum kümmern will.
Die Entwickler die wir haben, haben alle samt eine kommerziellen Weg eingeschlagen.
-
Zitat
Deinterlace Video: Aktiv
Das ist schwachsinn. Deinterlace ist nur sinnvoll wenn man Interlaced content anschaut. Was soll man denn bei progressive content deinterlacen? Bitte das nie auf On stellen, immer auf Auto belassen. -
[fn][/fn]So dann:
Beebox 3150 , RAM, SSD sind bestellt.Gibt's hier ein HowTo für Installation von "Libreelec"
Danke Leute, bin dann mal gespannt. Geht über die Box auch AirPlay? Dann könnte ich mein AppleTV 4 verkaufen
Airplay geht immer so lange bis es sich Apple neue überlegt und unsere Implementierung erneut gezielt sabotiert ... schmeiss alles weg was proprietär ist
-
Poste mal dmesg | pastebinit
radeons / intels kann man per boot param deaktivieren.
-
Das war einer meiner Lieblingssender Top Dokus, super Bildqualität, sehr schade.
-
Danke für die ausführliche Antwort. Und gut, dass ihr ein paar Connections habt. So lange die Kiste bei mir läuft, bin ich zufrieden. Mir ist das ganze "Heimkino True HD muss gehen" nicht mehr so wichtig, seit ich ein Kind und damit weniger Zeit habe.
Du weißt: Wer früh Metallica zu hören bekommt, der wird hinterher ein anständiger Metaller *hint* *hint*
-
Wir haben Probleme Entwickler zu finden. Die meisten Leute die Android machen, machen das kommerziell, also die meisten Hersteller tun das. Jeder Hersteller hat ne eigene API, Rockchip, Allwinner ;-), AMLogic - alle wollen eine "Spezialbehandlung", die Shield ist die erste Box die wirklich per MediaCodec und Audiotrack halbwegs ordentlich funktioniert und auch sonst ne ansprechende Hardware hat. Seit dem Firmware-Update, vor dem ich massiv mit Nvidia und Android devs selbst diskutiert habe, gab es noch "ohrenbetäubende" Bugs, vielleicht erinnert sich der eine / andere an die Stottergeräusche beim Seek.
Leider stehen auf Android immense architektonische Veränderungen an, weil über Jahre nur "reingepatched, workarounded, etc." wurde. Dies hat letztlich, neben ein paar Menschlichkeiten, zum Bruch mit dem letzten Android Maintainer geführt. Dieser macht jetzt mit SPMC auf Basis von v16 weiter. MrMc hat gesehen, dass mit v16 was Video / Audio angeht kein Blumentopf zu gewinnen ist und hat die Audio-Engine / VideoPlayer von Version 17 auf Version 16 zurückportiert (!) 10 tausende Zeilen Code. Man bedenke, das ganz Zerwürfnis kam daher, dass das Audio / Video Team gesagt hat: Ey, Jungs lasst das mit v16 sein, das funktioniert nicht richtig, ihr bekommt drops, es ist ein immenser Hack und hat keine Zukunft (*) - MrMC hat das gleich kapiert - und obwohl er auch nicht mehr offiziell bei kodi dabei ist - die richtigen technischen Schlüsse gezogen.
So sachen wie inputstream / libwidevine kompiliert zu bekommen ist nur die halbe Miete. Den Content den man da bekommt wird mittels DASH zusammengebaut, d.h. je nach Bandbreite kann sekündlich der Stream / sein Größe etc. wechseln. Der "Renderer" muss sich anpassen und das so, dass kein einziger Frame kaputt geht ... Auf Android braucht das Ding alleine 500 ms um seinen Mode wieder korrekt einzustellen (im AML Decoder wird sogar forciert 500 ms geschlafen, um solche Designbugs zu beheben). Kurzum: Es ist viel Arbeit zu tun, Arbeit die man nicht mit "ach wäre doch toll" weg oder hindiskutieren kann.
Hier wird in Android momentan nichts investiert. Es werden nur features reingepatched, weiter workarounds reingebaut. Welcher freie Mensch hat denn Lust sich in seiner Freizeit mit einer geschlossenen Platform rumzuärgern und für jede Box unterschiedliche Workarounds einzubauen? Ja, genau - keiner - deshalb kümmert sich ja auch niemand um die Androidplatform.
Eine gute Nachricht hab ich vielleicht dennoch. Ich hab mit Android's Chef-Audio-Entwickler verhandelt (ja kodi hat ein paar Connections). Die nächste Android Version wird - wegen uns - eine IEC Passthrough Variante bekommen. Dann sollten sachen wie EAC3, Atmos, etc. kein so unglaublicher Krampf wie jetzt mehr sein. Zusammen mit unseren Audio-Änderungen in v17 sind dann zum Beispiel "Pause Bursts möglich", sprich, wenn mal etwas Audio fehlt, kann man pause frames schicken ohne dass es "butz" macht. All dies ist mit v16 nicht möglich ... wenn sich also jemand eine Shield kauft, dann soll er nicht traurig sein, wenn viele Dinge nicht richtig funktionieren.
Für den "otto normalverbraucher" ohne 4k, ohne Atmos, ist ein RPi3 die weitaus bessere Wahl.
Falls es technische Fragen im Detail gibt, bitte gerne Fragen. Ich wollte den Android Port vor paar Monaten mal übernehmen, hab dies auch für Audio getan und die beschissene Android v23 API implementiert, aber dann wurds mir zu dumm, mit all den "Nervbacken" die nur nach Features, Features, Features gerufen haben ...
Also: Sucht ein paar fähige Entwickler, die FernetMenta, Mapfau (inputstream Miterschaffer) und mir dabei helfen den eingeschlagenen Weg (Entkopplug von Application und Render, korrekte EGL Implementierung) mit zu gehen. Es ist viel Arbeit aber der Aufwand wird sich lohnen. Ich denke, dass das in 6 Monaten zu schaffen ist
* Um das zukunftsfähig zu machen habe ich mit FernetMenta den "nicht IEC pfad" in die Audio-Engine eingebaut. Wir können jetzt raw passthrough sprechen, ohne die IEC frames im Sink auszupacken ... einziger Abnehmer: Android und zum Glück obsolete mit v24 API. Diese Erweiterung war schon fertig, bevor v16 final wurde ...
-
Kommt drauf an, ob du HEVC-10 bit und 4k@60p angucken willst.
Falls ja gibt es nix gutes momentan ... intel hat zu allem Übel noch ihren Broxton chip rausgeworfen
Ich bin ein großer Anhänger der "max 200 Theorie". Kaufe nie etwas das mehr als 150 euro kostet und tausche es dafür alle 12 Monate aus (Speicher / SSD kann man meist 2x verwenden, in der nächsten Box).
Falls 4k@30 hz ausreichen (welcher content ist denn überhaupt 4k@60 momentan?), dann ist ne günstige kleine Beebox mit 2x2 gb ram zu empfehlen und einer Milhouse LibreELEC Installation. Da läuft dann prime, skygo, hevc 8 bit, 4k@30 h264, 1080i50 livetv, 1080p24 blurays. Atmos / TrueHD / DTSHD / EAC3 passthrough.
Kauf dir mal eine über amazon, probier es aus via USB stick und schick sie zurück wenn sie dir nicht gefällt.
-
Ich würde die Shield verkaufen und gegen etwas anderes ersetzen. Sie ist ihr Geld im Bezug auf kodi nicht wert. SPMC als auch kodi sind auf Android nichts anderes als Flickwerk auf einer
beschissenenunglaublich schlechten AUDIO API ... TrueHD / Atmos wird nur funktionieren mit Aussetzern alle paar Minuten. 4K Playback geht nur über Surface Rendering und auf die Farben hast du keinen Einfluss.Da Kodi momentan nicht mehr für Android entwickelt wird (kein Maintainer, ein Haufen bugs) musst du sowieso SPMC verwenden, weil das die einzige Version ist die TrueHD / Atmos halbwegs kann. Die aktuellen v17 nightlies haben zwar auch Code in diese Richtung aber nuja - grade starten die nightlies nicht mal mehr.
Sachen wie inputstream (für sky, amazon prime) kannst du die nächsten Monate noch ziemlich vergessen, wenn es jemals funktionieren sollte.
-
Hier, guck: https://github.com/xbmc/xbmc/pull/9694 kam vor 7h rein und das nightly wird erst wieder gegen morgen gebaut, so gegen 4:00 unserer Zeitzone.
-
Der Fix wurde vor 4h gepushed. Dein Nightly is 14h alt ...
-
Die nightly von morgen - hat das behoben. Wurde vor 5 Minuten upstream gepushed.
-
Hätte er jetzt "oder sowas" nicht gesagt, hätte ich den Fehler auch nicht eingrenzen können ...
ist genau das gleiche hier wie im Kodi forum, in 90% fehlt einfach der [definition='1','1']debuglog[/definition] und hält somit Leute, die in ihrer Freizeit Dinge fixen wollen, gnadenlos auf.
-
Ohne [definition='1','1']debuglog[/definition] wird keiner eine Lösung finden. Also: poste mal einen + mediainfo.
-
Hallo,
Bin neu hier. Nutze schon länger kodi und habe keine Lust mehr aufwändig über chrome Amazon Prime zu schauen.
Ich habe meinen Raspi in Rente geschickt und mir ein Qnap 453a zugelegt. Wenn ich hier aus richtig verstanden habe benötige ich für das Qnap die libssd_wv-lib. Gibt's die irgendwo zum Download? Und gibt es irgendjm. Der nur sagen kann sie ich die ob dann auf dem Qnap installiere??
Danke Euch!Wie installierst du denn kodi auf dem qnap? Du brauchst eine v17 version und das inputstream addon, dann musst du passend zu deinem system (libc, etc.) die libssd_wv.so bauen und einspielen. Kurzum: Es muss alles zu deiner toolchain passen.
Das scheint mir ein größerer Krampf zu sein als einfach den RPi wieder hervorzuholen und "out of the box" prime zu schauen.
-
Poste deinen [definition='1','1']debuglog[/definition]. Gehe sicher, dass AVR und TV angeschaltet sind bevor du kodi startest.
-
Hallo Fritsch...
Ich betreibe einen
NUCCPYH(Brasswell) mit 8GB und einer 120GB SSD
Als OS nutze ich derzeit Librelec
(Millhouse)Kodi 17.0 Alpha
Ich hab null Probleme bis jetzt...
angeschlossen per HDMI an einen DENON X3100 ..
die einzige Veränderung die ich machen muss das auch BD Isos usw völlig ruckelfrei laufen ist das ich unter Beschleunigung
VDPAU aus habe..das gleiche ist auch bei OE 6.03 VDPAU aus und alles flüssig ist es aktiviert Stottern FULLBD Isos (nicht alle)
Hast du dafür eine Erklärung?Und stimmt das Gerücht das KODI ab Version 17 auch ATMOS selber dekodieren kann?
Gruss NFo
VDPAU macht auf intel hw überhaupt keinen Sinn. Intel nutzt VAAPI. Warum das dann dennoch ruckelt, obwohl es gar nicht erst "aufgehen" sollte, kann ich ohne [definition='1','1']debuglog[/definition] nicht sagen. Einfach VDPAU auf intel hw immer aus machen.
Zum Atmos: Ich habe keine derartigen Informationen. Kodi code war das sicher nicht. Wir decodieren den TrueHD Track, ignorieren aber die atmos bits.
-
@fritsch: Bist du auch bei Libreelec dabei? wäre doch gut wenn so eine koryphäe bei dem neuen Projekt mithilft!!!
Nein. Ich bin da nicht dabei. Ich hab aber nix gegen die Leute die das machen und kann deren Gründe sehr gut verstehen. Ich konzentriere mich auf kodi an sich, paketieren und so sollen die anderen machen. Das raubt unglaublich viel Zeit, wenn man versucht beides, d.h. kodi + libreelec / openelec, auch noch nebenbei zu machen ...
Zu den Problemen mit den Baytrails J1900, J29xx gibt es bisher für alle kernels vor 4.5 nur die Lösung per bootloader den maxcstate auf 1 zu begrenzen, 2 oder 3 oder 5 führen genau zum gleichen Freeze. Es gibt ein paar Reports, dass Kernel 4.5.0 "besser" funktionieren soll, aber bestätigen kann ich das nicht. Verkauft einfach eure Baytrails, die GPU ist eh übel und nehmt für kurze Zeit ne Beebox oder ne andere zbox mit Braswell. Wenn Broxton / Kabilake mit HEVC-10 bit support kommen werden die Karten sowieso neu gemischt. Größere Investition lohnen daher nicht. Viel Geld für ne SKL Nuc auszzugeben ist auch total daneben, weil die auf keinen Fall die neuen LiveTV Standards ruckelfrei abspielen können, da kein hevc-10 bit support. Sample gefällig: http://fritsch.fruehberger.net/samples/future…v-hevc-10bit.ts
Um es abzuschließen: OpenELEC mit version 16 oder auch librreelec mit v16 sind absoluter Mumpiz auf intel nucs ... bleibt auf den v15 EGL preview version oder geht direkt auf v17. Warum? Darum: http://forum.kodi.tv/showthread.php?tid=231955
Auf Deutsch:
v16: schlechte Farben, Banding, immenser overhead, da jede decodierte Surface einmal kopiert werden muss. Die Einstellung "Use Limited Range" ist bullshit in den Versionen, da vaapi -> OpenGL eine fullrange expansion ohne dithering macht.
v15 EGL/ v17: Videos können 1:1 nach dem decodieren per zero copy angezeigt werden, 4k@60 läuft problemfrei. Gilt für h264 und hevc-8bit (auf Braswell oder größer). In Kombination mit einem Kernel Patch (den OE und LibreElec) haben werden die Farben zusätzlich vom Kernel auch nicht mehr vermatscht. Zusätzlich gibt es Dithering das hilft banding effekte durch etwas random noise zu verbessern.