[mythtv] MythSocket class
John P Poet
jppoet at gmail.com
Sun May 28 15:32:43 UTC 2006
On 5/28/06, John P Poet <jppoet at gmail.com> wrote:
> On 5/27/06, Isaac Richards <ijr at case.edu> wrote:
> > On Monday 01 May 2006 10:59 pm, Jim Westfall wrote:
> > > Jim Westfall <jwestfall at surrealistic.net> wrote [04.19.06]:
> > > > I wasnt able to reproduce the slave backend issue in testing. I have an
> > > > updated patch I will try and get submitted this weekend. It addresses
> > > > the backend worker thread hack and expands the conversion to include
> > > > mythcontext and a few other classes that use QSocket[Device].
> > >
> > > Here is the updated version.
> > >
> > > I ended up stripping out QSocketNotifier and replaced it with an internal
> > > thread to monitor the socket. The thread will only be started if
> > > callbacks are setup. I setup the callbacks to be similar to how daniel
> > > did them with streamlisteners. It should be possible to ditch qobject
> > > once something is done with the background connect() code.
> > >
> > > On the backend I removed all the worker thread code and am letting the
> > > MythSocket thread handle processing the requests via the readyRead
> > > callback. There are still a few things that need to be worked out. Each
> > > new thread costs 7-10megs of memory and there is a 30 second delay when
> > > deleting playback objects. This can lead to large memory usage if someone
> > > is triggering alot of file transfers (ie xfering png images, while
> > > browsing recorded list). There is also no limit on the number of threads
> > > that can concurrently be processing requests, this was mostly limited to
> > > 5 before with the worker threads.
> > I've updated this patch to take care of the remaining issues Jim outlined
> > above (one thread to do all the select()ing, and keep the threadpool in the
> > backend around for processing). I'd appreciate testers - I don't have a
> > slave backend (and can't easily set one up) to test against. I'd like to
> > commit this next weekend, if possible. Things seem to work pretty well,
> > though, from what I can see.
> > mythsocket4.diff was generated against revision 10051, and you'll need
> > something fairly recent for it to work.
> > Isaac
> I grabbed version 10051 and applied these patches. I then started up
> recordings on most of my tuners.
Forgot to mention...
I had to add an include of assert.h in mythsocket.cpp on my Fedora
Core 5 machine. This was not necessary on my Fedora Core 4 box.
Also, I had to disable a VERBOSE:
--- libs/libmythtv/dvbrecorder.cpp (revision 10051)
+++ libs/libmythtv/dvbrecorder.cpp (working copy)
@@ -614,9 +614,11 @@
VERBOSE(VB_IMPORTANT, "Writing PAT & PMT @"
<<ringBuffer->GetWritePosition()<<" + "
if (_pat && _pmt && ringBuffer)
To keep it from saturating my logs.
More information about the mythtv-dev