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
In article <514637fa.5080...@tvdr.de> you write:
>On 17.03.2013 21:52, 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
On 17.03.2013 21:52, 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 can put it in files/patch-
In article <20130316082610.gj23...@t60.brauer.lan> you write:
>On Fri, Mar 15, 2013 at 10:54:04AM +0100, Gerhard Brauer wrote:
>>
>> I never have any problem during other actions with the remote VDR
>> (recording, viewing, place cutting marks,...) _exept_ when i start
>> the cutting procedere itse
On Fri, Mar 15, 2013 at 10:54:04AM +0100, Gerhard Brauer wrote:
>
> I never have any problem during other actions with the remote VDR
> (recording, viewing, place cutting marks,...) _exept_ when i start
> the cutting procedere itself with the keyboard shortcut "2".
> Most times (> 95%) the remote
Hello,
i'm new on this list and my English is not the best...
I'm using VDR 1.7 headless on a FreeBSD machine. Interaction with
this vdr server is done via vdr-sfxe from the xineliboutput plugin.
I never have any problem during other actions with the remote VDR
(recording, viewing, place cutting
11 matches
Mail list logo
