hi there… question, since over here i might get fiber with ( different VLAN) TV…does this mean that TV over fiber does not work with a Turris?
If it is multicast based it will not work with TurrisOS 6. Alternatively you could use TurrisOS 5.4.4 or Openwrt 21.02.6. I made the observation that multicast in Openwrt 21.02.7 is broken as well
1 Like
Short answer: Yes, unfortunately, unless the problem is analyzed in-depth for a (user applicable) fix (on Turris Omnia).
I can’t recommend buying Turris products after all the trouble I had with various essential functions even when using the command line through SSH to put things together - something that does not bother me at all by itself.
For me, multicast streaming last worked with Turris OS 3 on my Turris Omnia.
I skipped version 4 and 5 because of significant (quality) issues and finally updated to 6.
Recently, I retested streaming on Turris OS 6.3.2 - to no avail.
I also found that at least IGMP was not passing through the LAN/Switch despite proper firewall/filter tables etc… igmpproxy and udpxy could therefore not even try to fulfill their purpose. However, unproxied (direct) streaming through WAN worked locally on Turris, I was able to stream into a watchable video file using ffmpeg and saw expected traffic.
Given limited out-of-the-box debugging tools and available time, I did not bother any further and put the Turris aside to handle only my legacy WiFi. I might give it away at some point.
The other reason for that is that I put together a 25 GBit router that works with pfSense and currently with plain netfilter (nftables) - just because the experiment was actually fun and yielded expected results after a few hours - not something I can say about Turris OS/OpenWrt.
1 Like
That’s not entirely true - udpxy doesn’t care about IGMP working on the LAN side. That’s the point of it. It translates multicast to unicast, so if you are able to get the stream from the WAN locally on the Omnia, so will udpxy.
I resorted to this setup after fighting this for some time and it works, but it’s a bit painful - requires udpxy support in the player or some search&replace on the playlist. But works for now.
However, it seems that my Omnia is destined the for same future as yours. I used to be excited about the 10gig version (if it ever comes out), but after this & the 6.0 push fiasco… sorry, not interested.
You’re absolutely right about udpxy on Turris, didn’t think about that.
In my setup, it sits next to streaming clients at a separate Switch and WiFi AP (on a NAS behind NGINX, which serves corresponding station playlists and larger file shares). WiFi throughput/stability was the main reason for me to set up udpxy.
Anyway, it’s unfortunate that we seem to have very similar issues in general.
Well, that can be a major reason for slow sales to an average joe like myself, since cable tv is slowly replaced by fiber ( VLAN ) tv.
Most of the technical stuff published in this topic is far beyond my knowledge about IGMP and such, therefore my question.
And if i understand correct, this is a kernel, and /or openWT flaw that can only be solved by users?
as stated, fiber IPTV is the future, so a major (sales) Bummer.
Unfortunately, facts speak for themselves. Just look at the changelog of the last 3 versions and check what Turris is focused on. We’re got a network routing appliance that cannot do core networking stuff like multicast but that can run Librespeed, Syncthing or even Transmission, and the problem hasn’t even been acknowledged by anybody maintaining the firmware. Now read between the lines 
As usual, there are many possibilities without knowing the actual cause of the problem. It could indeed be a problem in the kernel (network modules) or any other binaries requiring a patch for Turris OS or the underlying OpenWrt followed by a regular Turris OS update on the device. Or it could be some not so obvious config issue that can also be fixed by most users through the web UI or SSH until the fix is added to the OS package.
Since unicast streaming with udpxy is at least troublesome if even possible to set up on a TV or a proprietary streaming box, I’m afraid that a Turris is currently not a good option.
1 Like
This is indeed a kernel/driver flaw, either something in networking stack of the kernel or (more likely) the switch/NIC driver. It is pretty hard for a kernel bug to be solved by users to be honest ;-). But Turris support shows no interest in this… even though it’s their problem, or potentially openwrt problem, but openwrt will likely want nothing do with it (clearly), since Turris is not their device.
So it’s either on the community (with the understanding that not many people have the required knowledge or have time and experience to troubleshoot it), or to get cznic support to actually care 
2 Likes
I’d recommend contacting their official support via email (this forum is not the correct channel for support requests).
This way, they will have the info from multiple users and can prioritize based on number of tickets.
many tickets = bigger pressure to fix the issue
1 Like
I’d recommend contacting their official support via email (this forum is not the correct channel for support requests).
Personally this is something I’ve done, their reply is somewhere in this forum thread.
1 Like
just to be clear, this is about ‘official’ iptv that one is receiving from a ISP, correct?
Since i also read IPTV with kodi ( or simulair clients on android boxes with less 'official" IPTV suppliers ) … The latest one works without any problem , someone told me 
So, i assume this is about official ( VLAN ) IPTV Correct?
The one provided by your internet/cable provider/operator.
Specifically based on IP multicast and where you usually have a separate set top box provided by the provider.
The box connects to the network via a standard RJ45 ehthernet cable, directly to the Omnia.
The igmpproxy allows the cable box itself (on the internal network) to join multicast groups, that are available on WAN interface of the Omnia.
Whether VLANs are involved or not, depends on the provider/operator and their technical setup.
1 Like
My android phone, as well…
1 Like
Now, I understand that if I used linear television I would be unhappy if my router would not support it, so all affected have my sympathies. On the face of it multicast looks like a decent solution (for some definition of decent) but this simply is a rather under-tested piece of code (few users actually use multicast in the first place, so as unpleasant as this might sound, this is a niche use-case. I am sure team turris would like to be able to help, but I assume they have more urgent things to work on, like moving TOS to OpenWrt 22, so its underpinning will not ne EOL’d soon).
I doubt the niche part? Since IPTV over fiber is getting more and more common? And far more common ( if you want to have healthy sales ) than one might think? Maybe not amongst the current die hard CLI users, but for an average joe defenitly.
Yes, multicast is certainly not niche. Multicast support has been part of the basics for decades now. It was first standardized in the 1980’s.
IPTV is just one application that runs on top of the fundamental multicast protocols and is certainly gaining in importance. Maybe the number of users is not large enough yet in some countries.
But dismissing these problems with arguments like “niche application” would simply be ignorant and will indeed hurt the project more with every day that goes by.
Excluding potential customers with standard requirements is completely absurd by any standards of market research.
They are basically already missing out on millions of potential customers by ignoring basic multicast requirements for IPTV, not to mention other applications like audio/video calls/presentations, especially also business applications in that area.
My ISP actually offered Turris for a while but soon ditched it…
So my opinion has only been solidified by the discussion here: Turris is dead - at least until someone with a clear view on reality takes control.
I mean, they are selling quiet expensive hardware, it’s not just another open source project where they can say: It’s free, take it as it is or f**k off.
Not sure what’s the end goal of your rant here. If you are looking to get the issue resolved, this might no be the best approach.
Turris is a project run by the .cz TLD registrar (essentially a government body), here in Czechia and believe me, the $1M they raised back in 2016 is long gone, and the project itself is understaffed. As far as I am concerned, they are my heroes for continuing to support their HW for many years and providing auto-updates and new features (I have lived the pure OpenWrt life, and don’t particullary like burning summer weekends on updating my router - manually, and migrating the config - also manually).
You are free to contribute to either OpenWrt or Turris. If this is not something you can do, then either go to 5.4.4 or just buy another router. It’s OK.
Sidenote (@DIKKEHENK): IPTV via unicast is also quite common, and something that many providers do (e.g. to enable users to watch TV on mobile devices or computers; VOD and PVR).
I mostly agree. However, nobody wants problems, not even for free. And Turris is not free, there’s no room for the aforementioned “OSS attitude”. Companies selling commercial products (not the sames as collecting substantial donations and compensating with first batches of hardware) should be glad that they can build their product on OSS and at least ask the community for support with problems their paying customer have and not ignore them. The apparent “fix it yourself” or “we don’t care” attitude will certainly not generate more income to hire the devs needed.
And btw. I did try to build Turris OS to fix issues. But the effort to even get a proper testable package that works was too high in comparison to other Linux distros or even “from scratch” builds a few years back. If they would be working only on OpenWrt support, it would be a different story. So yes, I don’t bother anymore, but I’d still like for this project to succeed. And that’s not something the community can turn around by itself, apparently…
1 Like
There are multiple ways of implementing IPTV, multicast is only one if them (actually, probably better seen as “several” as there are multiple multicast versions).
For the ISP multicast is attractive as even for multiple users watching the same prgram only a single data stream is needed, but that really only pays off if users watch the same and are willing to do so at the same time…
Whether multicast is becoming more and more common or whether it stays “niche” is IMHO an open question. This is linked with the fate of linear TV, if people “cut the cord” and move to on-demand streaming, then multicast is not an obvious improvement anymore…
I apologize for formulating too terse here; IMHO it does not really matter for how long a standard has existed if the question is maturity, correctness and performance of deployed implementations, multicast code in an OS will bit-rot unless the code is actually exercised routinely. Not sure about multicast, but ,y take is that it has seen little wide-spread usage in the last decades and hence I question the quality of implementations a bit.
IPTV does not care, it can just as well run over uni-cast, and IIUC some implementations actually do both, on channel switch they start with uni-cast all the while establishing multicast subscription in the background and switch over after a few seconds…
Whether linear IPTV gains importance or not I can not say… and I do not argue that multicast should not work, but I only state that due to long under-use I am not surprised implementations might not be up to snuff…
Since I am not in any way involved with the “project” orther than having bought an omnia in the crowdfunding campaign, please do not use my words/assessment against team turris, they are innocent here 
The second part is conjecture, or do you have proof of widespread multicast usage over the wider internet?
ISPs tend to have different selection criteria for routers they offer than end-customers, namely keep support calls to a minimum, which in my experience often means that ISP routers only offer few features/options.
Again, not speaking for team turris, but that seems a harsh assessment based on muticast? Especially since it is not even clear whether the ISP actually uses multicast in a standards conformant way…
Mmmh, now I would also assume that a “router” would qualify for normal router duties, but did they actually ptromise multicast IPTV capabilities pre-sale?
1 Like