Niklas Brunlid wrote:
> 2008/1/24 Roger Heflin <[EMAIL PROTECTED]>:
>> MVallevand wrote:
>>> On Jan 23, 2008 1:29 PM, Roger Heflin <[EMAIL PROTECTED]> wrote:
>>>
>>>> The basic startup of mvpmc uses about 8-8.5M, I am not sure where
>>>> all of that comes from, the code and shared libraries come to
>>>> about 4M (2.7 exe, 1.2M shared libs).
>>> You're not seeing the first 4M bank with the wrapper filesystem.
>>>
>>> Martin
>> /proc/meminfo says there is 14M of ram that the kernel sees, so how
>> much does the device actually have?
>>
>> What exactly is the wrapper filesystem?
>>
>> At bootup I see about 8-8.5MB show by ps as being used by mvpmc,
>> with 400-500kb free, and with about 3M tied up in buffers.
>>
>> About 1M is tied up in the tmpfs for /live/memory.
>>
>> It looks like one could either just load the top level categories
>> in the menu, and discard everything else, and then when one goes
>> down a level again load just the entries that are needed there,
>> and discard the rest, and this would reduce the amount of ram
>> required to hold large numbers of recordings, but would increase
>> the network traffic ( and probably time) needed to produce
>> the next menu, but would work for larger number of recordings.
>>
>> If I understand what is happening, one thread has a full listing
>> of the recordings while a delete is happening, and then a update
>> comes in and another copy starts being made, and before that finishes
>> another refresh happens and a 3rd copy comes in, and it just does
>> not have the ram to deal with all of them, but would eventually clean
>> everything up given enough time.
>>
>> Maybe the solution is to either in the delete to save the info to
>> delete the show, and then remove the program info before doing the
>> delete so that there is enough space for the new info that will show
>> up on the refresh (after the delete), or maybe the solution could also be
>> to temporarily delay/stop the callback event for the update when doing
>> a delete and call that callback after the delete is done, it very
>> much looks like the update callback and the delete are interacting
>> in a very bad way. Mine only fails if I do several deletes quickly,
>> someone else (with around 800+ recordings) reports that delete always
>> messes things up.
>>
>> Comments, Ideas? I have a full git here, and can build my own
>> dongles, and can duplicate the problem, does the problem sound
>> right? And what about the possible solution?
>
> Hi,
>
> Sorry for replying so late, kinda forgot about this thread... :)
>
> Anyway, I just got a H3 wireless MVP and am seing the same problems
> (not just when deleting). I'm up to 1900 movies/episodes on my MythTV
> backend and moving around in the mvpmc menus is an excersice in
> patience... selecting MythTV->Watch Recordings takes a long time to
> end up in a usable state.
I am up to 720 and so far it is not that bad.
I have noticed that it takes 3-5 seconds to load the shows, I am wondering if
it
would be faster to read in from a binary file located on NFS that contained
the show data, or put a binary file on NFS that at least contains the more
troublesome data and retrieve it as necessary (when one selects show info).
From some looking around with the current method that mvpmc uses it is not
possible to grab a single recording's information. It may be possible if we
were using the xml method that is in the 0.21 and newer myth, and then it would
be possible to not load/ignore the information that is not often used and
retrieve as necessary.
Here is the current proginfo structure:
struct cmyth_proginfo {
char *proginfo_title;
char *proginfo_subtitle;
char *proginfo_description;
char *proginfo_category;
long proginfo_chanId;
char *proginfo_chanstr;
char *proginfo_chansign;
char *proginfo_channame; /* Deprecated in V8, simulated for compat. */
char *proginfo_chanicon; /* New in V8 */
char *proginfo_url;
long long proginfo_Length;
cmyth_timestamp_t proginfo_start_ts;
cmyth_timestamp_t proginfo_end_ts;
unsigned long proginfo_conflicting; /* Deprecated in V8, always 0 */
char *proginfo_unknown_0; /* May be new 'conflicting' in V8 */
unsigned long proginfo_recording;
unsigned long proginfo_override;
char *proginfo_hostname;
long proginfo_source_id; /* ??? in V8 */
long proginfo_card_id; /* ??? in V8 */
long proginfo_input_id; /* ??? in V8 */
char *proginfo_rec_priority; /* ??? in V8 */
long proginfo_rec_status; /* ??? in V8 */
unsigned long proginfo_record_id; /* ??? in V8 */
unsigned long proginfo_rec_type; /* ??? in V8 */
unsigned long proginfo_rec_dups; /* ??? in V8 */
unsigned long proginfo_unknown_1; /* new in V8 */
cmyth_timestamp_t proginfo_rec_start_ts;
cmyth_timestamp_t proginfo_rec_end_ts;
unsigned long proginfo_repeat; /* ??? in V8 */
long proginfo_program_flags;
char *proginfo_rec_profile; /* new in V8 */
char *proginfo_recgroup; /* new in V8 */
char *proginfo_chancommfree; /* new in V8 */
char *proginfo_chan_output_filters; /* new in V8 */
char *proginfo_seriesid; /* new in V8 */
char *proginfo_programid; /* new in V12 */
cmyth_timestamp_t proginfo_lastmodified; /* new in V12 */
char *proginfo_stars; /* new in V12 */
cmyth_timestamp_t proginfo_originalairdate; /* new in V12 */
char *proginfo_pathname;
int proginfo_port;
unsigned long proginfo_hasairdate;
char *proginfo_host;
unsigned long proginfo_version;
char *proginfo_playgroup; /* new in v18 */
char *proginfo_recpriority_2; /* new in V25 */
long proginfo_parentid; /* new in V31 */
char *proginfo_storagegroup; /* new in v32 */
unsigned long proginfo_audioproperties; /* new in v35 */
unsigned long proginfo_videoproperties; /* new in v35 */
unsigned long proginfo_subtitletype; /* new in v35 */
};
24 char *'s
26 longs/ints/timestamps (I don't know if these are different lengths).
So about 200 bytes per program before anything is allocated to any of the char
*. If something is allocated to the char *'s then there are a number of
bytes
for the reference counters for overhead for each allocation, plus the bytes
allocated.
I suspect that a number of the entries aren't used anywhere except show_info
and
a number of the entries even if they are used in show_info aren't of any use to
a person so could probably be ignored.
I need to figure out a way to gauge how much memory is being used so I can get
an idea of how much is being saved.
>
> Also, watching recordings through the MythTV interface simply doesn't
> work when I use the wireless network - if I start to watch something
> it takes a few minutes until anything appears, and then only in short
> bursts. I can see on the router lights and statistics that only a few
> packets every few seconds are actually transmitted...
> However, if I watch the same recording by selecting the .mpg file
> through the file browser it plays just fine, and I can see that the
> wireless traffic flows perfectly. Could this be because there is much
> more free (and less fragmented) memory when playing that way?
I don't know about the wireless part.
>
> Finally, I wanted to ask if anything came from this discussion. Did
> anyone manage to test the proposed changes? If not, how long does it
> take to get to the point where I can play around with the code myself?
> I make my living as a codemonkey but haven't done much private coding
> in years except for a few private hacks in mythfilldatabase...
>
> / Niklas (op)
>
There are instructions someplace about what it takes to setup the development
git environment.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
