Wer den Skin nicht selbst bauen möchte:
Hier die 2 Dateien, die sich im default skin ändern.
Einfach nach "client/dist/skins/default" kopieren.
Wer den Skin nicht selbst bauen möchte:
Hier die 2 Dateien, die sich im default skin ändern.
Einfach nach "client/dist/skins/default" kopieren.
Hallo,
Anbei ein Patch.
Es werden 3 Fehler behoben, die zum Absturz (core dump) von VDR führen.
Außerdem werden damit auch tvscraper Bilder unterstützt. Dafür ist als POC eine Änderung in client/src/components/Event.vue . Diese wird aber erst nach dem neu Bauen des Skins wirksam. Und es wird tvscraper v1.2.1 oder neuer benötigt.
~ Markus
horchi ist noch in Urlaub, daher nicht wundern wenn er sich momentan nicht meldet.
Ich hatte das gleiche Verhalten bei Verwendung von libwebsockets >= Version 4.0. Nach Downgrade auf V. 3.2.3 lief es wieder einwandfrei. Im Plugin - Quellcode gibt es da eine Stelle die das Timeout-Handling betrifft, die sich in Version 4 von vorherigen Versionen unterscheidet.
Das mit dem trägen Update des Displays mit dem aktuellen libwebsockets stelle ich hier leider auch fest. Also wollte ich libwebsockets 3.2.3 kompilieren - für Opensuse Tumbleweed gibt's leider kein Repo mit dieser alten Version.
Doch leider geht's nicht. Daher hoffe ich jetzt auf @horchi mit einem Update von osd2web. Hoffentlich ist das nun nicht frech...
Vielen Dank!
Stefan
cd /usr/local/src && wget https://github.com/warmcat/libwebsockets/archive/refs/heads/v3.2-stable.zip && unzip v3.2-stable.zip && rm v3.2-stable.zip && cd libwebsockets-3.2-stable
mkdir build && cd build
cmake ..
make
[ 1%] Building C object CMakeFiles/websockets.dir/lib/core/alloc.c.o
[ 1%] Building C object CMakeFiles/websockets.dir/lib/core/buflist.c.o
[ 2%] Building C object CMakeFiles/websockets.dir/lib/core/context.c.o
[ 3%] Building C object CMakeFiles/websockets.dir/lib/core/lws_dll2.c.o
[ 3%] Building C object CMakeFiles/websockets.dir/lib/core/libwebsockets.c.o
/usr/local/src/libwebsockets-3.2-stable/lib/core/libwebsockets.c:568:1: Fehler: widersprüchliche Typen für »lws_tokenize« aufgrund von enum/integer-Konflikt; der bestehende Typ ist »int(struct lws_tokenize *)« [-Werror=enum-int-mismatch]
568 | lws_tokenize(struct lws_tokenize *ts)
| ^~~~~~~~~~~~
/usr/local/src/libwebsockets-3.2-stable/lib/core/libwebsockets.c:569:1: Anmerkung: vorherige Deklaration von »lws_tokenize« vom Typ »lws_tokenize_elem(struct lws_tokenize *)«
569 | {
| ^
cc1: Alle Warnungen werden als Fehler behandelt
make[2]: *** [CMakeFiles/websockets.dir/build.make:132: CMakeFiles/websockets.dir/lib/core/libwebsockets.c.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/websockets.dir/all] Fehler 2
make: *** [Makefile:156: all] Fehler 2
Display More
hier läuft osd2web mit der aktuellen Version der libwebsockets von github:
git clone https://github.com/warmcat/libwebsockets.git
cd libwebsockets
mkdir build
cd build
cmake ..
make
make install
dann das osd2web neu übersetzen und es läuft mit libwebsockets 4.3
root@gate~> grep libweb /var/log/vdr.log
Sep 26 10:50:03 gate vdr: osd2web: using libwebsocket version '4.3.99-v4.3.0-280-g7ef2065f'
Doch leider geht's nicht. Daher hoffe ich jetzt auf horchi mit einem Update von osd2web. Hoffentlich ist das nun nicht frech...
was ist mit Update gemeint?
Hallo Horchi,
endlich komme ich wieder an den VDR. Danke für Deinen Beitrag.
Funktionieren tut es schon mit libwebsockets 4.3. Aber bei Kanalwechsel braucht osd2web einige Sekunden, bis es den neuen Kanal anzeigt. Mit libwebsockets 3.2 ging das immer sofort.
Ist das bei Dir anders?
Stefan
ja ist bei mir komplett flüssig bzw. war komplett flüssig inzw. habe ich auf einer meiner Installationen auch Verzögerungen festgestellt.
Ich sehe es mir heute Abend genauer an
läuft hier flüssig mit dieser Version
Plugin osd2web: using libwebsocket version '4.3.99-v4.3.0-281-g4144c1e6'
Die Probleme sollten mit Version 0.3.0 des Plugins behoben sein
Die Probleme sollten mit Version 0.3.0 des Plugins behoben sein
Klasse, vielen Dank, Horchi! Dein Plugin läuft wieder supergut...
Wie bekomme ich die Log-Meldungen des Plugins ausgeschaltet?
Egal was ich in Make.config unter DEBUG einstelle, es bewirkt nichts.
Stefan
Hallo,
ich habe seit der neuen Version unter yavdr (Ubuntu 22.04 LTS) nur noch einen weißen Bildschirm, logmeldungen gibt es keine.
Muss ich da evtl. noch an einer Schraube drehen?
Rufe ich die Webseite über einen Browser im Netz auf stürzt der vdr ab.
Es gibt einen segfault:
Oct 13 22:28:58 vdr vdr: osd2web: HTTP: Requested uri: (12) '/data/getenv'
Oct 13 22:28:58 vdr kernel: [ 1362.627462] vdr[4905]: segfault at c ip 00007fd3c04c91cc sp 00007fd36e7fb2a0 error 6 in libvdr-osd2web.so.2.6.1[7fd3c04b3000+2e000]
Oct 13 22:28:58 vdr kernel: [ 1362.627477] Code: ff ff ff 48 8b 85 10 ff ff ff 48 89 c7 e8 c4 be ff ff 48 8b 85 38 ff ff ff 48 89 c7 e8 9d b6 fe ff 89 c2 48 8b 85 d0 fe ff ff <89> 50 0c 48 8b 85 d0 fe ff ff 8b 40 0c 8d 50 11 48 8b 85 d0 fe ff
massi
- selbst compiliert oder ist die neue Version es schon in der yavdr Distribution enthalten?
- Plugin Build 0.3.0?
- welche libwebsock?
- Backtrace?
Die Version ist schon in yavdr enthalten (0.3.0-0yavdr0~jammy), habe ich aber nicht selbst kompiliert ist aus dem seahawk repository.
libwebsockets (4.0.20-2ubuntu1)
Wo kann ich den plugin build nachschauen?
Und wie erstelle ich einen backtrace?
Mit Plugin Build meinte ich die Version, also die 0.3.0 ist damit beantwortet.
Backtrace ist vielerorts erklärt kann sich sich je nach Distribution etwas unterscheiden.
Du kannst mal versuchen den VDR zu beenden und ihn so an der Konsole zu starten:
ulimit -c unlimited
vdr
dann bring ihn so wie du es oben beschrieben hast zum crashen. Danach solltest du in dem Ordner in in welchem du ihn aufgerufen hast eine Datei mit core im Namen finden. Wenn ja hebe sie auf dann klären wir wie du reinschauen kannst. Ansonsten musst du klären wie es bei yavdr geht. Ggf. fängt dort der systemd die Core Files ab.
ZU Version der libwebsocket, ich hab hier kein System mit einer 4.0 - kann hier jemand bestätigen das osd2web damit das von massi beschriebene Problem hat?
Ich habe jetzt mal versucht einen Backtrace zu erstellen, mir wird nach dem Crash auch angezeigt: Speicherzugriffsfehler (Speicherabzug geschrieben)
Nur, wo wird der hingeschrieben, im aktuellen Verzeichnis ist er jedenfalls nicht zu finden?
Du verwendest doch yaVDR (?). Dann frage doch mal die yaVDR Spezialisten.
Ja, werde ich mal machen.
Mir ist es nun gelungen einen Backtrace zu erstellen, hoffe ich zumindest...
logging debugredirect: off: Debug output will go to both the screen and the log file.
logging enabled: on: Logging is enabled.
logging file: The current logfile is "vdr.log".
logging overwrite: off: Logging appends to the log file.
logging redirect: off: Output will go to both the screen and the log file.
#0 0x00007f669a17d2b8 in cWebSock::doEnvironment (wsi=0x7f6628002630,
sessionData=0x0) at websock.c:1100
header = '\000' <wiederholt 4111 Mal>
p = 0x7f669a1b0c30 <cWebSock::doEnvironment(lws*, cWebSock::SessionData*)::header+16> ""
e = 0x7f669a1b1c30 <cUpdate::updateReplayControl(int)::lactive> ""
dirSkin = 0x7f66280318f0
result = 0
path = 0x7f6628001e20 "\361/a\336a\177"
obj = 0x7f6628001e60
oEnvironment = 0x7f66280022b0
oSkins = 0x7f6630049840
pSkinEntry = 0x0
strJson = 0x7f662803c660 "{\"event\": \"environment\", \"object\": {\"skins\": [{\"name\": \"horchiTft\", \"themes\": [\"gray\", \"graycd\", \"plain\", \"bluecd\", \"blue\", \"anthraize\"]}, {\"name\": \"default\", \"themes\": [\"default\"]}, {\"name\": \"my_skin"...
#1 0x00007f669a17c917 in cWebSock::dispatchDataRequest (wsi=0x7f6628002630,
sessionData=0x0, url=0x7f66280235c9 "/data/getenv") at websock.c:902
statusCode = 404
method = 0x7f66280235cf "getenv"
#2 0x00007f669a17a5f7 in cWebSock::callbackHttp (wsi=0x7f6628002630,
reason=LWS_CALLBACK_HTTP, user=0x7f66280023d0, in=0x7f66280235c9, len=12)
at websock.c:373
res = 0
file = 0x0
url = 0x7f66280235c9 "/data/getenv"
sessionData = 0x0
clientInfo = "unknown"
#3 0x00007f669a0baeb2 in lws_http_action () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#4 0x00007f669a0bc1d0 in lws_handshake_server () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#5 0x00007f669a0c432d in lws_read_h1 () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#6 0x00007f669a0c4cf9 in lws_h1_server_socket_service () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#7 0x00007f669a0c512f in rops_handle_POLLIN_h1 () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#8 0x00007f669a0a5666 in lws_service_fd_tsi () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#9 0x00007f669a05dea6 in _lws_plat_service_forced_tsi () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#10 0x00007f669a05e2cb in _lws_plat_service_tsi () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#11 0x00007f669a05e332 in lws_plat_service () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#12 0x00007f669a0a584e in lws_service () from /usr/local/lib/libwebsockets.so.19
No symbol table info available.
#13 0x00007f669a179f3f in cWebSock::service (threadCtl=0x55658dca58f0) at websock.c:219
nextWebSocketPing = 1697460677
#14 0x00007f669a179efa in cWebSock::syncFct (user=0x55658dca58f0) at websock.c:201
threadCtl = 0x55658dca58f0
#15 0x00007f66a990fac3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#16 0x00007f66a99a1a40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Display More
Genau das suchte ich, damit sieht das Log aufgeräumter auf.
Vielen Dank und auch für die Pflege einiger Plugins! Das musste ich jetzt mal loswerden...
Stefan
War der Backtrace nicht ausreichend, um dem Problem auf die Schliche zu kommen?
Don’t have an account yet? Register yourself now and be a part of our community!