Posts by dile

    Empfangsprobleme kann ich ausschließen. Das ist IPTV mit MagentaTV von hier. Die Channels.conf funktioniert auch am anderen VDR.

    Hab gerade die VDR Aufnahmen per NFS eingebunden und beim Abspielen von Aufnahmen das gleiche Problem. Ich kann aber auch nur H264 Sender/Aufnahmen testen.


    Gruß dile

    Funktioniert das Plugin auch mit einem AmlogicS905Y2 ?

    Ich hab mal testweise den VDR von Zabrimus auf einem MagentaTV Stick installiert.

    Das OSD funktioniert. Allerdings bleibt das Video schwarz und es kommt nur der Ton.


    Im Log sehe ich immer wieder die Meldungen:


    Code
    1. Jun 23 09:26:11 CoreELEC kernel: 0: timeout_process decoder timeout, DPB_STATUS_REG 0xf0
    2. Jun 23 09:26:11 CoreELEC kernel: 0: vh264_work_implement, decode timeout flush dpb



    dmesg.txt

    Ich wollte das auch mal ausprobieren und bekomme den folgenden Fehler:


    Die betroffenen Aufnahmen funktionieren im VDR eigentlich ganz normal. Wenn ich diese aber mit dem VLC öffne, dann kommt der am Anfang ganz schön ins straucheln und zeigt erst mal nur Standbild.


    Ist es sinnvoll mal ein Video auf Fehler zu analysieren und falls ja wie mach ich das am besten? Oder soll ich mal ein Video bereitstellen damit sich das mal jemand anschauen kann der sich auskennt. ;-)


    Gruß dile :-)

    Hallo zusammen,


    ich verwendet das iptv Plugin mit Magenta TV [IPTV] T-Home MagentaTV - channels.conf - aktuelle Einträge


    Mit der aktuellen Version des VDR bekommt man ja jetzt auch angezeigt ob eine Aufnahme Fehler beinhaltet. Ich habe leider das Problem das sporadisch einige Aufnahmen Fehler beinhalten.


    Einmal hatte ich das Problem, dass wenn mehrere Aufnahmen parallel laufen es zu Fehlern kommen kann. Dies konnte ich mit der Erhöhung der

    net.core.rmem_max und net.core.rmem_default in der /etc/sysctl.conf minimieren.


    Leider habe ich aber immer noch das Problem das es beim Beginn der Aufnahme zu Fehler kommen kann. Ich habe noch nicht verstanden wovon das abhängig ist weil es bei manchen Serienaufnahmen gar nicht, bei anderen manchmal und bei einigen auch fast immer vorkommt. Bei Aufnahmen die direkt gestartet werden, scheint das auch nicht aufzutreten.


    Hier mal ein Beispiel bei dem im IPTV Plugin --trace=1 aktiviert ist:


    https://pastebin.com/qH3nts5v

    Die Meldung "IPTV: Detected 1 RTP packet errors" hab ich beim Start eine Aufnahme eigentlich immer. Auch bei Aufnahmen bei denen kein Fehler auftritt.


    Ich hab aktuell die net.core.rmem_max und net.core.rmem_default erhöht. Wenn ich diese wieder kleiner mache bzw. mit dem Standardwert laufen lasse, dann tritt die Problematik beim Start der Aufnahme zwar immer noch auf, aber die Anzahl der Fehler die der VDR dann meldet ist deutlich kleiner.


    Jemand eine Idee woran das noch liegen könnte oder wie man das weiter eingrenzen kann?


    Gruß dile :)

    Bei mir ist die Festplatte auch immer wieder vollgelaufen bevor der VDR angefangen hat Aufnahmen zu löschen.


    Ich glaube der VDR prüft/löscht nur Aufnahmen wenn eine Aufnahme gestartet wird oder läuft. Wenn keine Aufnahme ansteht und die Festplatte läuft wie bei mir mit Non-VDR Daten unter das MinDISKSPACE dann kann die Platte voll sein bevor Aufnahmen gelöscht werden.

    In der Datei recorder.c folgendes entsprechen erhöhen:


    #define MINFREEDISKSPACE (512) // MB

    Da ich wegen des vollen Speichers gerade erst aufgeräumt habe, teste ich erst mal mit einem hohen Wert.

    Code
    1. #define MINFREEDISKSPACE (102400) // MB


    Bin mir noch nicht sicher ob das wirklich funktioniert:

    Hier das vollständige Log: https://pastebin.com/2wX0n640


    Code
    1. Apr 26 10:02:47 europa vdr[376747]: [376852] low disk space (100892 MB, limit is 102400 MB)

    Zum Zeitpunkt als das Limit erstmals unterschritten wurde gab es 3 manuell gelöschte Aufnahmen die noch nicht endgültig gelöscht wurden und unter anderem eine Aufnahme vom 03.01.2022 mit einer Lebensdauer von 14 Tagen.


    Code
    1. Apr 26 11:08:53 europa vdr[376747]: [377106] low disk space (96569 MB, limit is 102400 MB)

    Auch als der Speicher weiter unterschritten wurde. Die Aufnahme beendet wurde und eine weitere Aufnahme lief, wurden weder die gelöschten Aufnahmen endgültig gelöscht noch eine Aufnahme mit niedriger Lebenszeit angefasst.


    Erst später wurden dann die gelöschten Aufnahmen endgültig gelöscht. Würde aber vermuten das dies auch ohne Änderung der minfreediskspace passiert wäre.


    Code
    1. Apr 26 15:31:52 europa vdr[376747]: [379564] low disk space (96303 MB, limit is 102400 MB)

    Auch aktuell wurde noch keine andere Aufnahme mit einer niedrigen Lebenszeit gelöscht.


    Code
    1. Apr 26 12:15:11 europa vdr[376747]: [377828] low disk space (96578 MB, limit is 102400 MB)
    2. Apr 26 12:15:11 europa vdr[376747]: [377828] recording to '/srv/vdr/video/Magische_Gärten/2022-04-26.11.43.20-0.rec/00020.ts'
    3. Apr 26 12:16:03 europa vdr[376747]: [376760] VNSI: Requesting clients to reload timers
    4. Apr 26 12:16:52 europa vdr[376747]: [377828] low disk space (96514 MB, limit is 102400 MB)
    5. Apr 26 12:16:52 europa vdr[376747]: [377828] recording to '/srv/vdr/video/Magische_Gärten/2022-04-26.11.43.20-0.rec/00021.ts'
    6. Apr 26 12:17:03 europa vdr[376747]: [376760] VNSI: Requesting clients to reload timers
    7. Apr 26 12:18:03 europa vdr[376747]: [376760] VNSI: Requesting clients to reload timers
    8. Apr 26 12:18:34 europa vdr[376747]: [377828] low disk space (96451 MB, limit is 102400 MB)
    9. Apr 26 12:18:34 europa vdr[376747]: [377828] recording to '/srv/vdr/video/Magische_Gärten/2022-04-26.11.43.20-0.rec/00022.ts'

    Bei einer laufenden Aufnahme kommt dann regelmäßig die Meldung "low disk space" dabei wird jedes mal eine neue *.ts Datei erzeugt. Ist das so gewollt?


    Gruß Dirk

    Man kann Quota pro User bzw. Gruppe vorgeben, d.h. wenn der VDR nicht als root läuft, kann man ihm über hard limits Grenzen setzen: https://www.digitalocean.com/c…system-quotas-on-debian-9

    Das kannte ich noch gar nicht. Vielen Dank für den Input.


    Da müsste ich dem VDR aber einen festen Wert für den Speicherplatz zuweisen. Es würden also Aufnahmen gelöscht werden wenn noch viel Speicher frei ist weil der Non-VDR Bereich wenig belegt, bzw. wenn der Non_VDR Bereich sehr viel belegt könnte die Platte trotzdem volllaufen.


    Mit dem Hinweis von msv teste ich erstmal die Lösung von Klaus.

    Hallo,


    soweit ich das verstanden habe, löscht der VDR Aufnahmen nach der PRIO erst wenn der Speicherplatz tatsächlich komplett aufgebraucht ist. Da ich auf der Festplatte aber auch noch andere Dienste verwende, möchte ich nicht das der freie Speicherplatz auf 0 geht. Gibt es die Möglichkeit das der VDR schon mit den Löschen von Aufnahmen nach der PRIO anfängt, wenn ein bestimmter Wert an freien Speicherplatz unterschritten wird?


    Ich würde mir das so vorstellen, dass wenn der freie Speicherplatz z.B. 3 GB unterschreitet, das dann schon angefangen wird, entsprechende Aufnahmen zu löschen bis der Wert wieder überschritten wird.

    Kann man das realisieren?


    Gruß dile :)

    Da ich auf einem Testsystem ein neues EPGD installiert hatte war die Funktion gar nicht in der Datenbank, weil ich das vergessen hatte.

    Code
    1. CREATE FUNCTION epglv RETURNS INT SONAME 'mysqlepglv.so';
    2. CREATE FUNCTION epglvr RETURNS INT SONAME 'mysqlepglv.so';

    Mit dem angepassten Pfad in der Datenbank funktioniert es jetzt.

    Ich hab jetzt in der /etc/mysql/my.cnf folgendes hinzugefügt:

    Code
    1. [mysqld]
    2. plugin_dir=/usr/lib/x86_64-linux-gnu/libmariadb3/plugin

    Das Verzeichnis in der Datenbank ist auch geändert:

    Code
    1. mysql -u root -p -e "SELECT @@plugin_dir;"
    2. Enter password:
    3. +-----------------------------------------------+
    4. | @@plugin_dir |
    5. +-----------------------------------------------+
    6. | /usr/lib/x86_64-linux-gnu/libmariadb3/plugin/ |
    7. +-----------------------------------------------+


    Da aber der bisherige Pfad der Plugins aus der Datenbank auch nicht leer ist, frage ich mich ob es nicht besser wäre den Pfad für Plugins nicht über die Datenbank anzupassen und das Plugin stattdessen manuell zu kopieren.



    Warum sind die beiden Pfade in Debian jetzt überhaupt unterschiedlich? Ist das ein Fehler in Debian?


    Gruß dile

    ja die mysqlepglv.so ist da

    hab epgd auch nochmal gelöscht, neu runter geladen und neu übersetzt



    Tobi

    Find ich gut das du die Debian Pakete wieder pflegen möchtest. Ich würde sehr gerne wieder auf deine Pakete zurück wechseln statt selber zu bauen.


    Vielen Dank für deine investierte Zeit.


    Folgende Plugins benutze ich am Server:


    dummydevice iptv vnsiserver suspendoutput epgsearch epg2vdr live


    Folgende Plugins benutze ich an den Clients:


    rpihddevice iptv epg2vdr skinelchihd tvguide fritzbox osdteletext


    Gruß Dile

    Ich hab jetzt in der /etc/mysql/my.cnf folgendes hinzugefügt:

    Code
    1. [mysqld]
    2. plugin_dir=/usr/lib/x86_64-linux-gnu/libmariadb3/plugin

    Das Verzeichnis in der Datenbank ist auch geändert:

    Code
    1. mysql -u root -p -e "SELECT @@plugin_dir;"
    2. Enter password:
    3. +-----------------------------------------------+
    4. | @@plugin_dir |
    5. +-----------------------------------------------+
    6. | /usr/lib/x86_64-linux-gnu/libmariadb3/plugin/ |
    7. +-----------------------------------------------+

    Trotzdem kommen noch die Fehlermeldungen beim start von epgd


    Die Konfiguration zur Datenbank wird ja in der epgd.conf festgelegt. Da sehe ich keine Pfad für das Plugin Verzeichnis.


    Den Plugin Pfad in der Datenbank selbst kann ich soweit ich das gelesen habe auch nicht direkt anpassen.


    Ich vermute das muss im Makefile angepasst werden?


    Wenn ich unter epglv/Makefile folgendes ändere dann wird zwar das Plugin im neuen Pfad installiert aber der Fehler bleibt der gleiche


    #MYSQL_PLGDIR := $(shell mysql_config --plugindir)

    MYSQL_PLGDIR = /usr/lib/mysql/plugin/