Posts by holger_p.

    epgd sollte nicht crashen, auch wenn die verwendete API Unsinn zurückliefert. Das ist immer ein Bug in epgd

    Sehe ich auch so. Da ist die Prüfung innerhalb epgd nicht erfolgt. Wo kann man den Bug melden bzw. in welchem Repo wird epgd gepflegt? Nur hier ?

    Hi,


    I verified under yaVDR-Ansible (thanks to seahawk1986 fast repositories) with current versions

    Code
    1. vdr-plugin-skinflatplus 0.6.1+git20210621-13-b8006d67-0yavdr0~focal
    2. vdr-plugin-skinnopacity 1:1.1.8-0yavdr0~focal
    3. vdr-plugin-softhddevice 1.2.1-0yavdr0~focal

    I could not determine any crash during detached startup. Thanks. Thread can be closed since the issue is solved.

    lnj it did not happen under yaVDR Ansible running on Ubuntu Bionic which uses:

    - VDR 2.4.0

    - softhddevice 1:1.0.5+git20200928-2-78f23fa-0yavdr0~bionic

    - skinnopacity 1.1.3.git20140524.1729-10yavdr0~bionic


    In my case the "Magick" crashes started using/upgrading to Ubuntu Focal which uses

    - VDR 2.4.7

    - softhddevice 1.1.1-0yavdr0~focal

    - skinnopacity 1:1.1.8-0yavdr0~focal

    Hi,

    [...]

    I also think that this problem should be fixed in the output device so that not every skin has to implement a workaround.

    [...]

    I personally do not have any preferences if it is better to solve this situation
    a) in softhddevice or

    b) to perform the OSD checks in (any) of the skin plugins or
    c) anywhere else (i.e. in the VDR by kls as mentioned by wirbel )

    For any references I created Github issue for lnj on this first of all:

    Starting softhddevice in detached mode leads to segfault of VDR (2.4.7)


    Regards,

    Holger.

    I did tests until reproduce the problem, everything works. Try disabling the rest of the plugins, maybe some combination fails.

    vdr-2.5.5, nopacity 1.1.8, Ubuntu 20.04.

    I will continue tests.

    lnj I did a test to disable - with vdrctl - all plugins etc. but kept satip, softhddevice and skinnopacity enabled. The vdr 2.4.7 crashes during startup.

    With deactivation of the skinnopacity and using default LCARS or classic skin the startup works without any (VDR startup ) ssue.

    I furtheron installed and used vdr-plugin-skinflat with keeping skinnopacity disabled: The VDR crashes during startup using this skin as well.


    The given workaround by seahawk1986 to comment out -Din the softhddevice.conf to start the VDR with an attached frontend works as such. No crashes during startup.


    P.S. My VDR setup is an Intel setup,; no additional graphic cards etc.

    Hi, seahawk1986

    Ansonsten müsste man mal einen Backtrace produzieren und nachvollziehen, was genau da zum Crash führt.

    Ich werde mal (zeitnah) einen Backtrace erstellen und hier posten (Versuch mit vdr-dbg & nopacity-dbg):

    vdr_bt_full.txt


    Ohne genaue Ahnung zu haben, passiert der VDR Crash wohl hier:

    Code
    1. Thread 1 (Thread 0x7f9ee2e8e800 (LWP 6555)):
    2. #0 0x00007f9ee30fe18b in raise () from /lib/x86_64-linux-gnu/libc.so.6
    3. #1 0x00007f9ee30dd92e in abort () from /lib/x86_64-linux-gnu/libc.so.6
    4. #2 0x00007f9edcb769eb in ?? () from /usr/lib/libGraphicsMagick-Q16.so.3
    5. #3 <signal handler called>
    6. #4 0x00007f9edce6df60 in cNopacityDisplayChannelView::CreatePixmaps (this=0x55bfe6e90b50) at displaychannelview.c:154
    7. #5 0x00007f9edce5dc6c in cNopacityDisplayChannel::cNopacityDisplayChannel (this=0x55bfe6e66640, WithInfo=<optimized out>) at displaychannel.c:22
    8. #6 0x00007f9edce9d9d7 in cNopacity::DisplayChannel (this=<optimized out>, WithInfo=<optimized out>) at nopacity.c:32
    9. #7 0x000055bfe6127479 in cDisplayChannel::cDisplayChannel (this=0x55bfe6e07c10, Number=1, Switched=true) at skins.h:468
    10. #8 0x000055bfe60cb43a in main (argc=<optimized out>, argv=<optimized out>) at device.h:354


    P.S.: Das -Din softhddevice.conf entfernen ist ein funktionierender Workaround; der VDR 2.4.7 startet ohne Mucken mit nopacity 1.1.8.


    Danke und Gruß,

    Holger.

    Hallo, zusammen.


    Habe die Tage testweise einmal einen yaVDR Ansible von Ubuntu 18.04 auf 20.04 gehievt. Hat soweit auch gut geklappt. Allerdings produziert der VDR 2.4.7 beim Start (mit aktivem vdr-plugin-skinnopacity) einen Segmentation Fault.


    Im laufenden Betrieb kann ich bspw. vom LCARS auf NOPACITY Skin ohne Problem umstellen. Deaktiviere ich vorab mit vdrctl skinnopacity startet der VDR auch einwandfrei.


    Eine leere setup.conf brachte ebenfalls keine Änderung beim Startverhalten des VDR. Hat jemand irgendwelche weiteren Ideen dazu ...?


    Hier einmal ein Auszug aus dem Log:

    Log

    Gruß,

    Holger.

    Hallo, zusammen.


    Also ich habe mir meine softhddevice Einstellung einmal genauer angeschaut.

    Ich habe nun herausbekommen, dass ich keinen Tonversatz habe, wenn ich den Parametersofthddevice.SoftStartSync = 1

    eingestellt habe. Die Log Meldungen "slow down video, duping frame" sind dann weg. Egal ob HD oder non-HD Sender.

    Schaue ich mir nun non-HD-Aufnahmen an, erhalte ich die Meldungen allerdings beim Abspielen:

    Code
    1. Mar 15 14:08:00 vdr vdr: video: slow down video, duping frame
    2. Mar 15 14:08:00 vdr vdr: video: 23:02:27.243 +71 6798 0/\ms 182+5 v-buf
    3. Mar 15 14:08:00 vdr vdr: video: speed up video, droping frame
    4. Mar 15 14:08:00 vdr vdr: video: 23:02:27.243 +31 6854 0/\ms 182+3

    Während der Wiedergabe ist ein leichtes, permanentes Ruckeln erkennbar.


    Setze ichsofthddevice.SoftStartSync =0und spiele danach die non-HD Aufnahmen ab, ist deren Wiedergabe der Aufnahmen in Ordnung.

    Allerdings erhalte ich dann bei sämtlichen Sendern "slow down video, duping frame" und der Ton driftet weg.


    Das verwendete Plugin (aus den yaVDR Ansible Repos) ist:

    Code
    1. vdr-plugin-softhddevice-vpp 0.7.0+git20180203

    Hat jemand bis dato ähnliche Erfahrungen gemacht?


    Gruß,

    Holger.

    Hi, Uwe.


    Ich hatte anfangs mit yavdr-ansible auch so ein ähnliches Phänomen mit dem softhddevice.


    Im Anhang findest Du meine aktuellen Einstellungen des Plugins, mit dem ich auch das Driften des Tons in meiner Umgebung in den Griff bekommen habe.


    P.S.: Die CPU meiner BeeBox ist eine N3150.


    Gruß,

    Holger.

    Hi, kamel5 .


    Jetzt funktioniert das Timer-Anlegen auf meinem (remote) vdr-server über das Peering genau so, wie es soll. Vielen Dank dafür.:thumbup:


    Dank auch an seahawk1986 für das schnelle Bereitstellen des aktuellen TV-Guide Plugin Pakets in den "yaVDR-Ansible" Repos.


    Danke und Gruß,

    Holger.

    .

    Hallo, kamel5


    Auch nach den Änderungen der setup.conf keine Änderung:


    1. Info: Starte ich den vdr auf dem Server durch, entfernt dieser den SVDRPHostName; somit bleibt dieser leer.

    2. Wie beschrieben: Im Prinzip funktioniert das Peering zwischen Client und Server sowie das Anlegene von Timern, allerdings nicht aus TV-Guide heraus.


    Editiere ich im vdr manuell den mit TV Guide angelegten Timer (z.B. deaktivieren), dann wird dieser z.Zt. als "timer 4" auf dem Server angelegt/aktualisiert und steht dort zur Verfügung. Lege ich den Timer im TV Guide über "Aufnahme" direkt an, dann finde ich im Log immer nur "timer 0" und nichts am Server. Der Timer wird also nur lokal angelegt.


    Immer noch ratlos,

    Holger.

    Hi, kamel5 .


    Auf meinem aktuellen yaVDR-Ansible Client kann ich z.Zt aus dem tv-guide Plugin (noch) keine Timer direkt auf meinem Server mittels Peering anlegen. Die Konfiguration funktioniert ohne TV-Guide.


    Konfiguration

    Client (vdr)

    Package: vdr-plugin-tvguide

    Version: 1.2.16-0yavdr0~bionic


    Server (vdr-server)


    1. Anlegen eines Timers aus TV-Guide heraus

    Client Beispiel aus syslog:

    Code
    1. Feb 8 15:20:32 vdr vdr: [1638] timer 0 (2 1555-1715 'Bares für Rares') set to event Sa. 08.02.2020 16:00-17:00 (VPS: 08.02. 16:00) 'Bares für Rares'
    2. Feb 8 15:20:32 vdr vdr: [1638] timer 0@vdr-server (2 1555-1715 'Bares für Rares') added (active)


    Server Syslog zeigt nichts.


    2. Anwenden des "Workarounds" den Timer zu deaktivieren:

    Client Syslog beim Deaktivieren des Timers:

    Code
    1. Feb 8 15:21:36 vdr vdr: [1812] ERROR: oops while storing remote timers!
    2. [...]
    3. Feb 8 15:22:49 vdr vdr: [1638] added timer 4@vdr-server (2 1555-1715 'Dokumentation~Bares für Rares')


    Server Syslog beim Deaktivieren

    Code
    1. Feb 8 15:23:07 vdr-server vdr: [5787] timer 4 (2 1555-1715 'Dokumentation~Bares für Rares') set to no event
    2. Feb 8 15:23:07 vdr-server vdr: [5787] timer 4 (2 1555-1715 'Dokumentation~Bares für Rares') set to event Sa. 08.02.2020 16:00-17:00 (VPS: 08.02. 16:00) 'Bares für Rares'


    Zur Zeit tappe ich im Dunkeln.


    Gruß,

    Holger.