HD cut list editing devours memory

[stephen.kuntz@…]

When editing an HD cut list the memory that is consumed is not release when show exiting back to the menu. If editing multiple shows all memory is consumed and swapping starts to happen to the point where mythfrontend reports it has insufficient resources. Memory is only released after exiting mythfrontend.

I have 6G of memory and can edit ~4 1/2 hour shows (approx 4.8G each) before my system crawls and I need to restart mythfrontend.

[robertm]

Using VDPAU? What happens if you use GL or Xv? If the issue disappears, almost definitely a dupe of #9144.

[anonymous]

I've tried both with VDPAU and using the CPU++ setting. Both yield the same result.

[robertm]

Please provide -v playback logs when using the (default, NON VDPAU) Slim playback profile and triggering this issue. Thanks.

[robertm]

Also, please perform this test with current trunk (perform an update before gathering logs)

[Bill Meek <keemllib@…>]

mythfrontend -v playback

[Bill Meek <keemllib@…>]

Test script: Reboot, start system monitor, mythfrontend -v playback, record memory usage, exit FE, save log, restart FE and change DefaultVideoPlaybackProfile? via GUI for next test.

Cutlist had already been loaded and saved.

The same recording was used in both cases, HD "Blue Bloods."

1st column is for Slim (Not VDPAU) , 2nd column is for VDPAU Normal. All memory is megabytes used.

Slim    VDPAU
Memory  Memory  Recorded memory used:
514.1   514.6   Before <return> to start playback
562.9   667.1   About 10s into playback
566.4   853.0   After: e (edit), right arrow (10 times), e
538.6   824.5   ESC to exit playback

2.6.35-22, Ubuntu 10.10, AMD 64 X2 6000+, Terra, NVIDIA X Driver = 260.19.06

Please attach all output as a file in bug reports.
MythTV Version   : 27055M
MythTV Branch    : trunk
Network Protocol : 63
Library API      : 0.25.20101028-1
QT Version       : 4.7.0
Options compiled in:
 linux debug using_alsa using_jack using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_dvb using_frontend using_iptv using_ivtv using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[robertm]

Bill, are you the reporter? The above results seems to bear out my suspicion that this is a VDPAU issue. I am looking for a log from the original reporter with the Slim playback profile, having triggered the issue. If you are seeing an issue with Slim, then this log may still be valid, but your memory figures for Slim look totally appropriate.

[Bill Meek <keemllib@…>]

Replying to robertm:

Bill, are you the reporter?

I'm not and only ever used Slim for the test above. Sorry, won't add more (unless asked.)

[Phil]

I was having the same problem with 0.24-rc1, where MythTV would start using all 4GB of RAM within 30 seconds of beginning to edit a cut list (both with VDPAU Normal and VDPAU Slim).

However, I updated trunk to [27076] today and haven't had any issues so far. Whatever was causing this seems to be fixed.

[robertm]

Guys, appreciate the updates (and the possibility that this is fixed) but I really need the *original reporter* to report back, as he contends the issue is present with the Slim profile, and if that's true then there could be a bug he haven't seen (versus the VDPAU specific one with certain driver versions). Leaving this infoneeded with an explicit request that *only* the original reporter produce logs, or at the very least that whomever is seeing this produce logs with the Slim, non-VDPAU profile.

Stephen, if I do not see logs *from you* in the next day or two, I will be closing this ticket as a dupe.

[anonymous]

This is the original reporter... I can reproduce this with the latest svn.

[anonymous]

*can't reproduce this with the latest svn