Opened 14 years ago

Closed 13 years ago

#1693 closed patch (wontfix)

osd total time of quai-live 60fps shows gets doubled when recording completes

Reported by: perveilerj@… Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version:
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I believe this fixes the problem gdragon was seeing in ticket #799. Basically, the total length of a quasi-live recording is reported to NVP incorrectly for non-29.97 fps dtv recordings when the recording stops, resulting in the total length being doubled once the recording completes

The dtv recorders assume a 29.97 fps stream. When the recording finishes, tvRec took the recorder's frame count, divided by its frame rate (which was incorrect for 60fps recording, like ATSc 720p), and informed the NVP of the new total length. This patch fixes the issue by changing NVP to use the frame count from the recorders and decoders and the frame rate from the stream it is playing. This makes NVP::SetFileLength?() and NVP::SetLength?() unnecessary, so they goes away. I've tested the patch with 1080i and 480i (29.97 fps) and 720p (60fps) recordings and they all seem to work now.

Attachments (1)

head_patch.diff (11.9 KB) - added by perveilerj@… 14 years ago.
patch against r9716

Download all attachments as: .zip

Change History (6)

Changed 14 years ago by perveilerj@…

Attachment: head_patch.diff added

patch against r9716

comment:1 Changed 14 years ago by danielk

Resolution: wontfix
Status: newclosed

This seems to make the problem worse by further entrencing an invalid assumption of a fixed number of frames per second.

The underlying problem with the dtv recorders and the way MythTV tracks where we are in the recording is that the frame rate is not fixed when using these recorders. A network can switch to 24 fps for filmed programs and then to 30 fps for a commercial (see WB and UPN).

The #799 problem is really a seperate problem, it is due to a misscounting of the frames in DTVRecorder::FindKeyframes?(). This happens because we don't parse the PES packet properly. This patch would only hide one of the effects of this, skipping would still be broken because we would still be writing a broken position map.

comment:2 Changed 14 years ago by perveilerj@…

A couple of closing comments (using Trac because hopefully they clarify the patch/ticket, and this topic has come up more than once on the users list):

1) Yeah, I know #799 is different. There you told gdragon (not the o.p.) his problem WASN'T actually #799... #1693 was meant to be about HIS problem (not #799's original poster's problem).

2) When you say the patch "makes the problem worse" you're talking strictly about the the constant framerate assumption, not the patch's behavior, right? I think I read you correctly, just making sure because functionally it worked for me.

3) Any fix to the changing framerate problem will still require NVP to use frames instead of seconds computed by recorders/decoders (which is what this patch really does), so isn't this at least a step along that path? Is this more applicable under a different title (maybe "NVP doesn't handle non-constant framerates"). I can continue working on this, but I'd want to know if I'm at least going in the right direction.

Number 3 starts to get involved and off-ticket, so we can discuss it in the mailing list. Numbers 1 and 2 seemed relevant to the ticket though.

--Jack

comment:3 Changed 13 years ago by ylee@…

Resolution: wontfix
Severity: mediumlow
Status: closedreopened
Type: patchdefect
Version: 0.20

I can confirm that this issue still exists within 0.20.20060823-3 (ATrpms). While watching both The Simpsons and American Dad (both on FOX and thus 720p) Sunday night "quasi-live," as each recording completed the total recorded time on the OSD exactly doubled; for example, 29 minutes and 57 seconds became 59 minutes and 54 seconds. Exiting the recording and reentering solved the problem in both cases.

comment:4 in reply to:  3 Changed 13 years ago by anonymous

Replying to ylee@pobox.com:

I can confirm that this issue still exists within 0.20.20060823-3 (ATrpms).

Sorry; I meant 0.20.20060828-3.

comment:5 Changed 13 years ago by danielk

Resolution: wontfix
Severity: lowmedium
Status: reopenedclosed
Type: defectpatch
Version: 0.20
Note: See TracTickets for help on using tickets.