[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mythtv-dev
Subject:    [mythtv]  Scheduler needs table keys?
From:       f-myth-users () media ! mit ! edu
Date:       2007-02-27 8:31:12
Message-ID: 200702270831.DAA05516 () out-of-band ! media ! mit ! edu
[Download RAW message or body]

    > Date: Sun, 28 Jan 2007 21:28:13 -0500
    > From: Chris Pinkham <cpinkham@bc2va.org>

I have -finally- been able to put together a test system so I can
test your suggested commenting out of curRecording->SetFilesize in
two places in libs/libmythtv/mpegrecorder.cpp [this is in 0.18.1].
[Your actual message was sent Tue, 23 Jan 2007 23:46:50 -0500 and
had a subject of "trunk driver", if that helps in locating it.]

Things don't quite behave as you describe below, but I don't yet know
if that's actually a problem.  I haven't (yet) tested this in my
production server and should probably get an answer to my question
below before I try it.

    > * On Sun Jan 28, 2007 at 09:14:53PM -0500, f-myth-users@media.mit.edu wrote:
    > >> From: Chris Pinkham <cpinkham@bc2va.org>

    > > As a stopgap until the real fix goes in (or as something I might be
    > > able to do immediately to my .18), do you or anyone have any idea what
    > > -not- writing recorded.filesize will do?  If it's a complete nonstarter
    > > 'cause it'll break everything else, fine, but if it would be possible
    > > to just patch out that pair of lines you indicated and live with it
    > > until the table locking gets sorted out, well...

    > Shouldn't cause any big issues that I know about.  The recorders should
    > be doing one final curRecording->SetFilesize() when the recording is
    > done anyway.  The filesize is updated during recording for a couple

In my test system, it's not getting set at the end, since you
suggested commenting out -both- occurrences of SetFilesize; one
is in ProcessData, but the other is in FinishRecording.  Did you
mean to totally inhibit the latter, or did you just not notice
that one of the calls was there?

    > reasons including if the backend is stopped prematurely, that is part
    > of the reason we write out the seektable while recording also.  The
    > seektable is also written out so that a player can get the seektable
    > from the DB without having to request it from the backend.

    > There is code in mythbackend to fill in the filesize if it is missing
    > whenever the frontend requests the list of recordings, so if you view
    > the list of recordings while a recording is in progress, the filesize
    > field will be populated with the current filesize which will then get
    > updated with the final filesize by the recorder when the recording ends.

[Isn't happening, but see above.]

In an unmodified system, recorded.filesize gets updated every 15
seconds, which makes sense if it happens every 30 keyframes.

In my test system, recorded.filesize starts out 0 when a recording
commences, and is modified to the current filesize the instant the
frontend looks at it (e.g., the first time I go to the listing of
what's been recorded---I did this a minute or so into a 5-minute
manual recording).  At that point, nothing I do, including skipping
around in the recording, leaving and reentering that frontend page, or
even terminated and restarting the frontend, causes the value to
change.  [This is really easy to demonstrate; I just put the relevant
SQL query in a one-second loop in a shell and watched it in another
window while playing around.]  Obviously the frontend sees a value
there and never tries to update it.

I noticed that -something- split out an error flagging my test
video about "MPEG motion vector out of boundary" and "concealing 45
DC, 45 AC, 45 MV errors" (and some other warnings in between).  I
don't have enough data to know if this happens on every file made
without recorded.filesize, nor whether this tends to happen in an
unmodified system.  (I've seen those errors before, but chaulked it up
to the corruption I'm trying to fix.  But this system was recording a
single stream w/nothing else going on---maybe the very end was
mangled? I didn't -see- anything in the stream when I watched it.)
(I don't actually know what spit it out; it was coming from mpeg2video
but I can't easily copy the error into this message 'cause my test
machine is off the network---simplest way to ensure that no
conceivable screwup on my part could cause it (or me) to damage
the active database on the production machine.)  It -shouldn't-
have been the commflagger, since I was recording PBS and I already
have that set not to flag---but it happened a few minutes -after- I
shut down the backend & frontend, and what else could have been running?
Especially on a machine not on the network that I wasn't typing at?
[I set the manual rec via mythfront, not mythweb, so I wasn't offered
the option not to commflag---but I would have guessed that it would
have inherited the setting from when I set up that channel months ago.]

Note:  if not having the filesize set -is- causing commflagging to
barf, I need to know in order to tell commflagging not to start until
the recording is finished.  (Right now, it runs concurrently.)

So the big question:  Do I care that recorded.filesize won't -ever-
get updated to the "final" value?  What looks at it?  Or should I
only remove the use in ProcessData and leave FinishRecording alone?
[I'm assuming that, by the time that's running, we've read all the
ivtv buffers we ever will, so it doesn't matter if -that- hangs for
30+ seconds if the scheduler is already running; is this correct?]

[I'm hoping to try out this patch in my production machine ASAP, but
that's probably about 24 hours away since that's its next maintenance
window.]

Thanks!

    > Before the filesize was stored in the database, the master backend would
    > have to check the filesizes of every recording whenever the recordings
    > list was requested by the frontend.  So if anyone thinks it is slow to
    > start up the Watch Recordings screen now, think about how it was back
    > then when the backend had to stat every recording's file to get its
    > filesize before returning the recordings list. :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

[prev in list] [next in list] [prev in thread] [next in thread]