[vdr] timeline tvonscreen plugins
Anyone know if development on these for vdr-1.5.x is underway? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Announce LoadEPG 0.1.11
En/na Luca Olivetti ha escrit:
If I change the function cLoadepgOsd::SwitchToEpgChannel (and only that
function) to use cDevice::PrimaryDevice() to do the switching then
everything works as expected (well, special characters show up as little
squares in accents in the epg, but I'll look into that).
I made a crude hack: I assume that the epg is in ISO-8859-15, so if
SystemCharacterTable is different than iso-8859-15, I call iconv to
convert the file in cLoadepgOsd::SaveEpg, just before the LoadFile label:
fclose( File );
const char *syschar=cCharSetConv::SystemCharacterTable();
if (syschar==NULL || !strcasestr(syschar, ISO-8859-15)) {
char *cmd;
asprintf(cmd, iconv -f ISO-8859-15 -t %s -o
\%s.converted\ \%s\, syschar ? syschar : UTF-8,FileName,FileName);
SystemExec(cmd);
free(cmd);
asprintf(cmd, mv \%s.converted\ \%s\,
FileName,FileName);
SystemExec(cmd);
free(cmd);
}
}
LoadFile:;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Problems with cCutter::Active()
Hi, I call in my plugin in a loop (in a thread) cCutter::Active() every second. If I stop an editing process over the main menu entry, VDR crashes from time to time: - *** glibc detected *** vdr: double free or corruption (!prev): 0x08407fc0 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb7cff7cd] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7d02e30] vdr(_ZN14cCuttingThreadD0Ev+0x31)[0x809b7a1] vdr(_ZN7cCutter4StopEv+0x39)[0x809aa89] vdr(_ZN7cCutter6ActiveEv+0x3c)[0x809ab7c] /home/nordlicht/src/vdr-1.4.7/PLUGINS/lib/libvdr-extrecmenu.so.1.4.5(_ZN12WorkerThread6ActionEv+0x2e)[0xb73dadbe] vdr(_ZN7cThread11StartThreadEPS_+0x2c)[0x80fce1c] /lib/tls/i686/cmov/libpthread.so.0[0xb7f0431b] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7d6757e] - If I remove the cCutter::Active()-call from my thread, everything is fine. Has anyone an idea what goes wrong there? Greets, Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.6 crashing (workaround)
On 07/24/07 13:09, Malte Schröder wrote:
On Mon, 23 Jul 2007 16:20:23 +0200
Malte Schröder [EMAIL PROTECTED] wrote:
Hello,
when I switch for example to sunshine live 1.5.6 crashes. Plugins loaded
are remote, skinenigmang and epgsearch.
This prevents vdr from crashing. But I don't understand how channel
can be a null-pointer in that code-path. It is only set at the start of
the method and then checked if it is a null-pointer. Okay, it is
being re-set a few lines before, but that is in the true part of the
condition.
--- vdr-1.5.6/eit.c 2007-07-21 16:58:04.0 +0200
+++ vdr-1.5.6.prod/eit.c2007-07-24 12:06:46.0 +0200
@@ -209,7 +209,7 @@
LinkChannels-Add(new cLinkChannel(link));
}
}
- else
+ else if(channel)
channel-SetPortalName(linkName);
}
}
@@ -256,7 +256,7 @@
if (!HasExternalData)
pEvent-FixEpgBugs();
- if (LinkChannels)
+ if (LinkChannels channel)
channel-SetLinkChannels(LinkChannels);
Modified = true;
}
I believe the actual problem was introduced by myself.
I wanted to simplify the original patch to have only a single
call to Channels.NewChannel(), and in doing so wrote
channel = ... instead of transponder = ...
Please try the attached patch.
Klaus
--- eit.c 2007/07/21 14:58:04 1.124
+++ eit.c 2007/07/28 13:16:43
@@ -199,7 +199,7 @@
else if (Setup.UpdateChannels = 4) {
cChannel *transponder = channel;
if (channel-Tid() != ld-getTransportStreamId())
-channel = Channels.GetByTransponderID(linkID);
+transponder = Channels.GetByTransponderID(linkID);
link = Channels.NewChannel(transponder, linkName, , , ld-getOriginalNetworkId(), ld-getTransportStreamId(), ld-getServiceId());
//XXX patFilter-Trigger();
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.6
On 07/23/07 07:23, Hermann Gausterer wrote: On Sun, Jul 22, 2007 at 10:38:21PM +0200, Klaus Schmidinger wrote: Marco Schlüßler sent me the fix - see attachment. It was a side effect of the changes in skipspace()... this patch seems to work only partialy: - lstc wdr 250-17 WDR Köln;ARD:11836:hC34:S19.2E:27500:601:602=deu:604:0:28111:1:1101:0 250-901 WDR M�nster;ARD:12421:hC34:S19.2E:27500:101:102=deu:104:0:28310:1:1201:0 CUT 250-1425 WDR D�sseldorf;ARD:12421:hC34:S19.2E:27500:101:102=deu:104:0:28308:1:1201:0 - looks like only The Ü (ONLY UPPERCASE) does not work for me :-o newt 1:20:23:0:5:0:0:AAAÖÖÖÜÜÜ€€€€ 250 14 1:20:2007-07-23::0005:0:0:AAAÖÖÖ���€€€€: vdr: [17770] timer 14 (20 -0005 'AAAÖÖÖ�\377�\377�^F�\377�\377�^F�\377�\377�^F€€€€') added vdr: [17770] deleting timer 14 (20 -0005 'AAAÖÖÖ�\377�\377�^F�\377�\377�^F�\377�\377�^F€€€€') newt 1:20:23:715:720:0:0:Bühnendübel 250 14 1:20:2007-07-23:0715:0720:0:0:Bühnendübel: here it get strange: after putting a Ü in the Line, the timer gets added but the normal output of the complete timerline is not always echoed back: i have to press enter for getting a prompt; only every second input of lstt works; newt 1:20:23:800:805:0:0:BÜHNENDÜBEL lstt 15 500 Command unrecognized: lstt lstt 15 250 15 1:20:2007-07-23:0800:0805:0:0:B�HNEND�BEL: Well, the fix in skipspace() did fix the problems as far as I could see them. Any further UTF-8 problems will probably need to be debugged by somebody actually using UTF-8. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems with cCutter::Active()
Martin Prochnow wrote: I call in my plugin in a loop (in a thread) cCutter::Active() every second. If I stop an editing process over the main menu entry, VDR crashes from time to time: cCutter::Active is more than a simple query function. It also does the cleanup of the thread, the error handling and the external script calls. Because of that, the function is not thread safe, and can only be called from the main thread. The double free is probably because both threads try to free cCutter::editedVersionName at the same time. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems with cCutter::Active()
Udo Richter schrieb: Martin Prochnow wrote: I call in my plugin in a loop (in a thread) cCutter::Active() every second. If I stop an editing process over the main menu entry, VDR crashes from time to time: cCutter::Active is more than a simple query function. It also does the cleanup of the thread, the error handling and the external script calls. Because of that, the function is not thread safe, and can only be called from the main thread. The double free is probably because both threads try to free cCutter::editedVersionName at the same time. Is there another way to check for a running editing process from a plugin? Or some kind of workaround? Greets Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timeline tvonscreen plugins
Anyone know if development on these for vdr-1.5.x is underway? For compile Probs on timeline-1.0.141 for VDR up from 1.5.0 should atached diff help. Beside a note on all plugin devs. I which the handling of fonts will be changed in next plugin versions. Stop the stupid handling to copy or link fonts in plugin config dirs. For this you can simple use the font-cache used by fontconfig. KLS shows a simple way in (=vdr-1.5.3) font.c #include fontconfig/fontconfig.h how is this to handle. Use for font handling the system own mechanisms and installed fonts. fontconfig should be included by all Distributions. All other ways pass miles far on a clean/clear configured system. -- Regards Gentoo Developer Joerg Bornkessel [EMAIL PROTECTED] vdr-timeline-1.0.141_vdr-1.5.x.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timeline tvonscreen plugins
On 07/28/07 18:57, Joerg Bornkessel wrote: ... Use for font handling the system own mechanisms and installed fonts. fontconfig should be included by all Distributions. Plugins don't even need to directly access any fontconfig stuff. They can use cFont::GetAvailableFontNames() to get all of the available font names, and create their own fonts with cFont::CreateFont(). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timeline tvonscreen plugins
On 07/28/07 18:57, Joerg Bornkessel wrote: ... Use for font handling the system own mechanisms and installed fonts. fontconfig should be included by all Distributions. Plugins don't even need to directly access any fontconfig stuff. They can use cFont::GetAvailableFontNames() to get all of the available font names, and create their own fonts with cFont::CreateFont(). yeah ok, but this make it depend on =vdr-1.5.3 imho, should included code parts eg. (cFont::GetAvailableFontNames()) in plugins directly then not work on older vdr versions too ? Anyway, my thoughts on it are, this font handling should be generally fixed/changed in plugins, not only in depend from vdr-1.5.3 Klaus, maybe you can backport this functions on vdr-1.4.* That makes it plugin devs more easily, they still for the vdr-1.5.x refuses itself ;) -- Regards Gentoo Developer Joerg Bornkessel [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timeline tvonscreen plugins
On 07/28/07 22:14, Joerg Bornkessel wrote: On 07/28/07 18:57, Joerg Bornkessel wrote: ... Use for font handling the system own mechanisms and installed fonts. fontconfig should be included by all Distributions. Plugins don't even need to directly access any fontconfig stuff. They can use cFont::GetAvailableFontNames() to get all of the available font names, and create their own fonts with cFont::CreateFont(). yeah ok, but this make it depend on =vdr-1.5.3 imho, should included code parts eg. (cFont::GetAvailableFontNames()) in plugins directly then not work on older vdr versions too ? Anyway, my thoughts on it are, this font handling should be generally fixed/changed in plugins, not only in depend from vdr-1.5.3 Klaus, maybe you can backport this functions on vdr-1.4.* That makes it plugin devs more easily, they still for the vdr-1.5.x refuses itself ;) As a plugin author I would keep a stable version that runs with VDR 1.4.x and a developer version that runs with VDR 1.5.x. Trying to have a single version that runs with all versions of VDR is bound to fail if the differences become too big. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
