[mythtv-users] searching dialog then player abort after BE migration
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
More information about the mythtv-users