[mythtv] Some bugs (0.15)

[Bruce Markey]

Matt Zimmerman wrote:
> On Fri, May 21, 2004 at 05:40:32PM -0700, Bruce Markey wrote:
> 
> 
>>This seemed to work well last time so I'll try again. Here are some bug
>>that I know of right now. I don't believe that any of these are critical
>>but may nice to have them fixed if the solutions are low impact. 
> 
> 
> These seem like nice, bite-sized projects for interested parties...after the
> 0.15 release. :-)

Isaac said about the same thing ;-). When I did this before 0.14
there really were several small oddities but Isaac knocked out
at least a dozen or so. This time, as I went through the bugs I knew,
I fixed four or five small ones rather than writing about them
and sent some to gigem off-line for things he's worked with. All
that was left are these bite-sized projects that aren't really new.

None of these are must fix bugs.

>>During seeks, playback sometimes jumps back to the beginning of the
>>recording. If seeking in roughly the same spot again, the jump to the
>>beginning may reoccur. I suspect this may be a result of positionMap
>>entries with a file position value of 0. The seek code should probably
>>check for a sane value, say greater than 2048, before seeking. Otherwise
>>treat it as keyframe not found.
> 
> 
> I've never seen this in 0.14; did you?  Where do you think the bogus entries
> could be coming from?

Yes, it's always been there but is infrequent. I see it no more
than once or twice per week if that. You can, of course, play
through the file or seek as long as the destination of the seek
isn't the bad entry. If I get teleported back to the beginning,
I seek close to where it jumped and either play through the bad
spot or take a longer skip over it. I had one of these at about
the 27:30 mark in Sportscenter this morning. Things like this
I fast-forward a lot. If it was something I watch all the way
through, I'd have never seen it.

>>After a recording completes, the encoder sends an "INSERT" statement
>>to the database for each keyframe (even though this recordedmarkup
>>data is updated every 15 seconds during the recording). One hour is
>>3600 inserts and on a remote slave, a three hour recording can take
>>over a minute to complete the network traffic before it will begin the
>>next back to back recording. Remote one hour back to back recordings
>>usually have about a 17sec delay.
> 
> 
> Hmm, I never noticed this before, but I see it in 0.14 as well, now that I
> look.  The process only takes about 2 seconds here for a one hour recording
> (backend and DB on different hosts), though, so it's not surprising that I
> didn't notice.

I hadn't either until you and David were talking about speeding
up the scheduler between back to back recordings. The reason the
scheduler queries are slow is because the encoder is pounding the
DB with recordedmarkup.

I see about 2sec also for encoders on the database machine. It's
the remote slaves that suck. cpinkhan knows about this and said
he has an idea of how he wants to fix it but I imagine he hasn't
had much time to spend on myth lately.

--  bjm