On 18.03.2013 15:43, Dominic Evans wrote:
> I noticed that
> http://anonscm.debian.org/gitweb/?p=pkg-vdr-dvb/vdr-plugin-markad.git
> is actively maintained, but no deb has been uploaded to debian
> archive. Do you plan to upload one whenever vdr 1.7.41 / vdr 2.0.0
> gets uploaded to unstable/expe
Hi,
I've submitted an issue against the XVDR plugin, but seems it's VDR
but not XVDR issue.
Can someone, please, look at this
https://github.com/pipelka/vdr-plugin-xvdr/issues/103?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mail
Running vdr 1.7.41
I have previously seen this issue on earlier development snapshots,
but had simply ignored it as I was running development code. However,
as we near 2.0, I thought I might query it on the mailing list.
In my syslog I occasionally see an error related to my DVB-S frontend
attemp
On 8 May 2012 19:29, Tobi wrote:
> On 08.05.2012 18:34, Marx wrote
>> I didn't know and that's why his repository isn't updated. In fact I use
>> lately Debian's version (and I was quite suprised that so new version is
>> available in Debian). Hovewer number of available plugins in Debian is
>> pr
I would like to make after recording hook which create symlink for
1.ts file. Name of this symlink should be made of title (T in info
file). I will take care of duplicates etc, but now I would like to know
if it's possible to easily read title.
For now I have a script which simply parse info
The formatting of the sample channels.conf entry for RTL Television
gets badly paragraph wrapped in vdr.5.
Simple fix to prevent line wrapping happening is to put it into a
table. Patch attached. This also fixes a lintian warning about this
line in debian build logs.
vdr.5.patch
Description: Bin
In article <5146cc8e.4070...@tvdr.de> you write:
>On 18.03.2013 08:41, Gerhard Brauer wrote:
>> On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
>>> Ok I looked at cutter.c again and now I think I found the cause:
>>> Linux must default to bigger thread stacks than FreeBSD, FreeBS
On 18.03.2013 10:10, Gerhard Brauer wrote:
On Mon, Mar 18, 2013 at 09:13:02AM +0100, Klaus Schmidinger wrote:
On 18.03.2013 08:41, Gerhard Brauer wrote:
The cutting process now works without segfaulting or unbehavior exit
of the vdr process itself - but during cutting i got A LOT of "frame
lar
On Mon, Mar 18, 2013 at 09:13:02AM +0100, Klaus Schmidinger wrote:
> On 18.03.2013 08:41, Gerhard Brauer wrote:
> >
> > The cutting process now works without segfaulting or unbehavior exit
> > of the vdr process itself - but during cutting i got A LOT of "frame
> > larger than buffer" x greater the
On 18.03.2013 08:41, Gerhard Brauer wrote:
On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
Ok I looked at cutter.c again and now I think I found the cause:
Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
default seems to be 2 MB on amd64 and MAXFRAMESIZE is alm
On Mon, Mar 18, 2013 at 08:41:00AM +0100, Gerhard Brauer wrote:
>
> The cutted recording itself seems to be corrupted. When trying to
> play it i got "incomplete PES packet":
> ---
> Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended
> (pid=33513, tid=54684672)
> Mar 18
On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
> >
> Ok I looked at cutter.c again and now I think I found the cause:
> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
> Try the patch below, you
12 matches
Mail list logo
