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 VDR
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 like dvb
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
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
most of the cpu
and causes hundreds
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 sleep
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 it
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
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,
and
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 be
fine
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
this
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 footprint issue is
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 call must
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
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
(the patch I attached to my previous post) with vdr-1.5.2.
Do
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
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 Variante
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
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
currently
being extended, maybe by another
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
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
channel
live you should also be able to view
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
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 setup, just with 100M ethernet instead of wifi and
NFS instead of samba
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 the
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 plugin. eg
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 RemoteWonder with it. LIRC has support for it.
Or, if your remote is supported by the kernel
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 the one i'm using.
The keymap
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 on
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 out if
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 math.h
#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 for converting frame numbers into hh:mm:ss.ff
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 same
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 adapter0/
drwxr-xr-x 2 root root 120 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
35 matches
Mail list logo
