Opened 14 years ago

Closed 14 years ago

#971 closed defect (fixed)

LiveTV endless playback loop of previous show when shows change.

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

Description

I was going to report a problem with stuttering and multiple second freezing on LiveTV when programs change, however as I was watching a program change this morning, LiveTV went into an endless loop of the last few seconds of the previous show. Attached are the frontend and backend logs of the incident.

A little more information:

  • SVN 8514
  • Standard decoding (no XVMC, although the stuttering I was experiencing before was ocurring with XVMC enabled)
  • AC3 passthrough enabled
  • Backend and frontend logging using "-v all,nodatabase,noaudio"
  • DVB-T card (Happauge NOVA-T) running on an Athlon XP 2600+

I've always seen stuttering on program change boundaries with the new LiveTV code, but this is the first time I've seen it loop. However, seeing as there was a post on the dev list about someone else having the problem, it's not just an isolated incident.

Attachments (8)

livetv-loop-backend.log (32.1 KB) - added by johan@… 14 years ago.
livetv-loop-frontend.log (147.2 KB) - added by johan@… 14 years ago.
rb-switch-dbg.patch (9.9 KB) - added by danielk 14 years ago.
debugging patch
livetv-with-dk-patch.log (17.5 KB) - added by johan@… 14 years ago.
LIveTV program change with danielk's patch
gdb.txt.active-process (11.3 KB) - added by dag@… 14 years ago.
gdb.txt.inactive-process (984 bytes) - added by dag@… 14 years ago.
mythtv.log.int (44.7 KB) - added by dag@… 14 years ago.
Backend log
mythfrontend.log.int.bz2 (77.1 KB) - added by dag@… 14 years ago.
Backend log bzipped because of size restriction

Download all attachments as: .zip

Change History (20)

comment:1 Changed 14 years ago by johan@…

I'm trying really hard to get these logs attached to the ticket, but both Firefox and IE are throwing errors that the site is not available when I hit the Attach button. Any ideas?

Changed 14 years ago by johan@…

Attachment: livetv-loop-backend.log added

Changed 14 years ago by johan@…

Attachment: livetv-loop-frontend.log added

comment:2 Changed 14 years ago by johan@…

Got it. Logs attached.

transproxy + squid no likey file uploads.

comment:3 Changed 14 years ago by Isaac Richards

Priority: majorminor
Severity: highmedium

Changed 14 years ago by danielk

Attachment: rb-switch-dbg.patch added

debugging patch

comment:4 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

Johan, can you try the attached patch?

It doesn't fix anything, but it should print out useful diagnostics when you run 'mythfrontend -v playback'. Then attach the resulting logs along with a description of what happened.

comment:5 Changed 14 years ago by johan@…

Hi Daniel,

I haven't watched a show change live for quite some time, and the looping only ever happened a couple times, however as per your instructions I applied your patch to SVN 8771 and watched a show change on an SD channel (I'm having a tough time switching to HD channels at the moment, the either goes to a black screen on change, or the channel plays fine for a little bit then totally locks up after bringing up the OSD ---- but I digress, that's another issue entirely).

Attached is the frontend log (-v playback) over the 7:30pm program change. There was a *very* brief audio skip at the change, but otherwise it happened without incident - none of the skipping / hanging / looping I've seen previously.

If you don't see anything amiss in the log, I would suggest the ticket be closed. To be honest, I completely forgot that I had opened it.

Thanks for your efforts.

Changed 14 years ago by johan@…

Attachment: livetv-with-dk-patch.log added

LIveTV program change with danielk's patch

comment:6 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8841]) Fixes #971. Fixes #900.

In SwitchToProgram?() we check if we close to the end before doing a switch. This was safe for low bitrate programs, but with high bitrate programs the RingBuffer? was initialized with a larger readblocksize. Also the valid video frames check isn't terribly valid with nVidia XvMC, which uses a total of only 8 video buffers.

This reworks this check and moves it to NVP::IsReallyNearEnd?(). It uses information from the RingBuffer? to set the thresholds so it scales with different bitrates. Also, the ringbuffer now takes the play_speed into account when using timestretch. The raw bitrate as reported by ffmpeg is scaled by timestretch value. Also since IsReallyNearEnd?() is using the real readblocksize in it's calculations, I've applied John Poet's patch for making 1080i @ >=1.2 timestretch work by increasing the readblocksize.

The params may need some tuning for the best performance. The values I used are both theoretically safe and worked for the 400 ringbuffer switches I threw at it. But the params are somewhat conservative. When I used the theoretical minimums, I did observe a lockup after about 70 switches, so my model isn't perfect.

comment:7 Changed 14 years ago by dag@…

Resolution: fixed
Status: closedreopened

The report I sent in 1067 was assumed to be a duplicate of this and I would like to report that the repeat of the previos show still happens in 8854.

Tell me what logs you want and I will try to provide.

Dag

comment:8 Changed 14 years ago by dag@…

More info: As there are always two mythfrontend "processes" (threads I guess) active when this happens I suspect that the problem has something to do with the older thread not being able to stop properly. I gdb:ed that process and found that it seems to be stuck in a poll() called from snd_pcm_direct_shm_create_or_connect in alsalib. Could be a alsa problem. What alsalib version are you other using out there?

comment:9 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

Dag, I'm going to need some debugging info from you in order to do anything for you.

First, front and backend logs using '-v playback' and '-v record' and a clear description of what happens.

Second, once it gets stuck in this loop, please hit Ctrl-C on the frontend and get a backtrace. Point out the two processes you are talking about.

BTW I'm using alsa-lib 1.0.9; If you think this is an ALSA problem try that version.

[I'm marking this as 'fixed', in reference to the original report. Reopen when you have the info requested.]

comment:10 Changed 14 years ago by dag@…

Resolution: fixed
Status: closedreopened

OK, happened again this morning. Noticed that I don't have a symbol table in the mythfrontend, but you will see the function calls at least. I will recompile with debug today.

I am also still using 8854. Visible symptoms are:

  1. Show changes, but Myth will repeat what was looked at before. In this case the kids started watching 8:44 and everything since that was repeated. Presumably Myth starts showing the "old" recordings file.
  2. The system will not respond to keys when this happens. Don't think it is a focus issue though.
  3. There will be two mythfronend process (threads?) in a ps listing. One of them definitely inactive, owned by init and having a very low CPU usage (accumulated). The other is the "main" display item. Attached traces from both. The inactive process will exit immediately when you attach to it either through gdb or strace which indicates that it was waiting for a signal of some kind.

The alsalib I am using is also 1.0.9 so that shouldn't be an issue then, providing Mandriva has done anything to it...

Attaching the log files requested.

Changed 14 years ago by dag@…

Attachment: gdb.txt.active-process added

Changed 14 years ago by dag@…

Attachment: gdb.txt.inactive-process added

Changed 14 years ago by dag@…

Attachment: mythtv.log.int added

Backend log

Changed 14 years ago by dag@…

Attachment: mythfrontend.log.int.bz2 added

Backend log bzipped because of size restriction

comment:11 Changed 14 years ago by dag@…

The last attachment is of course a mythfronend log, not backend.

comment:12 Changed 14 years ago by Isaac Richards

Resolution: fixed
Status: reopenedclosed

(In [8866]) Fix a race condition (was confused about where it was in the chain during a smooth transition between shows)

Probably fixes #942, #971, #1213, and any other 'livetv breaks at end of a show' issue.

Note: See TracTickets for help on using tickets.