I have one more issue with IPTV, after streaming for few minutes it gets stuck and gives error on my tv "live stream is not available" and starts again.
before giving it much brain power(?)... i'll take the lazy way out and say try 'release'(21.02.1) and see if the same behavior is present there...
It's not that big of an issue, I rarely use it and switching between channels resume the stream.
next time instead of re-installing run this... it will print more stuff to the log;
############## setup do once curl http://rpi4.wulfy23.info/misc/https-dns-debug.sh > /bin/https-dns-debug.sh chmod +x /bin/https-dns-debug.sh ### run once now then repeat later /bin/https-dns-debug.sh
(let it fail once or twice then run it again... restart the service... run it again... and PM me the output...
cat /tmp/https-debug then you can re-install)
Smells a bit like an unicast/multicast issue. Some IPTV solutions use unicast immediately after a channel switch, and the after buffers are filled to catch up with a multicast stream of the selected program it will use multicast and stop unicast. If there a multicadt issues they will hence have a behavior like yours.....
possibly related to your other issue still?
bottom of that thread says something about xaomi not supporting igmp? topology changed?
It was when I was trying to change my IPTV box location. Right now, IPTV device is connected with switch and switch connected with Lan port on pi4. I have had issues of stutter from time to time on IPTV stream but not the stream stopping altogether.
Mmmh, same switch port that worked before, or is the switch new?
I don't know how to diagnose it.
i owe you for the hassle above (and beta testing)... so offer on the table to login and poke around... might be difficult tho' as the tv is not always doing what i need to see... and testing micro adjustments/setting change is not so feasable remotely...
Same port as well, I assume then. I had asked thinking that maybe the switch might have not been configured for IGMP snooping on the relevant port yet. But if the same port used to work than that is unlikely to be the case... (you probably already restarted the switch*)
*) The old, 'have you tried turning it off and on again?" approach
curl http://rpi4.wulfy23.info/misc/https-dns-debug.sh > /bin/https-dns-debug.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3424 100 3424 0 0 3605 0 --:--:-- --:--:-- --:--:-- 10600 [root@network /]# chmod +x /bin/https-dns-debug.sh [root@network /]# cat /tmp/https-debug cat: can't open '/tmp/https-debug': No such file or directory [root@network /]# curl http://rpi4.wulfy23.info/misc/https-dns-debug.sh > /bin/https-dns-debug.sh +x /bin/https-dns-debug.sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3424 100 3424 0 0 10219 0 --:--:-- --:--:-- --:--:-- 10282 [root@network /]# chmod +x /bin/https-dns-debug.sh [root@network /]# cat /tmp/https-debug cat: can't open '/tmp/https-debug': No such file or directory [root@network /]#
you have to run it first... be aware it will undo your package re-install so... after you reproduce... you need to re-install the package....
how to run it? sorry for my noob questions
may as well PM about this now... could be alot of posts with little benefit to others...
yes, you can. Want me to give you remote access? and how to do it?
uci set zerotier.sample_wulfy23.enabled='1' uci commit zerotier /etc/init.d/zerotier enable /etc/init.d/zerotier start
can PM about this too... (other than findings main points... as it will also probably drag on a bit)
so @moeller0 does this look relevent
unknown 2 485 src=192.168.1.11 dst=188.8.131.52 packets=4 bytes=128 [UNREPLIED] src=184.108.40.206 dst=192.168.1.11 packets=0 bytes=0 mark=0 use=1
lan has igmp snooping enabled but iptv is separate zone... firewall?
##### uci show firewall | grep -i iptv firewall.@zone.network='wan' 'wan6' 'IPTV' 'accessmodem' ####### uci show network | grep -i iptv network.IPTV=interface network.IPTV.device='eth1' network.IPTV.proto='static' network.IPTV.ipaddr='10.10.10.1' network.IPTV.netmask='255.255.255.0'
basically doing some reading now on the whole extra zone / topology thing cause it's new to me as well... but like moeller first stated... mcast seems to run pretty good and could be some sort of 'unicast-command' over the zones thing or something...
(and what role if any a smart switch might have in that)
googled conntrack 'unknown proto'...
this talks about something called pim?
IGMP packets coming from LAN, to allow the router to keep knowing which multicast clients are listening: iptables -A INPUT -i br0 -p igmp -j ACCEPT My specific setup is using pimd and PIMv2, I don't know if this protocol is always used or not, but I had to allow the PIM protocol for it to work while keeping the DROP policy, when the source IP wasn't just 192.0.2.1 (but 10.4.4.5): iptables -A INPUT -s 192.0.2.1 -i eth0 -p pim -j ACCEPT
mrd6 - 2013-11-30-c805eb33255dbc0b6647d463c6c67d1c9d3105a0-3 - Multicast is becoming a major component in next generation networks, used in several scenarios, from video broadcasting to multimedia conferencing. In order to be implemented, new technology needs supporting hardware and software across a set of devices and systems. MRD6 is an implementation of a modular IPv6 Multicast Routing Framework for the Linux operating system and provides MLDv2 (as well as MLDv1), PIM-SM and MBGP support. pimbd - 2018-06-19-dbf4e5913b06e3160f506df15e6a047a403a5f21-2 - This package provides a daemon which implements the Protocol Independent Multicast BIDIR routing protocol. Note that a routing protocol must be installed and running in order for PIM to function.
next stop likely a full tcp-dump of both sides of everything or hopefully just the iptv stuff if I can get my head around how to grab it all (likely everything will be cleaner/safer)...