Re: [vdr] vdr-xine 0.7.10 buffering
Hi, Jouni Karvo wrote: It takes about 5 secs to start stopped disks. It is not a problem when starting a recording, but when recordings span over several disks there will be an annoying pause when it is time to start reading from another disk. Is there a possibility to configure (for example) a 10s buffering for playback while keeping the live-TV buffering as it is now? I don't think that this is a matter of vdr-xine but at least it looks like there is a simple solution in xine regarding the annoying pause: try to increase engine.buffers.audio_num_buffers and engine.buffers.video_num_buffers in xine's config file ~/.xine/config so that these input buffers are able to hold 10 seconds of the stream. Depending on the sampling rate of the audio stream, a single buffer may hold for example 24 ms of audio data. So a 10 seconds buffer will need 1 ms / 24 ms = 416 buffers. A formula for video isn't that easy, so let's assume 60 seconds of the stream make 30 MB on disk = 10 seconds yield 5 MB. A single buffer holds 2048 Byte so for 10 seconds you'll need 5 * 1024 * 1024 / 2048 = 2560 buffers. As xine tries to keep it's input buffers filled, VDR will read ahead 10 seconds in regard to the position of the image you currently see on screen. This should allow the other disk to spin up without an input buffer underrun. A drawback of such large buffers is that VDR is way ahead the picture you currently see on screen. So if you jump forward 60 seconds, you'll actually jump 70 seconds and if you jump backward 60 seconds you'll only jump 50 seconds. That's why I suggested in my MANUAL to set audio_num_buffers to the smallest value possible which is 4. In my opinion, a more proper solution should patch VDR to do some nonblocking dummy reads on the next recording file when replaying the current recording file enters the disk spinup margin. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | http://www.muempf.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Stefan Huelswitt kirjoitti: On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
Kartsa schrieb: Stefan Huelswitt kirjoitti: On 01 Feb 2007 Reinhard Nissl [EMAIL PROTECTED] 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VPS autotimer stopped prematurely
Hans-Peter Jansen wrote: Hmm, to clarify: the reliability of VPS is impaired starting from 00:00 CET up to which time? Which times are impared, start and/or end time? All events are stopped (status 1) on 0100 CET/0200 CEST. So if you have an event that runs from 0030 CET to 0130 CET, it will stop (status 1) on 0100 CET. For the next event, in this case starting at 0130, everything will be okay, so status 4 will be transmitted at the correct time. So for every programme which will end (or might end in the case of a delay) after 0100 CET/0200 CEST, you'll have to take into account that the VPS timer will stop at 0100/0200. Maybe Klaus could syslog some more detailed infos regarding the deviation, and possibly check the values semantically, e.g. in this case, vdr could have checked the original duration, compared with the broadcasted one, and better had used the longer one.. Could that be a useful strategy? Does anybody see downsides? No, I don't think this is the right way. This is really something the broadcaster has to fix. Regards, Andreas. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
