Posts by S:oren

    Aktuell nutze ich das remote-plugin, darüber klappt das sicherlich nicht?

    Das klappt, man muss nur die Fernbedienung neu anlernen, d.h. remote.conf loeschen (umbenennen als Backup), dann vdr neu starten. Die mitgelieferte Fernbedienung der S2-6400 (keine Keycodes ueber 0x40) habe ich sogar gleichzeitig zu der CEC-Fernbedienung nutzen koennen, dazu beide Fernbedienungen getrennt anlernen, dann die beiden remote.conf zu einer hintereinanderhaengen. Keine Garantie, dass das in Zukunft noch funktionieren wird...
    Gruss,
    S:oren

    Solcherlei macht die Firmware nicht, es wird der original code zum PC geschickt verodert mit 0x80000000. Kommen diese Werte so im Treiber an ("REMOTE EVENT: xxx" im syslog bei verbose=3)?

    Diese Werte habe ich als Keycodes mit evtest und im remote-plugin gesehen.


    Mittlerweile habe ich auch die Stellen im Treiber gefunden (saa716x_ff_ir.c):
    "ir->key_map = i+1;" und "if (!(ircom & 0x1000)) data |= 0x40;" Dort ist noch kein CEC-Protokolltyp eingebaut, das ist also kein Problem der Firmware. Leider habe ich gerade keinen Zugriff auf den vdr zum Testen eines Patches.


    Bleiben als Wunsch fuer die Firmware das Nichteinschalten des Fernsehers beim Aufwachen (dafuer gibt es ja bei Bedarf das "mHdffCmdIf->CmdHdmiSendCecCommand(HDFF_CEC_COMMAND_TV_ON);" im dvdhdffdevice, was man dann aber auch weglassen kann) und Support fuer CEC SystemStandby.


    Gruss,
    S:oren

    Folgendes Problem habe ich mit einer Philips-Fernbedienung ueber HDMI-CEC:
    die Tasten 'rechts' und 'play/pause' liefern den selben Keycode 69
    die Tasten 'ChannelDown' und 'blau' liefern den selben Keycode 114

    Scheinbar wird in der Firmware zu allen CEC Remote Control Pass Through Message-Codes zuerst eine 1 addiert und dann das Bit 0x40 gesetzt, bevor der Code als Keycode an das input-Device uebergeben wird. Ein einfaches Addieren von 0x40 oder 0x80 wuerde dieses Problem loesen und trotzdem keine (zusaetzlichen?) Kollisionen mit RC5-Codes erzeugen. Oder habe ich 'was uebersehen?

    Ausserdem wuerde ich mich sehr freuen, wenn man die Nutzung von CEC fuer input-events getrennt vom Einschalten des Fernsehers beim VDR-Start einstellen koennte. (Insbesondere das Einschalten des Fernsehers beim Aufwachen fuer eine Timer-Aufnahme finde ich wenig sinnvoll.)

    ich glaube, das war/ist von UFO auch angedacht worden (remote-plugin)
    Gruß Fr@nk

    Leider wird schon beim Aktivieren von CEC im dvbhddevice-plugin der Fernseher eingeschaltet. Da kann das remote-plugin nicht mehr viel machen, denke ich.


    Noch ein Wunsch:
    Bitte auch bei CEC System Standby Messages ein input-event erzeugen.


    Nochmal, am besten gleich mit diesem neuen Post hier als Referenz:
    Copperhead: bitte in die Liste aufnehmen


    Danke,
    S:oren

    Habe ueber Weihnachten einen HD-VDR aufgebaut, die S2-6400 funktioniert wirklich gut, vielen Dank an die Entwickler!


    Folgendes Problem habe ich mit einer Philips-Fernbedienung ueber HDMI-CEC:
    die Tasten 'rechts' und 'play/pause' liefern den selben Keycode 69
    die Tasten 'ChannelDown' und 'blau' liefern den selben Keycode 114


    Vielleicht gibt es dafuer einen Fix in der Firmware.


    Ausserdem wuerde ich mich sehr freuen, wenn man die Nutzung von CEC fuer input-events getrennt vom Einschalten des Fernsehers beim VDR-Start einstellen koennte. (Insbesondere das Einschalten des Fernsehers beim Aufwachen fuer eine Timer-Aufnahme finde ich wenig sinnvoll.)


    Copperhead: bitte in die Liste aufnehmen


    Danke,
    S:oren

    Hallo winni,


    hier ist die versprochene neue Version des vdr.epgsearch-exttimeredit-Patch, damit funktioniert die Timeruebersicht jetzt auch wie gewuenscht. Die Erkennung geloeschter Timer in cMenuTimerItem::Set ist etwas unelegant, vielleicht hat da ja irgendjemand noch eine bessere Idee.


    Im zugehoerigen Patch von epgsearch werden die Timer in cMenuMyEditTimer jetzt direkt programmiert. Die Abhaengigkeit des Timereditmenue-Service von der Setup-Option habe ich drin gelassen, da VDR-Patches ueblicherweise nur in die grossen Patchsammlungen uebernommen werden, wenn sie abschaltbar sind. Kannst Dir ja ueberlegen, ob Du das mit uebernimmst. Die Einrueckungen im Code sind moeglicherweise nicht immer sinnvoll, da ich aus der Mischung von Tabs und Leerzeichen nicht so recht schlau geworden bin.


    Gruss,
    S:oren

    Hallo winni,


    alles klar, fuer Suchtimer ist SVDRP Pflicht.
    Mein Problem mit dem Update der Timeruebersicht haengt mit cMenuMyEditTimer::ProcessKey zusammen. Das wird - falls ich nichts uebersehen habe - immer im Vordergrund-Thread ausgefuehrt (Tastendruecke im OSD-Menue auswerten, wie von Klaus beschrieben). Ich denke, dass man hier also immer die Timer direkt programmieren kann, auch wenn diese Methode ueber das Service-Interface benutzt wird.
    Hast Du etwas dagegen, cMenuMyEditTimer::ProcessKey auf direkte Timerprogrammierung umzustellen? Ich wuerde sonst einen entsprechenden Patch vorbereiten...


    Gruss,
    S:oren

    Mir sind noch 2 Probleme mit meinem vdr.epgsearch-exttimeredit-Patch aufgefallen:
    1. Beim Anlegen neuer Timer aus der Timeruebersicht wird immer noch das Standard-VDR-Timeredit-Menue verwendet.
    2. Die Timeruebersicht wird nicht aktualisiert.


    Das erste Problem ist schnell zu fixen (da kann ich nochmal einen neuen Patch bauen), das 2. Problem ist nicht so trivial, da der Timer von epgsearch nicht direkt geaendert wird, sondern in einem Extra-Thread, der auch noch so lange wartet, bis die Timeruebersicht geschlossen wird.


    winni, gibt es einen Grund fuer das relativ komplizierte Verfahren mit Thread und SVDRP? Hier etwas zu aendern waere ein groesserer Umbau.


    Gruss,
    S:oren

    Hallo winni,


    von mir aus kannst Du den patch gerne mit epgsearch ausliefern, wenn Du ihn für gut genug hälst ;) .
    Die Abhängigkeit von der Setup-Option habe ich analog zu der Setup-Option des Main-Menu-Hooks eingebaut, damit die Menüs zwischen EPG-Aufruf und Übersichtsaufruf nicht inkonsistent sind (wie bisher, nur umgekehrt). Lass den patch weg, wenn er Dir nicht gefällt; wenn man die Standard-VDR-Menü-Option 'rausnimmt, gibt es sowieso kein Problem. Denkbar wäre auch eine weitere Service-Funktion, die im Gegensatz zu der bisherigen auf die Option reagiert, andererseits kann ich mir nicht vorstellen, dass jemand im epgsearch das neue Menü abschaltet und dann doch über den Service von einer anderen Stelle darauf zugreifen will.


    Gruß,
    S:oren

    Ich habe hier mal einen patch für den 1.6er VDR gebaut, um das epgsearch-timeredit-Menü auch aus der Timerübersicht heraus verwenden zu können. Dann ist noch ein patch für epgsearch angehängt, damit man doch das Standard-VDR-Timeredit-Menü bekommt, wenn es im epgsearch so konfiguriert ist.
    Vielleicht hat sonst noch jemand Verwendung dafür.


    Gruß,
    S:oren

    In der README.DE steht, dass man im Timer-Edit-Menü benutzerdefinierte Wochentage für Wiederholungsaufnahmen nutzen kann. Mir gelingt es nicht, eine Aufnahme zu programmieren, die dienstags bis freitags gilt. Habe ich da etwas falsch verstanden, oder hat jemand einen Tipp für mich!?


    Danke,
    S:oren


    PS: Vielen Dank an Winni für das tolle Plugin!

    Quote

    Originally posted by speed
    also ich, bzw alle hier in meinem Haushalt,finden die transparenten Themes wirklich toll.
    Wir würden es toll finden, wenn das in einen Setup einstellbar wäre.
    speed


    Also ich finde transparente OSDs auch wirklich toll. Ich stelle das unter Einstellungen->Plugins->Skinelchi->Colors ein. Fuer andere Skins ist das natuerlich woanders.


    Nichts für ungut...
    S:oren

    Ich war der Meinung, dass die Endtransparenz eine Eigenschaft des Skins sein sollte und nichts mit dem Soft-OSD zu tun hat. Aber genau wie der Wahl des Einstellungsmenues ist das sicher Geschmackssache, kann sich jeder passend hinbiegen, falls er moechte. Je mehr variable Parameter vorhanden sind, umso groesser ist normalerweise der Wartungsaufwand.
    Wenn schon ein zusaetzliches Feature, dann waere es eventuell sinnvoll, das Verhalten im Nicht-Palette-Only-Modus von langsam mit richtigen Farben auf schnell mit falschen Farben und Farbkorrektur im letzten Schritt umzustellen. Hatte ich weggelassen, weil das SoftOSD m.E. sowieso nur mit single osd window und somit moeglichem palette_only-Modus gut aussieht (fluessig und mit richtigen Farben)...


    Gruss,
    S:oren

    Quote

    Originally posted by zulu
    War mehr eine Mitteilung das es da wohl noch klemmt.


    Im git auf vdr-developer.org gibt es eine neuere Version, bei der noch ein paar Sachen aufgeraeumt sind. Falls es auch damit nicht funktioniert, habe ich keine Idee mehr und brauche jemanden mit den beschriebenen Problemen sowie Zeit und Lust zum Debugging...


    Gruss,
    S:oren

    Quote

    Originally posted by woz
    Bitte nicht böse sein ;)


    Wurde eigentlich das Problem bei der Freimachung des primären Devices schon gelöst.


    Ich habe mehrere Kombinationen von FF und budget (PCI und USB) getestet, hat immer prima funktioniert, egal ob ueber FF oder budget empfangen wird. Keine Ahnung, ob eine SkyStar2 so ein besonderes Device ist, oder ob die Probleme von einer ungewoehnlichen VDR-Patchversion kommen oder auf eine besondere Plugin-Kombination zurueckzufuehren sind.
    Die Ferndiagnose ist natuerlich schwierig, wenn das beschriebene Symptom ein allgemeines "geht nicht" ist...


    Gruss,
    S:oren

    Hier ist eine Variante des dvb-softosd patches, wie ich sie benutze.
    Der patch lässt sich unter Einstellungen->DVB einschalten und konfigurieren.


    Dieser patch ist gegen eine nicht ganz aktuelle Version des etobi-multipatch-vdr
    erstellt. Möglicherweise ist bei anderen VDR-Sourcen etwas Handarbeit beim
    Patchen nötig. Aber vielleicht hat trotzdem sonst noch jemand Verwendung dafür...


    Gruss,
    S:oren


    PS: Ich nutze skinelchi mit single 8bpp osd window. So kann "SoftOSD Palette Only"
    fuer fluessiges Blenden bei minimaler CPU-Last aktiviert werden.


    PPS: Vielen Dank an Ardi fuer seine Patchversionen!