Posts by Ein Eike

    Wozu soll das gut sein, ausser dass es die Übersichtlichkeit stört?

    Warum hat der Patch das überhaupt eingeführt?

    Wäre die Warnung weg, wenn man diese Änderung im Patch ganz entfernen würde?

    Ich finde initialisierte Daten immer besser als zufällige. Im Zweifel sorgt es für besser verstehbare Fehler, wenn NULL verwendet wird und nicht irgendein 0x0815.


    Aber falls du dich dafür interessieren solltest, den Permashift-Patch in den Core-VDR aufzunehmen, wär' ich total kompromissbereit... ;)
    Ich denke, er hat bewiesen, dass er langlebig ist.

    Ich dokumentier' mal, wie weit ich mit der Fernbedienung komme...


    irw mag nicht, also zurück auf Los - mode2.

    Das hat mir erstmal "Partial read [x] bytes" geliefert.

    Es funktioniert aber, wenn ich es mit mode2 --driver=default starte, dann kommen space, pulse und co.

    Für mich sieht es so aus, als ob im Fehlerfall die ganze DVB-Geschichte noch nicht geladen ist.

    Vermutung, weil es direkt davor kommt: Die 0.1s vom easyvdr-module-loader sind zu knapp.

    Dann müsste die Meldung mit der Firmware noch später im Log auftauchen.


    Zwischenstand: Video scheint gelöst. Ich hab die Verzögerung zum Laden des DVB-Treibers (wenn ich es richtig verstanden habe) von (überaus geizigen!) 0.1 Sekunden auf (natürlich viel zu großzügige) 5 Sekunden gestellt, und fünf von fünf "Kaltstarts" sind zum Video gekommen. Hatte also vermutlich auch nichts mit kalt/warm oder umbooten zu tun, sondern war ein Timingproblem.

    Ich hab schon gelesen, es wird nicht mehr sehr aktiv an EasyVDR 5 gearbeitet. Eine einfache Verbesserung wäre, hier mal per default ein/zwei Sekunden zu gönnen. Cool wäre natürlich sagen wir 10 Sekunden busy waiting, ob der Adapter noch den Hintern hochbekommt.


    Ich geht mir dann mal Lirc und co anschauen...

    Der Fehler mit der Karte dürfte Filgender sein :

    /dev/dvb/adapter1/frontend0: Keine Berechtigung

    Wem gehört die dann?

    Was das mit umbooten zu tun hat, verstehe ich nicht...

    Ein paar Boots später: es hängt nicht fest am "umbooten". Mal geht es beim ersten Mal unter EasyVDR 5, mal nicht. Nun muss ich sagen, dass ich mit dem alten nicht sehr viele Erfahrungen mit neu booten habe, der lief ja wie gesagt lange durch... Könnte also sein, dass dasselbe unter 3.5 auch passiert wäre.


    In den Berechtigungen steht rw für Gruppe video. Aber ein echtes Rechteproblem sollte ja reproduzierbar auftreten.


    Ich hatte noch vermutet, dass es ein Timing-Problem sein könnte und der Treiber vielleicht zu spät bereit wäre. Dann hätte ich vermutet, dass ein Neustart des VDR-Programms helfen könnte. Wenn ich den vom VDR-Menü aus auslöse, bekomme ich aber weder den Gutfall noch den Schlechtfall in den Logs?

    Hallo!


    Ich wollte mein EasyVDR-3.5-System mal auffrischen. Anlass ist, dass ich den VDR bei Inaktivität nun endlich schlafen lege und das System jetzt auf eine SSD umziehen soll, um schneller "aufzustehen" (das klappt leider schlecht, aber darum will ich mich später kümmern).


    Zwecks Auffrischung habe ich EasyVDR 5.0 Alpha Stable installiert, und, nun, ich wäre nicht hier, wenn es einfach so funktioniert hätte. (Ihr kennt das: Wenn's klappt, bedankt sich mal wieder keiner... Danke für VDR, EasyVDR und all die guten Plugins!)


    Die Ausgangslage ist also ein funktionierendes EasyVDR 3.5 auf der einen Platte (daher WAF: 100%) und eine Neuinstallation auf der anderen. Nachdem ich rumprobiert und nichts erreicht hatte, hab ich nochmal frisch rüberinstalliert, es ist also nicht händisch um-/verkonfiguriert. Die Hardware sollte in der Signatur stehen, entscheidend ist die DVBSky S952 V3.


    Die Sache mit dem Video ist "lustig": Ich dachte bis vorhin, es funktioniert - aber das tut es nur, wenn ich von der alten auf die neue Installation um-boote. Einmal spannungsfrei geschaltet und nur die neue Installation gebootet gibt keinen Empfang. Es fehlt also offensichtlich irgendeine Initialisierung.



    Das mit der FB ist weniger lustig, da scheint es an den Grundlagen zu hake(l)n...

    Code: irw
    Cannot connect to socket /run/lirc/lircd: No such file or directory
    Code: systemctl status lircd.service
    ● lircd.service - Flexible IR remote input/output application support
    Loaded: loaded (/lib/systemd/system/lircd.service; disabled; vendor preset: enabled)
    Active: inactive (dead)
    Docs: man:lircd(8)
    http://lirc.org/html/configure.html
    Code: systemctl status inputlirc.service
    ● inputlirc.service - Zeroconf LIRC daemon using input event devices
         Loaded: loaded (/lib/systemd/system/inputlirc.service; disabled; vendor preset: enabled)
         Active: inactive (dead)
           Docs: man:inputlircd(8)
    
    Nov 16 11:26:35 easyVDR systemd[1]: /lib/systemd/system/inputlirc.service:4: Failed to add dependency on udev, ignoring: Invalid argument
    Nov 16 11:26:35 easyVDR systemd[1]: /lib/systemd/system/inputlirc.service:4: Failed to add dependency on lircd, ignoring: Invalid argument


    Ich hänge noch ein Bündel der lirc-Konfigurationsdateien an.


    Danke für jede Hilfe!

    Eike


    inputlirc.service.txtlircd.service.txtlircd.socket.txtlircd-setup.service.txtlircd-uinput.service.txtlircmd.service.txt

    Sehr schön, dieser Effekt ist mir bei der Sofortaufnahme-Dauer noch gar nicht aufgefallen.

    Ich hab das auch nicht gewusst (und letztens hätte ich es so gut gebrauchen können...)! :D


    ...aber nicht wieder neu "gestartet", d.h. es gibt keinen Livebuffer mehr bis das nächste mal der Kanal umgeschaltet wird.

    Das war schon Absicht so. Die Hintergrundaufzeichnung wird neu gestartet, wenn du wieder im Liveprogramm bist (ohne umschalten), also wenn du zum Beispiel die Stop-Taste drückst. Wenn ich mal zwischen live und Zurückgespultem wechsle (wie letztens bei der Leichathletik-EM), hab ich im Zweifel nachher eher zu viel als zu wenig aufgenommen...


    Was mir aber gerade beim Testen aufgefallen ist: Wenn die erste Aufnahme noch aufnimmt und ich von Live wieder zurückspulen will, behauptet der VDR, es wäre kein Receiver mehr frei. Ist mir aber in jahrelangem "Produktivbetrieb" noch nie begegnet.


    Ciao,

    Eike

    Hallo!

    - wenn eine Aufnahme mit der "roten Record-Taste"ausgelöst wird, wird immer eine Aufnahme mit der Dauer einer Direktaufzeichnung angelegt. Hier würde ich es besser finden, eine Aufnahme der gerade aktuellen Sendung zu machen, d.h. am Anfang den Permashift-Buffer mit zu nutzen, die Endzeit aber nach der aktuellen Sendung zu setzen. Möglicherweise kann das auch im Setup als wählbare Option angeboten werden.

    Eigentlich wollte ich dir erzählen, dass Permashift sich da doch genauso verhält wie der Rest des VDRs, und man das lieber da einbauen sollte...

    ... bis ich nach langem Starren auf timers.c herausgefunden habe, dass es das schon gibt. Man stellt die Sofortaufnahme-Dauer in den VDR-Optionen auf 0.

    Sollte das rauskommen, was du suchst!

    - Zum Anzeigen des Live-Buffers von Permashift wird nicht nur die Pausentaste benutzt, sondern auch die Rückspultaste (kFastRew). Diese Taste nutze ich auch in TVGuide um Seitenweise in der Zeit rückwärts zu navigieren. Das geht nicht mehr, wenn man den Permashift-Patch in vdr.c anwendet. Hier würde ich mir wünschen, das die Rückspultaste nur dann von Permashift ausgewertet wird, wenn kein OSD offen ist. Der angehängte 2-zeilige Patch löst dieses Problem.


    Ich nehm es rein.


    Klingt aber, als gäbe es da noch eine größeren Baustelle, die eigentlich im VDR selbst gelöst werden sollte?


    (Ich finde ja, dass die Zurückspultaste auf der Fernbedienung auch im OSD zurückspulen sollte, während die auf der Tastatur das eher nicht machen sollte - zumindest nicht während einer Texteingabe. Wäre aber vielleicht aufwändiger, man müsste die Tastendefines ggf. wieder "aufdröseln"...)


    Ciao,

    Eike

    Hallo!


    Dann muss ich wohl mal was schreiben...


    Man muss nur drohen, dann klappt es auch! ;)


    Nein, im Ernst: Du hast deinem Namen keine Ehre gemacht - wenn der Fehlermelder die Lösung gleich mit findet, kann er kein Kamel sein... ;)

    Ich werd's in Release 1.4 einbauen.

    Danke!


    Was mir allerdings noch aufgefallen ist, auch schon bei der alten Version.

    Die Timeshift-Aufnahme wird nicht immer zuverlässig beendet, wenn man den Modus verlässt.

    Dazu habe ich aber noch keine Systematik erkannt.


    Ich bin da grad ehrlich gesagt nicht mal sicher, wie das Sollverhalten ist. Ich schau nochmal rein.

    Die Debugausgaben sollten in der aktuellen Version erweitert sein, aber mir scheint, für diesen Fall gibt das noch nicht viel her. Kannst ja bei Gelegenheit trotzdem mal schauen, was das Log sagt.


    Danke nochmal!

    Eike

    Hallo Carel,


    Leider gibt’s eine Fehler beim Kompilieren:

    Hab's versucht mit vdr-2.4.6 und vdr-2.5.1


    dein Compiler scheint strenger zu sein als meiner.


    Kannst du mal folgendes probieren?


    In vdr.c, ca. Zeile 1360, sollte folgendes stehen:


    Code
    // Pausing live video:
    case kFastRew:
      // test if there's a live buffer to rewind into...
      LOCK_CHANNELS_READ;
      if (cDevice::ActualDevice()->GetPreRecording(Channels->GetByNumber(cDevice::CurrentChannel())) == NULL) {
        break;
      }
    // fall through to pause
    case kPlayPause:


    Ersetze das mal bitte durch dieses hier (also einfach zwei geschweifte Klammern mehr):


    Code
    // Pausing live video:
    case kFastRew:
    {
      // test if there's a live buffer to rewind into...
      LOCK_CHANNELS_READ;
      if (cDevice::ActualDevice()->GetPreRecording(Channels->GetByNumber(cDevice::CurrentChannel())) == NULL) {
        break;
      }
    }// fall through to pause
    case kPlayPause:


    Gesundheit!

    Eike

    Hallo!


    Ich habe nach Ewigkeiten mal wieder eine Version meines Plugins für permanenten Timeshift "Permashift" zusammengepackt.

    Abgesehen von Codecleanup ist nur ein Patch für den aktuellen VDR 2.4.6 dazugekommen.

    Da meine Testmöglichkeiten *hüstel* eingeschränkt sind, hoffe ich auf den einen oder anderen Neugierigen.


    Hier gibt's den Quellcode: https://github.com/eikesauer/P…/releases/tag/v1.0.4-beta


    Und eine Erklärung, worum es überhaupt geht: https://ein-eike.de/vdr-plugin-permashift/


    Gesundheit!

    Eike

    Als erstes: Mein Karte läuft ohne den Anschluss, also, das Problem muss damit nicht gelöst sein.

    Ich muss mich korrigieren!

    Ich hatte gestern das Kabel nach dem Foto nicht wieder eingesteckt, mich abends gewundert, dass kein Empfang war...

    ... und festgestellt, dass ich es offensichtlich doch brauche.

    Das währe der Klassiker für C

    Ich würde davon abraten, heutzutage reines C zu lernen.

    Für C++ wäre wohl das der Klassiker.

    Von dem rate ich ab, wenn du nicht schon ein guter Programmierer bist oder wirklich "hart im Nehmen".

    Der Autor sagt an einer Stelle, er möchte die Intelligenz des erfahrenen Programmierers nicht beleidigen (oder so ähnlich).

    You have been warned. ;)


    Eine Positiv-Empfehlung kann ich leider nicht geben.

    Hallo!


    Sorry für die lange Pause. Wir haben zwei Babys, die meistens die komplette Zeit auffressen...

    (Aber Ein Eike, der ein Baby mit dem Fuß wippt, eines in einem Arm wiegt und mit der freien Hand an einem 4K-Fernseher in ca. 8-Punkt-Schrift den VDR konfiguriert, war sicherlich ein Anblick für die Götter. ;o) )


    Hi, hast du denn mittlerweile die Firmware umbenannt, damit die auch geladen wird?

    In deinem dmesg Auszug sieht das nicht so aus.


    Ich habe nichts umbenannt, hätte ich sollen?


    Soweit ich das sehe, wird derzeit der Closed-Source-Treiber verwendet.


    Hier die entsprechenden Ausgaben auf meinem System:



    Code
    root@easyVDR:/lib/firmware# ls | grep rs6000
    dvb-demod-m88rs6000.fw
    dvb-fe-rs6000.fw
    root@easyVDR:/lib/firmware# diff dvb-fe-rs6000.fw  dvb-demod-m88rs6000.fw
    root@easyVDR:/lib/firmware#


    Passt das?


    Der Zustand ist weiterhin so, dass das System mit einem (beliebigen) Empfänger läuft, aber sobald ich den zweiten per EasyVDR-Setup dazuschalte, es früher oder später in "lost lock" läuft (siehe syslog). Beim Versuch heute war es das erste Mal nach ca. 7 Stunden, danach häufiger.



    *edit*

    Ich hab mir das nochmal angekuckt. Erst alle 13,x Minuten, dann alle 7,x Minuten? Schon eher verdächtig...?




    Ciao,

    Eike

    So...


    ... die Fernbedienung läuft.


    Hier die Auflösung. Vielleicht hilft es ja mal einem einsamen Sucher.


    ir-keytable gibt aus:

    Code
    root@easyVDR:/etc/lirc# ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event13) with:
    Driver SMI_PCIe, table rc-dvbsky
    Supported protocols:
    Enabled protocols:
    Name: IR (DVBSky S952 V3)
    bus: 1, vendor/product: 4254:0552, version: 0x0001
    Repeat delay = 500 ms, repeat period = 125 ms

    In der /etc/lirc/hardware.conf steht jetzt:



    Ich hatte dann mit einer lircd.conf aus /var/lib/vdr/remotes/DVBSKy_S952/ gearbeitet (vermutlich dev_input?)

    und damit die meisten Tasten außer den Cursortasten und den Farbtasten bekommen.


    Statt das noch anzugehen, hab ich gleich die OneForAll eingerichtet. ir-keytable gibt ja kein unterstütztes

    Protokoll an, aber RC-5 scheint zu gehen. Darauf stellt man meine OneForAll genau wie die hier ein,

    mit dem Code 1672.


    Dann habe ich mit irrecord angelernt:

    irrecord -H devinput -d /dev/input/event13 irrecord.testoneforall


    Dabei wurden immer zwei Zahlen ausgegeben:


    Code
    KEY_FASTFORWARD          0x04000400001E34 0x00000000000000

    Wenn man die hintere löscht, funktioniert's.


    Meine lircd.conf sieht nun so aus:



    So super-offensichtlich war das nicht alles... Aber es läuft nun.


    Der Empfang ist mit einem Receiver seit einer Woche stabil.

    Ich werde bei Gelegenheit den zweiten wieder anschließen

    und kucken, ob es damit auch läuft.


    Danke an alle Helfer!


    Ciao,
    Eike