Beiträge von gda

    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

    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:

    Code
    1. *Channel->Name() == '\0'


    aber das reicht natürlich nicht wie du schon gezeigt hast, also:

    Code
    1. 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:

    Code
    1. multischedule.ecpp: In member function 'virtual unsigned int {anonymous}::_component_::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&)':
    2. 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

    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

    Code
    1. watch cat /proc/interrupts

    kannst 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


    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

    Das ist sehr schade! Ich dachte eigentlich, daß das für alle, die keine FF-Karten verwenden, das wichtigste Ausgabeplugin wäre - oder täusche ich mich da?
    Da sollte es doch wirklich *eine* verbindliche Quelle geben...


    Na ja, die meisten Anwender bauen ja nicht selbst sondern benutzen Pakete aus Distributionen.
    Da haben sich dann die Distributoren eben schon mit abgequält, sonst wäre der Leidensdruck sicherlich größer.


    Gerald