Beiträge von FireFly

    Ich habe mal etwas am HbbTV URL Plugin weiter gebastelt....


    Was jetzt geht:

    • es werden nicht mehr alle URLs auf dem Transponder herausgefiltert, sondern nur noch die URLs, die zum aktuellen Kanal (Live TV) gehören
    • die URL-Einträge werden mit ControlCode (Autostart/Present), Application ID, Prio und Name im OSD Menü angezeigt (zusätzlich wird die Anzeige auch ins Syslog geschrieben weil da Cut'nPaste besser geht ;D)
    • die Aktualisierung der URL Liste wird sofort nach Kanalwechsel aktiviert, danach läuft sie alle 60 sec (die Liste dürfte relativ statisch sein)
    • im OSD Menü kann mit der roten Refresh-Taste manuell die Liste im OSD aktualisiert werden (das gibt die interne Liste neu aus, es wird kein neuer Scan auf dem Transponder gestartet)
    • im OSD Menü kann man mit PgUp/ PgDown einen Kanal rauf/runter springen, muss dann aber mit dem roten Refresh Button die Liste im OSD selbst aktualisieren
    • wenn man einen Eintrag mit OK auswählt wird ein externer Browser gestartet, der die HbbTV-Seite anzeigt :welle

    Als Beispiel hier mal die URL-Liste von Das Erste und der Eintrag "EPG" in Firefox:

         



    Als Browser ist derzeit FireFox eingestellt (#define BROWSER in hbbtvmenu.c) und er muss die Extension FireHBBTV installiert haben. Der Browser wird über SystemExec detached gestartet, es bleibt also das Fenster unabhängig vom VDR offen. Wahrscheinlich geht es auch mit anderen Browsern wenn sie das von HbbTV benutzte CE-HTML verstehen. Außerdem muss der VDR User die Berechtigung haben, das Browserfenster auf dem Desktop zu öffnen und die DISPLAY-Variable muss stimmen (im Code derzeit hart codiert auf :0).


    Jetzt ist die nächste Frage, wie man das Browserbild in die VDR-Anzeige bekommt.

    Anstatt Firefox könnte man WebKit nehmen, dass es auch als Library gibt wenn ich mich recht erinnere. Kann man bei SoftHDdevice einen Layer davor legen und den von WebKit beschreiben lassen? Ähnlich wie das OSD vor dem Video liegt?


    Happy compiling

    FireFly

    Das burn Plugin wird noch gewartet, aber nicht mehr weiterentwickelt, d.h. ich passe es an neue VDR Versionen an, es wird aber keine neuen Funktionalitäten geben, auch weil sich das Kosumverhalten aufgrund der Speicherpreise verändert hat (wieso noch zig DVDs brennen, wenn man es bequem auf nem 64GB Stick transportieren kann)


    Wo Du den Inhalt des resources-Verzeichnisses hinkopieren musst kann ich Dir leider nicht genau sagen, weil jeder das Resource-Verzeichnis des VDR woanders hinlegt. Ich habe z.B. so eine Meldung im Log:

    Code
    1. vdr: [13758] starting plugin: burn
    2. vdr: [13758] burn: loaded skin Vorgabe using /usr/share/vdr/plugins/burn/menu-bg.png and /usr/share/vdr/plugins/burn/menu-button.png

    Wenn Du dem VDR als Parameter kein --resdir mitgibst, nimmt er das einkompilierte als Default. Mit vdr -h sollte er das anzeigen. Und da kopierst Du dann den Inhalt des resource-Folders aus dem burn-Paket hin.Und warum der ursprüngliche Autor da keine Fehlermeldung ausgibt wenn die fehlen, kann ich Dir auch nicht sagen. Ich werde es aber mal im Hinterkopf behalten, dass bei einer neuen Version im Fehlerfall was ausgegeben wird.




    Ich meinte ja auch nicht jedes einzelne Plugin-Makefile sondern in das globale Makefile des VDR. IIRC wird das dann in vdr.pc geschrieben, die von den einzelnen Plugin-Makefiles eingelesen wird. Wie das genau funktioniert muss aber jemand erklären, der es verstanden hat...

    Deine Fehlerbeschreibung und die Fehlermeldung stimmt mit meinen überein, die ich mit yausbir und dem USB watchdog hatte, allerdings müsste das dann bei allen Kernel mit USB watchdog (IIRC 3.17+) auftreten. An einen HW-Fehler glaube ich auch nicht.

    Leider konnte ich bisher nicht finden, wo die USB-Routinen zum Lesen mit Timeout aufgerufen werden, aber vielleicht liest Du oder jemand anderes sich ja in den Quelltext ein und findet den/die Call(s).

    Du nutzt also nicht LIRC, sondern die Remote Control Treiber des Kernels - wobei mich wundert, dass das da noch nicht angepasst sein soll (Der USB Watchdog ist mit Kernel 3.17 oder so gekommen und das ist ja schon eine ganze Weile her und ich kann mir nicht vorstellen dass das bisher niemand ausprobiert hat).

    Die einzige Stelle, die danach aussieht ist Zeile 214:

    rc->timeout = MS_TO_NS(100);

    aber alle anderen Treiber in diesem Verzeichnis haben auch 100ms als Timeout eingestellt.

    Welche Kernel-Versionen nutzt Du denn auf Deinen Systemen?

    Die Versionen beim aktuellen yavdr sind:


    vdr-plugin-burn/trusty,now 0.2.2-7yavdr3~trusty amd64

    m2vrequantiser/trusty,now 1.1-1 amd64

    Nunja, burn 0.2.2 ist vom Feb 2013 ....


    sosonni schrieb:

    Und bzgl. dem shrinken: burn verschätzt sich schon mal, das stimmt. Die 4 Folgen "The_IT_Crowd" im obigen Beispiel hat burn als ca. 5 GB angezeigt und hat angemerkt, dass die Aufnahmen geschrumpft werden. 5GB ist jetzt nicht viel größer als 4,5GB (DVD) und verrechnet sich trotzdem.

    Eine Idee wäre, den Requant-Faktor ein wenig zu erhöhen, damit das Image öfter/immer auf eine DVD passt. Im folgenden script, könnte man evtl. diesen Faktor beeinflussen, weiß aber nicht wie.

    Genau, ca 5GB sind nicht viel größer als 4,5 GB, nur mal satte 11% ! Und was sind "ca 5GB" ? Bei 5,2 GB sieht das noch schlechter aus.

    Wie Du job::get_requant_factor() in job.c sehen kannst, ist bereits ein Faktor 1,04 eingebaut, also 4% Sicherheit.

    Und um es nochmal zu sagen: weder verschätzt sich burn noch verrechnet es sich, sondern die Requantisierer arbeiten prinzipbedingt nicht genau genug.

    Hast Du mal die Größen der mpv's vorher und nachher verglichen? Was machen die Requant-Programme daraus? Da der Faktor wie oben beschrieben nur eine Richtgröße für die Quantisierung ist, kann das Ergebnis auch größer ausfallen.

    um das mal abzuschließen .....

    Das Problem ist die USB_watchdog-Funktion, die in neueren Kernel eingeführt wurde und Devices rauswirft, wenn nach einer bestimmten Zeit kein USB-Frame mehr geliefert wurde. Da usb_interrupt_read() im Patch einen Timeout von 25ms hat, ist das relativ häufig aufgetreten. Mit einem Timeout von 50000ms, den auch andere Plugins nutzen, funktioniert yaUSBir fehlerfrei.


    Um den LIRC bei Updates nicht jedes mal patchen zu müssen, habe ich den Patch zum LIRC-Plugin umgeschrieben (siehe Anhang). Die Sende-Funktion nutze ich nicht, dafür ist vermutlich doch der LIRC-Patch notwendig da im LIRC noch ein #define geändert wird.

    Vielleicht, funktioniert burn besser in der nächsten Version 0.3.0, da steht in der History:

    Wieso "in der nächsten Version" ? Welche nutzt Du denn?

    Das Problem ist, dass mittlerweile einige Requantisierer im Netz verschwunden sind, tcrequant ist z.B. seit längerem bei transcode nicht mehr dabei. Beim Release von 0.3.0 hatte ich noch diese gefunden:

    M2VRequantiser => 1.1 https://launchpad.net/m2vrequantiser

    requant_lxdvdrip => 1.77 http://sourceforge.net/projects/lxdvdrip/

    Zu der Größe: burn berechnet den Shrinkfaktor und übergibt ihm dem Requantisierer. Was der daraus macht, d.h. ob er sich daran hält, kann burn nicht beeinflussen. Insbesondere bei hohen Kompressionsraten tendieren die Requantisierer dazu, weniger stark zu komprimieren d.h. das ISO-Image wird zu groß. Wenn Du also ein paar MB shrinken willst sollte es meistens passen, wenn Du 30-40-50% shrinken willst ist die Wahrscheinlichkeit hoch, dass es zu groß wird weil die Requantisierer nicht mitspielen.