[mythtv] MythSocket class

[John P Poet]

On 6/7/06, John P Poet <jppoet at gmail.com> wrote:
> On 6/7/06, Isaac Richards <ijr at case.edu> wrote:
> > On Wednesday 07 June 2006 11:40 pm, John P Poet wrote:
> > > *Much* better, but not perfect.
> > >
> > > I had to add "#include <assert.h>" to mythsocket.cpp for Fedora Core 5.
> > >
> > > I seem to be able to consistently get it to fail to record a show....
> > >
> > > I started up both backends and my frontend.  Went into the guide and
> > > selected enough shows to record, to completely saturate my tuners.
> > > Myth proceeded to record all the shows just fine.
> > >
> > > Then, before those shows and finished recording, I:
> > >
> > > * Stopped mythbackend on the slave.
> > > * Deleted the backend log on the slave
> > > * Stopped mythbackend on the master.
> > > * Deleted the backend log on the master
> > > * Started mythbackend on the master.
> > > * Started mythbackend on the slave.
> > >
> > > Myth *thinks* it started recording all the shows again, however one of
> > > them did not record -- no file was even created for it.  The show that
> > > failed to record is:
> > >
> > > "Encore! With James Conlon".
> > >
> > > According to the logs, myth thinks it was writing it to
> > > /mythtv/cobalt/1014_20060607204400.mpg (on the slave backend).
> > > However, this file was nowhere to be found afterwards.
> > >
> > > I am attaching the logs which where created after the restart.
> > >
> > > After all of these shows finished.  I tried those exact same steps
> > > again, with the exact same result -- one of the shows on the slave
> > > backend did not generate a file after restarting.
> > >
> > > Let me know if you want me to do it again, without deleting the logs
> > > during the restart.
> >
> > Actually, I'd like to see if it happens without the patch.  Your logs show it
> > as being recorded, and it's well past the point where this patch could be
> > causing it not to record.  Going by your logs, I'd say it's something
> > completely unrelated.
> >
> > Can you get a full bt of the slave backend when it's not recording when it
> > should be?
> >
> > Isaac
>
> Rebuilt the software on the slave backend with debuging, and tried to
> reproduce the failure again (twice), but now it is working fine.  It
> is interesting that it failed for me in the same way two times in a
> row.  Guess that was just luck.
>
> I will bang on it some more tomorrow night.
>
> As far as the mythsocket stuff goes, so far I *really* like it.  It
> has been a long time since my backends and frontend have re-synced
> this well.  For about the last year, if the backend was restarted, the
> fronted would hang for a LONG time.  With the mythsocket patch it
> resyncs nice and quick.
>
> I have nothing of any importance scheduled to record in the near
> future, so I will continue to run with this patch.  I will let you
> know if I find any (other) problems.  I will try to reproduce the
> record failure and get you a BT.
>
> John

I was able to get it to fail to record an "in progress recording"
after restarting mythbackend, but this time it was on the master --
which I had not recompiled with --compile-type=debug.

Now that both of my backends are compiled with debugging, I have not
been able to make it happen again.  I will keep trying.

I do have one problem to report: The frontend does not seem to
dynamically update.

If you DELETE a show, the entry for that show is greyed-out, but the
entry will stay in the list until you leave the "Watch Recording"
screen, and return to it.

Same is true for a "new" recording.  The backend can start recording a
show, but if you are already in the "Watch Recordings" screen, the new
show will not be in the list.  Once you leave the "Watch Recordings"
screen and come back to it, then the show is in the list.

John