[vdr] [patch] softdevice+mplayer-plugin
Hi This patch allows correct work of mplayer-plugin with softdevice from cvs. Otherwise softdevice lock output resources, and mplayer can't play (for example no audio for me). softdevice.diff.bz2 Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
If I pause live video then restart it starts in slo-mo i.e. judders, and then eventually freezes, but may then start again, still juddering and freezing ... Well, then I have no idea why it wouldn't work with an NTFS partition, while it does work with others. Klaus Hi Klaus, I have similar problems using a NFS share under some circumstances: The general problem is that the index file stops growing after a few seconds, while the 1.ts file growing normally. 1. Using a local HDD with ReiserFS for recording, everything works well. 2. Using NFS V3 with the mount options tcp,hard,sync the index file stops growing. 3. Using NFS V3 with the mount options tcp,soft,async the index file keeps growing. I was happy figured that out, but there seems to be another problem. While having heavy network load this problem occurs again. An example: Cutting a movie on my NFS share, while recording a new movie to the same NFS share causes in the same problem, the index file stops growing. And... it does not start growing again, after the cutting has finished. This means that I have to stop/start the recording to get a correct index file again. Could it be possible, that the process which is writing the index dies in some kind? I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? -Günter Hi, I have checked the recording directory and sure enough, the index file stops growing after a short while (seconds). I have tried mounting the NTFS partition with the async option but to no avail, i.e. problem is still there. BTW: How do I respond to an already open thread? All I seem to be able to do is start a new one. Mark. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] softdevice+mplayer-plugin
On Sunday 22 March 2009, ua0lnj wrote: Hi This patch allows correct work of mplayer-plugin with softdevice from cvs. Otherwise softdevice lock output resources, and mplayer can't play (for example no audio for me). Thanks, if thats so simple... some action on: pmExtern_THIS_SHOULD_BE_AVOIDED. I'll apply this patch to cvs. If you like another name than ua0lnj being mentioned in README, please send me your real name. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 22.03.2009 01:42, Niedermeier Günter wrote: If I pause live video then restart it starts in slo-mo i.e. judders, and then eventually freezes, but may then start again, still juddering …. and freezing … Well, then I have no idea why it wouldn't work with an NTFS partition, while it does work with others. Klaus Hi Klaus, I have similar problems using a NFS share under some circumstances: The general problem is that the index file stops growing after a few seconds, while the 1.ts file growing normaly. 1. Using a local HDD with ReiserFS for recording, everything works well. 2. Using NFS V3 with the mount options tcp,hard,sync the index file stops growing. 3. Using NFS V3 with the mount options tcp,soft,async the index file keeps growing. I was happy figured that out, but there seems to be another problem. While having heavy network load this problem occurs again. An example: Cutting a movie on my NFS share, while recording a new movie to the same NFS share causes in the same problem, the index file stops growing. And... it does not start growing again, after the cutting has finished. This means that I have to stop/start the recording to get a correct index file again. Could it be possible, that the process which is writing the index dies in some kind? The thread that writes the index file is the same one that writes the actual recording. I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. Strange - the code for actually writing the index file hasn't changed between PES and TS recording. But maybe you can take a closer look at the changes to cIndexFile between version 1.7.2 and 1.7.3. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? I believe you mean 'genindex'. Maybe I should make VDR automatically generate an index file when replaying a TS recording without one... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Hawes, Mark schrieb: /If I pause live video then restart it starts in slo-mo i.e. judders, and/ / then eventually freezes, but may then start again, still juddering …./ / and freezing …/ / / / Well, then I have no idea why it wouldn't work with an NTFS partition,/ / while it does work with others./ / / / Klaus/ Hi Klaus, I have similar problems using a NFS share under some circumstances: The general problem is that the index file stops growing after a few seconds, while the 1.ts file growing normally. 1. Using a local HDD with ReiserFS for recording, everything works well. 2. Using NFS V3 with the mount options tcp,hard,sync the index file stops growing. 3. Using NFS V3 with the mount options tcp,soft,async the index file keeps growing. I was happy figured that out, but there seems to be another problem. While having heavy network load this problem occurs again. An example: Cutting a movie on my NFS share, while recording a new movie to the same NFS share causes in the same problem, the index file stops growing. And... it does not start growing again, after the cutting has finished. This means that I have to stop/start the recording to get a correct index file again. Could it be possible, that the process which is writing the index dies in some kind? I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? -Günter Hi, I have checked the recording directory and sure enough, the index file stops growing after a short while (seconds). I have tried mounting the NTFS partition with the async option but to no avail, i.e. problem is still there. BTW: How do I respond to an already open thread? All I seem to be able to do is start a new one. Mark. Hi, o.k. that is exactly the same problem I have. But here is a missunderstandig: I'm using a network share from my NAS mounted with NFS filesystem NOT NTFS. NTFS is a local filesystem on one of your local HDD's. Using NTFS you don't have a mount option like soft or async. Perhaps it depends on some kind of speed. NTFS is userspaced not kernel. I don't know. I'm using a normal email client like thunderbird, choose the mail I want to answer to, and everything is ok. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 22.03.2009 09:15, Hawes, Mark wrote: ... I have checked the recording directory and sure enough, the index file stops growing after a short while (seconds). I have tried mounting the NTFS partition with the async option but to no avail, i.e. problem is still there. Please try adding some debug output to the cIndexFile functions to see whether any new index entries are generated at all. BTW: How do I respond to an already open thread? All I seem to be able to do is start a new one. Well, I didn't mean to mention this, but since you're asking: for starters it might be a good idea to stop posting in HTML and to set line wrapping to a reasonable value ;-) To reply to a posting, hit the Reply button in your email client. Make sure the reply goes to the list, and not to the original poster. Maybe you need to hit Reply to all and remove the original poster's address from the list of receipients. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. Strange - the code for actually writing the index file hasn't changed between PES and TS recording. But maybe you can take a closer look at the changes to cIndexFile between version 1.7.2 and 1.7.3. The last VDR I used was 1.4.7 This is my first step with the new devel version 1.7.x I can't say when the problem occured first, but I try to figure it out, including older versions. Unfortunately I'm not experienced in C/C++, but I will give it a try. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? I believe you mean 'genindex'. Yes, of course, I meant genindex - it was early in the morning. Maybe I should make VDR automatically generate an index file when replaying a TS recording without one... This sounds good, very good! And it would solve our problem here in some kind. I will come back here as far as I have news about. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: I believe you mean 'genindex'. Maybe I should make VDR automatically generate an index file when replaying a TS recording without one... good idea stefan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Strange - the code for actually writing the index file hasn't changed between PES and TS recording. But maybe you can take a closer look at the changes to cIndexFile between version 1.7.2 and 1.7.3. Possibly you may want to have a look to my logfile, while the error occurs: snip Mar 22 12:25:06 vdr-142 vdr: [23234] record /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] recording to '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:06 vdr-142 vdr: [2257] recording thread started (pid=23234, tid=2257) Mar 22 12:25:06 vdr-142 vdr: [2258] receiver on device 2 thread started (pid=23234, tid=2258) Mar 22 12:25:06 vdr-142 vdr: [2259] TS buffer on device 2 thread started (pid=23234, tid=2259) Mar 22 12:25:08 vdr-142 vdr: [23234] replay /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:08 vdr-142 vdr: [23234] playing '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:09 vdr-142 vdr: [2260] dvbplayer thread started (pid=23234, tid=2260) Mar 22 12:25:09 vdr-142 vdr: [2261] non blocking file reader thread started (pid=23234, tid=2261) Mar 22 12:25:11 vdr-142 vdr: [23234] timer 1 (2 1225-1525 '@Wintersport') set to event Son 22.03.2009 13:05-15:00 (VPS: 22.03 10:15) 'Wintersport' Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 60% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:15 vdr-142 vdr: [2258] buffer usage: 80% (tid=2257) Mar 22 12:25:16 vdr-142 vdr: [2258] buffer usage: 90% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] buffer usage: 100% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] ERROR: 1 ring buffer overflow (65 bytes dropped) Mar 22 12:25:23 vdr-142 vdr: [2258] ERROR: 19932 ring buffer overflows (3747216 bytes dropped) Mar 22 12:25:29 vdr-142 vdr: [2258] ERROR: 21852 ring buffer overflows (4108176 bytes dropped) Mar 22 12:25:35 vdr-142 vdr: [2258] ERROR: 19089 ring buffer overflows (3588732 bytes dropped) snap BTW: I just tried to replay this recording using vlc, and the TS file is also corrupted. Not only the index file stops, the ts file is also defect. Important: My NFS share has enough bandwidth to record three or more streams at the same time. No problem at all with older vdr's using the same share. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 22.03.2009 12:39, Niedermeier Günter wrote: Strange - the code for actually writing the index file hasn't changed between PES and TS recording. But maybe you can take a closer look at the changes to cIndexFile between version 1.7.2 and 1.7.3. Possibly you may want to have a look to my logfile, while the error occurs: snip Mar 22 12:25:06 vdr-142 vdr: [23234] record /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] recording to '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:06 vdr-142 vdr: [2257] recording thread started (pid=23234, tid=2257) Mar 22 12:25:06 vdr-142 vdr: [2258] receiver on device 2 thread started (pid=23234, tid=2258) Mar 22 12:25:06 vdr-142 vdr: [2259] TS buffer on device 2 thread started (pid=23234, tid=2259) Mar 22 12:25:08 vdr-142 vdr: [23234] replay /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:08 vdr-142 vdr: [23234] playing '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:09 vdr-142 vdr: [2260] dvbplayer thread started (pid=23234, tid=2260) Mar 22 12:25:09 vdr-142 vdr: [2261] non blocking file reader thread started (pid=23234, tid=2261) Mar 22 12:25:11 vdr-142 vdr: [23234] timer 1 (2 1225-1525 '@Wintersport') set to event Son 22.03.2009 13:05-15:00 (VPS: 22.03 10:15) 'Wintersport' Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 60% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:15 vdr-142 vdr: [2258] buffer usage: 80% (tid=2257) Mar 22 12:25:16 vdr-142 vdr: [2258] buffer usage: 90% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] buffer usage: 100% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] ERROR: 1 ring buffer overflow (65 bytes dropped) Mar 22 12:25:23 vdr-142 vdr: [2258] ERROR: 19932 ring buffer overflows (3747216 bytes dropped) Mar 22 12:25:29 vdr-142 vdr: [2258] ERROR: 21852 ring buffer overflows (4108176 bytes dropped) Mar 22 12:25:35 vdr-142 vdr: [2258] ERROR: 19089 ring buffer overflows (3588732 bytes dropped) snap BTW: I just tried to replay this recording using vlc, and the TS file is also corrupted. Not only the index file stops, the ts file is also defect. Well, if there are buffer overflows and the TS data is corrupted, it's no wonder the index file stops growing. Does this happen on all channels, or only on some (or even only on a particular one)? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sparse DVB adapter numbers
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.
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/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter5/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter6/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter7/
r...@vdr:/dev/dvb#
But vdr uses only the first two devices.
Is there any easy possibility to patch the code accordingly?
./vdr -D 0 -D 1 -D 5 -D 6 -D 7
I'm afraid this won't work, because VDR stops scaning for DVB devices
as soon as it hits a gap.
You might want to try changing this function:
bool cDvbDevice::Initialize(void)
{
int found = 0;
int i;
for (i = 0; i MAXDVBDEVICES; i++) {
if (UseDevice(NextCardIndex())) {
if (Probe(*cDvbName(DEV_DVB_FRONTEND, i))) {
new cDvbDevice(i);
found++;
}
else
NextCardIndex(1); // skips this one === changed line
}
else
NextCardIndex(1); // skips this one
}
NextCardIndex(MAXDVBDEVICES - i); // skips the rest
if (found 0)
isyslog(found %d video device%s, found, found 1 ? s : );
else
isyslog(no DVB device found);
return found 0;
}
Untested, don't know if it will actually work as expected.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Well, if there are buffer overflows and the TS data is corrupted, it's no wonder the index file stops growing. Does this happen on all channels, or only on some (or even only on a particular one)? Well, I've tried it on several channels ARD,ZDF,arte,Das Vierte,MünchenTV and so on. Channels with high (6-8MBits/s) and normal (3-4MBits/s) bandwidth. Every channel has the same problem. Using hard,sync,intr on NFS shares causes in a reduction of permanent write-throughput to roundabout 4,5 to 5,0 Mega Bytes/s. That should be enough to record two streams at the same time. Using soft,async,nointr on NFS shares causes in a higher permanent write-throughput to roundabout 9,5 to 10,0 Mega Bytes/s. With this setting, I can make two records at the same time, but a third one (record or playback or cutting) does not work well. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Well, if there are buffer overflows and the TS data is corrupted, it's no wonder the index file stops growing. Does this happen on all channels, or only on some (or even only on a particular one)? Additional infos: I recompiled older versions beginning at 1.7.3 and made some tests. 1.7.3 acts exactly like 1.7.4 one record - bufferoverflow The native networkthroughput is between 2,8-3,7 Mega Bytes /s for one stream. - Much to high I think! 1.7.2 seems to be o.k. one record - no problem - throughput is between 0,8-1,2 MB/s two records - no problem - throughput is between 1,8-2,6 MB/s three records - no problem - throughput is between 2,8-4,0 MB/s four records - PES pkt shortened - throughput is between 3,8-5,4 MB/s All tested while using the slower NFS share. Why does one TS stream require a three times higher bandwidth in 1.7.3/1.7.4 than a PES stream in 1.7.2 do? I think we're getting closer to the problem :-) -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sparse DVB adapter numbers
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 adapter1/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter5/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter6/
drwxr-xr-x 2 root root 120 Mar 19 11:59 adapter7/
But vdr uses only the first two devices.
Is there any easy possibility to patch the code accordingly?
./vdr -D 0 -D 1 -D 5 -D 6 -D 7
I'm afraid this won't work, because VDR stops scaning for DVB devices
as soon as it hits a gap.
Good i didn't know that years ago when setting up my vdr boxes... :)
IOW this approach has been working for me for quite a while w/o any
problems. Note i'm still at 1.4.x and my 'gaps' actually contain
adapters (unused by this vdr instance).
If the gaps really are a problem you could always renumber the adapters
using udev rules such as
SUBSYSTEM==dvb, SUBSYSTEMS==pci, KERNELS==:00:0e.0, PROGRAM=/bin/sh
-c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s 0 $${K#*.}',
NAME:=%c
SUBSYSTEM==dvb, SUBSYSTEMS==pci, KERNELS==:02:09.0, PROGRAM=/bin/sh
-c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s 1 $${K#*.}',
NAME:=%c
etc
artur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.2.6
Hi, a new IPTV plugin release is now available: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ 2009-03-22: Version 0.2.6 - Added a note about recommended frequencies into README. - Fixed a locking bug with section filters. - Fixed some lint warnings. I strongly encourage every IPTV user to upgrade the plugin, as the locking bug in older versions caused crashing during zapping on certain VDR setups. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
On Wed, Mar 18, 2009 at 02:40:38PM +0200, Antti Palosaari wrote: Heinrich Langos wrote: I ran dvbtraffic (itself causing about 10 wakups but hardly any cpu load) on another console to see what is happening and it seems like femon does only check the receiver's status while zap realy causes data to be transfered from the USB device to the host. yes. femon only reads demodulator status and zap starts transfer. So the rather heavy load that I see with vdr is probably not caused by vdr itself but by the USB data transfer. The new questions are: Does every USB DVB-T receiver cause the same amount of cpu load? Not sure. This device uses USB bulk transfer with packet size 512. This is most typical packet size and protocol, very many devices are using just same. Some devices are using different packet size. There is also isochronous transfer used instead bulk, but it is not very very common. I have no idea how much load it generates. I doubt all USB-transfers will generate almost same load when transferring same amount of data. In my understanding USB does not use DMA and that's why it generates high load? DMA is only possible between memory and the USb host controller. The USB device is always polled for data. Even the so called interupt transfer mode is nothing but a high frequency polling mode... well USB sucks compared to firewise but than again, usb devices are cheap as chips because they can be stupid. I ran a couple of tests with a different DVB-T USB stick. The rather old Fujitsu-Siemens DVB-T Mobile TV. That one turns out to need a lot less system resources. It also transfers the whole transport stream (several video and audio streams) over the USB and leaves demuxing to the host. So we are not comparing apples and oranges. Comparing those numbers seems to indicate that there is room for improvment for the af9015 driver. I'll try to get my hands on a couple more different usb receivers to try out some of the other drivers. What I also found rather scary was the 200 wakups per second that vdr did even when there is no dvb device to read from. So I removed all vdr plugins and started adding them one by one. epgsearch - no problem live - no problem streamdev-server - no problem ffnetdev - BINGO Which makes sense when considering that ffnetdev tries to implement a full featured card in software. I just didn't know they also try to implement an INPUT device! With the usb device enabled, I get various degrees of CPU load, depending on the plugins installed, but in general the number of wakeups per second is constant at about 200 per second. Even without any plugin and with noting to do. In other words: vdr is polling its input devices at 200 Hertz even when is is completely idle! I wonder if that is realy necessary... Some vdr guru willing to enlighten me? (I'm willing to dodge the stones thrown at the heretic :-) ) cheers -henrik PS: I am willing to take the whole driver thread off-list if somebody feels that this is not the proper list for it, but I think the way vdr behaves when it is idle is interesting to more people. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Hi! Heinrich Langos schrieb: I ran a couple of tests with a different DVB-T USB stick. The rather old Fujitsu-Siemens DVB-T Mobile TV. That one turns out to need a lot less system resources. It also transfers the whole transport stream (several video and audio streams) over the USB and leaves demuxing to the host. So we are not comparing apples and oranges. Comparing those numbers seems to indicate that there is room for improvment for the af9015 driver. I'll try to get my hands on a couple more different usb receivers to try out some of the other drivers. I borrowed an af9015 device some time ago, and the owner told me that the primary problem with it is that it has no hardware PID filter. So even if VDR is only doing EPG scanning, the complete multiplex is congesting the USB link. Maybe your Fujitsu-Siemens receiver has a hardware PID filter... Ciao Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 22.03.2009 15:36, Niedermeier Günter wrote: Well, if there are buffer overflows and the TS data is corrupted, it's no wonder the index file stops growing. Does this happen on all channels, or only on some (or even only on a particular one)? Additional infos: I recompiled older versions beginning at 1.7.3 and made some tests. 1.7.3 acts exactly like 1.7.4 one record - bufferoverflow The native networkthroughput is between 2,8-3,7 Mega Bytes /s for one stream. - Much to high I think! 1.7.2 seems to be o.k. one record - no problem - throughput is between 0,8-1,2 MB/s two records - no problem - throughput is between 1,8-2,6 MB/s three records - no problem - throughput is between 2,8-4,0 MB/s four records - PES pkt shortened - throughput is between 3,8-5,4 MB/s All tested while using the slower NFS share. Why does one TS stream require a three times higher bandwidth in 1.7.3/1.7.4 than a PES stream in 1.7.2 do? A TS recording is only marginally more data than the same length recording in PES. I don't think that recording in TS should require so much more bandwidth than PES. There must be an other problem that's causing this, but since this doesn't happen here on my system, I'm afraid you'll need to do the debugging ;-) Just to be sure: this *is* an unpatched version 1.7.4. we're talking about, right? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Here's the powertop output for the siemens stick in various situations: cheers -henrik running zap to tune into a channel and transfer the TS over USB PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)( 5.8%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C20.1ms ( 0.0%) 188 Mhz 100.0% C31.9ms (94.2%) Wakeups-from-idle per second : 486.1interval: 10.0s no ACPI power usage estimate available Top causes for wakeups: 55.3% (598.2) USB device 5-1 : DVB-T 2 (Afatech) 42.8% (462.3) interrupt : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 0.5% ( 5.6) zap : schedule_timeout (process_timeout) 0.2% ( 2.3) events/0 : schedule_timeout (process_timeout) 0.2% ( 2.2) khubd : queue_delayed_work (delayed_work_timer_fn) 0.2% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.2% ( 2.0)kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.2% ( 1.8) xfsbufd : schedule_timeout (process_timeout) 0.1% ( 1.0) zap : do_nanosleep (hrtimer_wakeup) 0.1% ( 1.0) ifconfig : b44_open (b44_timer) 0.0% ( 0.5) kernel core : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.5) kernel core : schedule_delayed_work_on (delayed_work_timer_fn) 0.0% ( 0.3) kernel module : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) interrupt : uhci_hcd:usb3, eth0 0.0% ( 0.2) init : schedule_timeout (process_timeout) 0.0% ( 0.2) kernel core : __netdev_watchdog_up (dev_watchdog) 0.0% ( 0.2) runsvdir : schedule_timeout (process_timeout) 0.0% ( 0.1)screen : do_setitimer (it_real_fn) 0.0% ( 0.1) kernel module : f8b4191b (inet_frag_secret_rebuild) 0.0% ( 0.1) kernel core : addrconf_verify (addrconf_verify) 0.0% ( 0.1) nmbd : schedule_timeout (process_timeout) Suggestion: Enable USB autosuspend by pressing the U key or adding usbcore.autosuspend=1 to the kernel command line in the grub config Q - Quit R - Refresh U - Enable USB suspend -- running vdr and having it idle around. -- i.e. not recording anything jukebox:/home/data/static# /etc/init.d/vdr start Starting Linux Video Disk Recorder: vdr Searching for plugins (VDR 1.6.0-2/1.6.0) (cache hit): epgsearch femon dvdswitch quickepgsearch conflictcheckonly live epgsearchonly dvd ffnetdev streamdev-server xineliboutput. PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)(14.8%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C20.1ms ( 0.2%) 188 Mhz 100.0% C31.3ms (85.1%) Wakeups-from-idle per second : 655.9interval: 10.0s no ACPI power usage estimate available Top causes for wakeups: 45.8% (606.2) USB device 5-1 : DVB-T 2 (Afatech) 35.6% (470.9) interrupt : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 16.7% (220.9) vdr : futex_wait (hrtimer_wakeup) 0.7% ( 9.5) vdr : schedule_timeout (process_timeout) 0.2% ( 2.2) khubd : queue_delayed_work (delayed_work_timer_fn) 0.2% ( 2.2) events/0 : schedule_timeout (process_timeout) 0.2% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.2% ( 2.0)kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.1% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.1% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup) 0.1% ( 1.0) ifconfig : b44_open (b44_timer) 0.0% ( 0.5) kernel core : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.5) kernel core : schedule_delayed_work_on (delayed_work_timer_fn) 0.0% ( 0.3) kernel module : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) vdr : hrtick_set (hrtick) 0.0% ( 0.2) kernel core : __netdev_watchdog_up (dev_watchdog) 0.0% ( 0.2) xfssyncd : schedule_timeout (process_timeout) 0.0% ( 0.2)
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
A TS recording is only marginally more data than the same length recording in PES. I don't think that recording in TS should require so much more bandwidth than PES. That's clear to me. There must be an other problem that's causing this, but since this doesn't happen here on my system, I'm afraid you'll need to do the debugging ;-) No problem, I'll try debugging the problem with my tools :-), but I have no chance debugging in the code. :-( Just to be sure: this *is* an unpatched version 1.7.4. we're talking about, right? Yes, of course. It's installed from a fresh download, also 1.7.3 and 1.7.2 -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
...is there switch, or simple possibility to change recording format from TS to PES in 1.7.4 - just for a simple verification? BTW: In your environment, do you stream over net or local disk? Because streaming to a local (linux)disk makes no problem, and would be hard to produce it, or measure the diskload. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
On Sun, Mar 22, 2009 at 06:16:29PM +0100, Martin Emrich wrote: Heinrich Langos schrieb: I ran a couple of tests with a different DVB-T USB stick. The rather old Fujitsu-Siemens DVB-T Mobile TV. That one turns out to need a lot less system resources. It also transfers the whole transport stream (several video and audio streams) over the USB and leaves demuxing to the host. So we are not comparing apples and oranges. I borrowed an af9015 device some time ago, and the owner told me that the primary problem with it is that it has no hardware PID filter. So even if VDR is only doing EPG scanning, the complete multiplex is congesting the USB link. Maybe your Fujitsu-Siemens receiver has a hardware PID filter... Hi Martin, I am pretty sure the Siemens stick doesn't filter PIDs. The easy way to find out about that is to look at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices and check if the device works with usb 1.1 or absolutely needs 2.0. Also the system load doesn't seem to differ a lot between vdr being mostly idle and recording. I'll get my hands onto a Toshiba USB DVB-T Tuner PX1211E-1TVD this week. That one should have a pid filter as it seems to support USB 1.1 as well as 2.0. cheers -henrik ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 22.03.2009 19:06, Niedermeier Günter wrote: ...is there switch, or simple possibility to change recording format from TS to PES in 1.7.4 - just for a simple verification? Sorry, PES recordign has been completely removed from VDR. In your environment, do you stream over net or local disk? Because streaming to a local (linux)disk makes no problem, and would be hard to produce it, or measure the diskload. My test machine is diskless, so recordings go to an NFS mount. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
There must be an other problem that's causing this, but since this doesn't happen here on my system, I'm afraid you'll need to do the debugging ;-) Which changes have been made between 1.7.2 and 1.7.3 in file writing mechanism? Not codechanges, because I dont understand them, but in words please. E.g. blocksize changed from xxx to yyy changed algo. changed cache or something else which can influence the performance. I found out, that in 172 the most time up to 20 stream data blocks are transmitted via NFS between one NFS WRITE CALL / WRITE REPLAY and NFS COMMIT CALL / COMMIT REPLAY combination and the next one. In 173/174 the number of stream data blocks decreases to an amount of 5 blocks maximal. Therefor the number of NFS WRITE CALL / WRITE REPLAY and NFS COMMIT CALL / COMMIT REPLAY combinations increases up to 4 to 5 times higher than in 172. This produces an enormous overhead, and this overhead could be reasonable for the two MegaByte/s networkoverload above the normal load with 1 MB/s per stream. Perhaps Klaus, you have an idea. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
A TS recording is only marginally more data than the same length recording in PES. I don't think that recording in TS should require so much more bandwidth than PES. That's clear to me. There must be an other problem that's causing this, but since this doesn't happen here on my system, I'm afraid you'll need to do the debugging ;-) No problem, I'll try debugging the problem with my tools :-), but I have no chance debugging in the code. :-( Further investigation reveals ringbuffer overflows reported in syslog as soon as recording starts. I can put some trace into the code as Klaus has suggested. Assuming that what I am experiencing with NTFS is another manifestation of the problem Gunter is seeing with NFS - What would be useful? Just to be sure: this *is* an unpatched version 1.7.4. we're talking about, right? Yes, of course. It's installed from a fresh download, also 1.7.3 and 1.7.2 Mine is also a clean 1.7.4 install. Note that I am using the latest Liplianin drivers with two patches applied - av7110_ts_replay_1.diff and av7110_v4ldvb_api5_audiobuff_test_1.diff applied. Mark. -Günter -- This message was scanned by ESVA and is believed to be clean. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
