[mythtv] MythSocket class

John P Poet jppoet at gmail.com
Fri Jun 9 02:32:20 UTC 2006


On 6/8/06, John P Poet <jppoet at gmail.com> wrote:
> 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

It also appears that mythsocket8.diff no longer applies cleanly to latest svn?

John


More information about the mythtv-dev mailing list