Der Commit wurde gemerged, aber das Paket ist weiterhin vorhanden. Ich denke, es müsste vorerst reichen, wenn man das irgendeinem (virtual) package als Abhängigkeit mitgibt.
Posts by rell
-
-
Zur Info vorab: https://github.com/LibreELEC/LibreELEC.tv/pull/11527
Evtl. bedeutet das für den ein oder anderen, dass er seine FB Konfiguration anpassen muss. Ich selbst benutze momentan (wenn ich richtig liege) flirc->eventlircd->lirc->VDR. Ich müsste wohl dann direkt die keyboard events abgreifen?!
-
Zabrimus Ich hängs mal an diesen Thread.
Gestern wollte ich seit langem mal wieder was in der Mediathek anschauen, konkret "Kapitän Kimmich". Anwahl über ARD hat nicht funktioniert, das Video hat nicht gestartet. Das war aber dann auch über die App vom Samsung TV so. Ich wollte dann das Video über die ZDF Mediathek starten, was dann den VDR beendet hat.
BT:
Code
Display More(gdb) bt #0 __strlen_generic () at ../sysdeps/aarch64/multiarch/../strlen.S:53 #1 0x0000007f88802ff4 in __printf_buffer (buf=buf@entry=0x7f627cda60, format=format@entry=0x7f627ce0f0 "[2656] [softhddevice] device: %s: playmode not supported %d", ap=..., mode_flags=<optimized out>) at /home/andreas/git/VDRSternELEC/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/build/glibc-2.43/stdio-common/vfprintf-process-arg.c:443 #2 0x0000007f88824088 in __vsnprintf_internal (string=<optimized out>, maxlen=maxlen@entry=999, format=format@entry=0x7f627ce0f0 "[2656] [softhddevice] device: %s: playmode not supported %d", args=<error reading variable: Cannot access memory at address 0x1fd89f383c0>, mode_flags=mode_flags@entry=0) at vsnprintf.c:96 #3 0x0000007f8888db78 in __vsyslog_internal (pri=11, fmt=<optimized out>, ap=..., mode_flags=mode_flags@entry=0) at syslog.c:222 #4 0x0000007f8888e06c in __vsyslog (pri=<optimized out>, fmt=<optimized out>, ap=...) at syslog.c:100 #5 0x0000007f882f6450 in cSoftHdLogger::LogError (this=<optimized out>, format=format@entry=0x7f88337e00 "device: %s: playmode not supported %d") at logger.cpp:85 #6 0x0000007f883057d4 in cSoftHdDevice::SetPlayMode (this=0x3b7cd720, play_mode=3960089168) at /home/andreas/git/VDRSternELEC/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/toolchain/aarch64-libreelec-linux-gnu/include/c++/16.1.0/bits/shared_ptr_base.h:1751 #7 0x0000000000499a14 in cDevice::AttachPlayer (this=0x3b7cd720, Player=0x7eec0a2a50) at device.c:1407 #8 0x000000000050811c in cControl::Attach () at player.c:90 #9 0x0000007f7babb688 in VdrPluginWebServer::StartVideo (this=<optimized out>, input=...) at web.cpp:202 #10 0x0000007f7bae2498 in pluginweb::VdrPluginWebProcessor::process_StartVideo (this=0x7f68009790, seqid=0, iprot=<optimized out>, oprot=0x7f68009650, callContext=<optimized out>) at thrift-services/src-gen/VdrPluginWeb.cpp:3632 #11 0x0000007f7bacfb60 in pluginweb::VdrPluginWebProcessor::dispatchCall (this=0x7f68009790, iprot=<optimized out>, oprot=<optimized out>, fname=..., seqid=0, callContext=0x0) at thrift-services/src-gen/VdrPluginWeb.cpp:3434 #12 0x0000007f7bacc3f4 in apache::thrift::TDispatchProcessor::process (this=0x7f68009790, in=..., out=..., connectionContext=0x0) at /home/andreas/git/VDRSternELEC/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/toolchain/aarch64-libreelec-linux-gnu/sysroot/usr/include/thrift/TDispatchProcessor.h:121 #13 0x0000007f7bb3411c in apache::thrift::server::TConnectedClient::run() () from /usr/local/lib/vdr/libvdr-web.so.13 #14 0x0000007f7bb1a3a0 in apache::thrift::concurrency::ThreadManager::Worker::run() () from /usr/local/lib/vdr/libvdr-web.so.13 #15 0x0000007f7bb2c88c in apache::thrift::concurrency::Thread::threadMain(std::shared_ptr<apache::thrift::concurrency::Thread>) () from /usr/local/lib/vdr/libvdr-web.so.13 #16 0x0000007f7bb17e00 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(std::shared_ptr<apache::thrift::concurrency::Thread>), std::shared_ptr<apache::thrift::concurrency::Thread> > > >::_M_run() () from /usr/local/lib/vdr/libvdr-web.so.13 #17 0x0000007f88b411bc in ?? () from /usr/lib/libstdc++.so.6 #18 0x0000007f8882f0bc in start_thread (arg=0x7f627cf160) at pthread_create.c:454 #19 0x0000007f8888f75c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone3.S:75konkret:
Code
Display More#5 0x0000007f882f6450 in cSoftHdLogger::LogError (this=<optimized out>, format=format@entry=0x7f88337e00 "device: %s: playmode not supported %d") at logger.cpp:85 ap = {__stack = 0x7f627ce3a0, __gr_top = 0x7f627ce3a0, __vr_top = 0x7f627ce370, __gr_offs = -48, __vr_offs = -128} fmt = "[2656] [softhddevice] device: %s: playmode not supported %d\000\000\000\000\000\034\017.\210\177\000\000\000\020\004\255;\000\000\000\000(\004\255;\000\000\000\000\250\257Q9\271t{\177\220\341|b\177\000\000\000\000\0042\210\177\000\000\000 \327|;\000\000\000\000\000\352\251;\000\000\000\000", '%' <repeats 16 times>, "s\000\000|\177\000\000\000\240\b\000|\177\000\000\000\360\377\377\377\000\000\377\377\000\000\000\000\000\000\000\000\000\377\377\000\000\377\377\377\000\000\377\000\000\377\377\377\360\017\360\377\000\017\360\377"... threadId = <optimized out> #6 0x0000007f883057d4 in cSoftHdDevice::SetPlayMode (this=0x3b7cd720, play_mode=3960089168) at /home/andreas/git/VDRSternELEC/LibreELEC.tv/build.LibreELEC-RPi4.aarch64-13.0-devel/toolchain/aarch64-libreelec-linux-gnu/include/c++/16.1.0/bits/shared_ptr_base.h:1751 __FUNCTION__ = "SetPlayMode" #7 0x0000000000499a14 in cDevice::AttachPlayer (this=0x3b7cd720, Player=0x7eec0a2a50) at device.c:1407 No locals. #8 0x000000000050811c in cControl::Attach () at player.c:90 MutexLock = {mutex = 0x67b378 <cControl::mutex>, locked = true} #9 0x0000007f7babb688 in VdrPluginWebServer::StartVideo (this=<optimized out>, input=...) at web.cpp:202 page = 0x7eec0a2a50Der playmode riecht arg verdächtig. Kann es sein, dass die Basisklasse cPlayer nicht mit dem playmode bzw. überhaupt nicht initialisiert wird? Ich denke, hier müsste noch sowas wie ein : cPlayer(pmAudioVideo) dran...
Der cefbrowser verabschiedet sich anschließend noch mit einem abort(), aber da fehlen mir die debug symbole für einen backtrace.
-
Kein Stress, ich kann EAC3 nur selber nicht testen... Danke!
-
carel I can't confirm it with skinlcarsng and OpenGL-Rendering.
-
-
Hallo zusammen,
könnte jemand mal testen, mit einem Ausgabeplugin != softhddevice-drm-gles und skinlcars eine Aufnahme zu löschen, aber die Abfrage mit Exit zu canceln? Siehe https://github.com/rellla/vdr-plu…gles/issues/183 Ich kann das Verhalten hier bei allen VDR skins nachstellen. Zwischen den Farbbuttons bleibt die Abfrage sichtbar.
Ich möchte nur wissen, ob das ein Bug in VDR oder im Ausgabeplugin ist...
Danke
-
Version 1.6.7 ist online. Damit sollte jetzt auch das ganze PiP-Handling sauber funktionieren. Zumindest konnte ich bisher keine Fehler produzieren. Das war mir schon lange ein Dorn im Auge....
neumann2k Wenn du Zeit findest, könntest du damit DD+ nochmal testen, dann schaue ich mir das nochmal an. Evtl. war der Bug verantwortlich, der sich in die 1.6.6 eingeschlichen hat und den ich mit https://github.com/rellla/vdr-plu…2f56d71d2d16a97 gefixt habe...
-
Läuft diese Kombination vernünftig mit HD, ohne das der Raspi überfordert wird?
Ja.
Kann mir jemand einen Tipp geben, wie ich den VDR am einfachsten darauf installiere?
Wenn du was "fertiges" möchtest, MLD oder VDR*ELEC.
-
AnixeHD glaub ich auch.
-
vdr-projects auf GitHub funktioniert einfach zu gut. Deshalb gibt es dazu keine Posts. Die Menschen melden sich halt immer dann, wenn etwas nicht geht ...
Ich würde nicht daraus schließen dass sie nicht genutzt wird.
Ich finde z.B. https://github.com/vdr-projects/v…R-Plugin-System äußerst praktisch.
Auch wenn ich mal den aktuellen Source eines Plugins suche, dann werde ich auf vdr-projects fündig.
Genauso sehe ich es auch und möchte es nicht missen. Ich nutze nur ca. 5 Plugins und die laufen und ich weiß wo sie sind... Aber die formatierten VDR manuals und die Gesamtübersicht ist trotzdem extrem praktisch.
-
Für den Fall, dass noch jemand das Problem mit der aktuellen LE hat, dass eventlircd nicht mehr auf den Flirc-Empfänger anspricht - ich musste die udev-rule anpassen:
Code# FLIRC receiver ATTRS{idVendor}=="20a0", \ ATTRS{idProduct}=="0006", \ ENV{eventlircd_enable}="true", \ ENV{eventlircd_evmap}="default.evmap"Ansonsten reagiert Flirc als Keyboard und die LIRC.* Einträge in der remote.conf greifen nicht mehr. Wer bisher "nur" die KBD*-Einträge genutzt hat, merkt es wohl gar nicht. Mir ist es nur aufgefallen, da die User1-9 nicht mehr meine keymacros ausgelöst haben. User1-9 waren nur bei LIRC.* konfiguriert.
Wenn das Verhalten noch wer bestätigen kann, könnte man das in der readme anpassen... Wie es sich bei CE verhält, weiß ich nicht.
-
kamel5 Ich habs gefunden:
https://gitlab.com/kamel5/skinlca…type=heads#L799 stimmt nicht. Es wird x + y und w + h übergeben. Das neue DrawScreenResolution() erwartet aber x0, y0, x1 und x2 und macht daraus dann w + h für DrawText(). Ob das mit den margins passt, weiß ich nicht, das ist bei cLCARSNGDisplayReplay() nur einmal dabei. M.E. müsste es so sein:
Diff
Display Morediff --git a/displaychannel.c b/displaychannel.c index c97debd..457d42e 100644 --- a/displaychannel.c +++ b/displaychannel.c @@ -781,7 +781,7 @@ void cLCARSNGDisplayChannel::Flush(void) { if (withInfo) { if (!message) { - DrawDate(osd, xc21 + Margin, yc00 + Margin, xc22 - textBorder - 2 * Margin, yc01 - 2 * Margin, Theme.Color(clrDateFg), Theme.Color(clrDateBg), osdFont, &lastDate); + DrawDate(osd, xc21 + Margin, yc00 + Margin, xc22 - textBorder - Margin, yc01 - Margin, Theme.Color(clrDateFg), Theme.Color(clrDateBg), osdFont, &lastDate); DrawDevice(); DrawSignal(); DrawTimer(); @@ -794,9 +794,9 @@ void cLCARSNGDisplayChannel::Flush(void) Total = present->Duration(); } DrawSeen(Current, Total); - DrawTrack(osd, xc14 + Margin, yc15 + Margin, xc18 - textBorder - 2 * Margin, yc16 - 2 * Margin, Theme.Color(clrTrackName), frameColorBg, (zoom) ? smlFont : osdFont, &lastTrackId); + DrawTrack(osd, xc14 + Margin, yc15 + Margin, xc18 - textBorder - Margin, yc16 - Margin, Theme.Color(clrTrackName), frameColorBg, (zoom) ? smlFont : osdFont, &lastTrackId); int x = leftIcons - SymbolSpacing; - DrawScreenResolution(osd, xc19 + Margin, yc15 + Margin, x - xc19 - 2 * Margin, yc16 - yc15 - 2 * Margin, Theme.Color(clrChannelSymbolOn), frameColorBr, (zoom) ? smlFont : osdFont, &oldResolution); + DrawScreenResolution(osd, xc19 + Margin, yc15 + Margin, x - Margin, yc16 - Margin, Theme.Color(clrChannelSymbolOn), frameColorBr, (zoom) ? smlFont : osdFont, &oldResolution); DrawEventRec(present, following); DrawBlinkingRec(); }Was meinst du dazu? Jedenfalls taucht jetzt auch die Auflösung bei mir auf.
(Schade nur, dass mein OpenGL OSD das bisher nicht abgefangen hat...)EDIT: So siehts jetzt aus - mit "SD576i"
The content cannot be displayed because you do not have authorisation to view this content. -
Es scheint an DrawScreenResolution() zu liegen. Wenn ich das auskommentiere, passt es. Zumindest bei einem schnellen Test.
Im Übrigen sehe ich auch keinen Unterschied in der Darstellung. Ich suche da mal weiter.
-
Läuft hier mit CPU Osd auch ohne Probleme, werds schon finden. Komisch nur, dass das jetzt auftritt, obwohl (fast) nichts geändert wurde....
-
Danke, ich gehe mal auf die Suche...
-
Hallo kamel5 ,
hast du hier https://github.com/rellla/vdr-plu…gles/issues/258 eine Idee, welche Änderung im skin das auslösen könnte?
Ich habe VDR*Elec upgedatet und damit 0.5.4 nachgezogen. Vorher trat das nicht auf, vermutlich hatte ich 0.5.3. Und an den opengl Sachen habe ich im Ausgabedevice kürzlich nichts geändert...
-
Oh...
EDIT: Kannst du mir ein Log zur Verfügung stellen?
EDIT2: Was zeigt dein Receiver an? Springt der in den PCM mode, DD+ oder kann er gar nichts locken? -
neumann2k In der Version 1.6.6 sind jetzt einige Änderungen enthalten, die passthrough betreffen. Evtl. löst es dein Problem ja ...
-
Auf die Schnelle kann ich das nicht testen, aber wenn dem wirklich so ist, wäre es interessant, ob es für das Feature eine Alternative zu .annotate oder graphicsmagick an sich gibt...