Meines Wissens ist der "USB-Token" der Empfänger der Fernbedienung (alles per Funk, bis auf ein- und ausschalten)
siehe: hier
Meines Wissens nach ist der USB-Token ein Dongle der von einem Wetek-Kernelmodul abgefragt wird, um sicherzustellen, dass die Software nicht auf Clones ausgeführt wird. Die Fernbedienung ist in einem 2. USB-Stick.
Bei der OpenELEC-Edition der Play ist dieser Dongle auf das Mainboard gewandert.
Gerald
könnte mir jemand ein update bzgl. cubieboard / raspberry pi und Benutzbarkeit als vdr remote client geben?
Man, der Thread ist 3 Jahre alt! Ich kann nur sagen, dass die Geräte Raspberry PI 0/1/2/3, Odroid C2, Wetek Play/Core/Hub/Play 2 mit Librelec und Kodi mit meinem VDR auf basis von yaVDR-Paketen funktionieren.
Gerald
hallo. ich habe IVDRCleint mit IVDR aber leider bekomme ich kein stream mit IVDRCleint.
mit webbrowser geht es aber mit das app nicht.
ich habe beim app zwar die epg´s aber wenn ich auf stream gehe kommt nur cann nicht verbinden und kein stream liefern.
Wie Frodo schon sagte, das ist kein yaVDR-Thema.
Gerald
Ich komme auf den Server, aber beim Download per Webbrowser bekomme ich schon eine Fehlermeldung. Irgendwas mit "Wrong Parameter". Dabei baut den Request ja deren Seite zusammen. Meine Verlängerung ist erst wieder Dezember 2017 fällig.
Ich habe das mal gemeldet.
Gerald
Zitat
Doch kein HDMI 2.0 und die 4K-Auflösung wird bloß hochskaliert: Mit diesen Klarstellungen sorgt Asus in der FAQ zum Tinker Board für Ernüchterung. Der mittlerweile von mehreren deutschen Versandhändlern für 60 Euro zur Vorbestellung angebotene Raspberry-Pi-Konkurrent verliert damit an Attraktivität, hatte Distributor Farnell doch HDMI 2.0 versprochen. Stattdessen gibt es laut Asus-FAQ doch nur HDMI 1.4, also 3840 × 2160 Pixel mit maximal 30 Hz Bildwiederholrate. Und diese UHD-Auflösung entsteht durch das Hochskalieren aus dem Full-HD-Format. Die eingebauten Decoder für H.264- und H.265-(HEVC-)Material sollen aber auch 4K-Videos verarbeiten. Doch einen Treiber für diese Hardware-Decoder liefert Asus auch noch nicht.
Das ist witzig, gerade das habe ich eben mit einem Entwickler diskutiert, der bereits ein Tinkerboard hat und damit 4K zum Laufen gebracht hat. Bei ASUS steht nirgendwo, dass es nur HDMI 1.4 gibt, heise hat nur von den 30Hz der Mali GPU den falschen Umkehrschluß gemacht, dass das Gerät nur HDMI 1.4 kann.
Das der Mali nur hochskaliertes HD mit 30Hz als 4K ausgibt ist überhaupt nichts neues und passiert auch so mit Amlogic chips. Hier wird vergessen, dass der Mali aber nur für das Userinterface benutzt wird! Die Videoausgabe erfolgt davon völlig unabhängig und kann sehr wohl 4K!
Ich war erst auch sehr enttäuscht, aber nachdem ich nun weiß, dass einer meiner Entwicklerkumpels es laufen hat, übrigens auch mit HEVC-Hardware decoding. Bin ich erstmal beruhigt.
Gerald
Unlängst hatte ich mal darüber nachgedacht, ob es nicht ganz witzig wäre, wenn der Film, den ich gerade sehe, gestoppt wird wenn ich den Raum verlasse und wenn ich einen anderen Raum mit Wiedergabe-Gerät betrete, dort an der selben Stelle weiter läuft.
Das wäre für mich "Multiroom". Nachdem ich es soweit hatte, dass pausiert wird wenn ich den Raum verlasse (bash script mit bluetooth proximity), habe ich dann die Lust verloren.
Der einzige weitere Raum wo das möglich gewesen wäre, wäre das Kinderzimmer gewesen. Wenn es plötzlich Ärger im Kinderzimmer gibt und ich da hin sprinten muss, und es läuft dort plötzlich "The Walking Dead", dann geht jeder erzieherische Effekt flöten.
Gerald
Außerdem ist nicht ganz klar ob du jetzt die yaVDR-Distribution, oder Ubuntu mit yaVDR-Paketen benutzt. Wenn Letzteres dann bist du in diesem Forum falsch. Der Thread würde dann hierher gehören.
Gerald
Wenn ich mich recht erinnere war der Vorteil von Multiroom dass ein Stream als Multicast gesendet wurde
Okay, aber was ist denn der Anwendungsfall dafür? Wenn man nicht genug Sitzgelegenheiten im Wohnzimmer hat?
Grundsätzlich begreift aber wohl jeder etwas anderes unter dem Begriff Multiroom. Vielleicht äussert sich der TO ja noch mal zu dem Thema und erklärt was er genau möchte.
Genau! Ich habe nämlich auch das Gefühl er stellt sich darunter etwas vor, was für uns schon lange völlig normal ist.
Gerald
Damit könntest du recht haben. Ich musste allerdings auf den Code schauen, Hut ab!
Wobei das nicht einfach ein GCC-Inkompatibilität ist, sondern ein fetter Bug.
gemeint war wohl eher:
*Channel->Name() == '\0'
aber das reicht natürlich nicht wie du schon gezeigt hast, also:
Channel->Name() == nullptr || *Channel->Name() == '\0'Aber so wie du es gemacht hast ist es schon schick.
Tss, ich sehe jetzt erst, dass ich viel zu lahm war und Lars schon einen Spoiler geschickt hatte. Deshalb wusste es Wirbel ohne in den Code zu sehen, Hut wieder drauf.
Gerald
na ja, die Idee war ja eigentlich, dass du da selber rein siehst, ist doch dein Projekt.
Das ist das Problem:
multischedule.ecpp: In member function 'virtual unsigned int {anonymous}::_component_::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&)':
multischedule.ecpp:302:50: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]Gerald
Reel "Multiroom" bedeutet, daß Timer an jedem Client programmiert werden können, aber zentral am Multiroom Server aufgenommen werden.
Danke! Da meine Tuner im Server stecken, passiert das bei mir sowieso. Die Aufnahmen programmiere ich nur über das Live-Plugin per Web-Browser. Über die Kodi-Clients würde es allerdings auch gehen. Also habe ich ja schon "Multiroom", cool.
Gerald
Kann mir mal einer erklären, was dieses "Multiroom" konkret tut? Ist wohl etwas mehr als nur einen Film gleichzeitig in mehreren Räumen abzuspielen, oder?
Gerald
Das bedeutet doch wohl, dass die Bibliothek libpages.a im Verzeichnis pages nicht gebaut wurde. Also ist das Problem wohl deutlich früher. Die Ausgabe vom Build von libpages wäre also wesentlich interessanter als die Zeile vom Linker.
Gerald
Mit load von 1.0 bei minimalem Takt laesst sich hervorragend leben. Das zeigt nur, dass das System optimal reagiert.
Ich persoenlich bin erst beunruhigt, wenn der Load groesser als die Anzahl der Kerne auf der Kiste ist; dann laeuft was schief.
Sehe ich genauso, ein System, dass die meiste Zeit gegen 0 load hat ist dramatisch überdimensioniert.
Gerald
Load bedeutet nicht das ein Prozess auf CPU warted. Sondern auf eine Ressource (was natürlich CPU sein kann).
Ein hoher Load bei wenig CPU Auslastung ist in der Regel das warten auf I/O z.B. der Festplatte.
Richtig, aber wenn der Unterschied zwischen System 1 und 2 nur die DD-Karte ist, dann bezweifele ich, dass es am I/O liegt. Die DD-Karte erzeugt ja keinen traffic auf der Platte.
Gerald
Wie kann ich rausfinden auf welchen Prozess die CPU grad wartet ?
Das muss ja kein Prozess sein, der Kernel ist ja auch noch da. Die DD-Karte erzeugt doch ständig Interrupts, ob da nun jemand darauf wartet, oder nicht ist egal. Bei jedem Interrupt wird der Interrupt-Handler des Kernel-Treibers aufgerufen.
Mit
watch cat /proc/interruptskannst du sehen was da so passiert.
Gerald
werde als naechstes ein wenig mit libreelec herumspielen und package.mk - dateien fuer serdisplib, graphlcd-base und das graphlcd kodi addon erstellen. mal schauen, ob ich ein libreelec-image mit diesen zusammenbekomme ...
Bei Bedarf könnte ich versuchen eine Einladung in den LibreELEC-Slack-Channel für dich zu bekommen.
Gerald
Die kenne ich noch nicht! Läuft da auch VDR?
klar
Welche Dist?
Easy für Rasp?
Die Frage verstehe ich nicht.
Gerald
Ganz so schwarz-weiß würde ich das nicht sehen. OpenSuSE hat auch ein große zufriedene Nutzergemeinde, das funktioniert nicht schlechter als die anderen genannten ... eben X11 muss halt laufen.
Das stelle ich gar nicht in Frage, nur ist diese Nutzergemeinde aber nicht gewillt, oder nicht in der Lage, einigermaßen aktuelle VDR-Pakete zur Verfügung zu stellen. Da hilft dann zypper auch nicht weiter.
Gerald
Bei dem kurzen Test, den ich mit MLD gemacht habe, hat das alles auf Anhieb prima funktioniert. Daher dachte ich, das sollte sich ja wohl hinkriegen lassen. Aber so einfach ist das anscheinend nicht. ich weiß schon, warum ich immer auf FF-Karten gesetzt habe ;-).
Na ja, aber das liegt doch an SuSE und nicht an softhddevice. Siehe MLD, und mit Debian/Ubuntu, Archlinux und dem Zeug von den Gentoo-Rittern hättest du deutlich weniger Probleme gehabt.
Gerald
