Bug #2146
Latest git build kills ADSL modem completely; internet and IPTV segments die completely
0%
Description
Hi,
I updated today to Git build revision c7e812bd and the same below problem happened. I was writing the below issue on Sunday but wanted to double test this issue before posting. Due to today's test it really seems that Tvheadend's IPTV at least with Inteno DG301AL modem and Telia-Sonera's IPTV is completely broken. Here goes the post which was written on last Sunday but was not posted (old post in quotes):
"I updated yesterday to Git build revision 7a06f00d. Immediately after updating and starting Tvheadend my ADSL went down. I couldn't even ping my ISP's gateway. ISP is Telia-Sonera. This was using old config. After that I decided to backup the old config and start from a clean slate with a fresh config. I managed to add 3 IPTV muxes with Tvheadend still working fine, but the 4th stream completely killed my ADSL gateway. I tried using two gateways (Thomson and Inteno) and the effect is the same. I've tried to configure the IPTV network with Network Discover on and off without any luck getting things to work.
Telia-Sonera has divided the internet traffic to VPI.VCI 0.33 and the IPTV traffic to VPI.VCI 0.35. Both "channels" / "pipes" go completely dead. The IPTV pipeline doesn't move any traffic. Same with the internet traffic pipeline. After restarting the gateway I can't even get DHCP UDP packets moving if the latest Tvheadend is up."
Last working revision for me is HTS Tvheadend 3.9.660~g4c7fc77. After reading the repository changes there seems be a lot of changes related to IPTV stream handling between my last working revision and the latest one. I have not backtracked builds this time. I was hoping a dev would suggest a specific build number which I could test out. Also, while running the non-working Tvheadend I see a lot of multicast traffic going through the ethernet adapter by checking the traffic out with Iptraf program.
The most worrying thing is that I heard that even the neighbours complained on Sunday that there were ISP troubles. Today (Tue 17th) I received a word from my ISP that there was not any large fault reports during the weekend (I created a fault incident on Saturday). Whatever the issue here might be, these neighbour issues should be treated as rumours. I do not have any solid proof that Tvheadend would go as far as killing out the ISP's gateway as well or the gateway blacklisting my connection for a while (I wouldn't even have the tools to see what the ISP's gateway is doing and seeing in the network). After all this being said, I'm a bit hesitant to do random testing. Any solid pointers with valid testing arguments are needed.
Currently I can't upgrade Tvheadend, which makes me a sad panda. I figured that this issue should be brought up. Maybe a dev would have some input on the issue.
Best Regards,
Jooseppi
History
Updated by Joo Seppi over 10 years ago
About not providing logs:
I ran the non-working Tvheadend builds with the standard -d option and did not receive any errors.
Updated by Joo Seppi over 10 years ago
Git revision 7083b9c3 behaves the same. No debug info available.
Git revision fdb9fd64 gives out two lines on the first start:
1) 2014-06-23 17:43:08.298 [ ERROR] iptv: read() error Function not implemented
2) Segmentation fault
Updated by Joo Seppi over 10 years ago
Managed to compile and run build HTS Tvheadend 3.9.992~g41a6af0 today. On the first start the scanning failed on a lot of the channels (used existing tvheadend configuration). I just put the failed ones to the state PEND and the scanning went through fine. A thing worth mentioning is that I also recreated my compiling environment from scratch. The environment is based on a qemu-arm-static Debian 6 / Squeeze chroot running under Debian 7 / Wheezy host. The tvheadend itself is running on a ReadyNAS NV+ V2 which is ARM based.
Updated by Joo Seppi over 10 years ago
Noticed I didn't add the specific Git revision above. It is 41a6af0c.
Updated by Jaroslav Kysela about 10 years ago
- Status changed from New to Fixed
Please, retest with current master. Note that the IPTV client cannot take down any device. It looks like an ISP or a router failure.