Nun, wenn es fertig ist, könnte ich es ja, bei Bedarf irgendwo hochladen.
Das wäre nett. Ich möchte es auch einmal ausprobieren. ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Beiträge von tomglx
-
-
Ich weiss nicht, ob ich der einzige bin, bei dem das Auflösungsicon in der Wiedergabeanzeige den Anfang des Fortschrittsbalkens und die Ausgabe der aktuellen Wiedergabezeit überlagert.
Beiliegender Patch behebt das Problem für mich+1
Bist du nicht. Geht mir genauso. Danke für den Patch. -
Ich patche meinen VDR dafür immer. Damit ist das bei mir dann der Default.
Also Full ACK. Damit könnte ich dann auch auf diese Änderung verzichten.
Für die Haptik des VDR wäre das ein großer Fortschritt.Bevor hier jemand für das extrecmenu als Grundfunktion plädiert würde ich erst einmal epgsearch bevorzugen.
Aber das wird wohl leider auch nichts. Wundert mich, wie es das dvbhddevice plugin geschafft hat. Immerhin hat
das nicht KLS geschrieben. -
Na ja, so richtig funktioniert das nicht.
Codevdr01_64 src # find . -name "Makefile" -exec grep -L "PKGCFG" {} \; |wc -l 266 vdr01_64 src #Ich habe ja schließlich keine 266 kupferfreie Plugins installiert.
Wie wäre es damit. Aus dem PLUGINS/src Verzeichnis.Codefind -H . -maxdepth 2 -name Makefile -exec grep -L PKGCFG {} \; | wc -l -
Hallo,
ganz schöner Glaubenskrieg hier. Dabei zieht mein Patch überhaupt nur dann, wenn die Plugins eben nicht bei einer Installation in den Rest des Filesystems.
Sie sorgt nur dafür das bei Bedarf eben alle *.so Dateien im PLUGINS/lib Verzeichnis landen. Die LCLBLD Methode wird IMHO sowieso kein Distributor nutzen.
Wenn man diesen Weg wählt, dann muss man sowieso danach selbst dafür sorgen das die *.so Dateien an ihren eigentlichen Zielort gelangen. Zumindest ist
das bei mir so und meiner Meinung nach gibt es LCLBLD überhaupt nur noch für solche Leute wie mich.Es ist ja nett darüber zu diskutieren was Pluginautoren hätten tun sollen, oder nicht. Dadurch das nicht von vorn herein entsprechende Regeln aufgestellt
wurden, ist es eben soweit gekommen. Klaus hat selber schon bemerkt, dass er besser Richtlinien oder sogar eine Zertifizierung für Plugins hätte einführen
sollen.Das nutzt jetzt nichts mehr! Das jetzt wieder einzufangen ist so, als würde man versuchen ein Foto aus dem Internet zu löschen. Warum? Weil es zwar viele
Plugins gibt, aber kaum noch Maintainer. Anders ausgedrückt. Warum nutzen alle Windows? Weil sie ihre steinalten Applikationen aus WIndows 95 Zeiten auch
heute noch betreiben können und wollen. MS ist das auch nicht recht, aber wenn man seine Nutzer nicht verärgern will, dann muss man eben kompatibel
bleiben. Warum verkauft Apple wohl iPhones wie blöd? Weil die Leute es einfach haben und keinen Ärger haben wollen.Wenn dieser Patch überflüssig ist, warum gibt es dann trotzdem den Kompatibilitätsmodus für alte Makefiles? Warum gibt es LCLBLD? Ebenfalls deswegen.
Wenn das mit der 2.1 entfernt werden sollte, dann bricht hier derselbe Shitstorm doch wieder los. Im Moment sind die Leute doch nur ruhig, weil sich alle
Plugins doch noch mit den alten Makefiles bauen lassen. Wie viele Leute versuchen es denn überhaupt mal, einen kompletten VDR nur mit neuen Makefiles
zu bauen? Distributoren mal ausgenommen.Die reine Lehre die hier von einigen fast fanatisch vertreten wird, ist entweder Realitätsfremd oder einfach egoistisch. Es ist einfach über etwas zu urteilen,
wenn man selbst nicht darauf angewiesen ist.Duck.
Gruss, Thomas
-
Hallo,
ich versuche mich hier gerade am Build der vdr version 1.7.38. Dabei arbeite ich mit dem aktivierten LCLBLD Schalter und
durchgängig mit neuen Makefiles.Leider werden dabei nicht alle Plugins komplett in das PLUGINS/lib Verzeichnis kopiert. Betroffen sind hier insbesondere Plugins
die mit Unterverzeichnisstrukturen arbeiten. Wie markad und andere.Ich habe mal eine Änderung erarbeitet, die das Problem für mich zu lösen scheint. Das die Wildcard hier nicht mehr auf libvdr-
geht, ist durchaus Absicht. Da gibt es einen Fall, in das man das benötigt.Diff
Alles anzeigen--- Makefile.orig 2013-02-25 21:04:48.725348108 +0100 +++ Makefile 2013-02-25 21:54:04.425473937 +0100 @@ -238,7 +238,7 @@ INCLUDES="-I$(CWD)/include"\ $(MAKE) --no-print-directory -C "$(PLUGINDIR)/src/$$i" VDRDIR="$(CWD)" || failed="$$failed $$i";\ if [ -n "$(LCLBLD)" ] ; then\ - (cd $(PLUGINDIR)/src/$$i; for l in libvdr-*.so; do install $$l $(LIBDIR)/$$l.$(APIVERSION); done);\ + find $(PLUGINDIR)/src/$$i -follow -name "lib*.so" -exec bash -c 'install {} $(LIBDIR)/`basename {}`.$(APIVERSION)' \; ;\ if [ -d $(PLUGINDIR)/src/$$i/po ]; then\ for l in `ls $(PLUGINDIR)/src/$$i/po/*.mo`; do\ install -D -m644 $$l $(LOCDIR)/`basename $$l | cut -d. -f1`/LC_MESSAGES/vdr-$$i.mo;\Ich würde mich freuen, wenn diese Änderung in der nächsten VDR Version berücksichtigt werden könnte.
Gruss,
Thomas -
-
Ich warte eigentlich immer noch darauf, daß mir jemand erklärt, was das denn für eine Abhängigkeit ist...
Ich verstehe einfach nicht, warum eine Skin von einem anderen Plugin abhängig sein sollte.Klaus
Ich versuche das einmal runter zu brechen.
Plugins sollen den Funktionsumfang erweitern. Warum sollte es dann nicht vorkommen können, dass Plugins auch untereinander diese Mehrwerte nutzen um ihren eigenen zu steigern? Kaskadierung eben. Wenn man ein Haus baut, dann kann zwar jeder ein Zimmer auf
das Fundament bauen, aber richtig gut wird es doch erst mit mehreren Stockwerken, oder?Bei EPGsearch ist es sogar noch extremer. Es schickt sich an, das Fundament teilweise ersetzen zu wollen.
Solche Durchgriffe treten IMHO bei Skin Plugins am ehesten auf, weil man Funktionen aus dem VDR Core zusammen mit welchen aus beliebigen Plugins unter einer Oberfläche zusammen fassen möchte. Aus meiner persönlichen Erfahrung kann ich da die Verbindung zwischen skinelchi und dem Avards Plugin nennen. Da wurde über Avards das aktuelle Seitenverhältnis ermittelt und dargestellt
(4:3, 16:9 usw.).Bei EnigmaNG und hier wird das u. a. zur korrekten Darstellung von Progressbars und Integration von Logos, sowie zur Teilung des Bildschirms benutzt.
Ich hoffe das hilft weiter.
-
Wenn ich die von mir genutzten Plugin mal auf Abhängigkeiten zum Epgsearch hin prüfe, so finde ich da auf Anhieb sowohl das
EnigmaNG Skin als auch GraphTFT. Nopacity ist hier wohl nur einem existierenden Trend gefolgt.Der Unterschied zwischen dem integrierten EPG und EPGsearch ist IMHO schon so groß, als ob man einen Trabbi mit einem Mercedes
vergleicht. Wie wichtig den VDR Benutzern das EPG ist, kann man auch sehr schön an dem Aufsehen messen, als letzthin
Änderungen am Format gemacht wurden.Wenn also solche Verbindungen zwischen Plugins geschaffen werden, dass ist das IMHO nur ein Beweis für die allgemeine Akzeptanz
und den Verbreitungsgrad und damit die Wichtigkeit von EPGsearch. Damit wird das Vorhandensein dieses Plugins schon fast zu einem
Standard erhoben.Da nun schon ein Trend zur Integration diverser bisher einzeln existierender Einzelpatches existiert (z. B. Unicable), so möchte ich hier
einmal die Frage stellen, warum es nicht sinnvoll sein könnte EPGsearch als Standard in den VDR Core zu integrieren?Damit würde sich die Frage mit den Pluginabhängigkeiten auch lösen lassen. Ich sehe hier durchaus auch das Problem, dass dann verschiedene Leute am Core weiter arbeiten müssten. Etwas das Klaus sich bisher exklusiv vorbehalten hat. Aus diesem Grund wurde
die Plugin Schnittstelle ja erst geschaffen. Bleibt die Frage nach einem Kompromiss zwischen beidem?Auch wenn diese Fragestellung hier untergehen sollte, bin ich mir sicher das es nicht das letzte Mal sein wird, dass jemand diese
Frage so oder in ähnlicher Form aufwirft.
Gruss und ein schönes neues Jahr, Thomas
-
IMHO wird es wohl höchste Zeit für die Version 2.0. Der Makefile Change wäre wohl in der 2.1.x Serie besser aufgehoben gewesen.
Mich würde mal interessieren wie viele hier bereits zwingend auf die 1.7.x angewiesen sind, weil es ohne kein HD gibt?
Das Argument mit der Developer Serie verfängt hier deswegen nur begrenzt.Beim Linux Kernel wurde mit der 2.6 die Trennung zwischen Developer und Stable aufgegeben. Wir befinden uns aufgrund der
langen Entwicklungszyklen indirekt in derselben Situation denke ich.Gruss, Thomas
-
FULL ACK. Ich möchte kontextabhängig jeden Tastendruck mit einem Pluginaufruf übersteuern können.
Bsp. Taste 0 mit dem Aufruf von zaphistory.
Auf den MainMenuHooks Patch für den Aufruf von epgsearch und extrecmenu verzichten können.
usw.Es ist Weihnachten. Da kann man sich mal was wünschen.
-
Hallo,
bei mir gibt es einen wunderschönen Segmentation fault im Plugin, wenn ich den VDR dazu veranlasse die FB neu anzulernen.
Nur falls das von Interesse ist.Gruss, Thomas
-
Nicht bei der Wiedergabe. Nur bei den HD Sendern der ProSiebenSat1 Gruppe.
IMHO haben die was am Encoder bei denen geändert.Gruss, Thomas
-
Hallo,
geht mir seit neuestem mit Kabel 1 genauso. Allerdings schon beim Aufschalten beim Senderwechsel. Manchmal bleibt der Ton ganz weg.
Mehrmaliger Senderwechsel löst das Problem dann meist.Eine Ursache dafür kenne ich allerdings auch nicht.
Thomas
-
Hallo,
das ist kein Wunder. In den neueren udev Versionen ist das Verhalten zum laden der Modul-Firmwares geändert worden. Der Treiber müsste darauf angepasst werden.
Ich weiß nicht, ob das hier schon geschehen ist. Sieht aber danach aus.Gruss, Thomas
-
Hallo,
ich bekomme jedesmal beim Beenden des VDR einen segfault an derselben Stelle. Im VDR selbst und zwar wenn das Ende eines der vielen Threads in das
Syslog geschrieben werden soll. Der Abbruch passiert beim Aufruf der vsyslog Funktion in der Methode syslog_with_tid. Hier mal ein kompletter Backtrace.
Leider kapiere ich nicht, wie ich diesen offenbar korrupten Aufruf abfangen soll und benötige Hilfe. Wer kann mir bitte damit helfen?Gruss, Thomas
(gdb) bt full
#0 0xb77a6424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb738593f in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = <optimized out>
resultvar = <optimized out>
pid = -1219489804
selftid = 13245
#2 0xb7387293 in __GI_abort () at abort.c:91
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {5, 3075216139, 0,
3075493888, 875837282, 1697920312, 905969664, 1697997110, 3077660624, 3073732608, 3073792495, 3074721008,
3077660624, 14, 3075216139, 1, 3073792495, 5, 3075219724, 3, 2939148438, 2, 3075216091, 1, 3075222824, 3,
2939148424, 8, 3075222828, 2, 3, 4096}}, sa_flags = -1355817064, sa_restorer = 0x400}
sigs = {__val = {32, 0 <repeats 31 times>}}
#3 0xb73c3795 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=
0xb74c40f4 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198
ap = 0x7 <Address 0x7 out of bounds>
ap_copy = 0x7 <Address 0x7 out of bounds>
fd = 19
on_2 = <optimized out>
list = <optimized out>
nlist = <optimized out>
cp = <optimized out>
written = <optimized out>
#4 0xb73cb119 in malloc_printerr (ptr=0x962ab88, str=0xb74c4188 "double free or corruption (out)",
action=<optimized out>) at malloc.c:5027
buf = "0962ab88"
cp = <optimized out>
#5 _int_free (av=av@entry=0xb7501420, p=p@entry=0x962ab80, have_lock=have_lock@entry=1) at malloc.c:3948
size = <optimized out>
fb = <optimized out>
nextchunk = <optimized out>
nextsize = <optimized out>
nextinuse = <optimized out>
prevsize = <optimized out>
bck = <optimized out>
fwd = <optimized out>
errstr = <optimized out>
locked = <optimized out>
#6 0xb73ccebd in _int_realloc (av=av@entry=0xb7501420, oldp=oldp@entry=0x962ab18, oldsize=oldsize@entry=8200,
nb=nb@entry=104) at malloc.c:4462
newp = 0x962ab18
newsize = 8200
newmem = <optimized out>
next = 0x962cb20
remainder = 0x962ab80
remainder_size = 8096
bck = <optimized out>
fwd = <optimized out>
copysize = <optimized out>
ncopies = <optimized out>
s = <optimized out>
d = <optimized out>
errstr = 0x0
---Type <return> to continue, or q <return> to quit---
nextsize = <optimized out>
#7 0xb73ceadf in __GI___libc_realloc (oldmem=0x962ab20, bytes=97) at malloc.c:3065
ar_ptr = 0xb7501420
nb = 104
newp = <optimized out>
hook = <optimized out>
oldp = 0x962ab18
oldsize = 8200
#8 0xb73c1efb in _IO_mem_finish (fp=0x9990a78, dummy=0) at memstream.c:132
mp = 0x9990a78
#9 0xb73b9841 in _IO_new_fclose (fp=fp@entry=0x9990a78) at iofclose.c:66
status = 0
#10 0xb7444104 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=3, flag=flag@entry=-1, fmt=fmt@entry=
0xaf2fe1ec "[13245] %s thread ended (pid=%d, tid=%d)", ap=ap@entry=0xaf2fe308 "ȑb\t\255\063")
at ../misc/syslog.c:228
now_tm = {tm_sec = 17, tm_min = 57, tm_hour = 20, tm_mday = 13, tm_mon = 7, tm_year = 112, tm_wday = 1,
tm_yday = 225, tm_isdst = 1, tm_gmtoff = 7200, tm_zone = 0x94756b0 "CEST"}
now = 1344884237
fd = <optimized out>
f = 0x9990a78
buf = 0x0
bufsize = 0
msgoff = 20
saved_errno = 0
failbuf = "\267", '\000' <repeats 27 times>
clarg = {buf = 0x963ae90, oldaction = 0x0}
#11 0xb7444577 in __vsyslog (pri=3, fmt=0xaf2fe1ec "[13245] %s thread ended (pid=%d, tid=%d)", ap=
0xaf2fe308 "ȑb\t\255\063") at ../misc/syslog.c:326
No locals.
#12 0x08146711 in syslog_with_tid (priority=3, format=0x81743b8 "%s thread ended (pid=%d, tid=%d)") at tools.c:40
ap = 0xaf2fe308 "ȑb\t\255\063"
fmt =
"[13245] %s thread ended (pid=%d, tid=%d)\000)", '\000' <repeats 166 times>, "(\343/\257\000\000\000\000\000\000\000\000GGD\267\364os\267\000\000\000\000\000\000\000\000\370\342/\257&,\024\b(\343/\257x7c\t\000\000\000"
#13 0x08142932 in cThread::StartThread (Thread=0x9630ba8) at thread.c:259
No locals.
#14 0xb7726adf in start_thread (arg=0xaf2feb40) at pthread_create.c:309
__res = <optimized out>
pd = 0xaf2feb40
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1217171468, 0, 4001536, -1355815896, 1653867654, -645410122},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call = 0
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
#15 0xb744854e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
No locals. -
Hallo,
ich lasse meinen VDR die Experimental Treiber normalerweise per udev laden. Dazu habe ich auch keine besonderen Regeln im Einsatz.
Leider funktioniert das seitdem Update auf Fedora 17 nicht mehr. Nach dem was ich nun heraus bekommen habe, liegt es am geänderten
udevd. Die Änderung ist nicht Fedora spezifisch, sondern wird über kurz oder lang alle Distributionen betreffen.Im Bereich der DVB USB Treiber ist diese Änderung offenbar schon bemerkt und die Treiber entsprechend angepasst worden.
Grundsätzlich erwartet der udevd nun, dass die Module Init Phase sehr kurz ist. Wenn nicht, killt der udev worker den Ladevorgang. In der
Regel sehr schnell. Damit wird das Laden der Firmware in dieser Phase nahezu unmöglich. Allenfalls asynchron wäre möglich. Da würde
der Rest der Initialisierungen aber nicht mehr funktionieren. Die Entwickler wollen damit ganz klar Probleme abstellen, die die Bootphase
zum Hängen gebracht haben, wenn ein Modul wegen der FW nicht korrekt geladen werden konnte und werden die Änderung wohl auch
nicht zurück nehmen.Ich arbeite im Moment um dieses Verhalten herum. Das heißt: Treiber blacklisten und per modprobe direkt vor dem VDR laden.
Nun die eigentliche Frage: Ist PowerMan dieser Umstand bekannt und plant er den Treiber entsprechend anzupassen?
Gruss, Thomas
-
Nö... geht nicht. Schaltet man zwischen 2 Sendern hin- und her, wird beim 2ten Mal lediglich die Signalstärke angezeigt.
Gruß
iNOB
Geht mir auch so. Mal kommen die Symbole und mal nicht.
Gruss, Thomas
-
Habe aber noch keine Lösung. An der HW liegt es nicht, denn nach einem Downgrade auf die 1.7.21 geht es.
Die gepatchte 1.7.26 kann alte Aufnahmen abspielen. Nur bei neuen wird Schrott aufgezeichnet. Das kartenunabhängig. Ist nicht auf meine TT S-6400 begrenzt. Es werden zwar Dateien erstellt, aber der dvbplayer
bricht den Abspielvorgang kommentarlos ab.
Eine Plain vdr-1.7.26 Installation hat diese Probleme nicht. Muss also am Patch liegen.
Ich wäre für eine Lösung ebenfalls dankbar.
Gruss, Thomas
-
Ähh, natürlich bin ich überrascht. Immerhin gibts die Karte schon ein paar Tage/Wochen/Monate - hatte wohl einfach den Aktualisierungsspeed Überschätzt...
Jemand muss mal sagen wie es ist.
Es wird für die 6400 wohl keine Media-Player Unterstützung geben. Weder mit mplayer, noch mit der xine-lib.
Das war mit den FF Karten IMHO schon ein Krampf.Das Beste ist, sich parallel eine Nvidia GK zu installieren und dann damit FreeVo oder XBMC zu betreiben. Das Gui ist dort sowieso auf einem Stand
(XBMC), den vdr wohl nie erreichen wird und man kann fast allen Mist abspielen. Obwohl ich auch dort Dateien habe, die sich nicht abspielen lassen, aber
mit mplayer gehen. Wer unbedingt XBMC-Live nutzen will, muss es allerdings selbst wissen. Das ist nicht mein Ding. IMHO wird es nie eine permanent
sauber funktionierende Integration geben.Für die Leute mit einem ATOM Board und nur einem PCIe Slot ist das nichts. Allerdings ist der ATOM für Media-Inhalte eh zu langsam.
