Opened 9 years ago
Closed 8 years ago
#12513 closed Bug Report - General (Fixed)
IPTV: Movistar TV stops LiveTV playback after a while
Reported by: | 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)
Change History (7)
comment:1 Changed 8 years ago by
Status: | new → infoneeded_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 8 years ago by
Could this be related? https://code.mythtv.org/trac/ticket/12558
Qt 5.4.2 has a bug with QUdbSocket and readyRead().
comment:3 follow-up: 6 Changed 8 years ago by
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 8 years ago by
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 8 years ago by
Interesting. Thanks for the detailed info. I'll take a look into it.
Regards, Antonio
comment:6 Changed 8 years ago by
Milestone: | unknown → 0.28 |
---|---|
Resolution: | → Fixed |
Status: | infoneeded_new → closed |
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.
mythfrontend --loglevel debug -v playback