[mythtv-users] searching dialog then player abort after BE migration

Matt Garman matthew.garman at gmail.com
Fri Jan 6 03:12:17 UTC 2012

On Thu, Jan 05, 2012 at 07:12:59PM -0600, Matt Garman wrote:
> On Thu, Jan 05, 2012 at 03:03:26PM +0000, Mike Perkins wrote:
> > On 05/01/12 03:24, Matt Garman wrote:
> > >
> > > I followed the suggestions on this page:
> > >
> > >      http://www.mythtv.org/wiki/Repairing_the_Seektable
> > >
> > > Basically, optimize_mythdb.pl (on both the FE and BE databases),
> > > mythcommflag, and mythtranscode.  None of these fixed the
> > > problematic videos; the problem still exists.
> > >
> > optimize_mythdb.pl is only ever going to work on the box that has the mysql 
> > database.
> > 
> > > But it is intermittent: some recordings are OK, some are
> > > problematic.  In fact, two shows can be recorded at the same time
> > > (HDHomeRun w/OTA) with one just fine and one being problematic.  Or,
> > > a single show can be recorded at any random time, and there seems to
> > > be a 50/50 chance that it will have the problem.  In other words, I
> > > can't see any pattern to the problem: not isolated to a particular
> > > time, channel, or TV show.
> >
> > Time, channel, TV show, no. But did you check to see which *tuner*
> > was used for the good/bad recordings? As things stand, you can
> > only do this by looking at the backend logs.
> I will study the logs.
> In the meantime, what kind of tuner issue would cause this problem?
> It seems highly unlikely that the tuner would suddenly develop a
> problem: it's a HDHomeRun, which means I didn't physically touch it
> at all.  It's worked without issue for a long time now.  Seems
> unlikely that it would develop problems right when I split my
> combined FE+BE out to two separate machines.
> Is it possible that I mis-configured the HDHomeRun when setting up
> the new BE?  What kidn of configuration problem would lead to this?
> Also: the videos play just fine, start to finish, as long as we
> don't try to search.  So they are being recorded correctly.  And
> since they are recorded correctly, I don't understand why
> mythcommflag --rebuild doesn't fix the seek table.  Is it possible
> there is some other issue at work?
> Also: my wife noticed another quirk: some videos that we initially
> thought were OK are only OK until you seek forward or backwards a
> few time.  Then the seeking functionality starts degrading: first
> the amount of seek starts getting random, then seeking forward makes
> the video go backward and vice-versa!

I compared tuner information in the logs to player performance.  All
recordings *except 1* from "cardid 1, sourceid 1" had the seek

Two other tuners showed up: "cardid 3, sourceid 1" and "cardid 4,
sourceid 1".  I don't know why I don't see a cardid 2.  Anyway, all
of the recordings from this tuner either worked perfectly, or were
ultra-small files that had no playback at all!

If anything, the problem seems to be getting worse.

For the files that were full-size, but didn't play back correctly
with Myth's internal player: I was able to play them just fine in
mplayer, complete with search back and forward.

So, now, in summary, after the BE migration, very few recordings
(say 10%) are viable in MythTV.  The rest are either tiny files and
have no data, or have bad seek behavior (but play fine in an
external player).

Thanks again,

More information about the mythtv-users mailing list