Beiträge von monarc99

Zitat von merlintm

Bash

michi@track:~/Downloads/test$ sudo dd if=OpenELEC-RPi.arm-6.0.1.img of=/dev/mmcblk0p1 bs=4M

Das .img Image ist eine Datei samt Bootmanager, voreingerichteten Partitionen usw ...
Das .tar enthält nur die Openelec Dateien.

Wenn du das tar Installieren willst, richtest du Partitonen, Bootmanager usw. selbst ein. (-> http://wiki.openelec.tv/index.php/Manual_Installation)
Beim img schreibst du es über das gesamte Device und nicht auf eine Partition dieses Devices. Du willst ja auch den Bootmanager überschreiben.

Zitat von custin

Dann bespielte ich sie weiter an dem Win10 Rechner und jetzt geht wieder nix mehr.

Die Platte kann in einem unstabilen Zustand sein, weshalb Linux sie nicht mounten möchte.

Ab Win8 und aufwärts gibt es "Windows Fast Boot" ... der Name ist etwas irreführend, weil Windows damit nicht schneller bootet, sondern nur noch halb runterfährt. (und dabei die angeschlossen Festplatten nicht abschliesst)
Würde Linux so eine Platte mounten, besteht die Gefahr dass der ganze Inhalt verloren gehen kann, wenn die Win10 sie das nächste mal verwendet.

Also die Platte wieder an Win10, Windows Fast Boot deaktivieren und die Platte von Win10 richtig abschliessen lassen. Und dann nochmal am Linux probieren.

Zitat von killercorny

Programmtechnisch denk ich ist das relativ unkompliziert zu lösen. Bei Abbruch einfach Reconnecten und neu synchronisieren.... Es muss halt nur jemand programmieren ^^.

Gibt es denn da einen internen KODI Befehl, den man sich auf ne Taste legen kann?

Du hast Ubuntu 14.04 (die Zahlen geben das Datum an, also erschienen April 2014)
Könnte sein, dass das vielleicht schon zu alt wird. z.B. zu alter libva Library, die bei dir für VAAPI zuständig ist.

Was du probieren kannst, wäre, dass ganze System zu upgraden. Also von 14.04 auf 15.04 und wenn du es nochmal wiederholst auf 15.10.

http://kodi.wiki/view/Kodibuntu#Upgrading_OS_base

Normalerweise installiert man aber komplett neu, weil so ein System Update auch schief gehen konnen und dann eventuell nix mehr bootet.
Aber wenn du eh irgendwas neu installieren musst.

Funktioniert

Musste zwar erst ein node 0.12 auftreiben, was bei dem arm wheezy debian wohl das höchste ist. Aber er zeigt die Kanäle an.
Aufs EPG kann man vermutlich nicht zugreifen?

Zitat von JensK

So alle Tests erfolgreich abgeschlossen und die Ursache gefunden. Es liegt an SSDP Announcements meines SAT Receivers. Wohlgemerkt, der macht nichts falsch.

Auf dem SAT Receiver laeuft ein xupnpd daemon, also ein einfacher UPNP server. Dieser schickt mit default Einstellungen alle 5 Sekunden seine SSDP Announcements ("ich habe was und kann anbieten") in die Welt hinaus.

Und genau das kickt die Shield nach ner Weile ab.

Guter Fund

Nur kickt er die Shield ab oder Kodi?
Kodi kann ja auch auf Port 1900 lauschen und dadurch außer Tritt kommen.

Zitat von jojo

Nachteile(!)

Es muss ein extra node.js Server gestartet werden bzw. der von mir verwendet werden.

Ich würde mich sehr über etwas feedback freuen!

Klingt interessant Muss ich mal ausprobieren.

Ist es denn aufwendig, den node.js Server lokal (z.B. auf einem Rasp oder anderen) aufzusetzen?

Zitat von skybird1980

An sich eine interessante Idee. Vertrauenserweckender wäre aber ein Einbau in ein z.B. .net Programm welches Lokal ausgeführt wird.
Wie Du schon selber sagst senden die Leute Dir damit die Logindaten.

Äh, nein ... du brauchst einen Server, auf den Kodi zugreifen kann. Das erledigt der node.js Server -> https://nodejs.org/en/download/
Denn setzt du einfach lokal bei dir irgendwo auf und lässt diesen jojos Script dort laufen, der als Bindeglied zwischen Kodi und Zattoo dient.

Zitat von JensK

Also nix. Da laeuft auch nicht viel drauf. Nen Apache, ein Ftp, SSH, Samba und NFS Server sowie ein Stueck anderer Serversoftware. Diese macht aber kein Broadcast, sondern nur dedizierte Port zu Port Kommunikation auf UDP Protokoll, welche statisch auf IP Level konfiguriert ist und somit niemals mit der Shield redet.
PS: Der Test im seperaten Netz war erfolgreich. Also ist die NIC in Ordnung und es ist definitiv irgendwas in meinem Netzwerk.

Bleibt eigentlich nur ausprobieren, bei welcher Hardwarekombination es wieder auftritt. Ne einzelne Box oder ein Zusammenspiel mehrerer Boxen.

Vorallem es tritt ja auch auf, wenn von USB abgespielt wird. D.h. die Shield wird vom Netzwerk derart angegangen, dass sie aus dem Tritt kommt, obwohl sie selbst nix aus dem Netz holt.

Zitat von JensK

Leider noch nichts gefunden. Aktuell habe ich erstmal ein extra Netzwerk mit nem geliehenen Router aufgebaut, um ein Fehler in der NIC der Shield 100%ig auszuschliessen.

Mein Debian Rechner, ne kleine Iomega iConnect ist schweigsam wie ein Grab. Die laeuft sei 124 Tagen und in den Logs ist einfach nichts zu sehen. Im Syslog sieht man brav die DHCP renewals, ein wenig cron Jobs, alles sauber.

Und was spuckt der Befehl dmesg aus?

Da bin ich gespannt, von welcher Kiste das ausgeht Schon was gefunden?

Ist denn beim Debian Server etwas im Kernel Log zu finden? Der Linux Kernel ist da immer ne gute Quelle, wenn man solchen Problemen auf der Spur ist.

Was für ne Hardware hast du denn?

Dann kann man nachsehen, welchen Treiber du brauchst.

Host CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz, 1 core available
GL_VENDOR = VMware, Inc.
GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)

