Posts by dile

    Bei mir beobachte ich, dass bei Aufnahmen von IPTV der Stream weiter läuft, wenn die Aufnahme beendet wird. Nach Live-Wiedergabe wird der Stream korrekt beendet.


    Normalerweise sollte das suspendoutput Plugin dafür sorgen das der Tuner nach der Aufnahme wieder freigegeben wird. Leider funktioniert das bei mir mit IPTV auch nicht. Ich habe leider auch noch keine Lösung für das Problem.


    VDR mit IPTV blockiert bei Aufnahme 2 IPTV Tuner und gibt nur einen wieder frei


    https://github.com/rofafor/vdr-plugin-iptv/issues/7


    Gruß dile

    Du könntest es mal mit "${*}" probieren, ob er das will.


    Wobei $* ja so eine Spezial-Variable ist, die alle Argumente als Strig enthält.

    Eventuell ist in dem einen Fall das Quoting unnötig, das weiss ich aber nicht auswendig.

    Ist das die einzige Stelle?


    Das macht keinen Unterschied. Ich habe es jetzt nochmal unter Debian Testing ausprobiert und bekomme mit dem original Script die folgende Meldung wenn ich es als root ausführe:


    lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs

    Output information may be incomplete.


    Mir ist auch aufgefallen das in den Logfiles auch der Benutzername vom User mit der UserID 1000 auftaucht wobei ich aber nicht verstehe woher das kommt.


    Vielleicht hat da noch jemand Input für mich. Vielen Dank

    Das Quoting von Dateinamen einfach weglassen, weil es mit nicht läuft, ist nicht gut. Das kann zu Problemen führen, wenn Leerzeichen ins Spiel kommen.

    Bei Debian tippe ich auf BASH als Ursache für das Problem, standardmässig ist die Shell nämlich gar nicht installiert und der Ersatz kann nicht alles. Man muss lediglich das Paket nachinstallieren, dann sollte es gehen.


    Die Bash ist bei mir installiert und trotzdem kommt der Fehler.


    Code
    1. bash --version
    2. GNU bash, Version 4.4.12(1)-release (x86_64-pc-linux-gnu)
    3. ii bash 4.4-5 amd64


    Woran könnte es denn noch liegen ?


    Gruß dile

    Hallo kamel5,


    ich habe den Peering Branch getestet und es funktioniert wie gewünscht.

    Wenn das Peering aktiviert und SVDRP Standardmaschine gesetzt ist wird der Timer auf dem Server gesetzt. Wenn man das Peering ausschaltet oder die SVDRP Standardmaschine löscht wird der Timer lokal gesetzt. Ich konnte keinen Fehler feststellen. Der Patch kann also in den Master :-)


    Vielen Dank Gruß dile

    Ich hatte die selben Fehler unter meinem Debian.


    Code
    1. nice -n $NICE_VAL "$*" 2>&1 | tee -a $LOG

    Ich habe dann die Zeile geändert und es lief auf den ersten Blick. Bin da aber nicht sehr erfahren in diesen Dingen und weiß nicht ob evt. ein anderes Problem damit verursacht werden könnte.


    Code
    1. nice -n $NICE_VAL $* 2>&1 | tee -a $LOG


    Außerdem ist mir noch aufgefallen:

    Das TARGET_DIR wird beim ausführen des Scriptes gelöscht wenn es noch komplett leer ist. (Sobald da was drin ist passiert das nicht mehr.)


    Wie sieht es denn beim Löschen von Aufnahmen aus ? Ich habe noch nicht die Zeit gehabt eine Löschung über den VDR zu testen. Aber nach einem manuellen löschen im Video Ordner und ausführen des Scriptes war die Aufnahme im sowohl im Target als auch im video Ordner noch etwas davon da.


    Gruß Dirk

    Ich habe mir ein Script geschrieben welches per cron einmal täglich läuft, die Aufnahmen die älter als 5 Tage sind auf die SATA HD kopiert und im SSD-Video Verzeichnis werden noch die MetaDateien gehalten und die Videos verlinkt.

    Das klingt nach einer guten Lösung die für mich auch sinnvoll sein könnte. Könntest du mir dieses Script zur Verfügung stellen ?


    Vielen Dank


    dile :-)

    Ein super interessanter Beitrag - ich antworte hier nur, damit mir dieser Beitrag nicht verloren geht..

    Ich fand diese Verwaltung mehrerer Festplatten war eines *der* Features von VDR. Ein echter Verlust.



    Ich bastle gerade an einem ähnlichen Plugin, aber mit total anderem Zielund damit auch völlig anderer Implementation. Mein setup besteht aus einer SSD für das root Dateisystem und mehreren langsamen Terabyte Datengräbern. Und mich stört die verschachtelte Ordner Hierarchie der Aufnahmen. Mein Plugin wird deswegen eher darauf zielen, alle Meta-Daten auf der schnellen SSD zu lassen und ausschließlich die riesigen Video-Daten (*.{ts,vdr}) auszulagern, aber ohne Ordner-Baumstruktur und die Aufnahmen je disk alphabetisch. Disk1 'a'..'h', Disk2 'i'..'z' usw.

    Meta Daten auf der SSD und Video Daten auf die Festplatte. An so einem Plugin hätte ich auch Interesse.

    Ggf. noch die Video Daten in einem Rutsch auf die Festplatte damit diese länger schläft und auf der SSD noch Aufnahmen die man kurzfristig schaut cachen.


    Gibt es da etwas neues ? Gruß dile

    Am besten wäre wenn der VDR nur ein Bild und Ton liefert wenn er auch benutzt wird. Man könnte den VDR detached verwenden und nur bei Bedarf auf attached setzen. Man könnte auch einen VDR Server ohne Ausgabe im Hintergrund für die Aufnahmen betreiben und den VDR für die Bild und Tonausgabe nur bei bedarf starten und beenden.


    Bei der ersten Aufnahme gibt es das Problem nicht. Bei der zweiten Aufnahme sieht man aber das 51 Sekunden vor dem eigentlichen Timer noch ein zweiter Kanal belegt wird. Dieser bleibt auch solange belegt und verursacht das Problem bis ich den VDR beende.



    Code
    1. Aug 10 10:47:09 jupiter vdr[28944]: [28944] switching device 4 to channel 6 I-1-98-1 (VOX)
    2. Aug 10 10:48:00 jupiter vdr[28944]: [28944] switching device 3 to channel 6 I-1-98-1 (VOX)
    3. Aug 10 10:48:00 jupiter vdr[28944]: [28944] timer 1 (6 1048-1105 'vox nachrichten') start

    Hier der Start des VDR Test Servers

    Hallo @ all


    ich betreibe einen VDR Server 2.4 mit dem IPTV Plugin Headless und bei der Suche nach der Ursache von Bildstörungen ist mir aufgefallen das mein VDR Server teilweise bei Aufnahmen noch einen weiteren Tuner belegt und diesen auch erst wieder freigibt wenn man den VDR Server beendet. Ich denke das ich das Problem mit den Bildstörungen gelöst habe und dieses Problem damit nicht zusammen hängt. Ich verwende auf meinem Server das suspendoutput so das normalerweise nach einer Aufnahme vom VDR kein Tuner mehr verwendet wird. In der Fritz Box ist mir in der Statistik aber aufgefallen das dies nicht immer klappt und teilweise noch Bandbreite benutzt wird. Außerdem ist mir aufgefallen das man unter "netstat -su" ab auftreten des Fehlers die "packet receive errors" bzw. "receive buffer errors" hochzählen.


    Mein VDR Server 2.4 ist selbst kompiliert. Testweise habe ich auf einem anderem System mal einen minimaleren VDR 2.4 Server von Tobi installiert und konnte den Fehler dort auch ohne suspendoutput nachstellen. Der Fehler tritt nicht generell auf so das ich schon einiges getestet habe. Es ist egal ob ich den Timer über das Live Plugin setzte oder er von epgsearch gesetzt wird. Allerdings tritt der Fehler nicht bei Aufnahmen auf die sofort starten sondern vor allem bei Aufnahmen die etwas weiter in der Zukunft liegen. Ich habe bereits den epgscan und die Funktion mit der sich der VDR mit anderen VDR syncronisiert, deaktiviert.


    Jemand eine Idee voran das liegen könnte und wie man das verhindern kann ? Dadurch wird von meinem DSL Anschluss unnötig Bandbreite belegt.



    Vielen Dank schon einmal im Voraus


    Gruß dile :)

    Lircd-uinput reagiert einfach auf empfangene Knöpfe (vom lirc-daemon) und gibt die Ausgabe an /dev/input/event weiter. Da die Eingabe von lircd (dem lirc-daemon) kommt ist die Datei


    Das war genau mein Problem --> nach deaktivieren dieses Dienstes fährt der Rechner nicht mehr runter und es werden nur noch die Befehle ausgeführt die für irexec konfiguriert sind --> damit ist mein Problem gelöst



    Wenn Du Lirc deinstallierst, kannst Du den IR-Receiver genauso gut ausstöpseln - ohne Lirc geht nichts.

    Ich habe das so verstanden das durch die rc_keymaps die Fernbedienung direkt im Kernel wie eine Tastatur eingebunden wird und dann die verschiedenen Programme direkt zugreifen können. KODI und VDR können dann ohne LIRC direkt die Fernbedienung verwenden. Leider kann Irexec nicht direkt auf diese Schnittstelle zugreifen so das es da noch den Umweg über LIRC braucht.


    Igord hab ich schon an anderem Rechner eingerichtet und läuft dort auch sehr gut (Fernbedienung ist nicht so träge) aber da an diesem Rechner aktuell nur eine Taste reagieren soll mache ich mir glaub ich nicht die Mühe das an dem Rechner einzurichten.

    Vielen Dank für deine Anregungen.


    Wenn ich eine ir-keytable ohne KEY_POWER lade dann tritt der Fehler nicht auf aber das war auch nicht mein Lösungsansatz da ich wissen wollte welche Anwendung das veranlasst.


    Bei der weiteren Suche habe ich die Ursache gefunden. Wenn der Dienst lircd-uinput geladen ist dann fährt der Rechner runter.

    Hab den jetzt generell deaktiviert (brauche den ja auch gar nicht) und jetzt tritt das Problem nicht mehr auf.


    Am liebsten würde ich Lirc komplett deinstallieren, da man das ja mit den Keymaps nicht mehr braucht. Aber irexec setzt darauf noch auf. Oder kennt jemand eine alternative zu irexec die direkt auf die Keymaps aufsetzen kann.


    Schöne Grüße

    Hallo,


    ich habe einen Debian Stretch Rechner der durchgehend läuft und an dem ein Igor-USB Emfänger hängt. Dieser Empfänger soll aktuell nur auf eine Taste reagieren und dann über irexec einen Dienst starten. Im gleichen Raum werden mit der Fernbedienung aber auch andere Signale für ein anderes Gerät gesendet das dieser Debian Stretch Rechner ignorieren soll.


    Bisher hat dies immer gut funktioniert. Jetzt habe ich aber auf dem Rechner auf Debian Stretch Backports upgedatet und damit läuft jetzt auf dem System ein 4.16. Kernel (vorher ein 4.9.)

    Jetzt ist es leider so das der Rechner sich runter fährt wenn ich auf der Fernbedienung die Power Taste (KEY_POWER) drücke (die aber für das andere System gedacht ist).





    Code
    1. /etc/rc_keymaps# ir-keytable
    2. Found /sys/class/rc/rc0/ (/dev/input/event7) with:
    3. Driver igorplugusb, table rc-hauppauge
    4. Supported protocols: lirc rc-5 rc-5-sz jvc sony mce_kbd rc-6 sharp xmp
    5. Enabled protocols: lirc rc-5
    6. Name: IgorPlug-USB IR Receiver
    7. bus: 3, vendor/product: 03eb:0002, version: 0x0001
    8. Repeat delay = 500 ms, repeat period = 125 ms
    9. root@jupiter:/etc/rc_keymaps#



    Gibt es eine einfach Lösung den Shutdown bei KEY_POWER zu verhindern. Am besten so das ich später die Taste noch in anderen Anwendungen benutzen kann.


    Vielen Dank für Eure Hilfe


    Gruß Dirk :)

    Ich hatte mit der vdr_2.3.8-1~etobi1 auch das Problem das die remote Timer damit grundsätzlich nicht funktionieren. Darauf hatte Tobi dann die Version vdr_2.3.8-2~etobi1 veröffentlicht, womit die Remote Timer auf meinem Raspberry mit meinem Server der damals auch auf Version 2.3.8 lief keine Probleme machten. Du solltest also mindestens vdr_2.3.8-2~etobi1 verwenden. Mittlerweile läuft bei mir aber der Raspberry und der Server mit 2.4 ohne Probleme. Besser wäre also zu schauen warum dein Pi nicht mit 2.4 funktioniert.


    Gruß Dile