Re: [vdr] vdr 1.7.4 memory leak?
Am Sonntag, den 12.04.2009, 16:30 +0200 schrieb Klaus Schmidinger: > On 04/12/09 16:20, marti...@embl.de wrote: > > I have setup an HTPC based on oxine + vdr > > It has 2gigs of RAM and another 2gigs of Swap space > > Upon booting it uses about 300megs of RAM. > > > > 5 hours later (running vdr all this time) > > I notice most of the ram is in use. > > > > Is this a known memory leak or a design feature? > > Neither one ;-) > > > If a known memory leak is there a patch for it or we need to wait for 1.7.5? > > I have released version 1.7.5 earlier today. > Please test if it happens with this one, too. > > > top - 16:15:00 up 45 min, 2 users, load average: 1.06, 1.34, 1.45 > > Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie > > Cpu(s): 21.2%us, 2.5%sy, 0.2%ni, 76.2%id, 0.0%wa, 0.0%hi, 0.0%si, > > 0.0%st > > Mem: 1811916k total, 1765156k used,46760k free,15640k buffers > > Swap: 2096472k total, 4972k used, 2091500k free, 1449112k cached > > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 6486 root 20 0 203m 59m 19m S 16 3.4 5:18.98 oxine > > 6699 root 20 0 172m 11m 5680 S 14 0.7 5:06.00 vdr > > 6133 root 20 0 94144 50m 32m S9 2.9 1:21.67 Xorg > > 6721 root 15 -5 000 S2 0.0 0:37.73 cx88[0] dvb > > 6330 root 20 0 63672 2324 1752 S1 0.1 0:16.44 CCcam.x86 > > 6702 root 15 -5 000 S1 0.0 0:12.24 kdvb-ad-0-fe-0 > > 1 root 20 0 3056 1900 576 S0 0.1 0:01.60 init > > I dont' see a problem here. > > Can you post the same info when the problem actually happens? Maybe you can sort it by memory usage (shift + m). Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.4 memory leak?
On Sunday 12 April 2009 17:20:47 marti...@embl.de wrote: > 5 hours later (running vdr all this time) > I notice most of the ram is in use. > > Is this a known memory leak or a design feature? All unused memory being used for caches is not a memory leak. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Possibly corrupt stream for VDR frontends in 1.7.4?
Hi, On Tue, Apr 14, 2009 at 11:31:07AM +0200, alexw wrote: > Hi, > > In your capture file, I can see the PAT insertion have a bad TS > continuity counter. But his should not prevent from getting the PMT and > decoding the stream. > > PID: 0118x continuity errors (PAT) > PID: 97 OK (PMT) > PID: 51111x continuity errors (VIDEO) > PID: 5158x continuity errors (AUDIO) > PID: 18 OK (EIT) > PID: 2687 OK > PID: 2736 OK > PID: 4070 OK > PID: 5663 OK Thanks for the info. > It seems that you are loosing packets from your DVB frontends/receiver. Yes, it looks so. > Is your computer overloaded during the transmission? No, my computer is not overloaded. > Is your DVB card or network card is using shared IRQ? Yes, it looks like it is using shared IRQ's. I have attached a cat /proc/interrupts. > Did you play with the PCI bus latency value? No. > Could you please try the latest VDR version 1.7.5. I have just tried out 1.7.5. It looks like it got a little bit better, but it stil has not solved my problems. > I made some HD h264 streaming tests with a popcorn hour as client device > over a wifi network and the video plays perfectly smooth with the 1.7.5 > VDR version. With version 1.7.4 the video was jerky due to TS error on > video stream. I have tried playing back the stream from 127.0.0.1. The problems are the same. So it has nothing to do with my network card. I will try to remove some of my DVB-Cards and also disable my onboard video card. Maybe it is really a problem with the IRQs. Thanks, Artem gandalf ~ # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 12888914411337786258 18240210 IO-APIC-edge timer 1: 0 13 58134 IO-APIC-edge i8042 4: 42230616 1199 IO-APIC-edge serial 7: 1 0 0 0 IO-APIC-edge 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 102657 89697935682647024913 IO-APIC-fasteoi cx88[0], cx88[0] 18: 83562 70885627779035382382 IO-APIC-fasteoi Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver 19: 33750 28102715365825602839 IO-APIC-fasteoi saa7146 (0), nvidia 20: 1159 6958 22822 49299 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:870 5186 14223 31689 IO-APIC-fasteoi ehci_hcd:usb2, HDA Intel 22: 1362511764611 11889259 42501600 IO-APIC-fasteoi ehci_hcd:usb1 23: 9 40122328 IO-APIC-fasteoi ohci_hcd:usb4 27: 5469 44304 205020 528868 PCI-MSI-edge ahci 28: 57293 40614114404702949035 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC:8139882570818551826192852078 Local timer interrupts RES:10141995513238 110955565177732 Rescheduling interrupts CAL: 15782 5712 16844 13890 Function call interrupts TLB: 31047 54416 56527 42984 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts SPU: 0 0 0 0 Spurious interrupts ERR: 1 MIS: 0 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr directories
Can somebody clarify please. Does vdr need simply a directory of its own for recordings (in my case I have assigned it /media/video/vdr ) or a unique mount point (in which case I would have to repartition since I have a 1TB hard drive mounted on /media/video but have other folders in /media/video (avi, mpg) Will vdr try to go through /media/video/avi (to my dismay if that is the case!) or just /media/video/vdr Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr directories
marti...@embl.de schrieb: > Can somebody clarify please. > Does vdr need simply a directory of its own for recordings (in my case I have > assigned it /media/video/vdr ) > or a unique mount point (in which case I would have to repartition since I > have > a 1TB hard drive mounted on /media/video > > but have other folders in /media/video (avi, mpg) > > Will vdr try to go through /media/video/avi (to my dismay if that is the > case!) > > or just /media/video/vdr > only /media/video/vdr vdr will look on - so no problem for you. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
