Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#9157 closed defect (Fixed)

HD cut list editing devours memory

Reported by: stephen.kuntz@… Owned by:
Priority: minor Milestone: 0.24
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (1)

fe-slim-edit.log (51.6 KB) - added by Bill Meek <keemllib@…> 13 years ago.
mythfrontend -v playback

Download all attachments as: .zip

Change History (14)

comment:1 Changed 13 years ago by robertm

Status: newinfoneeded_new

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

comment:2 Changed 13 years ago by anonymous

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

comment:3 Changed 13 years ago by robertm

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

comment:4 Changed 13 years ago by robertm

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

Changed 13 years ago by Bill Meek <keemllib@…>

Attachment: fe-slim-edit.log added

mythfrontend -v playback

comment:5 Changed 13 years ago by 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

comment:6 Changed 13 years ago by 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.

comment:7 in reply to:  6 Changed 13 years ago by 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.)

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by anonymous

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

comment:11 Changed 13 years ago by anonymous

*can't reproduce this with the latest svn

comment:12 Changed 13 years ago by stuartm

Milestone: unknown0.24
Resolution: Fixed
Status: infoneeded_newclosed
Version: UnspecifiedTrunk Head

comment:13 Changed 13 years ago by stuartm

Reporter: changed from stephen.kuntz@… to stephen.kuntz@…
Note: See TracTickets for help on using tickets.