Project

General

Profile

Bug #2468

IPTV issue

Added by Andrius P about 10 years ago. Updated about 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
IPTV
Target version:
-
Start date:
2014-11-11
Due date:
% Done:

100%

Estimated time:
Found in version:
3.9.1977~gd347c3d~trusty and up
Affected Versions:

Description

Hi,

IPTV channels are working all OK. I'm able to view them on different devices by using VLC, XBMC, Plex, etc.
But there's an issue. If I'm watching IPTV channels on several devices at the same time and one of the devices stops watching a channel, IPTV streaming is stopped on all other devices as well...
If I start watching any channel on any device again then streaming resumes on all other devices.
It looks like stopping one channel stops all streams and unsubscribes from all multicast packets.

Any ideas? 'Status' page is showing 0 for 'Input' and 'Output' columns.

TvHeadend version - 3.9.1977~gd347c3d~trusty on Ubuntu Server 14.10.

2014-11-11 10:58:34.468 subscription: 0001: "HTTP" subscribing on "ch1", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "ch1", provider: "YYY", service: "Channel 1", hostname="127.0.0.1", username="xbmc", client="Lavf/55.44.100"
2014-11-11 10:58:43.825 HTTP: 127.0.0.1: /stream/channel/ab50948b34cd4c5ab0e169bac54feea4 -- 401
2014-11-11 10:58:43.826 mpegts: LRT in IPTV network - tuning on IPTV
2014-11-11 10:58:43.826 subscription: 0002: "HTTP" subscribing on "ch2", weight: 100, adapter: "IPTV", network: "IPTV network", mux: "ch2", provider: "YYY", service: "Channel 2", hostname="127.0.0.1", username="xbmc", client="Lavf/55.44.100"
2014-11-11 10:58:57.534 subscription: 0001: "HTTP" unsubscribing from "ch1", hostname="127.0.0.1", username="xbmc", client="Lavf/55.44.100"
2014-11-11 10:59:07.526 webui: Stop streaming /stream/channel/ab50948b34cd4c5ab0e169bac54feea4?profile=pass, timeout waiting for packets
2014-11-11 10:59:07.527 subscription: 0002: "HTTP" unsubscribing from "ch2", hostname="127.0.0.1", username="xbmc", client="Lavf/55.44.100"


Files

netstat.txt (1.54 KB) netstat.txt Andrius P, 2014-11-11 12:22

History

#1

Updated by Andrius P about 10 years ago

I thought that it's an issue with router but udpxy is working without any issues. I can watch IPTV channels on several devices at the same time and closing stream on one device does not stop other streams.

#2

Updated by Jaroslav Kysela about 10 years ago

All your IPTV streams shares one IP address ?

#3

Updated by Jaroslav Kysela about 10 years ago

I mean address in the source URL...

#4

Updated by Andrius P about 10 years ago

No, all IPTV channels have different IP addresses - udp::1234, udp::1234, udp::1234, etc.
I tried to change udp::1234 to udpxy address http://192.168.0.xxx/udp/239.2.3.11:1234, but result is the same. If I stop one stream, then all streams stop as well..

#5

Updated by Jaroslav Kysela about 10 years ago

The UDP is one-directional without any "close" notifications to the server.. Could you check, if subscribed multicast groups persist for "not closed" streams ?

netstat -g

With all streams and with one stream unsubscribed...

#6

Updated by Andrius P about 10 years ago

See attached for log. It looks like it's unsubscribing from all streams..
Lines 4 and 5 are IPs for channels.

#7

Updated by Jaroslav Kysela about 10 years ago

No idea - the UDP multicast socket should be closed using the close syscall and kernel should remove only IGMP membership related to the IP address assigned to fd.

#8

Updated by Sam Stenvall about 10 years ago

This happens with HTTP sources too. If you open two channel URLs in VLC, then stop one of them, the other one will die a few seconds later and "Stop streaming <channel>, timeout waiting for packets" will show up in the log. This seems to be a fairly recent regression since I can't remember seeing it before.

#9

Updated by Sam Stenvall about 10 years ago

To add to my last post, the HTTP sources I noticed this issue with came from a custom software that restreams video as MPEG-TS so that tvheadend can read them. No multicast is involved at any point.

@perexg is there some additional information you'd like me to provide?

#10

Updated by Jaroslav Kysela about 10 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|053c0e4bc3b747f2080c2458157610373374b141.

#11

Updated by Andrius P about 10 years ago

The issue was fixed. Thanks!

Also available in: Atom PDF