Posts by holger_p.

Quote from lnj

Option dri 3 need for va-api-egl. And I don't know, how it works with old gpu. But without dri 3, va-api works for me with Intel UHD video and latest Ubuntu, i965 driver. va-api-glx seems to be staying for older systems, and support for glx is being removed.

Hi, I am having this issue with an N3150 processor based VDR. I suppose neither an Intel J3455 nor an N3150 are really "old" CPUs.

root@vdr:/var/log/apt# vainfo
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) CherryView - 2.4.1
vainfo: Supported profile and entrypoints
...

root@vdr:/var/log/apt# inxi -G
Graphics:
  Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics
    driver: i915 v: kernel
  Display: server: X.org v: 1.21.1.11 driver: X: loaded: intel dri: i965 gpu: i915 tty: 167x39
    resolution: 1280x720
  API: EGL v: 1.5 drivers: crocus,swrast platforms: gbm,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: mesa v: 24.2.8-1ubuntu1~24.04.1
    note: console (EGL sourced) renderer: Mesa Intel HD Graphics 400 (BSW), llvmpipe (LLVM 19.1.1
    128 bits)

After upgrading to the latest Ubuntu Mesa drivers (24.2.8-1ubuntu1~24.04.1 => 25.0.7-0ubuntu0.24.04.2), the screen shows no video but there is just audio with va-api-egl enabled for softhddevice.

Switching to va-api and removing
  Option      "DRI" "3"
in /etc/X11/xorg.conf.d/20-intel.conf fixes this for my VDR under yaVDR Ansible.

I recognised after all of the above that Kodi 21.3 (flatpak) is not working properly any longer: There is audio, no video but high CPU usage (approx. 200-300%).
So I rolled back the Mesa drivers going back to the initial settings and VDR and Kodi are working again.

I am afraid I do not get the clue here so i also had to hold the current Mesa driver packages on my VDR to workaround the issue which in my case are
libegl-mesa0 libgbm1 libgl1-mesa-dri libglx-mesa0 libxatracker2 mesa-libgallium mesa-vulkan-drivers

Quote from MarkusE

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 ?

Quote from mamomoz

[...]

Der Bug der API wird bestimmt bald gefixt werden.

Laut des Threads zu dem Bug bei der MovieDB (s. https://www.themoviedb.org/talk/62b7593bf0317400616a9f34) ist das Problem gefixt:

Quote

vom 26. Juni 2022, 18:58:
Hey guys,

The fix for this is going out right now. Over the next 6 hours you should see the names start to return as the cached items expire.

Cheers.

Sieht hier seit dem 25. Juni 2022, ca. 09:00 Uhr auch so aus. Habe jetzt erst einmal das Scraping für Epg und Recordings deaktiviert:

ScrapEpg = 0
ScrapRecordings = 0

kls: Schau' dir ggf. auch einmal Relax-and-Recover an (oder unter: GitHub - ReaR). Das ist ein Bash Skript basiertes Framework, dass z.B. ein bootbares ISO eines Systems im laufenden Betrieb inkl. Backup anlegen kann und das entstandene Image dann auch migrierbar ist (P2P, P2V, V2V, V2P). Bei Fragen einfach bei mir melden.

Hi,

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

vdr-plugin-skinflatplus 0.6.1+git20210621-13-b8006d67-0yavdr0~focal
vdr-plugin-skinnopacity 1:1.1.8-0yavdr0~focal
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.

Quote from lnj

All fixed, use latest git.

lnj: Great job. I will verify the solution.

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,

Quote from kamel5

[...]

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.

Quote from lnj

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.

seahawk1986: Hab mal versucht, einen Backtrace zu ermitteln (s.o.)

Hi, seahawk1986

Quote from 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:

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

Gruß,

Holger.

Hi,

mit

vdr-plugin-softhddevice 0.7.0+git20200325-788-1ef6f32-0yavdr0~bionic

kann ich nun non-HD Aufnahmen wieder ohne Ruckeln abspielen. Einen Ton-Versatz bei HD Sendern kann ich z.Zt. auch (noch) nicht feststellen.

Gruß und Danke an lnj für die Fixes.

Gruß,

Holger.

Quote from lnj

I reproduced a problem with sd records, will watch it.

Hi, lnj.

It is good to know to You could repdroduce SD issues. If required just let me/us know although I am dependent on the PPAs of yavdr ansible for further checking (I am less compiling experienced).

Regards,

Holger.

Hallo, wmautner.

Danke für die Info. Ein Fallback auf das Standard vdr-plugin-softhddevice zeigt identisches Verhalten wie bei der "-vpp" Version.

Sobald softhddevice.SoftStartSync =1ist, ist zwar das per SAT>IP gelieferte Bild okay, aber non-HD Aufnahmen "ruckeln".

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:

Mar 15 14:08:00 vdr vdr: video: slow down video, duping frame
Mar 15 14:08:00 vdr vdr: video: 23:02:27.243  +71 6798   0/\ms 182+5 v-buf
Mar 15 14:08:00 vdr vdr: video: speed up video, droping frame
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:

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.

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.