Prebuffering pause while realtime commflagging

[thomas@…]

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.

[thomas@…]

mythfrontend log

[cpinkham]

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.

[thomas@…]

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.

[thomas@…]

More examples

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

[thomas@…]

Prebuffering pause during commflag update.

[thomas@…]

No prebuffering pause during commflag update

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

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

[thomas@…]

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

[stuartm]

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

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