Ich lese das so ...

In einer vmware gestartet. Zur Verfügung steht 1 CPU mit 1 Kern mit 2.66 GHz.
Der Grafikkarte ist: Gallium 0.4 on llvmpipe ... das ist glaube ich ein Software Renderer.
Sprich der 1 Kern muss gerade alle Aufgaben der CPU + Grafikkarte übernehmen. Das kann ihn schon auslasten.

Zitat von mohol

Jetzt muss ich mir mal einen h265 Film besorgen.

Wenn du auf ne zukünftige Box schaust, ist die Frage, was du von ihr erwartest?

Bei H264 ist es einfach -> 1080p mit H264 und (automatisch) 8bit Farbtiefe. Damit war man safe und alle heutigen Player unterstützen das auch so per HW. Egal welches H264 File, es sollte i.d.R abspielen.

Bei H265 kommt jetzt neben 8Bit noch 10Bit Farbtiefe dazu. Und bei der Auflösung neben 1080p auch 4K.
Ob man jetzt 4k braucht oder nicht, aber wenn man wieder so einen Safe Point bei H265 bestimmen möchte, müsste der Player H265 bei 4K und 10Bit unterstützen. Dann kann bei H265 kommen was will, der Player sollte es per Hardware Decoder spielen.

Die Player für H265, die man heute so kaufen kann, können meist nur einen Teil davon. Also z.B. nur 8bit und keine 10bit. Und die allerwenigsten 4k.
Wer also explizit einen Player für H265 kaufen will, sollte noch die Option dazurechnen, dass er vielleicht noch ne Generation abwartet.

