[mythtv] Some bugs (0.15)

[Matt Zimmerman]

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. :-)

> When watching a record in progress and the recording ends, forward seeks
> no longer work. The player should discover that the encoder is no longer
> available and switch to the recordedmarkup data.

Yes, this is bothersome, but it's the same in 0.14 (i.e., not a regression).

> When paused, Right and Left are next frame and previous frame.  However,
> the first step after pause will jump forward by the number of frames
> stored in the vbuffers. This is because framesPlayed is actually the last
> frame decoded and does not reflect the number of frames decoded and
> buffered and therefore does not reflect the last frame displayed.
>
> If returning to the playbox after watching a recording and a new recording
> has started since the last time the playbox was exposed, the highlighted
> item in the list box is off by one. However, the description area and exit
> popup are correct.

Ditto on both of these.

> 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?

> 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.

-- 
 - mdz