Jason Tackaberry wrote:
> On Mon, 2009-01-26 at 19:50 +0100, Duncan Webb wrote:
>> The first stop-stopper is that the CPU usage is very high when freevo is
>> idle.
>>
>> Wonder if anyone knows how to find out what the problem could be?
>> Profiling the code also crashes, so that didn't help much.
>
> There's no substitute for a well placed print call :)
:-0 I've added the benchmarking code to the functions in main and osd,
doesn't show any surprises there.
Next step is to remove all the plug-ins, now the main menu is just 'TV'
and there are no other plug-ins except rom_drives that are running.
The CPU is running at 80% which is way to much.
> strace _might_ give you some clues. At the very least, if you see
> excessive calls to select, you know the main loop is stepping quite a
> lot, which probably means you have a very low duration timer running.
The poll time is set to 200 ms, which is much higher than I would
normally use (50 ms).
Looks like there are rather a lot of calls to:
futex(futex(0x81996e0, FUTEX_WAKE, 1) = 0
And rather a lot of calls to the skin code. This tends to imply that the
skin code is redrawing itself continuously rather than once in a while.
After adding some benchmarking code to the skins/main/main and
skins/main/view_area they are not showing what is looping so hard.
> It might then be helpful to add some debug lines to kaa's nf_generic.py
> to see what timers are getting invoked and how often.
>
> You could also try disabling your KeyboardInterrupt handler and let it
> bubble up uncaught, and then hit ctrl-c when it starts sucking cpu and
> see if anything informative shows up in the traceback.
It's sucking CPU all the time, well up to 95% during start-up, this is
normal.
I reckon this problem is going to be quite tricky to find.
>> The next problem is that the HTMLParser is not as robust as with
>> Python-2.4 or Python-2.5. This means that the IMDB searches tend to
>> cause a crash.
>
> The difference between 2.5 and 2.6 HTMLParser isn't much. In fact,
> doing diff on the two versions, the only change is with the unescape()
> method, and to me it looks like the 2.6 version is more
> feature-complete.
>
> Are you seeing tracebacks in unescape()? If not, the crashes might be
> caused by something else.
I'm pretty sure this is Python-2.6 related as it works fine with
Python-2.4 and Python-2.5
Traceback (most recent call last):
File "/sources/svn/freevo-1/rel-1/freevo/src/util/fxdimdb.py", line
815, in parsesearchdata
soup = BeautifulSoup(results.read(), convertEntities='xml')
File "/usr/lib/python2.6/site-packages/BeautifulSoup.py", line 1499,
in __init__
BeautifulStoneSoup.__init__(self, *args, **kwargs)
File "/usr/lib/python2.6/site-packages/BeautifulSoup.py", line 1230,
in __init__
self._feed(isHTML=isHTML)
File "/usr/lib/python2.6/site-packages/BeautifulSoup.py", line 1263,
in _feed
self.builder.feed(markup)
File "/usr/lib/python2.6/HTMLParser.py", line 108, in feed
self.goahead(0)
File "/usr/lib/python2.6/HTMLParser.py", line 148, in goahead
k = self.parse_starttag(i)
File "/usr/lib/python2.6/HTMLParser.py", line 226, in parse_starttag
endpos = self.check_for_whole_start_tag(i)
File "/usr/lib/python2.6/HTMLParser.py", line 301, in
check_for_whole_start_tag
self.error("malformed start tag")
File "/usr/lib/python2.6/HTMLParser.py", line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParseError: malformed start tag, at line 297, column 62
A workaround is to use html5lib, that will parse the data correctly. By
capturing the output to a file and running it through "tidy" and then
feeding it to BeautifulSoup it works fine.
Duncan
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
