[mythtv] MythSocket class

John P Poet jppoet at gmail.com
Sun May 28 07:31:39 UTC 2006


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.

Behavior is a little strange.  Topaz is my master backend, Cobalt is
my slave backend.  Both backends seem to startup just fine:

==2006-05-28 01:06:20.458 Using runtime prefix 2006-05-28 01:06:20.578 New DB connection, total: 1
2006-05-28 01:06:20.610 Connected to database 'mythconverg' at host: localhost
2006-05-28 01:06:20.618 Current Schema Version: 1141
Starting up as the master server.
2006-05-28 01:06:20.778 New DB connection, total: 2
2006-05-28 01:06:20.881 Connected to database 'mythconverg' at host: localhost
2006-05-28 01:06:20.996 New DB connection, total: 3
2006-05-28 01:06:21.000 Connected to database 'mythconverg' at host: localhost
2006-05-28 01:06:21.035 EITHelper: localtime offset -6:00:00
  <snip>
2006-05-28 01:07:18.538 adding: cobalt as a slave backend server
2006-05-28 01:07:18.565 Reschedule requested for id 0.
not expecting reply..
not expecting reply..
not expecting reply..
not expecting reply..
not expecting reply..
2006-05-28 01:07:21.202 Scheduled 408 items in 2.6 not expecting reply..
  <snip>

=2006-05-28 01:07:16.208 Using runtime prefix 2006-05-28 01:07:16.379 New DB connection, total: 1
2006-05-28 01:07:16.465 Connected to database 'mythconverg' at host: topaz
2006-05-28 01:07:16.474 Current Schema Version: 1141
Running as a slave backend.
2006-05-28 01:07:16.489 New DB connection, total: 2
2006-05-28 01:07:16.493 Connected to database 'mythconverg' at host: topaz
2006-05-28 01:07:16.497 EITHelper: localtime offset -6:00:00
<snip>
2006-05-28 01:07:18.505 Connecting to master server: 192.168.2.50:6543
2006-05-28 01:07:18.509 Connected successfully

But after a few minutes things get weird.  Cobalt is re-added as a
slave backend, and then dropped, even though it is still running and
recording:

=2006-05-28 01:14:47.545 adding: cobalt as a slave backend server
2006-05-28 01:14:47.591 setting 2/KRQE-DT/"Da Vinci's Inquest" as recording
2006-05-28 01:14:47.605 setting 4/KNME-HD/"Where Words Prevail" as recording
2006-05-28 01:14:47.612 Reschedule requested for id 0.
not expecting reply..
not expecting reply..
2006-05-28 01:14:51.555 Scheduled 407 items in 3.9 not expecting reply..
not expecting reply..
not expecting reply..
not expecting reply..
2006-05-28 01:14:52.623 AutoExpire: Found 3 recorders w/max rate of 349 MiB/min
2006-05-28 01:14:52.628 AutoExpire: Required Free Space: 2.7 GB w/freq: 5 min
2006-05-28 01:15:17.521 Slave backend: cobalt no longer connected
2006-05-28 01:15:17.533 Reschedule requested for id 0.
not expecting reply..
<snip>
2006-05-28 01:19:35.438 MythSocket(ad7db2f8:-1): readStringList: Error, timeout.
2006-05-28 01:19:35.457 SendResponse: Unable to write to client
socket, as it's no longer there
2006-05-28 01:19:35.458 Unknown socket closing
2006-05-28 01:19:35.458 MainServer::HandleAnnounce Monitor
2006-05-28 01:19:35.468 adding: topaz as a client (events: 0)
2006-05-28 01:19:35.472 MythSocket(830e800:-1): writeStringList:
Error, called with unconnected socket.
2006-05-28 01:20:35.188 MainServer::HandleAnnounce Monitor
2006-05-28 01:20:35.196 adding: cobalt as a client (events: 0)
2006-05-28 01:20:35.200 MainServer::HandleAnnounce Monitor
2006-05-28 01:20:35.203 adding: cobalt as a client (events: 1)

I am attaching complete logs from both backends.  Hope this helps.

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: topaz-backend.log.bz2
Type: application/x-bzip2
Size: 5397 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060528/4c3f5ccc/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cobalt-backend.log.bz2
Type: application/x-bzip2
Size: 6284 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060528/4c3f5ccc/attachment-0001.bin 


More information about the mythtv-dev mailing list