Beiträge von holger_p.

Zitat von 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 ?

Zitat von 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:

Zitat

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.

Zitat von 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,

Zitat von 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.

Zitat von 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

Zitat von 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.

Zitat von 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.

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:

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'
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:

Feb  8 15:21:36 vdr vdr: [1812] ERROR: oops while storing remote timers!
[...]
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

Feb  8 15:23:07 vdr-server vdr: [5787] timer 4 (2 1555-1715 'Dokumentation~Bares für Rares') set to no event
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.