Hi Richard,
thanks for the files. I just gave them a try and using valgrind I could
also see that there's a leak when a search timer update is run.
==4060== 452,152 (6,968 direct, 445,184 indirect) bytes in 134 blocks
are definitely lost in loss record 287 of 287
==4060==at 0x4024F20: ma
On 21.08.2011 10:26, Christian Wieninger wrote:
> But unfortunately valgrind does not give me the information where the leak
> is caused. Maybe the reason for this is that a search timer update runs in
> a separate thread or because plugins are dynamically loaded shared libraries?
> Has anybody an
On Sunday 21 August 2011 02:35:53 you wrote:
> I've finally managed to tune my 290e in as well. I have discovered that I
> need to remove all of the 2-way splitters that I'd been using to connect
> everything up to the wall socket, and then w_scan and scandvb can find the
> HD signal. But my versi
Am 20.08.2011 12:16, schrieb Klaus Schmidinger:
> On 19.08.2011 20:48, Udo Richter wrote:
>> Sure, however QueueMessage does not wait and does not return an user key
>> press.
>
> That's by design ;-)
> A background thread is not supposed to do this!
Osdserver has no other choice. From the main t
> The signal from my aerial goes through an amplifier to another amplifier with
four outputs!
> I could probably do with a new aerial!!
Interesting, it hadn't occurred to me to use an amplifier. Although the HD MUXs
are all broadcasting at low power at the moment until Digital Switch-Over is
f
Catching up with some bug reports/feature requests and supporting VDR 1.7.20.
The changes:
* Made changes in font settings be applied instantly, without the need
to change the channel (patch provided by Rolf Ahrenberg)
* Converted *.po to UTF-8 (Thx to Ville Skyttä!)
* Updated patch for
A plugin version of my TV-Anytime patch is now available at
http://projects.vdr-developer.org/projects/vdrtva
The plugin has (most of) the same features as the patch version, but without
the need to run a cron job to process the series links.
Comments criticisms and suggestions are always welco
On 19.08.2011 23:56, Steffen Barszus wrote:
On Fri, 19 Aug 2011 22:18:03 +0200
Udo Richter wrote:
Am 19.08.2011 15:30, schrieb Steffen Barszus:
On 08/19/11 11:46, Steffen Barszus wrote:
i would like to request, that
vdr is storing the length of a recording and make it accessible
to the plug-
Hi,
@Tobi: many thanks, worked like a charm!
@Richard:
I've found a big leak besides some smaller ones and fixed them in the
git. So please give it a try and let me know if it workes for you now.
Cheers,
Christian
Am 21.08.2011 10:58, schrieb Tobi:
On 21.08.2011 10:26, Christian Wieninger
@Christian:
I've cloned the Git repo and compiled / running your latest epgsearch
with the same config I sent you.
Will monitor for a couple of days and let you know,
Thanks - R
On 21/08/2011 15:50, vdr-requ...@linuxtv.org wrote:
Subject:
Re: [vdr] epgsearch plugin memory leak
From:
Christian
Hi Klaus,
On 19.08.2011 18:43, Klaus Schmidinger wrote:
There have been some reports about recording problems with VDR 1.7.20
on some HD channels.
This patch should fix this.
Klaus
--- remux.c 2011/08/15 09:50:14 2.58
+++ remux.c 2011/08/19 15:33:26
@@ -974,8 +974,10 @@
payloadUnitOfFrame = (
On 21.08.2011 22:20, André Weidemann wrote:
Hi Klaus,
On 19.08.2011 18:43, Klaus Schmidinger wrote:
There have been some reports about recording problems with VDR 1.7.20
on some HD channels.
This patch should fix this.
Klaus
--- remux.c 2011/08/15 09:50:14 2.58
+++ remux.c 2011/08/19 15:33:2
Does anyone know whether the eepg plugin should "just work" with the Huffman
encoded EPG broadcast on Freeview (DVB-T) HD channels in the UK? (Someone
mentioned it on here a week or so back.)
I'm pretty sure the EPG data is encoded in exactly the same way as it is on
Freesat, i.e. DVB-S, and e
On Sun, Aug 21, 2011 at 1:20 PM, André Weidemann wrote:
> Would the log messages look like this without above patch?
>
> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload -
> buffering
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer
> (23312 >
14 matches
Mail list logo
