Re: [vdr] [PATCH] dynamically sized ringbuffers v2

On 5/10/07, Artur Skawina <[EMAIL PROTECTED]> wrote: Auto sized ringbuffers, changes since v1: - increased maximum sizes for a few rb users. Most of the time just a small part will be used, but there will be more room for times when more is required. - a little smarter cRingBufferLinear::Read()

Re: [vdr] [PATCH] dynamically sized ringbuffers v2

Stone writes: > > > > It still wouldn't surprise me if this version caused a few overflows, > > but hopefully these will be very rare. > > I'm curious how streamdev will function with these buffer changes. And since I am not convinced that this memory footprint issue is significant, I am co

Re: [vdr] [PATCH] dynamically sized ringbuffers v2

And since I am not convinced that this memory footprint issue is significant, at a first glance, IMHO dynamic buffers are a good thing. we can get rid of small upper buffer size bounderies all together without wasting amounts of memory. this should result in even less buffer overflows when imple

Re: [vdr] [PATCH] dynamically sized ringbuffers v2

Stone wrote: > > It still wouldn't surprise me if this version caused a few overflows, > but hopefully these will be very rare. > > I'm curious how streamdev will function with these buffer changes. it works fine -- i'm using a headless vdr server and streamdev+softdevice clients, so t

Re: [vdr] [PATCH] dynamically sized ringbuffers v2

Jouni Karvo wrote: > Stone writes: > > > > > > It still wouldn't surprise me if this version caused a few overflows, > > > but hopefully these will be very rare. > > > > I'm curious how streamdev will function with these buffer changes. > > And since I am not convinced that this memory footp

[vdr] [ANNOUNCE] VDR sync early patch

Great patch, thank you very much! Now the dxr3 runs very smoothly and I don't need to be frightened while switching channels. I strongly suggest this patch for everyone with a dxr3-card! Keep up the good work! - jcw ___ vdr mailing list vdr@linuxtv

Re: [vdr] [ANNOUNCE] VDR sync early patch

Hi, which version of VDR, vdr-dxr3 and em8300 are you using? I've tried and ended up with this: em8300_video.o: Video sync rdptr is stuck at 0x0001b8fc, wrptr 0x0001b9f6, left 250 em8300_video.o: Video sync timeout -- Jaroslaw Swierczynski <[EMAIL PROTECTED]> www.archlinux.org | www.juvepoland.

Re: [vdr] [ANNOUNCE] VDR sync early patch

Jaroslaw Swierczynski schrieb: which version of VDR, vdr-dxr3 and em8300 are you using? I've tried and ended up with this: em8300_video.o: Video sync rdptr is stuck at 0x0001b8fc, wrptr 0x0001b9f6, left 250 em8300_video.o: Video sync timeout I have those messages as well - although not very oft

Re: [vdr] Re: BROKEN MAILS [was] 4:3 stretched to 16:9?

"Simon Baxter" <[EMAIL PROTECTED]> wrote: > > Martin <[EMAIL PROTECTED]> wrote: > > > > > Hey Simon,my answer sounds maybe stupid, but I always have all > > > output to 720x576. > > > > [..] > > > > please, for the love of god, fix your mua. > > Sorry - what's wrong with my mua? this was of c

[vdr] mplayer with dvd-menu support

Hello are there any plans to include in the mplayer-plugin a possibility for dvd play with dvd-menu support ? regards Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] A few observations on the vdr project

[EMAIL PROTECTED] wrote: As you yourself said in the above/below statement, time is a limited resource for this project and you can't spend all day developing vdr (and you have a life besides vdr =). The way I see it, is a clear roadmap could make the development more effective and avoid waste o

[vdr] softdevice crash

Hi there, My config: - Asus M2NPV-VM (Geforce6150), Hauppauge nexus-s. - suse 10.0, kde, vdr-1.4.4. I recently purchased a 32" LCD-TV, and I would like to set up vdr-softdevice, to connect vdrbox via D-SUB or DVI to the TV set. I compiled ffmpeg-0.4.9-cvs and vdr-softdevice-0.4.0 without any

Re: [vdr] A few observations on the vdr project

On 05/10/07 20:04, Udo Richter wrote: > ... > VDR development would speed up, if Klaus would delegate more work to > other talented coders, and doing more review instead of coding most of > it himself. Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all.