Opened 5 years ago

Closed 4 years ago

#12188 closed Bug Report - General (Fixed)

Movistar TV: IPTV random tuning

Reported by: amlopezalonso@… Owned by: Karl Egly
Priority: minor Milestone: 0.27.6
Component: MythTV - Recording Version: Master Head
Severity: medium Keywords: IPTV, Movistar TV
Cc: Ticket locked: no



I use an IPTV Recorder setting in order to watch spanish Movistar TV by means of a m3u playlist. Things are I randomly manage to properly watch channels 10-20% of times, whilst the rest issue a "Couldn't read first 2048 bytes" message. VLC on the same machine has no issues when tuning those channels using the same (though properly formatted) m3u file.

Attaching full BE/FE logs.

Regards, Antonio

Attachments (2)

BE.log (1.2 MB) - added by amlopezalonso@… 5 years ago.
BE log (level: debug; verbosity: all)
FE.log (1.4 MB) - added by amlopezalonso@… 5 years ago.
FE log (level: debug; verbosity: all)

Change History (12)

Changed 5 years ago by amlopezalonso@…

Attachment: BE.log added

BE log (level: debug; verbosity: all)

Changed 5 years ago by amlopezalonso@…

Attachment: FE.log added

FE log (level: debug; verbosity: all)

comment:1 Changed 4 years ago by Karl Egly

Component: MythTV - GeneralMythTV - Recording
Owner: set to Karl Egly
Status: newaccepted

Sorry for taking so long to look at this. It appears that you have configured plain UDP as transport when other sources on the internet and your logfile suggest that the data really is transported via RTP.

2014-06-25 21:55:42.849531 D  IPTVChan[1]: IsOpen([data]udp://[fectype][fec0][fec1]) false
2014-06-25 21:55:43.080972 D  MPEGStream[1](0x7f9c0c015c00): Resyncing @ 0+1 w/len 780 -> 28

The adjustment by 28 bytes per received packet suggests that there is a RTP header in front of the raw MPEG2TS data. But it also suggests that it is not the minimum 12 byte header but a bit more instead, which #11852 is about.

Things you can do now: Verify the transport VLC ends up using really is RTP. (something about access module RTP in the module tree within the messages window)

Things you likely need to do later: update your playlist to signal the RTP transport (just change udp:// to rtp://)

Things we have to do: fix #11852

Then this has to be tested again.

comment:2 Changed 4 years ago by amlopezalonso@…


I can confirm that VLC uses RTP. But when I tried to import the RTP playlist into MythTV (one year ago) it didn't work. Only replacing rtp with udp seemed to work.

I don't really know whether this behavior has changed since then. I will retest the same playlist as in VLC.

Regards, Antonio

comment:3 Changed 4 years ago by Karl Egly

Status: acceptedinfoneeded

I have pushed a likely fix to master four days ago. See [90b98524e04e5a37112e038bd9c5da6958fbf4f1].

If that does not fix recordings from Movistar TV via RTP then I could use some actual network packet traces (e.g. made with Wireshark when playing back a stream via VLC) to try and hunt it down.

comment:4 Changed 4 years ago by amlopezalonso@…

I'm getting this when compiling:

make[2]: Leaving directory '/usr/local/share/datos/tmp/desarrollo/mythtv.git/mythtv/external/FFmpeg'
(cd qjson ; /usr/lib/x86_64-linux-gnu/qt5/bin/qmake -o Makefile)
[ -f qjson/include/QJson ] && \
  (cd qjson/include ; rm -f QJson ; ln -s -f ../src QJson)
Makefile:47: recipe for target 'qjson-all' failed
/usr/bin/make -C qjson all
make[1]: [qjson-all] Error 1 (no tiene efecto)
make[2]: Entering directory '/usr/local/share/datos/tmp/desarrollo/mythtv.git/mythtv/external/qjson'
cd src/ && ( test -e Makefile || /usr/lib/x86_64-linux-gnu/qt5/bin/qmake /usr/local/share/datos/tmp/desarrollo/mythtv.git/mythtv/external/qjson/src/ -o Makefile ) && /usr/bin/make -f Makefile all
make[3]: Entering directory '/usr/local/share/datos/tmp/desarrollo/mythtv.git/mythtv/external/qjson/src'
compiling json_parser.c (g++)
In file included from parser.h:24:0,
                 from parser_p.h:25,
                 from json_parser.yy:26:
qjson_export.h:23:28: fatal error: QtCore/qglobal.h: No existe el fichero o el directorio
compilation terminated.

Any ideas?


comment:5 Changed 4 years ago by amlopezalonso@…

Ah! Nevermind. Got qtbase5-dev installed in Debian stretch and it's gone now.


comment:6 Changed 4 years ago by amlopezalonso@…

Fed a VLC-compatible playlist into MythTV and it throws:

IPTVChanFetch: DownloadPlaylist failed to download from /home/user/MovistarTV.m3u

The file has world-readable permissions.

A sample from the .m3u file:

#EXTINF:-1,Canal Sur Andalucía [2275]
#EXTINF:-1,Sundance [1039]
#EXTINF:-1,NAT GEO [740]

Any ideas?

comment:7 Changed 4 years ago by Karl Egly

MythTV expects a "channel name" in the form "channel number - channel name". IIRC it also gets confused by the @ sign. Here is an example for a MythTV style playlist. (guessing that the number in square brackets is the channel number)

#EXTINF:-1,2275 - Canal Sur Andalucía
#EXTINF:-1,1039 - Sundance
#EXTINF:-1,740 - NAT GEO

comment:8 Changed 4 years ago by amlopezalonso@…

Thank you. It's working now with Movistar TV!


comment:9 Changed 4 years ago by amlopezalonso@…

However livetv playback stops after a while getting lots of:

2015-09-29 20:35:35.020889 E  decoding error
                        eno: Error desconocido 541478725 (541478725)

Should I open a new bug report?


comment:10 Changed 4 years ago by Karl Egly

Milestone: unknown0.27.6
Resolution: Fixed
Status: infoneededclosed

Yes, please open a new bug. I vaguely remember hearing of such a behavior (recordings are working, but LiveTV does not) before.

Note: See TracTickets for help on using tickets.