Opened 4 years ago

Closed 4 years ago

#12513 closed Bug Report - General (Fixed)

IPTV: Movistar TV stops LiveTV playback after a while

Reported by: amlopezalonso@… Owned by:
Priority: minor Milestone: 0.28
Component: MythTV - General Version: Master Head
Severity: medium Keywords: IPTV, playback, livetv
Cc: Ticket locked: no

Description

IPTV playback freezes after a while in Movistar TV. Attaching log.

Regards, Antonio

Attachments (1)

FE.log (62.0 KB) - added by amlopezalonso@… 4 years ago.
mythfrontend --loglevel debug -v playback

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by amlopezalonso@…

Attachment: FE.log added

mythfrontend --loglevel debug -v playback

comment:1 Changed 4 years ago by Karl Egly

Status: newinfoneeded_new

I found some time to look at this. It is the continuation after fixing RTP reception in #12188.

The logfile does not contain any obvious (for me) root cause, so I'm just listing all suspicious parts and ask questions to try to identify the relevant parts.

Just for clarity. Do recordings work reliable? Or does this affect recordings and LiveTV?

2015-09-30 00:14:17.628516 D  MMulticastSocketDevice(:25): setsockopt - IP_MULTICAST_IF
                        eno: No se puede asignar la dirección solicitada (99)
2015-09-30 00:14:17.749717 D  MMulticastSocketDevice(:25): setsockopt - IP_MULTICAST_IF
                        eno: No se puede asignar la dirección solicitada (99)

Errno 99 is EADDRNOTAVAIL. It appears as if there may be an issue with the network configuration.

2015-09-30 00:14:26.901568 I  TV::HandleStateChange(): Changing from None to WatchingLiveTV
2015-09-30 00:14:28.209395 I  VidOutVDPAU: InputChanged(1920,1080,1.77778) 'None'->'H.264 VDPAU'
2015-09-30 00:14:28.210914 W  MythPainter: 36 images not yet de-allocated.
2015-09-30 00:14:28.694213 I  Player(0): Waiting for video buffers...
2015-09-30 00:14:28.798315 N  Player(0): Waited 104ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:28.901902 N  Player(0): Waited 207ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:29.005472 N  Player(0): Waited 311ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:29.108894 N  Player(0): Waited 414ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:29.212503 N  Player(0): Waited 518ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:29.316329 N  Player(0): Waited 622ms for video buffers LLLLdAAAAAAAAAAA
2015-09-30 00:14:29.420148 N  Player(0): Waited 726ms for video buffers AALAdLLLAAAAAAAA
2015-09-30 00:14:29.489943 E  PulseAudio: stream buffer under flow
2015-09-30 00:14:29.524396 N  Player(0): Waited 830ms for video buffers AAAAdAAAAAALLAAA
2015-09-30 00:14:30.236548 E  PulseAudio: stream buffer under flow
2015-09-30 00:14:31.089868 E  PulseAudio: stream buffer under flow
2015-09-30 00:14:31.137058 I  Player(0): Waiting for video buffers...
2015-09-30 00:15:14.637121 I  TV::HandleStateChange(): Attempting to change from WatchingLiveTV to None

I see it pick the H.264 1920x1080 video stream and attempt to start decoding it via VDPAU. But more or less directly the buffering errors begin. Audio stream buffer under flow from Pulseaudio, waiting for video buffers from our Player, etc.

Does playback even start?

Does this happen on all channels?

Does it happen with software decoding?

Does it happen with ALSA for audio playback?

2015-09-30 00:15:19.815317 W  RingBuf(/usr/local/share/datos/tv/livetv/1999_20150929231427.ts): ReadPriv(..32768, normal) -- waited 10009 ms for avail(0) > count(32768)
2015-09-30 00:15:19.815333 E  RingBuf(/usr/local/share/datos/tv/livetv/1999_20150929231427.ts): ReadPriv(..32768, normal) -- timed out waiting for data (10009 ms)
2015-09-30 00:15:19.815582 E  decoding error
                        eno: Error desconocido 541478725 (541478725)

Error 541478725 is the decimal representation of AVERROR_EOF from FFmpeg. It appears as if LiveTV playback is hitting the end of the buffer or (at least) one of the streams ends.

Searching for "LiveTV 541478725" turned up #11064 where the root cause was the network stream stopping due to the sender falling off the network.

Can you look at the network (e.g. via wireshark) around the time where the error occurs?

Does the multicast stream somehow stop? After about 50 seconds?

Can you compare to VLC's network activity?

Maybe we need yet another keep-alive mechanism.

comment:2 Changed 4 years ago by bmlong137@…

Could this be related? https://code.mythtv.org/trac/ticket/12558

Qt 5.4.2 has a bug with QUdbSocket and readyRead().

comment:3 Changed 4 years ago by amlopezalonso@…

Sorry for the delay. I've built last git pull and it seems the issue is gone! I tried several HD channels playback for more than 5 minutes and there is no freeze around.

I guess we can mark this as fixed but just after a few days as it is advisable just in case.

I think I can deal now with Movistar TV EPG. Any recommendations?

Regards and Happy New Year, Antonio

comment:4 Changed 4 years ago by Karl Egly

A quick search around the internet hints that Movistar TV is multicasting the EPG data in TV-Anytime format, but have moved from text to binary lately. Potentially just using the Binary MPEG format for XML.

So the existing (external) XMLTV grabber does not work anymore. Maybe the authors of the Kodi plugin, which appears to still be able to receive the Broadband Content Guide according to the TVHeadend forum referenced above, can confirm that its just a switch to binary. Then it should be relatively straightforward to update the xmltv grabber. But that is outside the scope of a MythTV ticket :-)

Also it should be straightforward to extend the generated M3U playlist to also contain the generated XMLTV channel id, so the configuration is a bit easier.

comment:5 Changed 4 years ago by amlopezalonso@…

Interesting. Thanks for the detailed info. I'll take a look into it.

Regards, Antonio

comment:6 in reply to:  3 Changed 4 years ago by Karl Egly

Milestone: unknown0.28
Resolution: Fixed
Status: infoneeded_newclosed

Replying to amlopezalonso@…:

I've built last git pull and it seems the issue is gone! I tried several HD channels playback for more than 5 minutes and there is no freeze around.

I'm closing this as fixed now, thanks for testing.

Note: See TracTickets for help on using tickets.