Ähnliches gilt für VP9: Googles Youtube Codec
Momentan unterstützt KODI kein DASH. Also alle Streams von Youtube sind auf 720p mit H264 limitiert.
An DASH in KODI wird aber gerade gebastelt, d.h. Youtube Video mit 1080p oder 4k wären dann vermutlich möglich. Die gibt es aber nur mit dem VP9 Codec.
Wer also viel Youtube kuckt und dort Videos in höherer Auflösung irgendwann kucken möchte, muss auch im Auge behalten, ob der Player VP9 per HW decodieren kann.

Nur als Überblick, wie es an der Codec Front gerade so aussieht.

Übrigends:

4K HEVC 10Bit Demos, wie sie Bluray und Satellit geplant sind, gibts hier:
http://demo-uhd3d.com/categorie.php?tag=hevc

Schalte mal bei komponenten [definition='1','3']Debug[/definition] Video / Audio und FFMPEG auf aktiv und spiele nochmal eine Datei nur mit Software Decoder ab. Vielleicht sieht man dann was.

das ist der reine Software Decoder ... also alles über den i7

Bei dc steht, welcher Codec die Decodierung gerade macht.
z.B. bei mir unter Linux verwendet er "ff-h264-vdpau" ... am Namen sehe ich, dass er gerade per GPU dekodiert.

Schau in den Codecinfos (Taste o) ... was steht da bei dc: ?

Das ist dann bei dir reine Software Decodierung bei dir? Also über den i7?

Zitat von waffi

Ja das stimmt. Normales 1080p rechnet ja der TV auch selber hoch.

Zitat von b0mb

Ich möchte ja stark bezweifeln, dass sich 60FPS im Filmbereich zeitnah, wenn überhaupt, etablieren werden.

Ich überlege gerade, wer skaliert eigentlich? Player (Kodi/Grafikkarte) oder der TV?

Wenn der alte (FullHD)-TV seinen Geist aufgibt und man sich einen neuen anschafft, kann man sich ja auch nen 4K TV kaufen. So viel teuerer scheinen sie ja nicht mehr zu sein.
Und egal ob man 4kp50 oder 720p50 (also normales öffentlich rechtliches TV) abspielen möchte, wird das wohl auf die native Auflösung des TVs (4k) skaliert werden.

Also z.B. 720p50 -> 4kp50. Wenn der Player das machen muss, braucht man automatisch nen HDMI 2.0 Ausgang am Player für einen 4k TV, oder?

Zitat von b0mb

Also vom Handing her ist SMB wesentlich einfacher zu handhaben.
NFS ist, so finde ich, immer für eine Fehlerquelle gut.
Ich habe mal was gelesen, das NFS im Vergleich zu SMB aufgrund des fehlendes Overheads unter optimalen Bedingungen 1 oder 2 MB mehr bringt.

Was meinst du mit Handling? Einrichtung oder drauf zugreifen?

Also Fehlerquelle macht NFS, einmal eingerichtet, eigentlich keine großen Probleme.
Der Unterschied zwischen NFS und SMB ist, dass SMB versucht sich "selbst" zu konfigurieren/koordinieren, während NFS ein klassischer Serverdienst ist.
D.h. bei NFS brauchst du zum Konfigurieren Unix-Hintergrundwissen, um es am Anfang zum Laufen zu bekommen. Das fällt vielen schwer, wenn man nur Windows kennt.
Bei SMB/Samba hat man es da am Anfang leichter, man kommt schneller zum Ziel. Da laufen dann aber im Hintergrund zwischen den einzelnen Instanzen komplexe Dinge ab, wenn es dann mal zwickt, musst du das studiert haben, um es lösen zu können.
Beides seine Vor- und Nachteile.

Bei Performance: SMB und NFS sind für verschiedene Zwecke gedacht

• SMB ist ein "Netzlaufwerk" (also Lesen und Schreiben gleich wichtig)
• NFS fürs Verteilen von Dateien vom Server zu den Clients (also nur 1 Richtung -> Lesen vom Server schnell, Schreiben zu Server langsam)

Das sieht dann so aus:

Die Vorteile hat NFS also nur, wenn es ums Lesen vom Server(NAS) zum Client(Kodi) geht.
Wenn man Lesen&Schreiben zusammen addiert, biste bei den 1-2 MB Unterschied.