Opened 12 years ago
Closed 11 years ago
Last modified 11 years ago
#5545 closed defect (fixed)
Mythbackend fills up memory till it crashes (~2GByte VSZ, 700MByte RSS)
| Reported by: | Owned by: | Janne Grunau | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.22 |
| Component: | mythtv | Version: | head |
| Severity: | high | Keywords: | |
| Cc: | danielk@… | Ticket locked: | no |
Description
I have a memory leak on my mythtv. It started when I switched from an old fashion tv (analog) card to a DVB-C card. The amount of memory growth changes between idle and recording. If I am recording the leek is about 5-10x higher then in idle. (In Idle mode mythtv is scanning my channels for EIT data. I do not use any XML grabber as our broadcaster offers 7 Days of EPG on a transport stream.)
I tried to produce vallgrind logs, however I can not keep valgrind running for a long time as it kills the rest of my system: 99% CPU usage during recording -> frameloss and mythweb not working properly.
I hope all needed information is included. If you need any additional info let me know. The problem happens in the 21.fixes branch to. I just switched to trunk in the hope it would be less segnificant there.
Operating System: ================= Gentoo - Pentium 4 (without HT) 1GByte Ram. Kernel - 2.6.24-gentoo-r8 TV-Card - Teratec Cynergy DVB-C Card
g++ -v ====== Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)
MythTV Version ============== Source: Trunk Revision: 17733 Configured with: --prefix=/usr --mandir=/usr/share/man --libdir-name=lib --disable-audio-alsa --disable-altivec --disable-audio-jack --enable-libx264 --enable-glx-procaddrarb --enable-dvb --disable-firewire --disable-lirc --disable-audio-arts --disable-directfb --dvb-path=/usr/include --enable-xv --enable-opengl-vsync --enable-xrandr --enable-x11 --enable-mmx --with-bindings=perl,python --compile-type=debug --tune=i686 --disable-distcc --disable-ccache
Mythfrontend was not running during valgrind test.
I am currently restarting mythbackend with a cron job twice a week to guarantee proper operating. If I keep it open longer it is killed due to extensive memory allocation.
message lissted in kernel-ringbuffer:
"mythbackend[5177]: segfault at 000002ed eip b5177f12 esp a9dfea10 error 4"
VSZ, RSS Statistic is (1 line every full hour):
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mythtv 10319 0.8 5.5 263340 57436 ? Ssl 10:26 0:17 /usr/bin/mythbackend --verb... mythtv 10319 0.4 5.2 260244 54872 ? Ssl 10:26 0:25 /usr/bin/mythbackend --verb... mythtv 10319 0.3 5.0 257548 52020 ? Ssl 10:26 0:31 /usr/bin/mythbackend --verb... mythtv 10319 0.3 4.7 254200 49108 ? Ssl 10:26 0:43 /usr/bin/mythbackend --verb... mythtv 10319 0.3 4.4 251104 45912 ? Ssl 10:26 0:51 /usr/bin/mythbackend --verb... mythtv 10319 0.2 4.1 248008 42660 ? Ssl 10:26 0:57 /usr/bin/mythbackend --verb... mythtv 10319 0.5 19.2 430296 199012 ? Ssl 10:26 2:06 /usr/bin/mythbackend --verb... mythtv 10319 0.2 20.3 433868 211160 ? Ssl 10:26 1:15 /usr/bin/mythbackend --verb... mythtv 10319 0.2 20.3 433868 211168 ? Ssl 10:26 1:26 /usr/bin/mythbackend --verb... mythtv 10319 0.2 20.3 434384 211212 ? Ssl 10:26 1:36 /usr/bin/mythbackend --verb... mythtv 10319 0.5 33.4 587320 346912 ? Ssl 10:26 3:35 /usr/bin/mythbackend --verb... mythtv 10319 0.4 40.5 652888 420360 ? Ssl 10:26 2:49 /usr/bin/mythbackend --verb... mythtv 10319 0.4 52.1 774624 540752 ? Ssl 10:26 3:15 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.8 851948 620480 ? Ssl Jul14 2:34 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.6 852480 618476 ? Ssl Jul14 2:41 /usr/bin/mythbackend --verb... mythtv 10319 0.2 59.4 852480 616228 ? Ssl Jul14 2:48 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 852480 616468 ? Ssl Jul14 3:13 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 852480 616468 ? Ssl Jul14 3:20 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 852480 616468 ? Ssl Jul14 3:26 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 852480 616468 ? Ssl Jul14 3:36 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 852480 616476 ? Ssl Jul14 3:43 /usr/bin/mythbackend --verb... mythtv 10319 0.2 59.5 852480 616492 ? Ssl Jul14 3:49 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853128 616652 ? Ssl Jul14 4:11 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853128 616652 ? Ssl Jul14 4:18 /usr/bin/mythbackend --verb... mythtv 10319 0.2 59.5 853264 616680 ? Ssl Jul14 4:24 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853264 616740 ? Ssl Jul14 4:45 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853396 616824 ? Ssl Jul14 5:08 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853396 616880 ? Ssl Jul14 5:13 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853532 616944 ? Ssl Jul14 5:22 /usr/bin/mythbackend --verb... mythtv 10319 0.3 59.5 853532 617048 ? Ssl Jul14 5:40 /usr/bin/mythbackend --verb... mythtv 10319 0.3 71.4 997060 739780 ? Ssl Jul14 6:46 /usr/bin/mythbackend --verb... mythtv 10319 0.3 71.9 1000956 745716 ? Ssl Jul14 5:54 /usr/bin/mythbackend --verb...
Attachments (11)
Change History (31)
Changed 12 years ago by
| Attachment: | logfile.13119.gz added |
|---|
Changed 12 years ago by
| Attachment: | logfile.15127.gz added |
|---|
Changed 12 years ago by
| Attachment: | logfile.17491.gz added |
|---|
Changed 12 years ago by
| Attachment: | mythtv-day.png added |
|---|
comment:1 Changed 12 years ago by
comment:2 Changed 11 years ago by
I had this same thing happen on my machine (Core 2 Duo x86_64). Was watching live TV, everything was fine for a while, but after a scheduled recording completed, a subsequent recording did not occur. At this point, I lost keyboard/remote control, and noticed my memory usage was skyrocketing. I have 4G of RAM. System at idle, watching live TV, mythfrontend normally uses approximately 5.4% of RAM, but at the time this was going on, usage was at 51% and climbing rapidly. I had to kill the frontend and bounce the backend to get things to recover.
comment:4 Changed 11 years ago by
Sorry, one other detail. My CPU usage for mythfrontend went from it's usual 14% to 38%
Changed 11 years ago by
| Attachment: | trimmed_logfile.txt added |
|---|
Uncompressed and cutdown copy of the valgrind log
comment:5 Changed 11 years ago by
| Milestone: | unknown → 0.22 |
|---|---|
| Severity: | medium → high |
Same valgrind log we keep seeing for this issue.
comment:6 Changed 11 years ago by
| Cc: | danielk@… added |
|---|
hmm, this is definitely a PES packet we're keeping too long. Since you say this goes up when you are not collecting EIT it must be a PAT/PMT or NIT/SDT table.
comment:7 Changed 11 years ago by
I built a fresh svn checkout of mythtv-fixes on 11 october 2008. I installed it on the 12th of october. Some early figures:
%CPU %MEM VSZ RSS TTY STAT START TIME
8.9 11.2 435760 108728 ? Ssl Oct12 122:07 9.2 14.3 466100 139272 ? Ssl Oct12 259:58 9.4 15.7 480016 152884 ? Ssl Oct12 399:55 9.6 17.5 497020 170316 ? Ssl Oct12 547:57 9.6 18.6 508312 181476 ? Ssl Oct12 688:08 9.7 20.0 521500 194544 ? Ssl Oct12 837:01
It still keeps on growing....
Just 1 Terratec Cinergy 1200 DVB-T card with 7 virtual tuners of which 3 are more or less 24/7 recording 3 TV channels off of one multiplex. Back to back programs overlap 2 minutes max (1 minute at begin, 1 minute at the end). The machine has 1GB of RAM and is running on a VIA Epia EN12000.
# mythbackend --version Please include all output in bug reports. MythTV Version : exported MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:
linux release using_alsa using_backend using_dbox2 using_dvb using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live
comment:8 Changed 11 years ago by
If there is anything I can do to help localizing the leak please let me know.
My email address is leak...a...t...anticat.ch.
comment:9 Changed 11 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Should be fixed by [19226]
comment:10 Changed 11 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
no, this leak is unrelated to [19226]
comment:11 Changed 11 years ago by
| Owner: | changed from Isaac Richards to Janne Grunau |
|---|---|
| Status: | new → assigned |
Thanks, janne!
Changed 11 years ago by
| Attachment: | valgrind3-5min.log.gz added |
|---|
Full Valgrind Log of 5min Recording
comment:12 Changed 11 years ago by
I have currently a spare Core2Duo machine. I made a test setup for mythtv with valgrind. The System is setup using mythubuntu 8.10 with latest weekly build of mythtv.
MythTV Version : 19626 MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in: linux profile using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_glx_proc_addr_arb using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live
I still have the usual memory growth of about 100MB per Hour. I did a 1hour recording and a 5minute recording, both with valgrind running. As it is a test setup without any personal data on the machine I offer to put the machine into a dedicated subnet accessible from the internet and pass the login to a developer if it helps to figure out the source for the memory growth.
comment:13 Changed 11 years ago by
Probably the important bits of these logs:
Short recording:
==7204== 11,534,336 bytes in 22 blocks are still reachable in loss record 778 of 778 ==7204== at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==7204== by 0x4373501: pes_alloc(unsigned) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x43960BC: PESPacket::PESPacket(PESPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x43941A1: MPEGStreamData::AssemblePSIP(TSPacket const*, bool&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x43948E1: MPEGStreamData::HandleTSTables(TSPacket const*) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x438C507: MPEGStreamData::ProcessTSPacket(TSPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x438531D: MPEGStreamData::ProcessData(unsigned char const*, int) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x4850CEC: DVBStreamHandler::RunTS() (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x48522DD: DVBStreamHandler::Run() (in /usr/lib/libmythtv-0.21.so.0.21.0) ==7204== by 0x631A7ED: clone (in /lib/tls/i686/cmov/libc-2.8.90.so)
Long recording:
==6691== 147,324,928 bytes in 281 blocks are still reachable in loss record 791 of 791 ==6691== at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==6691== by 0x4373501: pes_alloc(unsigned) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x43960BC: PESPacket::PESPacket(PESPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x43941A1: MPEGStreamData::AssemblePSIP(TSPacket const*, bool&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x43948E1: MPEGStreamData::HandleTSTables(TSPacket const*) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x438C507: MPEGStreamData::ProcessTSPacket(TSPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x438531D: MPEGStreamData::ProcessData(unsigned char const*, int) (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x4850CEC: DVBStreamHandler::RunTS() (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x48522DD: DVBStreamHandler::Run() (in /usr/lib/libmythtv-0.21.so.0.21.0) ==6691== by 0x631A7ED: clone (in /lib/tls/i686/cmov/libc-2.8.90.so) ==6691==
comment:14 Changed 11 years ago by
| Status: | assigned → accepted |
|---|
Please run valgrind with t5545.diff applied. It should at least make the leak smaller.
I suspect that we might read a PID with video data as PSIP. That's at least the only way I can explain PES packets larger than 65536 bytes.
Changed 11 years ago by
| Attachment: | t5545_debug_1.diff added |
|---|
comment:15 Changed 11 years ago by
Your patch did not produce any additional output on my system. So I also addad an else statement to doublecheck if the debug output was working. Result:
... 2009-01-14 10:56:01.602 Allocating a 3844 byte PES packet successful 2009-01-14 10:56:01.603 Allocating a 3844 byte PES packet successful 2009-01-14 10:56:01.603 Allocating a 3844 byte PES packet successful 2009-01-14 10:56:01.604 Allocating a 3844 byte PES packet successful 2009-01-14 10:56:01.606 Allocating a 3844 byte PES packet successful ...
I alterd the patch a little bit to also catch the other memory allocations. Result:
2009-01-14 18:23:44.043 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:23:44.134 static unsigned char* get_188_block() -> Allocating a 512*188 byte blocks 2009-01-14 18:23:56.069 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:24:08.030 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:24:20.449 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:24:34.210 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:24:46.950 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:24:58.720 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:25:12.089 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:25:25.770 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:25:37.789 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:25:49.919 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:26:03.640 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:26:16.721 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:26:28.430 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:26:41.540 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:26:55.230 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:27:07.529 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:27:19.300 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks 2009-01-14 18:27:33.140 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
a lot of allocations but never a free
Changed 11 years ago by
| Attachment: | t5545_debug_2.diff added |
|---|
Changed 11 years ago by
| Attachment: | t5545_debug_3.diff added |
|---|
comment:16 Changed 11 years ago by
Note 1: The patched line 322 and 325 conflicts during compile. I removed one case/break. this leads to NIT and NITo having the same value.
Note 2: My test machine is configured for MythtTV 0.21 with QT3. I had to rename on line 344 it.value() to it.data()
short time after start
1025 4096 blocks remain 1004 NIT, 1004 NITo, 0 other 10 NITs with network id 1 21 NITs with network id 2 21 NITs with network id 3 21 NITs with network id 4 20 NITs with network id 5 20 NITs with network id 6 20 NITs with network id 100 21 NITs with network id 139 21 NITs with network id 201 21 NITs with network id 202 21 NITs with network id 203 21 NITs with network id 204 21 NITs with network id 205 19 NITs with network id 206 19 NITs with network id 207 18 NITs with network id 273 19 NITs with network id 274 19 NITs with network id 275 20 NITs with network id 277 20 NITs with network id 298 20 NITs with network id 299 20 NITs with network id 300 20 NITs with network id 301 20 NITs with network id 317 20 NITs with network id 400 20 NITs with network id 401 20 NITs with network id 402 20 NITs with network id 403 20 NITs with network id 404 20 NITs with network id 410 20 NITs with network id 433 20 NITs with network id 480 20 NITs with network id 502 20 NITs with network id 600 20 NITs with network id 601 20 NITs with network id 602 20 NITs with network id 603 20 NITs with network id 604 10 NITs with network id 605 20 NITs with network id 735 20 NITs with network id 800 20 NITs with network id 860 20 NITs with network id 880 20 NITs with network id 888 20 NITs with network id 890 20 NITs with network id 891 20 NITs with network id 892 20 NITs with network id 910 20 NITs with network id 920 20 NITs with network id 942 21 NITs with network id 990
after ~15min
8193 4096 blocks remain 8172 NIT, 8172 NITo, 0 other 82 NITs with network id 1 164 NITs with network id 2 164 NITs with network id 3 164 NITs with network id 4 163 NITs with network id 5 163 NITs with network id 6 163 NITs with network id 100 164 NITs with network id 139 164 NITs with network id 201 164 NITs with network id 202 164 NITs with network id 203 164 NITs with network id 204 164 NITs with network id 205 162 NITs with network id 206 162 NITs with network id 207 162 NITs with network id 273 163 NITs with network id 274 163 NITs with network id 275 164 NITs with network id 277 164 NITs with network id 298 164 NITs with network id 299 164 NITs with network id 300 164 NITs with network id 301 164 NITs with network id 317 164 NITs with network id 400 164 NITs with network id 401 164 NITs with network id 402 164 NITs with network id 403 164 NITs with network id 404 164 NITs with network id 410 164 NITs with network id 433 164 NITs with network id 480 163 NITs with network id 502 163 NITs with network id 600 163 NITs with network id 601 163 NITs with network id 602 163 NITs with network id 603 163 NITs with network id 604 82 NITs with network id 605 163 NITs with network id 735 163 NITs with network id 800 163 NITs with network id 860 163 NITs with network id 880 163 NITs with network id 888 163 NITs with network id 890 163 NITs with network id 891 163 NITs with network id 892 163 NITs with network id 910 163 NITs with network id 920 163 NITs with network id 942 164 NITs with network id 990
I hope the output helps. If you prefare full files i can attatch them.
comment:17 Changed 11 years ago by
32769 4096 blocks remain 32755 NIT, 32755 NITo, 0 other 327 NITs with network id 1 655 NITs with network id 2 655 NITs with network id 3 655 NITs with network id 4 655 NITs with network id 5 655 NITs with network id 6 655 NITs with network id 100 655 NITs with network id 139 655 NITs with network id 201 655 NITs with network id 202 655 NITs with network id 203 655 NITs with network id 204 655 NITs with network id 205 655 NITs with network id 206 655 NITs with network id 207 655 NITs with network id 273 655 NITs with network id 274 655 NITs with network id 275 655 NITs with network id 277 654 NITs with network id 298 654 NITs with network id 299 654 NITs with network id 300 654 NITs with network id 301 654 NITs with network id 317 654 NITs with network id 400 655 NITs with network id 401 655 NITs with network id 402 655 NITs with network id 403 655 NITs with network id 404 655 NITs with network id 410 654 NITs with network id 433 654 NITs with network id 480 656 NITs with network id 502 656 NITs with network id 600 656 NITs with network id 601 656 NITs with network id 602 656 NITs with network id 603 656 NITs with network id 604 327 NITs with network id 605 656 NITs with network id 735 656 NITs with network id 800 656 NITs with network id 860 656 NITs with network id 880 656 NITs with network id 888 656 NITs with network id 890 656 NITs with network id 891 656 NITs with network id 892 655 NITs with network id 910 655 NITs with network id 920 655 NITs with network id 942 655 NITs with network id 990
Changed 11 years ago by
| Attachment: | t5545_fix1.diff added |
|---|
comment:18 Changed 11 years ago by
| Status: | accepted → started |
|---|
t5545_fix1.diff hopefully fixes the issue
The DVB tables have all empty destructors but since the data gets copied in the constructor they all would leak memory. Since we keep track of all the tables except of the NIT other the leak is rather small if no NIT others are transmitted.
comment:19 Changed 11 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | started → closed |
(In [19705]) implement DVBStreamData::DeleteCachedTable? to properly delete cached NITs and SDTs
it needs to be implemented in ScanStreamData? too due to multiple inheritance Fixes #5545
comment:20 Changed 11 years ago by
(In [19706]) backports [19705] from trunk. Refs #5545
implement DVBStreamData::DeleteCachedTable? to properly delete cached NITs and SDTs it needs to be implemented in ScanStreamData? too due to multiple inheritance
I experience similar (but not so extreme) growths of memory. I us e Terratec Cinergy 1200 DVB-T card with multirec to record three SD TV channels 24/7. Recently I started using EIT for soem radio channels besides the XMLTV based TV channels.
My stats so far: # cat /home/udo/psmyth.txt |cut -b16-65 %CPU %MEM VSZ RSS TTY STAT START TIME
I had a small crash of the backend at the empty line. I can not reliably run valgrind on the VIA EN12000 board: mythbackend gives strange errors and does not run well.
# mythfrontend --version Please include all output in bug reports. MythTV Version : exported MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in: