Iptv Stream Checker 3.0.5
Esmeralda Rusinski
The issue in short: same IPTV stream which works with VLC on Windows
, and works with Kodi on Android is not works with Rpi.
For the log: all devices are in the same network, using the same account
, conecting to the same stream for test.
I bought a iptv package from Rapid IPTV. The all streams and VDO work on VLC (Windows PC)
, and with Kodi (16.1) for Android.
But I cant seem to get it to work on my Raspberry pi 3 with OSMC installed on it.
Well here is the deal as @actiona also said in the same thread, how can any provide give access so cheap to every premium channel out there, there is a question of legality here thats why your thread hasnt gotten alot of attention.
If it would be my code, i could do a debug, and maybe I should start to learn it as it would take less time to solve this problem than to wait someone who is actually checking what i say, and not just copy and past some zen saying.
Before I have reported this issue, i did a long long search checking from linux side, checking from service provider side, checking other entries which may help. Go and link from this site any post which is related with IPTV, with this IPTV provider, where you can find any attached logs, or proper steps how to reproduce the problem.
Depending on your iptv service. If its not an authorized trusted paid service and instead one of these fly by night cheap card sharing services you would probably find they overselling there services or using cheap free streams. best way to check is try using another connection like your mobile phone and see if it gives same issues. will let you know more or less where fault is lying
My ISP delivers both internet and iptv over a fiber, and each of those are in separate VLANs. I have configured my router so that the WAN interface uses the internet VLAN, and I have created a separate interface for iptv on the iptv VLAN. This interface receives a separate IP over DHCP, and the STBs are within my LAN, so I have igmpproxy running with the iptv interface as upstream, and my LAN as downstream.
Everything works, but there is a performance issue that I haven't figured out. The multicast streams received by the STBs are typically somewhere around 7 Mbit/s each, and in my case there is a maximum of 4 simultaneous streams running, so an aggregate bandwidth of around 24 Mbit/s. However, in my testing I'm just using 1 stream, so less than 10 Mbit/s on average.
For example, if I run a Speedtest form my computer (which uses the WAN interface), I can provoke these issues. The WAN connection is capped on 300 Mbit/s (symmetric), and the problem seems worse on upload than on download.
The router is a Netgear R7800 running on 17.01 stable (a build based off of @hnyman's community build), so it should have plenty of power to handle this. I have tried building a firmware with the shortcut-fe patch included, but that didn't make much of a difference.
On a computer I assigned a static IP (192.680.10.66) in the IPTV network, and made this computer part of the network on the switch. Then I started an iperf3 server in UDP mode on this computer, and on a different computer in my LAN (192.168.12.101), I ran an iperf3 client. This simulates the traffic flow which happens for the TV, with the exception that it is unicast instead of multicast. That probably doesn't matter, since it is still UDP.
As you can see, that gives me a bandwidth of 600 Mbit/s. The IPTV stream does not become disrupted while doing this test. However, If I run some heavy data transfer (by using Speedtest) on the WAN connection, I get disruptions in the iptv stream. It seems that the disruptions are more frequent and severe during upload than during download.
@Nague: Good to hear that I'm not alone with this issue, but I find it hard to believe that this is unsolvable with the R7800. A dual core 1.7 GHz CPU should have enough power to handle this quite easily. The ISP home router (which I have too little control over) handles this without any problems, and that's also a Linux-based router (Zyxel FMG 3542). That's why I need to bypass it.
The big question still remains: How to achieve this? If the issue stems from the fact that the eth0 interface becomes saturated due to the high traffic, thus dropping some of the UDP traffic, how can this be avoided? I suspect that this is what's happening, I don't think it is the CPU that can't cope.
However, the physical speed of the eth0 interface is 1 Gbit/s, so there should be plenty of headroom for a 10-40 Mbit/s UDP stream in addition to the other internet communication which tops out at 300 Mbit/s in my case.
I found what looks like a workaround for this problem. I experimented a little with SQM, and when I enabled SQM on my internet VLAN (102) and set the speed to 200Mbit/s both on ingress and egress, I could run the speedtest without observing drops on the TV. However that means I sacrifice 100 Mbit/s of internet speed, so it isn't a desirable workaround.
I also tried enabling SQM on the parent device (i.e eth0), but that did not help. I still believe this is maybe the way to go, provided it is possible to prioritize the multicast (or just UDP, perhaps). The multicast traffic from my ISP comes with DSCP set like so:
I believe (well, more hope) it should be possible to use this for something, as the SQM settings has a setting for DSCP under "Advanced configuration". I tried fiddling with those settings (setting DSCP to "DO NOT SQUASH" and "allow"), but it didn't seem to do anything. Then I looked in the debug log, and found some errors that may have significance:
However, these errors appeared in the section for stopping the SQM instance, not in the starting section. Nevertheless that indicates it expected to see some rules relating to QOS there (which is why it wanted to delete them).
I'm struggling with the understanding of SQM and how I can prioritize ingress traffic marked with CS4. I've looked into the scripts, but I can't figure out how to do it. For instance, say I use cake and the script layer_cake.qos (and I also set DO NOT SQUASH and allow for DSCP). I set my interface to eth0, since this is the parent interface for both my internet and my iptv. If I then show the stats for eth0, I see something like this:
Almost all of the traffic ends up in the "Best Effort" category, it seems. There's also a Voice category that sees some traffic, but it's very little (and I don't know what traffic it is). How can I set up a category for the multicast video stream to give that priority? Is it even possible?
@moeller0: May I ask for your assistance here? Is it even possible to use SQM the way I want? In reality the iptv interface isn't bandwidth limited from the ISP side (only the wan is), but my issue is that heavy internet traffic disturbs the iptv traffic, and I guess it is because both use the eth0 interface as the parent.
So have a look at _cake/blob/master/sch_cake.c especially from line 1390, you will see that out of the available diffserv profiles diffserv8 and diffserv4 will treat CS4 maked packets as low latency (but beware cake will only give a small fraction of the available bandwidth to the low latency tier (there needs to be a cost/trade-ff for low-latency otherwise every application would request low latency, effectively resulting in normal or even high latency)). I would recommend you try diffserv4 based on the following:
static int cake_config_diffserv4(struct Qdisc sch)
{
/ Further pruned list of traffic classes for four-class system:
*
Correct, that is only sane after you checked that your ISP returns sane DSCP markings though. There have been reports of ISPs remarking lots of packets to CS1 (Background) and that might not be exactly what you want, better measure and then test whether it works as you find acceptable.
In that case I would expect setting a shaper on the internet VLAN with a rate of say 250Mbps might work (but make sure to instantiate a shaer on ingress and egress). Could you try starting with say 150Mbps for internet and successively increase the rate until your problems start to appear?
Yesterday I thought I had this solved, but that turned out to not be true after all.
My setup was cake with layer_cake.qos, and "Ignore DSCP on ingress" set to allow. I also edited defaults.sh and set the INGRESS_CAKE_OPTS, first to diffserv4, then to diffserv8.
With diffserv4, my video did not end up in the "Video"-tin, so cake obviously does not regard CS4-marked packets (which my ISP is setting for the video) as video. At first it seemed that running with diffserv8 my problem was solved, but for some reason after turning it off and then back on (and other combinations), the problem returned.
It is also somewhat annoying that I really don't understand why this issue appears in the first place. The maximum ingress of eth0 is 300 Mbit/s (capped by the ISP) plus the video stream (which is uncapped, but always under 40 Mbit/s), so total aggregate bandwidth is only 340 Mbit/s. This should not be a problem for this hardware even without any SQM.
The link from the ISP is gigabit fiber, which I currently terminate in a Cisco SG300 switch. As mentioned, the video and internet are in different VLANs, so in the switch I'm sending those two VLANs to my router WAN, and then I split it in two virtual interfaces, where the internet is my WAN, and the video has it's own interface that I have called IPTV.
Setting a shaper only on the internet VLAN did seem to work, but it also meant I had to sacrifice a lot of bandwidth, and I have issues understanding why that should be necessary. As mentioned in my previous post, the total ingress on eth0 will never exceed around 340 Mbit/s, which I would have thought it should be able to handle.
fc059e003f