Before banging my head against the wall of calling my ISP support line…
I have their router connected to the red network. It is the only physical connection between the router and my IPFIRE PC.
I don’t note any dropouts on my normal green network PC with streaming, for example YouTube videos.
But, my wired, static IP TV seems to get dropouts during normal viewing. I haven’t been able to localize it to a particular TV channel or other streaming service. It will, for instance watching the news, just stop for a second or two, then pickup where it was. (For example, in the middle of a sentence, then pickup without loosing a word.)
Any idea on how I could trouble shoot this?
I’d like to have pretty good evidence before I call the ISP…
can it be a problem of video codec, as in the GPU of your machine does not support the video codec used by the streaming service? This is what was happening to a friend of mine. He had a cheap Chinese set top box. I could not find anything wrong with his IPFire setting and He had a more than adequate bandwidth, so I tried the minipc that I use as a top box tv, and all the frame drops went magically away.
A Samsung tv has a codec for live network streams?
I suppose it does, since it is probably running some flavor of Linux (I guess)
try to watch iptv on a computer that is not too old using VLC or KODI, see what happens.
Edit, I assume you have correctly installed and configured igmproxy on your IPFire router.
absolutely not being an expert on smart TVs (I always try to avoid such devices ), you problem sound like running
for both the RED and GREEN interface of your IPFire machine might be a good first step: That way, we can see what is actually going over the wire, and what happens during the times you experience network hiccups.
tcpdump can be installed via Pakfire, please refer to this wiki page for further information.
To avoid confusions and doing multiple things at once (which makes it hard to tell which exactly solved the issue), I just keep any further advise for myself and wait for you to report back.
Thanks, and best regards,
No idea why I’d install igmproxy…so, nope, not installed.
The issue happens randomly, how would one shift through the out generated by tcpdump to find this needle in a hay stack?
OK, let me ask you this, you have an IPTV provider, right? You have a router that is bring internet in your home (for example and ADSL or a cable). You have connected the router to your IPFire machine, and you have conneted your samsung smart TV to the IPFire machine. Did I get everything right?
But, AFAIK, there is nothing “TV” special about my cable service.
so, how do you get an IPTV. Do you have a provider?
Spectrum (used to be Charter) cable modem.
Aha!..light just kicked on.
The TV feed is being provided by YouTubeTV app on the SamsungTV.
Ah, ok. Then ignore what I have said about igmproxy and the codec. You are not using an IPTV, where the tv feed arrives as a multicast (hence the need of using igmproxy add on) nor it is a codec problem.
I would follow @pmueller suggestion then. Also, personally I would hook up the televison directly to your router, bypassing IPFire, just to exclude it is IPFire that is causing the problem.
if IPFire turns out to be causing this problem, it might be useful to give Core Update 159 (testing) a try, as this release comes with a new major version of the Linux kernel, hence changing a bunch of networking code:
Well, first, you might want to limit
tcpdump to the actual traffic, such as from your TV’s IP address (GREEN) and to relevant destinations (RED). Then, however, you will need to have roughly an idea of the timeframe a network hiccup occurred - sorry.
Thanks, and best regards,