Well, the streamdev-client reads data from a ringbuffer and when there isn't
anything
to read it tries to sleep for 1us and loops. This wasn't a problem when the
timer
resolution was in the 1000..1us range (1000..100Hz); the usleep(1) call
slept
for one or more milliseconds.
With the high-re
Stone wrote:
> On 4/5/07, *Artur Skawina* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> wrote:
> With the high-res timers in kernel 2.6.21+ usleep(1) is no longer
> treated as
> usleep(1) and the streamdev client is almost unusable; it uses
>
Stone wrote:
>
> sure, just changing it to 'usleep(1)' works too. Is there a
> reason to avoid
> the ringbuffer infrastructure?
>
> No reason in particular, I just wanted to test which one worked best
> with performance. Thanks for the patch. :)
I tried the 1us -> (1000|1)us
Stone wrote:
>
> Is this patch for streamdev a direct result from selecting the new
> "Tickless System (Dynamic Ticks)" option in kernel 2.6.21? If yes, then
CONFIG_HIGH_RES_TIMERS "High Resolution Timer Support". Whether NO_HZ makes
a difference I'm not sure, i ran into this w/ both options on.
Sven Schwyn wrote:
> I'm having strange issues with my VDR box lately. However, I'm not sure
> at all it has anything to do with VDR as other services are running on
> it, too.
>
> The Gentoo box freezed four times in the past month, twice of which the
> very minute a VDR timer stopped. (Maybe eve
A while ago the remote plugins "telnet" server started acting strangely here;
it would
sometimes ignore all cursor and function keys, yet other keys would work
perfectly.
I'm not sure when exactly this began, most likely a newer kernel triggered this.
It does not happen always, but when it does i
vdr uses quite a lot of memory, RSS here used to be ~70M, so i decided to see
if it could be
reduced a bit. First suspects became the ringbuffers, cause i was seeing a lot
of log lines
such as "buffer stats: 96068 (1%) used". Turns out many buffers are way over
sized, only a few
percent of the m
> Patch below changes the interpretation of the 'Size' parm given when creating
> a buffer from a
> fixed length to a max limit. The buffers start out much smaller (currently
> 128k, instead of many
> megabytes) and grow automatically when they become almost full. This way all
> callers benefit,
> void cRecorder::Receive(uchar *Data, int Length)
> {
> if (Running()) {
> int p = ringBuffer->Put(Data, Length);
> if (p != Length && Running())
> ringBuffer->ReportOverflow(Length - p);
> }
> }
>
> it simply drops any data that does not fit into the buffer, which would
Klaus Schmidinger wrote:
> On 05/09/07 20:56, Artur Skawina wrote:
>>> void cRecorder::Receive(uchar *Data, int Length)
>>> it simply drops any data that does not fit into the buffer, which would be
>>> fine
>>> for live viewing, but isn't ideal when
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(), handles the TS buffer
better.
- faster buffer gr
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
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
Klaus Schmidinger wrote:
> If this "auto sized ringbuffers" change (which, from what I can
> see so far - haven't tried it myself - looks like a good idea)
> is ever to make its way into the official VDR source, you'll need
> to get rid of the above waiting. It says in receiver.h:
>
> ...the cal
This is still in a just-for-testing phase. Found a way to better stress test
this code, hence these changes:
- decreased the growth threshold from 1/2 to 1/3. IOW the goal is always for
66% of the buffer to be free; this increases the working set, but the
alternative (handling overflows by s
Jaroslaw Swierczynski wrote:
> It seems your patch is against VDR 1.5.x. Could you please backport it
> to VDR 1.4.x?
actually it's vs 1.4.6, but applies to 1.5.2 too.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/
VDR User wrote:
> I've recorded/watched a lot of tv in the last couple days and so far I
> haven't noticed any problems with this patch. I am currently using v3
> (the patch I attached to my previous post) with vdr-1.5.2.
Do you know how large the buffers usually grow?
If you haven't reduced vdrs
VDR User wrote:
> On 5/20/07, Artur Skawina <[EMAIL PROTECTED]> wrote:
>> VDR User wrote:
>> > I've recorded/watched a lot of tv in the last couple days and so far I
>> > haven't noticed any problems with this patch. I am currently using v3
>> >
Some time ago the softdevice plugin started crashing when playing video streams
containing errors, both while live viewing and watching recordings.
Today I found a transponder where it reliably occurred within seconds and
decided
to investigate. The picture buffers used for video were 8-byte align
Udo Richter wrote:
> Matthias Schwarzott wrote:
>> makefile-destdir.diff:
>> It add variable DESTDIR to makefile to install under $(DESTDIR) instead of /
>
> I would prefer something like DESTDIR=/usr/local that can be redirected
> to /usr or /tmp/newpackage/usr or similar, just as many configure
Oliver Joa wrote:
> Hi,
>
> ich habe mir heute einen zweiten LNB auf die Schuessel gebaut um Hotbird
> empfangen zu koennen. Jetzt weiss ich nur noch nicht wie ich beide LNB
> am geschicktesten mit meinem VDR verbinde (Beide LNB jeweils Quad). Ich
> habe 2 DVB Karten. Die professionelle Variant
Is anyone seeing some kind of problem when playing back files, but only when the
recording has not yet finished? Possibly just when replaying a file that is
currently
being extended, maybe by another VDR and/or over NFS.
[i had a problem like that many months ago, attempted to fix it, but it seem
VDR User wrote:
> On Wed, Mar 26, 2008 at 10:27 AM, Artur Skawina <[EMAIL PROTECTED]> wrote:
>> Is anyone seeing some kind of problem when playing back files, but only when
>> the
>> recording has not yet finished? Possibly just when replaying a file that is
>
alexw wrote:
I _think_ the issue was some kind of stuttering playback; it didn't
happen always, but often enough that one day i decided to see if writing
the stream in much larger chunks would help. It did; never seen it since.
I am using the following VDR setup: 2 VDR machines in
client(FF)/
VDR User wrote:
> On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina <[EMAIL PROTECTED]> wrote:
>> I have a similar setup, just with 100M ethernet instead of wifi and NFS
>> instead
>> of samba. wifi could be a problem, but if you're able to watch the same
>&g
This change makes vdr write the video stream directly to disk, bypassing
OS caches. O_DIRECT is used if it is supported, falling back to "normal"
I/O and fadvise() if not. Only recording is affected, playback remains
unchanged.
I did this to see if using direct i/o made sense for vdr, wasn't conv
alexw wrote:
> On Friday 28 March 2008 14:52:38 alexw wrote:
>> On Thursday 27 March 2008 18:22:35 Artur Skawina wrote:
>>> VDR User wrote:
>>>> On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina <[EMAIL PROTECTED]> wrote:
>>>>> I have a similar
Alexw wrote:
Sometimes the player stops in the middle of a recording due to a zero size
request. Here is the log:
vdr: [3836] dvbplayer thread started (pid=3643, tid=3836)
vdr: [3836] resuming replay at index 1950 (0:01:18.01)
vdr: [3837] non blocking file reader thread started (pid=3643, tid=3
JJussi wrote:
> On Wednesday, 2. Aprilta 2008 05:11:37 VDR User wrote:
>
>> Playback is faster then watching live tv?! Maybe if you skip past the
>> commercials or something! I've started playing back a recording many
>> times before it was finished and never had a problem with lockup or
>> that
Peer Oliver Schmidt wrote:
> Hello Michael,
>
>> Does anybody use RF remote control with VDR instead of IR? How to
>> configure such remotes?
>
> I used the ATI RemoteWonder with it. LIRC has support for it.
Or, if your remote is supported by the kernel input layer, you can use
the remote plugi
Wolfgang Fritz wrote:
> Artur Skawina schrieb:
>> Peer Oliver Schmidt wrote:
>>> Hello Michael,
>>>
>>>> Does anybody use RF remote control with VDR instead of IR? How to
>>>> configure such remotes?
>>> I used the ATI RemoteWonde
Wolfgang Fritz wrote:
> Artur Skawina schrieb:
>> sure, patch vs 2.6.25 below. These are just the minimal changes needed to
>> make
>> ati-remote work w/ one type of medion rf remotes (P/N 20018071). i did this
>
> Mine is P/N 20014751
afaict it looks exactly like
Gavin Hamill wrote:
> Over the last days, Thomas and I have been trying to sort out why my
> nearly-identical machine couldn't run his VGA sync patches properly.
>
> The key difference is my Radeon 7000VE is PCI, whilst his is AGP. I
> tried the PCI Radeon in two old Pentium-3 era machines, and
Richard F wrote:
> Teemu,
>
> I had a similar problem with budget Freecom / WT-220U USB stick tuners.
> I usually had to swap multiplex/transponder to get them to re-tune reliably.
> I observed that if they lost tuning, vdr made them re-try (which I saw in the
> log)
> but eventually would bomb o
Udo Richter wrote:
> Second: Priority and Lifetime of a recording IMHO don't belong to the
> name part. This could easily fit into the info.vdr file instead. Or does
> it make sense to have the same recording with different lifetime or
> priority in separate folders?
No and it actually causes p
Klaus Schmidinger wrote:
> Detecting the frame rate is done by looking at the PTS values, so
> it is independent of the actual broadcast system.
>
> Using this code for converting frame numbers into hh:mm:ss.ff...
>
>
> #include
> #include
Klaus Schmidinger wrote:
> On 05.01.2009 13:31, Artur Skawina wrote:
>> Klaus Schmidinger wrote:
>>> Detecting the frame rate is done by looking at the PTS values, so
>>> it is independent of the actual broadcast system.
>>>
>>> Using this code
Udo Richter wrote:
> On 21.01.2009 19:33, Gerald Dachs wrote:
>> Assumed I have 2 free Tuners and I zapp through the channels of one
>> tuner. Would it be possible to tune the 2. tuner to the same time to
>> the after next channel in change direction, so that for the next
>> channel change in the s
Patrick Rother wrote:
> For a reason not to go in details too much here, I would like to make
> vdr recognise sparse DVB adapter numbers.
>
> I have:
>
> r...@vdr:/dev/dvb# ls -l
> total 0
> drwxr-xr-x 2 root root 200 Mar 19 11:59 adapter0/
> drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter1/
> dr
Klaus Schmidinger wrote:
> On 21.03.2009 14:17, Artur Skawina wrote:
>> Patrick Rother wrote:
>>> For a reason not to go in details too much here, I would like to make
>>> vdr recognise sparse DVB adapter numbers.
>>> drwxr-xr-x 2 root root 200 Mar 19 11:59
Marcel Witte wrote:
> So ext4 seems to be perfect for a video-partition, but to make it more
> perfect, it would be nice if VDR could use the fallocate()-systemcall as
> mentioned in the article. This would prevent fragmentation in the file system.
a) i wouldn't fully trust ext4 for a few more
Carsten Koch wrote:
> I have a distributed VDR system in my house with a lot of disks
> that are NFS mounted by VDR PCs in two rooms.
> In order to conserve energy, I have used hdparm to set a spin down
> delay after which the disks turn themselves off.
> When /video/.update is touched (one of the
Kartsa wrote:
> I was about to test the performance of vdr when I stumbled on this message
>
> ERROR: /dev/dvb/adapter0/demux0: Too many open files
>
> I do not recall seeing this earlier. This came when fourth simultaneous
> recording started.
>
> Is this a vdr, dvb, or firmware issue? Seems li
Kartsa wrote:
>>> ERROR: /dev/dvb/adapter0/demux0: Too many open files
>>>
>>> I do not recall seeing this earlier. This came when fourth simultaneous
>>> recording started.
>> dvb/dvb-core/dmxdev.c- if (i == dmxdev->filternum) {
>> dvb/dvb-core/dmxdev.c- mutex_unlock(&dmxdev->mutex);
>>
44 matches
Mail list logo
