Feature #4621
RTP Discontinuity with Humax SAT>IP server
0%
Description
SATIP Server: Humax UHD 4tune+
TVheadend version: tvheadend_4.3-484~g442a871_armhf
running on Banana Pi Pro
Hi,
I'm not completely sure, but I don't think it's a bug with tvheadend itself, but rather a bug with the Humax firmware. Hence a feature request.
I keep getting occasional video artifacts. I traced with the satip parameter and found that "RTP Discontinuity" keeps showing up. Not all of them produce video errors, but if there is a video error (counter discontinuity), the RTP Discontinuity seems to be responsible.
I googled and found the tip to tune buffers, but to no avail. I'm not sure that's really the problem anyway. Both the Humax and the Banana pi that tvheadend runs on have Gbps ethernet and there should be no simple packet drops even on SD channels. I think the RTP discontinuity errors look a bit peculiar and different to the few logs I found through google. It's always the same pattern.
2017-09-22 20:32:40.262 [ TRACE]:satip: RTP discontinuity (47729 != 47730)
2017-09-22 20:32:40.262 [ TRACE]:satip: RTP discontinuity (47731 != 47729)
2017-09-22 20:32:40.262 [ TRACE]:satip: RTP discontinuity (47730 != 47731)
2017-09-22 20:36:50.294 [ TRACE]:satip: RTP discontinuity (38702 != 38703)
2017-09-22 20:36:50.294 [ TRACE]:satip: RTP discontinuity (38704 != 38702)
2017-09-22 20:36:50.295 [ TRACE]:satip: RTP discontinuity (38703 != 38704)
It's always like that, always the pattern
1 != 2
3 != 1
2 != 3
and always, absolutely always, 3 "RTP Discontinuity" errors at a time. Also, this problem did not exit on Humax firmware 1.00.16, but has in the three firmwares released since february and after more than half a year I've given up hope with them. With Humax firmware 1.00.16 I can watch and record multiple HD channels without these RTP discontinuity and continuity counter errors, but that firmware regularly freezes the SAT IP server and needs a hard reset when channel searching or updating the EPG (I think it does not like the frequency/speed at which tvheadend sends requests/subscribes when doing those tasks). Which makes it a major nuisance especially to initially set up.
Maybe there is a fix to this that can be done with tvheadend. If someone wants to do a fix (for either the RTP discontinuity on current firmwares or the channel/EPG errors with firmware 1.00.16) it'd really be appreciated. I'd just need to know what additional logs and tests would be required.
Files
History
Updated by Jaroslav Kysela about 7 years ago
Updated by Could you grab the UDP packets when tvh reports the discontinuty? (wireshark or tcpdump) ?
Updated by Hans Schneider about 7 years ago
Updated by Sorry for not answering earlier.
I have tcpdump installed, but I need some help with the command to make sure I capture and upload the right thing.
Would tcpdump -i eth0 -A -s 0 -w filename.pcap port 554
do the job?
I also tried "tcpdump -i eth0 udp -w filename.pcap"
If this is the right one, or another command that produces a file that's too big to upload: How many seconds around a RTP discontinuity should be kept after editing in wireshark?
Looking at the output of either of those in wireshark, I myself didn't notice anything. They looked the same to me at timecodes that the RTP discontinuities reported by tvheadend and when they are not
I don't have much experience with it though.
Thank you for your help!
Updated by Hans Schneider about 7 years ago
alternatively, as I mentioned in the initial post, watching channels works very well with tvheadend in combination with an older humax firmware.
I've used it for months before trying the latest firmware again. It just has that bug that makes the satip part of the humax freeze eventually when enabling the OTA EPG cron job and (longer) channel scanning like during the initial setup.
Would it be a big modification I'd have to make in my local builds to test if those two things would not make the humax freeze if the frequency of subscriptions during those tasks is lowered, i.e if there is e.g. a (bigger) delay between tunings? If putting a delay is possible, could you please help me with pointers on what I'd have to change?
Updated by Jaroslav Kysela about 7 years ago
The tcpdump should be like:
tcpdump -i /DEVICE/ -s 1500 -w filename.pcap ip host /IP_OF_YOUR_SATIP_SERVER/ udp
Export just few seconds before and after the discontinuity (get the time from the tvh's log).
Updated by Hans Schneider about 7 years ago
- File humaxsatip2.pcap humaxsatip2.pcap added
That gives me a syntax error. I ended up using
tcpdump -i eth0 udp -s 1500 -w filename.pcap
now. Shouldn't really be a difference because all traffic on eth0 of the ARM board running tvheadend is with the humax satip server.
The pcap file contains ~2 seconds before and after the RTP disontinuity
2017-10-20 16:44:58.811 [ TRACE]:satip: RTP discontinuity (29222 != 29223)
2017-10-20 16:44:58.811 [ TRACE]:satip: RTP discontinuity (29224 != 29222)
2017-10-20 16:44:58.812 [ TRACE]:satip: RTP discontinuity (29223 != 29224)
2017-10-20 16:44:58.812 [WARNING]:TS: DVB-S Network/12544.75H/SAT.1 Gold: MPEG2VIDEO @ #1279 Continuity counter error (total 46)
I disabled all tuners except for one. The tcpdump capture includes ~10 seconds before and after that RTP discontinuity.
Updated by Jaroslav Kysela about 7 years ago
I found the culprit. The tvheadend receives the UDP packets out-of-order, so the sequence is like:
29220 29221 29223 29222 29224 29225
There is no correction for this situation in the current code.
Updated by Jaroslav Kysela about 7 years ago
Retest with v4.3-583-g142d3ed91 , show 'RTP discontinuity' lines from log, if something does not work.
Updated by Hans Schneider about 7 years ago
- File 4.3-583-g142d3ed91.log 4.3-583-g142d3ed91.log added
With that build I always get a "No signal" error message and the channels never start showing. On the status page of the tvheadend webinterface it shows the SNR and Signal strength bars like normal while trying through the tuners. In the log it says "service instance is bad, reason: No input detected"
Updated by Hans Schneider about 7 years ago
That build looks very good. Have left it running a few hours and also recorded a few things as a test without errors. In the log, all RTP discontinuity messages now look like
2017-10-22 20:13:35.666 [ TRACE]:satip: RTP discontinuity (43800 != 43801), queueing packet
2017-10-22 20:13:35.666 [ TRACE]:satip: RTP discontinuity, requeueing packet (43801)
which I'd guess is the wanted behaviour. It really works great now.
Thank you so, so much for your patience and time to make the fix!
Updated by Mono Polimorph about 7 years ago
Updated by Hi,
As this "re-order" is done for RTP... why not move the code for IPTV inputs too? Now the code applyes only to the SAT>IP input, but other inputs can receive RTP packets as well.
Please, see this only as a suggestion. I comment it only because I see that the code is in the satip-client section. And perhaps will be interesting to share the code with other modules.
Regards. 
Updated by Maik Horn about 7 years ago
Updated by Hi,
i have similar errors. Normally everything runs fine for hours. But as soon as i start copying a large file over the network, i get massive problems with UDP:
2017-11-01 14:28:37.951 [ TRACE]:satip: Status string: 'ver=1.0;src=1;tuner=5,178,1,15,11493.75,h,dvbs2,8psk,on,0.35,22000,23;pids=18,5100,5101,5102,5103,5104,5105,5106,8187,0,1,16,17'
2017-11-01 14:28:38.089 [ TRACE]:satip: RTP discontinuity (31018 != 31019), queueing packet
2017-11-01 14:28:38.090 [ TRACE]:satip: RTP discontinuity (31018 != 31020), queueing packet
2017-11-01 14:28:38.090 [ TRACE]:satip: RTP discontinuity (31018 != 31021), queueing packet
2017-11-01 14:28:38.090 [ TRACE]:satip: RTP discontinuity (31018 != 31022), queueing packet
2017-11-01 14:28:38.091 [ TRACE]:satip: RTP discontinuity (31018 != 31023), queueing packet
2017-11-01 14:28:38.091 [ TRACE]:satip: RTP discontinuity (31018 != 31024), queueing packet
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, reset sequence to 31019 from 31018
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity (31018 != 31025), queueing packet
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31019)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31020)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31021)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31022)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31023)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31024)
2017-11-01 14:28:38.101 [ TRACE]:satip: RTP discontinuity, requeueing packet (31025)
2017-11-01 14:28:38.102 [WARNING]:TS: Astra1/11493.75H/Das Erste HD: H264 @ #5101 Continuity counter error (total 121)
2017-11-01 14:28:38.102 [ TRACE]:satip: RTP discontinuity (31026 != 31027), queueing packet
2017-11-01 14:28:38.102 [ TRACE]:satip: RTP discontinuity (31026 != 31028), queueing packet
2017-11-01 14:28:38.103 [ TRACE]:satip: RTP discontinuity (31026 != 31029), queueing packet
2017-11-01 14:28:38.103 [ TRACE]:satip: RTP discontinuity (31026 != 31030), queueing packet
2017-11-01 14:28:38.104 [ TRACE]:satip: RTP discontinuity (31026 != 31031), queueing packet
2017-11-01 14:28:38.104 [ TRACE]:satip: RTP discontinuity (31026 != 31032), queueing packet
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, reset sequence to 31027 from 31026
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity (31026 != 31033), queueing packet
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31027)
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31028)
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31029)
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31030)
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31031)
2017-11-01 14:28:38.105 [ TRACE]:satip: RTP discontinuity, requeueing packet (31032)
Maybe its related to this problem otherwise a hint to right direction would be nice, cause i don't know how to handle this.
Updated by Maik Horn about 7 years ago
To be clear i mean "But as soon as i start copying a large file over the network, to the same machine TVH is running on."
Updated by
Updated by Jaroslav Kysela about 7 years ago
@Maik Horn : It looks like a lost UDP packet issue. We cannot do anything. Tune your ethernet network. TVH tries to queue few packets and if the missing one is not received, the queue is processed in this case (and it's visible in the log you provided).