LiveTV endless playback loop of previous show when shows change.

[johan@…]

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.

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

[johan@…]

Got it. Logs attached.

transproxy + squid no likey file uploads.

[danielk]

debugging patch

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

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

[johan@…]

LIveTV program change with danielk's patch

[danielk]

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

[dag@…]

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

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

[danielk]

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

[dag@…]

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.

[dag@…]

Backend log

[dag@…]

Backend log bzipped because of size restriction

[dag@…]

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

[Isaac Richards]

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