Re: [vdr] Vdr or driver performance dropout
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr or driver performance dropout
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: replay stuttering
Kartsa schrieb: Could the chosen file system be causing this? I use LVM creating one partition on two disks and then I create one xfs on that partition. The disks are sata as mentioned earlier. My VDR is running completely via NFS and i have also this stutter problem especially when using timeshift. The replay hangs for some seconds and then resumes normally. This is reproducible with a vanilla vdr-1.4.5 (FuSi DVB-C, 2.6.19.2 with v4l-dvb-av7110-refactoring). When i increase PLAYERBUFSIZE in dvbplayer.c to MEGABYTE(16) the problem is gone. Perhaps i would be a good idea, as already suggested by Carsten Koch, to make this value configurable. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] to record or not
On 2/1/07, Michael Brueckner [EMAIL PROTECTED] wrote: Am Donnerstag 01 Februar 2007 23:42 schrieb abbe normal: wondering if there is a way from the timers menu to only select to record or not record a program. what im wanting to do is set a timer to watch a program but not have vdr record it... not sure but just thinking it would be nice to have a option in the menu to not record but still go to the program... Or use the epgsearch-Plugin and the Switch list. Michi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr why would you want this as a plugin it is a timer issue if done in the vdr timers setup then it will work with all plugins i would think... i maybe wrong but just thinking its would be a good item to have... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] to record or not
On 2/1/07, Patrick Mackin [EMAIL PROTECTED] wrote: I too would like this feature, but if you are using yaepg as many are, it seems like that is a feature the plugin should provide, not vdr. It makes absolutely no sense for a reminder feature to be done via plugin. This is a very common and basic feature offered in most dvb-c and dvb-s receivers. Honestly, I was surprised to find out vdr didn't already have it implemented because it -is- such a basic function. Logically I don't see it anywhere else other than the core code. I'm not sure why you mention yaepg as that's just an alternate means to view guide data. Yaepg has nothing to do with timer functionality or reminders. Maybe you could elaborate more on how you came to your opinion on this? It was suggested before that people can just set their timers to record for 0 or 1 minute (forgot which it was) so that it doesn't waste harddisk space but this is a terrible solution as it still creates unneeded/unwanted files and directories that you would have to go clean up. There's simply no reason for that. Cheers. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Hi, Thomas Lagemann wrote: But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device? But isn't it obvious that the output device cannot tell the TV station stop broadcasting, I cannot cope with the data flow? Hardware buffers on the receiving devices are small and tend to run full quickly when fed at a constant rate. Therefore, VDR tries to offload the receiving device by reading the data as fast as the device allows. I currently do not see a chance to fix this issue with the current API. Several functions would have to be changed to pass the information, that the receiving device may be blocked, to the places where buffer overflows are detected. 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] Re: vdr diseqc equivalence of szap diseqc n ?
Hi, Gregoire Favre wrote: maybe my hardware is not optimal : running a simple bash command : Which three cards do you have? card 0: card 1: card 2: for j in `seq 0 2`;do for i in `seq 1 12`; do szap -a $j -x -n $i ; date ;done;done TUNING.log And then grep FE_HAS_LOCK TUNING.log |wc 28 4482212 Which show I miss some lock ??? If I didn't drop a line while analysing the output, it seems that card 0 locks always, card 1 misses some locks and card 2 misses more locks. To test whether this is a switch or card issue, would you mind permuting the cables on your cards? For example: plug the cable on card 0 into card 2 and vice versa and run the test again. If card 2 locks always now, then it looks like a switch issue. With the original configuration, what happens if you run the inner szap loop in parallel on the three cards? I got lots of cx88[1]/2-mpeg: cx8802_timeout in syslogd. Hhm, a quick look into cx88-mpeg.c shows that a DMA transfer timed out in this case. Don't know what this means. Maybe a driver developer can tell you more. BTW: what has changed in your setup recently, as I you didn't report such issues in the past? 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] Transfer Buffer Overflow
Marko Mäkelä wrote: I've patched vdr twice so that it'd read the MPEG TS from a regular file instead of the /dev file system. The first time (about 2 years ago) on then-current vdr 1.3.x, it succeeded. The second time (maybe 1 year ago) failed with the symptoms you are reporting. Do you remember how you patched it? Maybe you could make cDevice::Transferring() return false, if it is a virtual method? Tried that, but it deosn't have any effekt. Reinhard Nissl wrote: But shouldn't the rate at which the TS-packets are gathered from the input device be controlled by the output device? But isn't it obvious that the output device cannot tell the TV station stop broadcasting, I cannot cope with the data flow? Hardware buffers on the receiving devices are small and tend to run full quickly when fed at a constant rate. Therefore, VDR tries to offload the receiving device by reading the data as fast as the device allows. I currently do not see a chance to fix this issue with the current API. Several functions would have to be changed to pass the information, that the receiving device may be blocked, to the places where buffer overflows are detected. Bye. Well, I just didn't expect the output device to request the packets as fast as possible, especially when buffer overflows occur. But you're right. When you consider that in the normal transmission theres kind of a natural limitation of the transfer rate, the system just doesn't need to deal with this. For the moment i work around the problem with program called buffer, that i read about in this list (http://linvdr.org/mailinglists/vdr/2005/09/msg00204.html) It can deliver my stream in smaller packets, and wait a defined time until it delivers the next one. Still doesn't work perfekt, but but i can work with that. Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this. so, thank you for your answers so far. Regards, Thomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
On Fri, Feb 02, 2007 at 10:24:51PM +0100, Thomas Lagemann wrote: Marko Mäkelä wrote: I've patched vdr twice so that it'd read the MPEG TS from a regular file instead of the /dev file system. The first time (about 2 years ago) on then-current vdr 1.3.x, it succeeded. The second time (maybe 1 year ago) failed with the symptoms you are reporting. Do you remember how you patched it? Sorry, no, I didn't save the working patch, because I felt it was a trivial modification. If I remember correctly, I replaced the variable that is assigned /dev/ + something with a character string constant, the absolute pathname of the MPEG TS file. There probably was some wrapper around the open() call. I don't remember changing anything else, but I cannot tell that for sure. I really should have saved the patch that worked. It was just a one-off thing to get a MPEG TS recording converted. The second time (when I failed to patch vdr properly) I ended up using mencoder and genindex. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Transfer Buffer Overflow
Hi, Thomas Lagemann wrote: Just another thought about the timing: MPEG-2 defines rules for a system target decoder, thats in charge for decoding and presenting the media at the right time, using the PTS-stamps in the PES packets. Is this usually done by the driver or is there a VDR instance that deals with this. It's done in the driver / xine. But it shouldn't be to complicated to extract the PTS value from a TS packet. The PTS value is very near to the beginning of a PES packet and a bit in the TS packet tells you that a new PES packet starts in this TS packet. When you extract PTS for each PID and calculate the difference to the first seen PTS for each PID, then you evaluate, how much time should have passed since the beginning of the TS file. If you put this information in relation to the time passed in reality since opening the TS file, you can throttle the TS stream so that it doesn't overflow the buffers any more. BTW: keep in mind, that video PTS jump back and forth as the images are broadcast in decoding order while the PTS time stamps describe presentation order. 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] Re: vdr diseqc equivalence of szap diseqc n ?
On Fri, Feb 02, 2007 at 09:50:44PM +0100, Reinhard Nissl wrote: Hello, Which three cards do you have? card 0: Hauppauge budget CI card 1: Geniatech budget card 2: Geniatech budget If I didn't drop a line while analysing the output, it seems that card 0 locks always, card 1 misses some locks and card 2 misses more locks. To test whether this is a switch or card issue, would you mind permuting the cables on your cards? Of course I don't mind :) For example: plug the cable on card 0 into card 2 and vice versa and run the test again. If card 2 locks always now, then it looks like a switch issue. With the original configuration, what happens if you run the inner szap loop in parallel on the three cards? I have tried with a new type of LNB and with another diseqc, so all changed... without any improvment, I think I have to put my dish right again after all those testings before doing some more try :-) Hhm, a quick look into cx88-mpeg.c shows that a DMA transfer timed out in this case. Don't know what this means. Maybe a driver developer can tell you more. BTW: what has changed in your setup recently, as I you didn't report such issues in the past? I was having 2 FF cards, and I got tuning problem on one card, since it seemed FF cards suffer from bad diseqc sending message, I bought two FF cards, but apparently, it wasn't just a card problem, unless my cards are broken... I'll report here ASAP, thank you very much, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] to record or not
On 2/2/07, martin [EMAIL PROTECTED] wrote: You should have a look at the BigPatch. It has some switch timer included. It sounds like we can just extract this feature out of the BigPatch. Has anyone tried that? The entire BigPatch sounds a little scary, but I too would like to try the one feature from it. :) Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Feature Request: 10 Second Jump from BigPatch, switch timer
To be honest, i use BigPatch for just one reason. During playback, I can jump 10 sec + / - with the 1 and 3 keys. I can't live without this feature, because jumping 1 Minute is nice, but most of the times way too long. So, actually, adding this 10 seconds jump to the main part, would also help me a lot! Regards, Martin PS: I changed the subject to the eMail, beause we have opened a new topic here. Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stone Gesendet: Samstag, 3. Februar 2007 02:05 An: VDR Mailing List Betreff: Re: [vdr] to record or not On 2/2/07, martin [EMAIL PROTECTED] wrote: You should have a look at the BigPatch. It has some switch timer included. It sounds like we can just extract this feature out of the BigPatch. Has anyone tried that? The entire BigPatch sounds a little scary, but I too would like to try the one feature from it. :) Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
