Das Bild im Landscape Format wird korrekt angezeigt. Das Bild im Portrait Format wird auf der linken Hälfte des Platzes angezeigt, auf der rechten Hälfte des Platzes bleibt das halbe Bild im Landscape Format stehen.
Probier mal diesen Patch
Das Bild im Landscape Format wird korrekt angezeigt. Das Bild im Portrait Format wird auf der linken Hälfte des Platzes angezeigt, auf der rechten Hälfte des Platzes bleibt das halbe Bild im Landscape Format stehen.
Probier mal diesen Patch
strncpy kopiert ganz "s" und das "\0" aus der nächsten Code Zeile überschreibt das letzte Zeichen von "s".
Mir ist schon klar was da passiert, auch wenn der Teil (IIRC) nicht auf meinem Mist gewachsen ist. Aber schaue Dir mal den kompletten Code an um zu verstehen was da wirklich passiert.
Mein Compiler meldet noch:
Da irrt die "KI" Deines Compilers (oder Du?): direkt danach wird ein Nullbyte geschrieben um solche Probleme zu verhindern:
Sch... hatte es extra noch in einen Link umgewandelt. Nach dem zurücknehmen geht's jetzt
Ja, hier werden Sie geholfen
Ich habe mal eine Issue dazu aufgemacht: https://github.com/vdr-project…lugin-epgsearch/issues/12
Das Limit brauchte man in ganz alten VDR Versionen.
Das ist leider fest einkompiliert und kein Runtime-Parameter
Problem beginnt ja offensichtlich auch bei der Erstellung des Titels, also bei epgsearch selbst ... das wiederum hat aber einen solchen schalter gar nicht?
Doch, aber gut versteckt: im EPGsearch wird MAX_SUBTITLE_LENGTH = 40 gesetzt wenn man beim Kompilieren nichts anders mitgibt.
Bei mir steht deshalb in der plugins.mk PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH=4096 damit das Plugin beim kompilieren das höher setzt
Also, das wird wohl nix! Als damals das Plugin programmiert wurde, hat cChannels::Load() eine Kanalliste in die angegebene Variable geladen, heutzutage wird IMMER in die gloabale Channels-Variable geladen, auch bei favourites.Load(...) ! Das erklärt auch, warum ohne activeChannelList.conf der VDR kein Bild mehr beim Start anzeigen konnte.
Man müsste den ganzen Teil neu schreiben (am besten mit tChannelID anstatt cChannels, da man ja nur eine Referenz auf den Kanal braucht und nicht die ganzen Kanalparameter selbst). Dazu fehlt mir allerdings neben der Zeit auch die Motivation ...
ja die Links müssen auf die channels.conf zeigen
Warum Links? Dann hätte der Entwickler doch gleich die Original-Channels.conf nehmen können....
Und im README steht: Provides a seperate favourites list, that is independent of vdr's channel list.
leider stürzt das Plugin bei der Nutzung ab
Müssten da nicht irgendwo dann auch StateKey.Remove() sein? Ich habe keine StateKeys benutzt, sondern überall LOCK_CHANNELS_READ/WRITE und damit habe ich keine Abstürze - Favoriten kann man damit aber auch keine anlegen, da offenbar der Group Separator (Kanalname beginnend mit ':') in der Kanalliste für Favoritenordner genutzt wird und die aber nur beim Einlesen der Kanalliste erzeugt werden, da das Flag groupSep über keine Funktion in channels.h gesetzt werden kann.
Copy your channels.conf to <VDR-CONFIG>/plugins/reelchannellist/activeChannelList.conf
and maybe also to <VDR-CONFIG>/plugins/reelchannellist/favourites.conf
and you should get the video at startup
However, editing of the favourites seems to be impossible as VDR is missing the channels->SetGroupSep() Funktion (groupSep is only set when reading a channels.conf file). Also I haven't undestood yet how the Favourites / Bouqets are intended to work.
Habe aus Neugier mal ein paar Sachen angepasst - aber ohne Sinn und Verstand wie das Plugin funktioniert.
Z.B. ein Lock auf Channels von Konstruktor bis zum Destruktor ist keine gute Idee, aber der Compiler ist mit den Befehlen erst mal zufrieden.
Da muss noch viel Aufwand reingesteckt werden, z.B. AddFloatingText() und "MenuMainHook_Data_V1_0" gibt's im Original-VDR nicht
Edit: ein Makefile auf aktuellem Stand ist auch kein Fehler
Edit2: die menu.c braucht die angepasste menu.h .... das AddFloatingText() habe ich inzwischen in cUtils gefunden
Mit dem Femon-Plugin ("Signalinformationen") kann man mit links/rechts durch die Frontends durchschalten, welches fürs Live-TV benutzt wird.
Ok, ich werde es mit -Wshadow probieren und versuchen das nochmal nachzustellen
Nach reiflicher Überlegung ... verstehe ich immer noch nicht was da passiert ist.
Beim Schneiden auf der zweiten SSD lief diese voll, so dass das Schneiden abgebrochen wurde. Dann hing der VDR mit offenem Recording Display bis ich ihn beendet habe.
(gdb) bt
#0 0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2 0x0000000000540f19 in cMutex::Lock (this=0x61bde0 <RecordingsHandler+96>) at thread.c:224
#3 0x000000000054167f in cMutexLock::Lock (this=0x7ffd415bd200, Mutex=<optimized out>) at thread.c:409
#4 0x00000000005063cf in cRecordingsHandler::Finished (this=0x61bd80 <RecordingsHandler>, Error=@0x7ffd415bd320: false) at recording.c:2119
#5 0x0000000000480895 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1525
(gdb) bt
#0 0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2 0x0000000000540f19 in cMutex::Lock (this=0x61bc00 <cControl::mutex>) at thread.c:224
#3 0x000000000054167f in cMutexLock::Lock (this=0x7f160247cc50, Mutex=<optimized out>) at thread.c:409
#4 0x00000000005009e7 in cControl::Shutdown () at player.c:110
#5 0x000000000049944d in cCutter::Active (this=0x7f1654005110) at cutter.c:714
calls Stop();
#6 0x000000000050bf8d in cRecordingsHandlerEntry::Active (this=this@entry=0x11858c0, Recordings=Recordings@entry=0x61bf80 <cRecordings::recordings>) at recording.c:1938
#7 0x000000000050c2dc in cRecordingsHandler::Action (this=0x61bd80 <RecordingsHandler>) at recording.c:2035
LOCK_RECORDINGS_WRITE in recording.c:2035
#8 0x0000000000541395 in cThread::StartThread (Thread=0x61bd80 <RecordingsHandler>) at thread.c:293
#9 0x00007f16a78c86ea in start_thread () from /lib64/libpthread.so.0
#10 0x00007f16a6139a6f in clone () from /lib64/libc.so.6
Alles anzeigen
Ich sehe aber in den beiden Backtraces keine zweite Mutex, die zu einem Deadlock führen könnte.
Kann es sein, dass der Compiler da die Mutexe verwechselt weil sowohl das statische cMutex cControl::mutex in cControl::Shutdown() als auch private cMutex mutex in cRecordingsHandler::Finished() nur als &mutex angesprochen werden?
kls : Kannst Du Dir das bitte mal ansehen?
Ich sag's nur ungern, aber ich habe wieder einen Deadlock, diesmal in RecordingsHandler::Finished()
Details später ...
Ja, es gab Abstürze bei mir.
Schneide und verschiebe meist gleich danach, hätte vor längerer Zeit mal einen Beitrag zu dem crash verfasst.
Es ging jetzt aber nicht um einen Absturz (Segfault) sondern um einen Deadlock, d.h. das Menü und der ganze VDR reagieren nicht mehr auf Eingaben.
Deinen Post hatte ich die Tage gefunden, der war vermutlich der Grund für den Fix, der mit 2.6.2 rein kam aber sporadisch einen Deadlock erzeugt hat. Mit dem neuen Fix müssten jetzt aber beide Probleme behoben sein.
Ich hatte es auch einmal beim Verschieben auf eine andere Partition, aber ansonsten nur manchmal beim Schneiden. Zusätzlich muss ja das Menü offen sein und auch dann tritt es nur sporadisch auf.
kamel5: Kannst Du den Patch auch mal installieren? Du konntest ja den Deadlock zuverlässiger reproduzieren als ich