Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#2603 closed defect (worksforme)

Prebuffering pause while realtime commflagging

Reported by: thomas@… Owned by: cpinkham
Priority: minor Milestone: 0.21
Component: mythtv Version: 0.20
Severity: medium Keywords:
Cc: Ticket locked: no

Description

When I am watching a recording while it is being recorded and commflagged in realtime, I get a prebuffering pause every now and then. I don't have that problem, when I watch already finished recordings (even when commflagging of 2 other recordings is in progress).

I did not have this problem with 0.19. It only appeared recently, either with 0.20 or some fix in 0.20 fixes. I am running atrpms 0.20-141, which should be 0.20 fixes r11499.

I have a remote frontend, NFS parameters like suggested in the wiki. Tried 8192 and 32768 block size for a test, but I was running 0.19 with 8192 block size without problems.

I can easily run 2 mythtranscode (MPEG2) jobs on the backend and watch without prebuf pause on the frontend. I also can easily fast forward with max. speed, when the backend is idle. So, I think this is not a CPU, IO or network problem of my backend.

I am attaching log from mythfrontend, where it can be seen, that the prebuffering pause happens during commflag update. I guess, the thread that handles that update has a too high priority.

Attachments (4)

frontend.log (6.1 KB) - added by thomas@… 13 years ago.
mythfrontend log
more-examples.txt (3.7 KB) - added by thomas@… 13 years ago.
More examples
bad.txt.bz2 (1.5 KB) - added by thomas@… 13 years ago.
Prebuffering pause during commflag update.
good.txt.bz2 (765 bytes) - added by thomas@… 13 years ago.
No prebuffering pause during commflag update

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by thomas@…

Attachment: frontend.log added

mythfrontend log

comment:1 Changed 13 years ago by cpinkham

Resolution: invalid
Status: newclosed

This happened over 1 second after the COMMFLAG_UPDATE was complete, so it's not because of the update event directly. It may be indirectly related, but I'm not sure. Something caused your video to reinit, perhaps a change in the resolution or aspect ratio of the video you were watching, and the prebuffer pause happened during that. Closing this as invalid for now since it is unrelated to realtime flagging.

comment:2 Changed 13 years ago by thomas@…

Resolution: invalid
Status: closedreopened

Reopening and attaching more examples, where it can be seen better, that it really seems to be related to the commflag update. Also, in the first example, there is also something about "new commBreakIter" and "AutoCommercialSkip?()" around the prebuffering pause. It really is a fact, that this happens only when watching with realtime commflagging. I can watch a prerecorded show (from a day earlier) with no problems, while the backend records and commflags 2 other shows.

Changed 13 years ago by thomas@…

Attachment: more-examples.txt added

More examples

comment:3 Changed 13 years ago by thomas@…

I added the requested debug log messages. Attaching good and bad log (because the problem does not happen every time). Both log fragments are nearing the end of recording/watching.

I think it happens because of a really large map being transferred and processed.

I am using 0.20 fixes (r11558).

nvr_enc->FillPositionMap?(start, end, posMap) takes long and is line 217 and line 251 is inside the loop.

Changed 13 years ago by thomas@…

Attachment: bad.txt.bz2 added

Prebuffering pause during commflag update.

Changed 13 years ago by thomas@…

Attachment: good.txt.bz2 added

No prebuffering pause during commflag update

comment:4 Changed 13 years ago by thomas@…

More info: I now have a new and much faster backend (upgraded from P3-866 to Athlon 64 X2 3800+) and this still happens. I also got a hint from a friend that it also happens with 0.19, but I do not have proof yet. For him and me this started happening around the time when switching from analog to DVB. So, a wild guess would be that the position map sometimes is much larger or more "complicated" when using DVB.

comment:5 Changed 13 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham
Status: reopenednew

comment:6 Changed 13 years ago by anonymous

This looks like the very issue I have been having and the same as ticket #2335. I have solved the issue for myself by tuning the mysql server. Have a look at this http://mythtv.org/pipermail/mythtv-commits/2007-April/027549.html. I bet it helps this situation. LiveTV produces alot of sql queeries for seek positions in mythbackend.

comment:7 Changed 12 years ago by thomas@…

I changed the mysql settings as suggested and the bug is still happening.

comment:8 Changed 12 years ago by stuartm

Milestone: unknown0.21
Resolution: worksforme
Status: newclosed

Could you confirm that this bug still exists in HEAD and reopen the ticket if that is the case?

comment:9 Changed 12 years ago by stuartm

This was probably fixed when I split the seektable out of recordedmarkup and into it's own table. Thanks to Dibblah for pointing out the ticket.

Note: See TracTickets for help on using tickets.