[mythtv] [mythtv-commits] Ticket #1381: Slow keyboard response over

mythtv at zacglen.com.au mythtv at zacglen.com.au
Sun Feb 26 04:50:29 UTC 2006


>> >> >We might be waiting for a while.  There's no such select() (or similar
>> >> > stuff)
>> >> >
>> >> >in the code that could be causing that. =)
>> >>
>> >> Yes, there is.
>> >> Try an strace and find out the *truth*.
>> >>
>> >> Anyone who has done any programming (like myself) will know
>> >> that QEventLoop()::exec invokes select().
>> >
>> >I didn't realize that I had to specifically put "in mythtv" in that
>> > sentenc e,
>> >
>> >since this is the mythtv mailing list & bug tracker and not the Qt one.
>> >
>> >Silly me.
>> >
>> >> This is probably a major top-level design error.
>> >
>> >That only happens to a few people?  That's highly doubtful.
>>
>> Really? So top level design flaws always immediate manifest themselves
>> and are instantly corrected?
>
>A 'major top-level design error' would generally be happening to more than 
>2 
>
>people.  You're 0 for 3 so far in coming up with ideas as to this 'major 
>
>design' issue.
>
>> Anyhow, for all those doubters out there, here are some stack traces.
>>
>> A)
>> #0  0x05449490 in select () from /lib/libc.so.6
>> #1  0x07173b68 in QEventLoop::processEvents () from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2  0x071e222b in QEventLoop::enterLoop
>> () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #3  0x071c94cf in
>> QApplication::enter_loop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #4 
>
>> 0x045a750d in MythDialog::exec () from /usr/lib/libmyth-0.19.so.0 #5 
>
>> 0x0806497d in RunMenu (themedir=@0xbfd2b100) at main.cpp:498
>> #6  0x0806c93a in main (argc=1, argv=0xbfd2b1b4) at main.cpp:1062
>
>Wow, look at that, a select() in Qt.  How's that mean it's a 'major top-lev
>el 
>
>design error' in mythtv, again?  I'm confused, please explain.  Remember, y
>ou 
>
>said:
>
>"But isn't is quite possible that there is some flakey code which is causin
>g 
>
>keystroke events to only be processed after the select() times out?"
>
>To which the answer was, and still is: 'no, it's not possible, since no suc
>h 
>
>code exists in mythtv.'  This doesn't mean that 'there are no selects() use
>d 
>
>anywhere, ever, when running mythtv'.  That would just be stupid, and 
>
>interpreting that statement like that, which you've apparently chosen to do
>, 
>
>is even sillier.
>
>Yes, Qt uses a select() to know when to wake up and process events.  This h
>as 
>
>absolutely nothing to do with the code, or the design of code, in myth 
>
>itself.  If you believe there is a bug in that part of Qt, which is _ever_ 
>so 
>
>slightly doubtful, take it up with Trolltech, not us.

Ok, so in your view everything is _ever_ so slightly doubtful.
In your world there is no bug in MythTV, and none in Qt either.
I am very happy for you.

>
>> B)
>>
>> > #0  0x05449490 in select () from /lib/libc.so.6
>> > #1  0x07450f48 in QSocketDevice::waitForMore () from
>> > /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2  0x0478db0d in SipFsm::CheckRxEvent
>> > () from /usr/lib/mythtv/plugins/libmythphone.so #3  0x047911e2 in
>> > SipThread::CheckNetworkEvents () from
>> > /usr/lib/mythtv/plugins/libmythphone.so #4  0x04792b27 in
>> > SipThread::SipThreadWorker () from
>> > /usr/lib/mythtv/plugins/libmythphone.so #5  0x04792fbb in SipThread::run
>> > () from /usr/lib/mythtv/plugins/libmythphone.so #6  0x071c2378 in
>> > QThreadInstance::start () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #7 
>
>> > 0x00373947 in start_thread () from /lib/libpthread.so.0
>> > #8  0x054502ce in clone () from /lib/libc.so.6
>
>Wow, another select(), but lookithat, it's in a separate thread that has 
>
>nothing to do with input processing.  Crazy, that.

Here you go again! "Nothing to do with input processing".
Everything that runs on same CPU can affect input processing!
Try running:
	dd if=/dev/zero of=/file1 &
	dd if=/dev/zero of=/video/file2 &
Then check your keystroke response time.

But I am very pleased that I have wowed you and sent you crazy.

>
>Might as well point out the joystick code's select() too, but <gasp> that's 
>
>also happening in a separate thread and won't impact keypress processing at 
>
>all, either.

Rubbish.
Just because something is running in another thread doesn't insulate
it from affecting any other thread.
Anybody who has written a program would know that.
It depends entirely on what your stupid threads are up to - and
what other threads they might be blocking.

I cannot believe how ignorant some so-called developers can be!

>
>> Goodness knows what the 'mythphone' stuff is trying to do - call home
>> I suppose. I have it disabled so why doesn't it just close itself and die?
>
>You don't have it disabled, since it's obviously running and installed.  
>
>Remove the plugin to disable it.  I never got around to making a way to 
>
>disable a plugin aside from not installing it.

It is already disabled.

>
>> Anyhow I figure that there might be excessive traffic from creating
>> new pixmaps when a menu selection highlighting needs to change.
>> But shouldn't they already exist as offscreen pixmaps?
>> That would certainly be much more efficient, not to mention faster.
>
>All the pixmaps for the menus are loaded + scaled when the menu xml files a
>re 
>
>parsed at the start of the program, or when the user changes something in t
>he 
>
>appearance settings.  All it does when the current selection changes is dra
>w 
>
>different stuff (which, incidentally, can be fairly slow depending on your 
>
>chosen resolution, what theme you're using, and if your X server has limite
>d 
>
>amounts of accel for blending pixmaps).  It only redraws the section of the 
>
>screen that's needed, as well.  You might want to try actually looking at t
>he 
>
>source to see what it's doing.  It's not like profiling stuff like this is 
>
>difficult.
>

I have decided to drop MythTv because it seems to be essentially reinventing
the wheel.  Besides a scheduler which knows how to assign non-overlapping
events to hardware, all interfacing can just as easily be done
via a browser.

And the advantages a browser has are:

a) They already exist and are well tested and relatively bug-free.
b) A remote client can do big fonts with minimum of HTML coding.
c) It kills two birds with one stone - true media convergence (non-myth).
d) I am sure there are plenty more reasons.

Besides, I can also arrange for the recorded files to be in whatever
format I wish, with/without any processing of my choosing.

Additionally I can totally avoid a database and use a simple filesystem
based scheme. I have already drawn on up on the back of an envelope.
I prefer configurations to be in plain files anyhow.

Have a nice development experience.
Bye.



More information about the mythtv-dev mailing list