[mythtv] Scheduler needs table keys?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sat Mar 3 03:48:59 UTC 2007


    > Date: Thu, 1 Mar 2007 01:36:54 -0500 (EST)
    > From: f-myth-users at media.mit.edu

    > I guess my real question wrt your paragraph above is, "Would such
    > locks propagate down to hanging ProcessData if -it- is not also
    > trying to update filesize?"

I'm hoping somebody can answer the implications of this question (and
the others) from my previous message in this thread (e.g., the one I'm
replying to here), but while I wait for that, here's some operational
experience with cpinkham's suggested patch to ProcessData:

It works!

[See also some recommendations at the very end.]

I commented out -only- the setfilesize call there (and not at
FinishRecording).  As expected, the first time either the frontend or
Mythweb looks at a recording in progress, it updates the filesize, and
that size stays frozen until the end of the recording.  The only time
I ever even -see- that number is in Mythweb (GANT doesn't seem to
display it in any screen I typically look at), and I don't care if it
doesn't stay updated as long as the rest of Myth doesn't care, either
---and it appears not to.

I did a bunch of testing, in a couple of ways.  The first way was the
way I'd been testing for the last few months---load up all tuners with
manual recordings, of which one runs 10 minutes and the rest run 15,
either with or without commflagging.  Unless the database has been
optimized in the last few hours (and sometimes even then), the old
code would generally cause all of the 15-minute recordings to glitch
at the 10-minute mark, as the scheduler locked tables when the 10m
recording ended.

In my current setup, my MBE is running the patched code, and an SBE
with a single tuner is running the unpatched code (a packaged version
of 0.18.1 installed over a year ago).  When the 10-minute recording
ended, none of the streams recorded by the MBE glitched.  However, the
stream being recorded by the SBE -did- glitch, as expected, because
its ProcessData is still trying to update recorded.filesize every 15
seconds and hangs while the scheduler locks tables.

In addition, I tried going into mysql's read-eval-print loop and doing
"LOCK TABLES RECORDED WRITE;" for about 30 seconds, followed by
"UNLOCK TABLES;".  I tried this while running the old code everywhere,
and of course it fell over and showed massive corruption in streams
being recorded.  When I did it in the current setup, no MBE stream was
corrupted, but the SBE stream (with the old code) missed the next 30
seconds of the stream---I must have locked the table -just- before
ProcessData tried to set recorded.filesize and it lost big.

Also:  I have automation that, when it runs, may try to delete 25-35
recordings as fast as it can.  (That takes about 5-10 -minutes-
because each deletion triggers a scheduler run, hanging later
deletions from completing until the scheduler is finished---another
reason I'd be all in favor of batching scheduler updates similarly to
the way TCP tiny-packet-avoidance works.  This isn't a filesystem
issue 'cause the recordings live in JFS's instant-deletion regime.)
I tried running this automation while recording a couple of streams on
the patched MBE.  I didn't get any corruption.  So it obviously
-wasn't- disk-thrashing or load or anything like that which was
causing my glitches, because I had the scheduler doing reschedules
constantly for 5+ minutes and didn't see a single glitch under the new
code.  [My automation is klugy but effective:  it uses wget to ask
mythweb to delete (so I don't have to speak Myth protocol), then stats
the relevant recording in the filesystem once per second until it
vanishes, at which point it asks for the next deletion.  Typically,
it must wait 5-10 seconds each time before the file actually vanishes.]

Conclusion:  Chris nailed this precisely.  Thanks!

Recommendation:  I'd advocate making this patch to SVN immediately.
Yes, it will break the ability to track in real-time the growing size
of a file, in those themes that support this, but it would be useful
to see if other people who are having corruption issues find immediate
relief.  [Failing that, anyone who's having problems should definitely
comment out the line with "curRecording->SetFilesize" in ProcessData
in libs/libmythtv/mpegrecorder.cpp.]

Yes, I know that there is a pending change to the whole way this value
is used (e.g., moving filesize out of recorded entirely, so it doesn't
matter if the scheduler locks that table, and perhaps other rearrangements),
but removing that single line from ProcessData is much faster and easier
to do as a stopgap---just in case the more-complete fix doesn't make
it into 0.21.  I only wish it had never wound up there in the first
place... :)

P.S.  This took forever to test because I had to build a test system
since my maintenance windows on the production system are tiny and
infrequent, but I'm now running the code on my production MBE and will
be migrating it to my production SBE soon.  [It's also highly annoying
that I had to take my test machine off the net and use its local head
only, because I couldn't take the risk that my source-built Myth was
somehow protocol-incompatible with the packaged version, and I
couldn't risk it bashing my production MBE if I momentarily screwed
up, e.g., if I somehow allowed my test machine to talk to the
production machine despite my precautions to avoid it.  I'm mentioning
this as yes another plea for CONFIRMATION before an auto-schema-upgrade,
unless there's a flag set in the database that says, "Yes, I'd like to
live dangerously."  It would have made my testing much easier if I
could have depended upon that behavior.]


More information about the mythtv-dev mailing list