I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Is this vdr related or firmware related. After all the error is fw error isn't it?
\Kartsa
On to, 2007-02-01 at 19:29 +0200, Kartsa wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Hi,
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
Bye.
Reinhard Nissl kirjoitti:
Hi,
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
Bye.
I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings.
\Kartsa
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote:
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
Bye.
I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings.
You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame.
Mrako
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote:
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
Bye.
I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings.
You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame
Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish.
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Marko Mäkelä kirjoitti:
I do not think that it is the reason. I checked that the cpu load was less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20% when there were 5 simultaneuous recordings.
You should really learn to use OProfile. With it, you can see which functions (or even which source code lines or machine instructions) are to blame
Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish.
Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources.
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
Marko
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish.
Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources.
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
I'll have to take that into consideration. I'll have to download the old version and all that :)
\Kartsa
On Thu, 1 Feb 2007, Kartsa wrote:
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish.
Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources.
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
I'll have to take that into consideration. I'll have to download the old version and all that :)
Hi,
I'll have to agree with this performance drop. I have very slow machine (P1 166 and 64 megs ram), it has fujitsu-siemens FF dvb-c card. I used 1.3.19 for very long time and it worked perfectly. Some time ago I decided to upgrade to 1.4.4, wrong decision. Now I cannot watch dvd while vdr is recording tow recordings at the same time. No problem here with earlier version.
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
And third problem which have gone worse is weird black output I get. Vdr is up and running, osd is shown, but no live video. Changing channels are very slow (ie. vdr shows the info screen very long). Restarting vdr corrects this (propably reloading the drivers is the actual "fix"). This has happened with 1.3.19 about once a week. Now with 1.4.4 I had to restart vdr everyday. That's not so nice.
Sometimes vdr finds the live video, after pressing 'ok' or something else. Is there any cure for this? (Other than making script to send some channel number every hour, unless theres user activity...)
I haven't tried to do _many_ recordings at same time with vdr-1.4.4, with 1.3.19 I tried, and I could record 4 channels at the same time and watch a recording. Watching 5th channel live was a bit jerky, but hey, it's a very low end machine...
Marko
On Fri, Feb 02, 2007 at 04:05:10PM +0200, Marko Myllymaa wrote:
On Thu, 1 Feb 2007, Kartsa wrote:
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Would it really matter in this case when cpu load was that small? I was just trying to say that even though there were almost no cpu load vdr was working sluggish.
Without trying it, it is hard to say. You may be right, the load is so small that the sluggishness can result from some mutex waits or something else that wouldn't stand out in a profiler that measures CPU resources.
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
I'll have to take that into consideration. I'll have to download the old version and all that :)
[snip]
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
I've experienced this once or twice on my setup (softdevice -vo dfb:mgatv, probably some late vdr 1.3.x, on 900 MHz Celeron with 128 or 256 MB of RAM). I sent a command via SVDRP, and it took something like a couple of minutes for VDR to react. As far as I remember, it wasn't recording anything - only replaying a recording or viewing live stream.
This may of course be related to some anomaly of softdevice. In the past 2 years that I've used vdr and softdevice, a few times softdevice has failed to start properly. It would play about 0.5 to 1 frames per second and use very little CPU. Restarting VDR has always helped.
Before setting up oprofile, you could attach strace to a running vdr and capture the output to a file for a few seconds. Do this for both the old and the new version of vdr, and see if you can find anything. The output will probably vary between runs, so attempts to use tools like "diff" may be futile.
Marko
Marko Myllymaa myllymaa@iki.fi wrote:
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz.
And third problem which have gone worse is weird black output I get. Vdr is up and running, osd is shown, but no live video. Changing channels are very slow (ie. vdr shows the info screen very long). Restarting vdr corrects this (propably reloading the drivers is the actual "fix"). This has happened with 1.3.19 about once a week. Now with 1.4.4 I had to restart vdr everyday. That's not so nice.
me 2 also on this point. exactly the same behalfier.
clemens
On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
Marko Myllymaa myllymaa@iki.fi wrote:
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz.
What type of remote receiver are you using? I've had delays with some remotes but not others:
1. USB2 Nova-T receiver with the remote plugin: works most of the time but goes through phases where it seems to be ignoring keypresses so I press the button again (several times!) and then a few seconds later it "catches up" and I end up in a different menu, etc. to what I wanted! Works OK but can be very annoying! Also gives the wrong codes, i.e. keys, sometimes which can be confusing!
2. PCI Nova-T receiver through lirc: works much better than the USB receiver but does feel as if there is a lag between pressing keys and things happening. Does sometimes do the buffering thing mentioned above but nowhere near as bad.
3. Home-made simple lirc receiver on a serial port through lirc: much more responsive than the two "proper" remote receivers! I would recommend this to anyone who can build the simple receiver. Finally got round to building another one for my main vdr system and it is so so much better now (was using the USB receiver previously).
I never worked out where the delays occurred, i.e. whether it was down to the DVB drivers or vdr itself. Seeing as the lirc receiver works fine, I'd be suspicious of the driver.
The above observations are on a 1.2 GHz Via Epia system, so not that powerful all things considered.
Cheers,
Laz
Laz laz@club-burniston.co.uk wrote:
On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
Marko Myllymaa myllymaa@iki.fi wrote:
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz.
What type of remote receiver are you using? I've had delays with some remotes but not others:
home brewed ir receiver on serial port using lirc. the same as you say worked best for you. i'm sure the problem is not on the IR side but on vdr, as that setup was not changed between vdr upgrades.
best regards ... clemens
Clemens Kirchgatterer kirjoitti:
Laz laz@club-burniston.co.uk wrote:
On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
Marko Myllymaa myllymaa@iki.fi wrote:
Also this newer version does some weird busylooping or whatever from time to time. Vdr gets all remote codes and buffers them, but just starts executing them after ~45s. One time it took so long, that I got ssh opened from other computer to restart vdr, but vdr had recovered.
i can confirm this. i get the same delays in key processing very frequently. i use also a low end machine - PII 233 MHz.
What type of remote receiver are you using? I've had delays with some remotes but not others:
home brewed ir receiver on serial port using lirc. the same as you say worked best for you. i'm sure the problem is not on the IR side but on vdr, as that setup was not changed between vdr upgrades.
I have home brewed also and I either do not think IR side is the problem. The delays became the longer the more recordings are on simultaneously. I just tested just to be sure that after second recording the playback of another recording starts to snap crackle and pop both sound and picture. Very small but noticeable. After third recording responces to remote are either very sluggish or in some remote actions nothing happens. And as I said earlier this behaviour is similar in PIII 550 and AMD 3000+.
And actually I think what ever is causing this may also be the reason for the AV sync problem I reported in another thread. I mean after the third recording AV sync is about all the time out of sync or atleast its no fun to watch. I'll report about this in the related thread.
\Kartsa
hi,
I have also currently the responsiveness problem. I have a P4 2.4GHz which runs at aout 20% load, so it should not be a performance problem.
Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't reported before you started complaining, as I have not had the energy to upgrade lately).
Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started.
For me, the vdr watchdog helps, but it definitely is not a DVB-driver problem, as I have modified runvdr to _not_ to reload DVB drivers, as that never helps anything anyway.
yours, Jouni
Hi,
Jouni Karvo wrote:
I have also currently the responsiveness problem. I have a P4 2.4GHz which runs at aout 20% load, so it should not be a performance problem.
Currently home-made lirc, vdr-xine and 1.4.1 (and that's why I haven't reported before you started complaining, as I have not had the energy to upgrade lately).
Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started.
For me, the vdr watchdog helps, but it definitely is not a DVB-driver problem, as I have modified runvdr to _not_ to reload DVB drivers, as that never helps anything anyway.
Are you using xine's video output driver xxmc?
I experience deadlocks with this driver on either nVidia or Via EPIA hardware. For example, when you replay a recording and press the pause button: the pause symbol (OSD) will never appear on screen, input_vdr's RPC thread blocks forever, vdr-xine waits for the RPC result while VDR is caught in cXineOsd::Flush().
I'm working on this issue but still do not have a complete solution to it: the deadlock is gone, but the OSD is still not shown on screen.
Bye.
hi,
Reinhard Nissl writes:
Are you using xine's video output driver xxmc?
yes, I am.
I experience deadlocks with this driver on either nVidia or Via EPIA hardware. For example, when you replay a recording and press the pause button: the pause symbol (OSD) will never appear on screen, input_vdr's RPC thread blocks forever, vdr-xine waits for the RPC result while VDR is caught in cXineOsd::Flush().
hmm... it has once locked, and sometimes the pause symbol does not show, but a quick re-pauseing fixes it.
I wonder if the slow responses to remote clicking can then be due to the same, or are there several unrelated issues...
yours, Jouni
Jouni Karvo jouni.karvo@tkk.fi wrote:
Reinhard Nissl writes:
Are you using xine's video output driver xxmc?
yes, I am.
but i don't. i have a full featured DVB card.
clemens
Jouni Karvo wrote:
Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started.
I wonder if this would help in xorg.conf Device section
Option "UseEvents" "True"
(from http://www.gossamer-threads.com/lists/mythtv/users/242086)
I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv.
BR, Seppo
hi,
Seppo Ingalsuo writes:
Jouni Karvo wrote:
Earlier I had an ATI GFX card and used XV (with xine) for playback, and had not this problem. After switching to nVidia GeForce FX 5200, it started.
I wonder if this would help in xorg.conf Device section
Option "UseEvents" "True"
This alone did not help, but
I got this tip and it helped to my random video freeze problems with Nvidia binary driver and Xv.
changing from xvmc to xv did.
thanks. Jouni
On Sat, Feb 03, 2007 at 10:43:37AM +0000, Laz wrote:
What type of remote receiver are you using? I've had delays with some remotes but not others:
- PCI Nova-T receiver through lirc: works much better than the USB receiver
but does feel as if there is a lag between pressing keys and things happening. Does sometimes do the buffering thing mentioned above but nowhere near as bad.
I got rid of this lag by disabling the asynchronously running repeat timer in the kernel:
http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch
The file ir-common.c has been renamed to ir-functions.c, but this still applies cleanly to the 2.6.19.2 kernel.
I'm using the linuxinput driver of DirectFB via softdevice. The remote plugin adds a layer of abstraction. If I remember correctly, it reduced the repeat rate, but there wasn't any noticeable lag. That is, I could open up a long menu, such as the EPG, and navigate to the desired line by pressing and holding the Down button. Without my kernel patch, the cursor would end up a few lines before or after the desired spot.
Marko
Kartsa kirjoitti:
Marko Mäkelä kirjoitti:
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
I'll have to take that into consideration. I'll have to download the old version and all that :)
I was unsuccesfull with setting up an environment where I could run vdr-1.3.22. It just exits with exit code 2 with no other explanation in. It tells me to turn off NPTL by setting LD_ASSUME_KERNEL=2.4.1 and then all I get is "error while loading shared libraries" to about any command I try. And then "cannot open shared object file: No such file or directory" and depending on the command the library file varies. So no comparison :(
\Kartsa
Kartsa kirjoitti:
Kartsa kirjoitti:
Marko Mäkelä kirjoitti:
In any case, you could profile the old and new version of vdr and see if there is any obvious difference.
I'll have to take that into consideration. I'll have to download the old version and all that :)
I was unsuccesfull with setting up an environment where I could run vdr-1.3.22. It just exits with exit code 2 with no other explanation in. It tells me to turn off NPTL by setting LD_ASSUME_KERNEL=2.4.1 and then all I get is "error while loading shared libraries" to about any command I try. And then "cannot open shared object file: No such file or directory" and depending on the command the library file varies. So no comparison :(
This thread changed to talking about different issues like ati and xine which are actually far from the original meaning of my post. I still have this performance issue. I could not make the comparison with earlier vdr version but I did do some profiling.
I did a seven minute session where I had 5 test recordings which started one minute apart and ended at the same time. After each recording had started I tested the responce of remote by just pussing menu button. After three recordings there began to be delay in menu appearance and after fourth recording the menu came up in pieces and after fifth recording there were no menu or if it ever did appear after several menu presses it was incomplete. This can be seen in the log (timeout waiting in LoadBitmap). Playback of a recording started to have small problems after third recording started and with four and five simultaneous recordings you really do not want to wath a movie like that.
This is the log during the test:
Mar 3 21:34:20 localhost kernel: oprofile: using NMI interrupt. Mar 3 21:35:00 localhost vdr: [2389] timer 1 (1 2135-2142 'TestRec1') start Mar 3 21:35:00 localhost vdr: [2389] record /srv/vdr/TestRec1/2007-03-03.21.35.50.99.rec Mar 3 21:35:19 localhost vdr: [2389] replay /srv/vdr/@Seabiscuit_-_amerikkalainen_legenda/2007-03-03.21.22.50.99.rec Mar 3 21:36:01 localhost vdr: [2389] timer 2 (2 2136-2142 'TestRec2') start Mar 3 21:36:01 localhost vdr: [2389] record /srv/vdr/TestRec2/2007-03-03.21.36.50.99.rec Mar 3 21:37:00 localhost vdr: [2389] timer 3 (7 2137-2142 'TestRec3') start Mar 3 21:37:00 localhost vdr: [2389] record /srv/vdr/TestRec3/2007-03-03.21.37.50.99.rec Mar 3 21:38:00 localhost vdr: [2389] timer 4 (8 2138-2142 'TestRec4') start Mar 3 21:38:00 localhost vdr: [2389] record /srv/vdr/TestRec4/2007-03-03.21.38.50.99.rec Mar 3 21:39:00 localhost vdr: [2389] timer 5 (9 2139-2142 'TestRec5') start Mar 3 21:39:00 localhost vdr: [2389] record /srv/vdr/TestRec5/2007-03-03.21.39.50.99.rec Mar 3 21:39:21 localhost kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1 Mar 3 21:40:19 localhost kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1 Mar 3 21:40:59 localhost last message repeated 2 times Mar 3 21:42:03 localhost vdr: [2389] timer 1 (1 2135-2142 'TestRec1') stop Mar 3 21:42:03 localhost vdr: [2389] timer 2 (2 2136-2142 'TestRec2') stop Mar 3 21:42:03 localhost vdr: [2389] timer 3 (7 2137-2142 'TestRec3') stop Mar 3 21:42:03 localhost vdr: [2389] timer 4 (8 2138-2142 'TestRec4') stop Mar 3 21:42:04 localhost vdr: [2389] timer 5 (9 2139-2142 'TestRec5') stop Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (1 2135-2142 'TestRec1') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (2 2136-2142 'TestRec2') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (7 2137-2142 'TestRec3') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (8 2138-2142 'TestRec4') Mar 3 21:43:04 localhost vdr: [2389] deleting timer 1 (9 2139-2142 'TestRec5')
During the test CPU idle was over 90% all the time. I used oprofiler during the test and these are the results:
CPU: P4 / Xeon, speed 3192.31 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 GLOBAL_POWER_E...| samples| %| ------------------ 145068 47.4769 vdr GLOBAL_POWER_E...| samples| %| ------------------ 137420 94.7280 vdr 7648 5.2720 anon (tgid:2389 range:0xfa6000-0xfa7000) 99854 32.6796 libc-2.5.so 35565 11.6395 libpthread-2.5.so 9336 3.0554 no-vmlinux 2888 0.9452 libcrypto.so.0.9.8b 2430 0.7953 oprofiled GLOBAL_POWER_E...| samples| %| ------------------ 2419 99.5473 oprofiled 11 0.4527 anon (tgid:3372 range:0xfb9000-0xfba000) 2269 0.7426 libqt-mt.so.3.3.7 1544 0.5053 sshd GLOBAL_POWER_E...| samples| %| ------------------ 1418 91.8394 sshd 108 6.9948 anon (tgid:3027 range:0x2a9000-0x2aa000) 14 0.9067 anon (tgid:3080 range:0x4a6000-0x4a7000) 4 0.2591 anon (tgid:3385 range:0xac1000-0xac2000) 1238 0.4052 libstdc++.so.6.0.8 860 0.2815 top GLOBAL_POWER_E...| samples| %| ------------------ 488 56.7442 top 372 43.2558 anon (tgid:3107 range:0x824000-0x825000) 704 0.2304 libX11.so.6.2.0 500 0.1636 libXft.so.2.1.2 471 0.1541 bash GLOBAL_POWER_E...| samples| %| ------------------ 462 98.0892 bash 5 1.0616 anon (tgid:3387 range:0x948000-0x949000) 4 0.8493 anon (tgid:3430 range:0xe91000-0xe92000) 442 0.1447 libncurses.so.5.5 401 0.1312 less GLOBAL_POWER_E...| samples| %| ------------------ 388 96.7581 less 13 3.2419 anon (tgid:3412 range:0x13c000-0x13d000) 362 0.1185 libproc-3.2.7.so 237 0.0776 ld-2.5.so 172 0.0563 ntpd GLOBAL_POWER_E...| samples| %| ------------------ 161 93.6047 ntpd 11 6.3953 anon (tgid:2431 range:0xec3000-0xec4000) 152 0.0497 sendmail.sendmail GLOBAL_POWER_E...| samples| %| ------------------ 144 94.7368 sendmail.sendmail 8 5.2632 anon (tgid:2451 range:0xd2d000-0xd2e000) 134 0.0439 lircd GLOBAL_POWER_E...| samples| %| ------------------ 89 66.4179 lircd 45 33.5821 anon (tgid:2358 range:0xbc3000-0xbc4000) 105 0.0344 oprof_start GLOBAL_POWER_E...| samples| %| ------------------ 53 50.4762 anon (tgid:3116 range:0x41a000-0x41b000) 52 49.5238 oprof_start 104 0.0340 httpd GLOBAL_POWER_E...| samples| %| ------------------ 96 92.3077 httpd 8 7.6923 anon (tgid:2483 range:0x2f8000-0x2f9000) 76 0.0249 libapr-1.so.0.2.7 63 0.0206 hald GLOBAL_POWER_E...| samples| %| ------------------ 61 96.8254 hald 2 3.1746 anon (tgid:2610 range:0xdef000-0xdf0000) 50 0.0164 libtermcap.so.2.0.8 49 0.0160 libglib-2.0.so.0.1200.9 37 0.0121 automount GLOBAL_POWER_E...| samples| %| ------------------ 23 62.1622 automount 14 37.8378 anon (tgid:2337 range:0xacc000-0xacd000) 36 0.0118 libgdk_pixbuf-2.0.so.0.1000.8 35 0.0115 init GLOBAL_POWER_E...| samples| %| ------------------ 32 91.4286 init 3 8.5714 anon (tgid:1 range:0x807000-0x808000) 31 0.0101 libgobject-2.0.so.0.1200.9 27 0.0088 libpango-1.0.so.0.1400.10 27 0.0088 bluecurve.so 24 0.0079 hald-addon-storage GLOBAL_POWER_E...| samples| %| ------------------ 14 58.3333 anon (tgid:2635 range:0x2f3000-0x2f4000) 10 41.6667 hald-addon-storage 23 0.0075 grep 23 0.0075 syslogd GLOBAL_POWER_E...| samples| %| ------------------ 22 95.6522 syslogd 1 4.3478 anon (tgid:2136 range:0x260000-0x261000) 22 0.0072 libevent-1.1a.so.1.0.2 22 0.0072 libpangoft2-1.0.so.0.1400.10 20 0.0065 gawk 16 0.0052 Xorg GLOBAL_POWER_E...| samples| %| ------------------ 15 93.7500 Xorg 1 6.2500 anon (tgid:2816 range:0x890000-0x891000) 16 0.0052 libgdk-x11-2.0.so.0.1000.8 14 0.0046 libgnomecanvas-2.so.0.1400.0 12 0.0039 pam_unix.so 12 0.0039 libart_lgpl_2.so.2.3.17 8 0.0026 libpam.so.0.81.5 7 0.0023 gdmgreeter GLOBAL_POWER_E...| samples| %| ------------------ 6 85.7143 gdmgreeter 1 14.2857 anon (tgid:2862 range:0x368000-0x369000) 6 0.0020 libdbus-1.so.3.2.0 5 0.0016 libfb.so 5 0.0016 rpc.idmapd GLOBAL_POWER_E...| samples| %| ------------------ 5 100.000 anon (tgid:2226 range:0xc4d000-0xc4e000) 4 0.0013 libsepol.so.1 4 0.0013 ophelp 4 0.0013 libgtk-x11-2.0.so.0.1000.8 4 0.0013 i810_drv.so 3 9.8e-04 libdl-2.5.so 3 9.8e-04 libm-2.5.so 3 9.8e-04 libfreetype.so.6.3.10 3 9.8e-04 libncursesw.so.5.5 2 6.5e-04 ls 2 6.5e-04 libselinux.so.1 2 6.5e-04 libdri.so 2 6.5e-04 crond 1 3.3e-04 cat 1 3.3e-04 libaudit.so.0.0.0 1 3.3e-04 libnss_files-2.5.so 1 3.3e-04 libresolv-2.5.so 1 3.3e-04 pam_succeed_if.so 1 3.3e-04 klogd 1 3.3e-04 dircolors 1 3.3e-04 expr 1 3.3e-04 id 1 3.3e-04 which 1 3.3e-04 xauth 1 3.3e-04 libXext.so.6.4.0 1 3.3e-04 libXfont.so.1.4.1 1 3.3e-04 libkrb5support.so.0.1 1 3.3e-04 libpopt.so.0.0.0 1 3.3e-04 mouse_drv.so 1 3.3e-04 libxaa.so
I've done the test with three different settings, one with a PIII733MHz, one with AMD Sempron 3000+, and one with Intel Celeron D 3,2GHz and the results are quite similar. With PIII and AMD I used one dvb-c card (DVB: registering new adapter (Technotrend/Hauppauge WinTV DVB-C rev2.X)) and with Celeron two dvb-c cards (DVB: registering new adapter (TT-Budget/WinTV-NOVA-C PCI) and DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X)). I use the ff cards video out.
I had only vdr-1.4.5-2 with no plugins or patches. I also used a home-brewed ir receiver with lirc.
And I used the latest firmware.
Can anybody use this data to tell me where the problem lies.
\Kartsa
On Sat, Mar 03, 2007 at 10:12:21PM +0200, Kartsa wrote:
I did a seven minute session where I had 5 test recordings which started one minute apart and ended at the same time. After each recording had started I tested the responce of remote by just pussing menu button. After three recordings there began to be delay in menu appearance and after fourth recording the menu came up in pieces and after fifth recording there were no menu or if it ever did appear after several menu presses it was incomplete. This can be seen in the log (timeout waiting in LoadBitmap). Playback of a recording started to have small problems after third recording started and with four and five simultaneous recordings you really do not want to wath a movie like that.
If I were you, I'd run OProfile only during the heavy-load situation (3 recordings running, when you are browsing the EPG menu. I'd try something like this:
opcontrol --reset sleep 2;opcontrol --start;sleep 20;opcontrol --stop
After that, you have 2 seconds to start browsing the EPG and 20 seconds to keep browsing. (Or to start playback and keep watching it.)
After this is done, look at
opreport -l /path/to/vdr | less
Obviously, you should compile vdr with debugging symbols enabled (CFLAGS and LDFLAGS containing -g).
I'll lose this mail account at the end of this month, and I think I will unsubscribe from most mailing lists, including this one. We can continue this off-list. You can find my email address at the bottom of my home page, http://www.iki.fi/~msmakela/.
Marko
Marko Mäkelä kirjoitti:
On Sat, Mar 03, 2007 at 10:12:21PM +0200, Kartsa wrote:
I did a seven minute session where I had 5 test recordings which started one minute apart and ended at the same time. After each recording had started I tested the responce of remote by just pussing menu button. After three recordings there began to be delay in menu appearance and after fourth recording the menu came up in pieces and after fifth recording there were no menu or if it ever did appear after several menu presses it was incomplete. This can be seen in the log (timeout waiting in LoadBitmap). Playback of a recording started to have small problems after third recording started and with four and five simultaneous recordings you really do not want to wath a movie like that.
If I were you, I'd run OProfile only during the heavy-load situation (3 recordings running, when you are browsing the EPG menu. I'd try something like this:
opcontrol --reset sleep 2;opcontrol --start;sleep 20;opcontrol --stop
After that, you have 2 seconds to start browsing the EPG and 20 seconds to keep browsing. (Or to start playback and keep watching it.)
After this is done, look at
opreport -l /path/to/vdr | less
Obviously, you should compile vdr with debugging symbols enabled (CFLAGS and LDFLAGS containing -g).
Okey, I'll try that, thanks for the tips.
Allthough I did another quick test with my PIII733 with softdevice and Matrox G400 (directfb installed) and I had no problems recording 9 simultaneous programs and still having no trouble with the menu and only (very) slight sync problems with playback. Should this be understood as a problem in dvb firmware because I did not use the video out on the ff card (cause there were none)?
Do people use more video out of video cards instead of ff card? And if so which is the best combination on video card and software?
\Kartsa
On 01 Feb 2007 Reinhard Nissl rnissl@gmx.de wrote:
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
I don't think that the problem is related to anything on VDR side.
AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout.
I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation.
Budget cards doesn't have this limitation, they can transfer the full transponder without problems.
Regards.
Stefan Huelswitt kirjoitti:
On 01 Feb 2007 Reinhard Nissl rnissl@gmx.de wrote:
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
I don't think that the problem is related to anything on VDR side.
AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout.
I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation.
Budget cards doesn't have this limitation, they can transfer the full transponder without problems.
I know the performance was better when I was using vdr-1.3.22. I know I had 9 recordings going on and still I was able to watch a previous recording and I was using a slower cpu and a ff card. Ofcourse my recent test does prove your point, hence the question "what is the best combination of hw and sw?".
\Kartsa
Kartsa schrieb:
Stefan Huelswitt kirjoitti:
On 01 Feb 2007 Reinhard Nissl rnissl@gmx.de wrote:
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
I don't think that the problem is related to anything on VDR side.
AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout.
I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation.
Budget cards doesn't have this limitation, they can transfer the full transponder without problems.
I know the performance was better when I was using vdr-1.3.22. I know I had 9 recordings going on and still I was able to watch a previous recording and I was using a slower cpu and a ff card. Ofcourse my recent test does prove your point, hence the question "what is the best combination of hw and sw?".
Guess the best would be if you could/would be able to limit the possible number of recordings on a single card (or one would be able to set a limit for FF Cards or a fixed limit would be set in VDR at compile time) Then you could have a combination of FF and budget cards like most here have most likely.
Steffen Barszus kirjoitti:
Kartsa schrieb:
Stefan Huelswitt kirjoitti:
On 01 Feb 2007 Reinhard Nissl rnissl@gmx.de wrote:
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22 (or something about) I made a test by recording nine channels simultaneously and watching a recording at the same time. I remember there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after fourth recording starts vdr becomes sluggish and there starts to come errors on log: dvb-ttpci: warning: timeout waiting in LoadBitmap when pushing menu button. And ofcourse no menu appears or menu appears only partly.
Exactly the same thing here and with the latest and the second latest firmware. My FF 2.1 TT card starts to die after third simultaneous recording. But then again, I think that budget cards are much better in this area.
Most likely, it's me who has to be blamed. Around 1.3.27, cVideoRepacker was introduced which has an impact on CPU load. This could be a reason why the menu is slow when running several recordings at the same time.
I don't think that the problem is related to anything on VDR side.
AFAIK the bandwidth from ARM to PCI bus is very limited on full-featured cards. With 3 recordings being transfered to VDR there is simply not enough bandwidth left for the OSD transfers. Hence the LoadBitmap timeout.
I experience the problem since VDR introduced concurrent recordings and I cannot believe that there is any VDR / firmware combination which doesn't show this behaviour as it's IMO a hardware limitation.
Budget cards doesn't have this limitation, they can transfer the full transponder without problems.
I know the performance was better when I was using vdr-1.3.22. I know I had 9 recordings going on and still I was able to watch a previous recording and I was using a slower cpu and a ff card. Ofcourse my recent test does prove your point, hence the question "what is the best combination of hw and sw?".
Guess the best would be if you could/would be able to limit the possible number of recordings on a single card (or one would be able to set a limit for FF Cards or a fixed limit would be set in VDR at compile time) Then you could have a combination of FF and budget cards like most here have most likely.
I too have one FF and one budget card and I occasionally do stumble in a situation when there is three or more recordings. And I am pretty sure they are not all from the same mux thus they are from two dvb cards. And btw I actually need to record from two muxes only and wrom fta channels only. And this is the reason why I have vdr with two cards in the first place.
But as it is there is a problem and as I said it does not seem to exist in an environment with something else giving the video out than FF card. Therefore the question still remains.
\Kartsa
-
Clemens Kirchgatterer -
Heikki Manninen -
Jouni Karvo -
Kartsa -
Laz -
Marko Myllymaa -
Marko Mäkelä -
Reinhard Nissl -
s.huelswitt＠gmx.de -
Seppo Ingalsuo -
Steffen Barszus