Beiträge von kls

  • MaxPixmapSize per default auf 2048x2048?

    Wenn ich mich richtig erinnere wurde cOsd::MaxPixmapSize() seinerzeit wegen Problemen mit zu großen Pixmaps beim Raspberry Pi eingeführt. Interessanterweise wird der Standardwert von 2048x2048 in der default Implementierung von cPixmapMemory gar nicht kontrolliert. Man könnte also unter Ignorierung von MaxPixmapSize() beliebig große cPixmaps anlegen ;-).


    Da eine Pixmap ein hardware-implementiertes Objekt sein kann, macht es schon Sinn, dass es da eine Obergrenze für die Größe gibt. Beim RasPi ist die nunmal 2048x2048. Das heißt, wenn wir den Defaultwert vergrößern, dann könnte man zwar mit softhddevice vielleicht größere Pixmaps anlegen, aber auf dem RasPi würde das dann nicht funktionieren (damit wären die RasPi-Benutzer die "angearschten" ;-).


    Mal angenommen, der Defaultwert wäre "unendlich", was würdest du denn dann in deiner Skin flatPlus machen, wenn auf dem RasPi 2048x2048 als Maximum angegeben wird?


    Eine mögliche Lösung für vertikales Scrolling von Texten ist im osddemo-Plugin mit ScrollPixmap gezeigt.

    Für einen horizontal scrollenden Text könnte ich mir vorstellen, diesen einfach in mehrere cPixmaps, die maximal MaxPixmapSize groß sind, auzuteilen und diese hintereinander "durchzuschieben".


    Klaus

  • [skinnopacity] invalid lock sequence report ... mit vdr-2.4.0 und skinnopacity(gepatcht)

    Wenn ich mir den Backtrace hier so anschaue, dann fällt auf, dass da aus dem Konstruktor von cDisplayChannel ProcessKey() und damit Flush() aufgerufen wird, während der Lock auf die Channels gehalten wird.

    Probier es mal bitte hiermit:

    Klaus

  • Suche Rat bzgl. Glasfaser

    Ich hatte extra die Schirmung des Kabels nur auf einer Seite angeschlossen und ein spezielles, galvanisches Trennglied für Ethernet-Kabel vebaut. Hat aber anscheinend alles nichts genützt...


    Klaus

  • Suche Rat bzgl. Glasfaser

    Ich habe eine Netzwerk-Verbindung (Kupferkabel, ca 20m) zwischen zwei benachbarten Häusern (mit galvanischem Trennglied). Bei einem Gewitter hat es mir kürzlich die Switche an beiden Enden zerlegt (interessanterweise nur den jeweiligen Port, an dem das Kabel angeschlossen war, sowie den jeweils benachbarten Port). Jetzt wollte ich zum Schutz vor Überspannungen sowas hier einbauen, aber das erhöht die Dämpfung anscheinend dermaßen, dass es zu immensen Paketverlusten kommt (Größenordnung 50%).


    Ich überlege daher, die Verbindung über eine Glasfaser-Leitung zu machen, was neben dem Vermeiden von Überspannungen auch gleich noch die galvanische Trennung erledigen würde. Leider kenne ich mich mit diesem Thema gar nicht aus, und es gibt da anscheinend einiges zu beachten. Was ich wohl brauche sind zwei Converter von Kupfer auf Glasfaser, aber da geht's schon los: "Multi-Mode", "Single-Mode", "SFP" - wenn man sich da nicht auskennt, kauft man wohl schnell was Falsches...


    Ich liste daher einfach mal meine Randbedingungen auf und würde mich über Tipps und Hinweise freuen:


    - Die Strecke zwischen den beiden Switches beträgt ca. 20 Meter.

    - Es soll eine Gigabit-Verbindung sein.

    - Das Kabel muss durch ein Leerrohr mit ca. 18mm Innendurchmesser passen. Da die Stecker ja wohl fest montiert sind, betrifft das wohl in erster Linie die Abmessungen der Stecker.


    Vielleicht hat ja schon mal jemand ein ähnliches Problem gehabt und kann mir weiterhelfen.


    Klaus

  • Timer ist gesetzt und Antenne dreht sich every hour

    Dein Timer benutzt anscheinend VPS. Bei VPS will VDR einmal pro Stunde auf den betreffenden Kanal schalten, um den entsprechenden Event aktuell zu halten (die Startzeit könnte sich ja verschieben).


    Mögliche Aktionen:


    - Timer ohne VPS aufnehmen lassen.

    - in vdr.c die Macros VPSLOOKAHEADTIME und/oder VPSUPTODATETIME verändern.


    Klaus

  • [strace] 0kb 00001.ts

    Und prompt sehe ich natürlich, dass meine Ausgabe drei Zeilen weiter hinten reingehört hätte:

    Code
    1. for (int i = 0; i < MAXRECEIVERS; i++) {
    2. cMutexLock MutexLock(&mutexReceiver);
    3. cReceiver *Receiver = receiver[i];
    4. if (Receiver && Receiver->WantsPid(Pid)) {
    5. fprintf(stderr, " %d", i);//XXX
    6. Receiver->Receive(b, TS_SIZE);

    Ist aber egal, denn so wie es aussieht kommen überhaupt keine TS-Pakete an (kein "FOO-DBG [005] d").


    Warum sich das in den beiden Fällen unterschiedlich verhält kann ich mir leider auch nicht erklären.


    Klaus

  • [strace] 0kb 00001.ts

    Das kann eigentlich nicht sein, denn das ist die zentrale Verteilstelle für TS-Pakete.

    Die Ausgabe erfolgt nach stdout, nicht ins Logfile!


    - Zeile an der richtigen Stelle eingefügt?

    - device.c neu übersetzt und vdr gelinkt?

    - VDR neu gestartet?


    Klaus

  • vaapidevice unter openSUSE 42.3 compilieren

    Ich habe dann mal http://packman.inode.at/suse/openSUSE_Leap_15.0 zu den Repos hinzugefügt (mit Priority 98, anscheinend bedeuten kleinere Werte eine höhere Priorität!?) und die Schritte ausgeführt, die 447377 vorgeschlagen hat (Ausgabe gekürzt wg. 10000-Zeichen-Limit):

    Tja, jetzt weiß ich nicht, was ich da antworten soll...


    Klaus

  • vaapidevice unter openSUSE 42.3 compilieren

    Ich habe jetzt mal die Beta von openSUSE Leap 15.0 installiert (nebenbei: seltsame Versionsnummerierung, 10, 11, 12, 13, 42, 15 ;-) und einfach alles nachinstalliert (via YaST), was beim Compilieren von vaapidevice angemeckert wurde. Am Ende sah es dann so aus:

    Das Paket libxcb-icccm4 ist zwar installiert, ein entsprechendes "devel"-Paket gibt es aber nicht.


    Die Pakete libavcodec57 und libavcodec-devel sind installiert, aber es wird dennoch ein fehlendes libavcodec/avcodec.h angemeckert.


    Weiter im nächsten Post...

  • vaapidevice unter openSUSE 42.3 compilieren

    Der_Pit : Packman habe ich jetzt eingetragen, aber wenn ich libavcodec-devel 3.4.2-12.8 installieren möchte, dann sagt er mir

    Code
    1. ffmpeg2-devel-2.8.13-32.1.x86_64 conflicts with libavcodec-devel provided by libavcodec-devel-3.4.2-12.8.x86_64
    2. ...
    3. Possible Solutions
    4. [ ] Following actions will be done: see below
    5. [ ] do not install libavcodec-devel-3.4.2-12.8.x86_64

    und das war's dann.

    Gibt es denn nicht irgendwo ein "Complete Idiot's Guide To Installing vaapidevice-Plugin? ;-)


    Klaus

  • vaapidevice unter openSUSE 42.3 compilieren

    Hab den Beitrag von hier wiedergefunden und die darin empfohlenen zypper-Aufrufe gemacht. Das hat anscheinend das komplette System upgedatet. Aber vaapidevice lässt sich nach wie vor nicht compilieren:

    Klaus

  • vaapidevice unter openSUSE 42.3 compilieren

    Ich komme jetzt endlich dazu, den VDR, den ich bisher nur provisorisch für die Entwicklung des MTD zusammengestöpselt hatte, "wohnzimmertauglich" zu machen :-). Dazu möchte ich für die Wiedergabe das vaapi-Plugin verwenden, welches aber leider etliche Libraries in neueren Verionen voraussetzt, als sie in openSUSE 42.3 vorhanden sind.


    Weiß jemand, ob man diese durch Hinzufügen eines geeigneten Repositories im YaST auf einfache Weise bekommen kann? Oder muss man sich die querbeet zusammensuchen?


    Klaus

  • DSGVO - Das Aus für den VDR User Counter

    Das Problem ist halt das ganze Brimborium, das wegen der DSGVO künftig nötig ist. Das zielt natürlich alles auf die "Großen" wie Facebook, Google, Amazon und wie sie alle heissen. Aber treffen wird es nur die "Kleinen", die sich kein Heer von Anwälten leisten können.


    Am einfachsten wäre es ja, wenn es irgendwo heissen würde, dass das Ganze nur für kommerzielle Anbieter gilt, aber einen solchen (verbindlichen) Passus habe ich leider nirgens gesehen. Im Zweifelsfall gehe ich da halt lieber auf Nummer sicher...


    Klaus

  • DSGVO - Das Aus für den VDR User Counter

    Ich habe den VDR User Counter jetzt so geändert, dass er nur noch eine Email-Adresse für die Bestätigung erfragt, aber keinen Namen, öffentliche Email-Adresse oder Homepage mehr. Die entsprechenden Daten habe ich auch vom Server gelöscht. Ich hoffe mal, dass damit der DSGVO genüge getan ist, denn es ist ja kein Eintrag mehr einem bestimmten Benutzer zuzuordnen.


    Fragt sich nur noch, was mit der "People"-Seite geschehen soll, denn da stehen ja noch Namen, die mit der entsprechenden VDR User Nummer verknüpft sind. Da sich auf der Seite eh schon länger nichts mehr getan hat und die vorhandenen Einträge vielleicht schon veraltet sind, tendiere ich dazu, sie ganz zu löschen.


    Klaus

  • DSGVO - Das Aus für den VDR User Counter

    Die neue DSGVO ("Datenschutzgrundverordnung") tritt ja demnächst in Kraft, und ich befürchte, das ist das Aus für den "VDR User Counter" - zumindest in seiner jetzigen Form.


    Die Angabe von Name, Email-Adresse und Homepage-URL zur Veröffentlichung sind zwar freiwillig, aber ob das alles mit der DSGVO vereinbar ist, wissen die Götter. Und bevor sich irgendwann ein Winkeladvokat findet, der meint, mich deswegen abmahnen zu können, nehme ich es lieber ganz vom Netz. Allzu groß ist der Verlust eh nicht, da von einstmals mehr als 2000 Usern gerade mal 352 übrig geblieben sind.


    Eine Möglichkeit wäre noch, Name, Email und Homepage ganz zu entfernen und das Ganze völlig anonym zu machen. Verliert dann zwar an Charme, wäre aber vielleicht DSGVO-konform(er).


    Klaus