Enigma2 IPTV auto-reconnect

I just set suls to 5002 with serviceapp. What I've noticed is older boxes cant handle over 6k bitrate
Does epg work with serviceapp? I know it didn't used to.

Ok I'm having the same issue on my main supplier as the original poster had. If I set to true, 1, 1024, 15 it resets every 15 seconds. If I set to probes threshold to 20 it resets every 20 seconds and so on. I've tried changing the RX queue threshold to higher and lower but still the same. Weirdly it works ok on my second supplier and just resets when it needs to. I don't get much buffering or freezes on my main supplier so for now have set it's output as m3u8 so bigmac ignores it.
 
It seems I need to add support for multiple providers to settings and match those against a service string, instead of a simple enable/disable and one size fits all, with the exception of the stuff that's filtered... I might look into it this weekend.
 
  • Like
Reactions: r0b
It seems I need to add support for multiple providers to settings and match those against a service string, instead of a simple enable/disable and one size fits all, with the exception of the stuff that's filtered... I might look into it this weekend.
If I can be any help please let me know :)
 
If I can be any help please let me know :)

Updated BigMac to 6.2.1a, with 3 new threshold settings blocks that are matched on user defined string(s) - they're matched in order with global settings last (1, 2, 3, global) - of course global settings match all services that weren't matched previously.
 
I have a couple of suggestions to improve the plugin if you are open to them ?

Firstly I think this has been mentioned before, but is there anyway you could remove the infobar when a restart occurs ? I know it can be disabled in the image, but I'd sooner keep it enabled for other things.

And secondly, and more importantly, could you incorporate a small delay before the plugin starts monitoring after a channel change ?

The reason being that often some links for certain channels from a provider are down and when you zap to them, if they are down, the plugin tries to restart the channel. This results in a spinner and the box being locked. This only happens on providers that require keen settings where the Consecutive Probe Threshold Count has to be set to a low value. But it does happen. Providers that are ok with a higher setting do not suffer from this issue. Adding a delay would allow the user to zap to the channel and see that it was indeed down and then move on before the plugin begins trying to restart the dead stream.
 
Great update oottppxx and thanks for your hard work. I still cannot get it to work properly on one of my providers. It just resets after 15-20 seconds whichever its set to. It seems to happen more on SD channels for some reason. FHD ones don't suffer as much. Is there anything else I can try?

Cheers
 
SD channels probably don't tax the network as much, so they'll fall under your RXQ Threshold more often, I'd presume? Try lowering this threshold quite a lot, it wouldn't be bad if you debugged a bit on the box while watching said channels and looked at the output of "netstat -atn" a few times to see the typical values.
 
  • Like
Reactions: r0b
I have a couple of suggestions to improve the plugin if you are open to them ?

Firstly I think this has been mentioned before, but is there anyway you could remove the infobar when a restart occurs ? I know it can be disabled in the image, but I'd sooner keep it enabled for other things.

And secondly, and more importantly, could you incorporate a small delay before the plugin starts monitoring after a channel change ?

The reason being that often some links for certain channels from a provider are down and when you zap to them, if they are down, the plugin tries to restart the channel. This results in a spinner and the box being locked. This only happens on providers that require keen settings where the Consecutive Probe Threshold Count has to be set to a low value. But it does happen. Providers that are ok with a higher setting do not suffer from this issue. Adding a delay would allow the user to zap to the channel and see that it was indeed down and then move on before the plugin begins trying to restart the dead stream.

Published 6.2.1b with zap indicator and zap delay settings, should fit the bill.

Note that we apply the zap delay after zapping, but not after restarting a service via the plugin... Let me know how this works, or if it needs redone.
 
Sweet.

Many thanks. Great enhancement. It was horrid when the box locked up because the plugin was constantly trying to restart a dead stream after zapping to one.
 
SD channels probably don't tax the network as much, so they'll fall under your RXQ Threshold more often, I'd presume? Try lowering this threshold quite a lot, it wouldn't be bad if you debugged a bit on the box while watching said channels and looked at the output of "netstat -atn" a few times to see the typical values.
Thanks mate I will give it a go :)
 
Thanks mate I will give it a go :)
No worries; the other way is just turning on debug on the plugin and use the "tail -f /tmp/bigmac-debug.log" to see debug info in realtime... once you zap to one of those SD channels you want to pay attention to the MATCH line, specially the ERXQ/RXQT: values (the first value is the measured one, the second what you set as threshold). You need to configure the threshold a bit below what you see as being the typical measured one.
 
  • Like
Reactions: r0b
No worries; the other way is just turning on debug on the plugin and use the "tail -f /tmp/bigmac-debug.log" to see debug info in realtime... once you zap to one of those SD channels you want to pay attention to the MATCH line, specially the ERXQ/RXQT: values (the first value is the measured one, the second what you set as threshold). You need to configure the threshold a bit below what you see as being the typical measured one.
Thanks mate

I enabled debug and ran telnet with line "tail -f /tmp/bigmac-debug-log". I can see the issue, it is showing as 0/1024 on some channels hence it erroring 15 times and restarting the stream. The ones that were working showed 42756/1024 etc. Is there anything I can try to make it see the correct data?

Cheers
 
Thanks mate

I enabled debug and ran telnet with line "tail -f /tmp/bigmac-debug-log". I can see the issue, it is showing as 0/1024 on some channels hence it erroring 15 times and restarting the stream. The ones that were working showed 42756/1024 etc. Is there anything I can try to make it see the correct data?

Cheers

Apparently that's the correct data... it's either too bursty or, more probable, too small to fill any queue... nothing the plugin can do. One option, if the channels are named as "SD" is to try and match on it on one of the service block settings, and set the rxq threshold there to 0, to disable the plugin... Of course that will match anything that will have SD in the URL as well (and note the match is case insensitive).
 
  • Like
Reactions: r0b
Thanks. Unfortunately the channels don't have sd in the url. Could I put the name of the supplier i.e "iptv.org" in the block setting?
 
Sure, anything that matches the URL is good to go, but if you have a mix of channels that require different settings and can't be easily matched with different strings, it might be challenging/impossible... There's only so much it accounts for.
 
  • Like
Reactions: r0b
Get a blackhole image it's designed for IPTV. Maybe your box is very old and you need to upgrade. I never had any issues with my iptv provider.

Blackhole 4.7 2018 version the best so far for me. mgcamd and iptv works like a charm.

I had a lot of problems myself with different images. You just have to find the right image for your device.

Other reason your iptv provider is shit :).
 
Last edited:
Get a blackhole image it's designed for IPTV. Maybe your box is very old and you need to upgrade. I never had any issues with my iptv provider.

Blackhole 4.7 2018 version the best so far for me. mgcamd and iptv works like a charm.

I had a lot of problems myself with different images. You just have to find the right image for your device.

Other reason your iptv provider is shit :).

Blackhole your having a laugh right ? worst image there is for streaming with outdated libs and cant even accommodate Serviceapp and Extplayer3 properly.

@r0b

I would try hacking your TCP Stack by moving your eth0 over to core 2 and increasing your E2 TCP buffer size. Google it if your unsure, but most linux sites report is has positive results. This hack has been around for years and I use it still on my VU+ Solo 4K

To do this, issue cat /proc/interrupts and make a note of the IRQ numbers used for eth0 and then edit lines 6 and 8 of the script Ive uploaded accordingly.

Then simply send the script to /etc/rc3.d and chmod to 755 and then reboot, then issue cat /proc/interrupts again to check that your eth0 is now running on core 2

This helps things a lot, but by far the greatest benefits from doing this are the other network tweaks that the script applies. The main one being the increasing of the TCP buffer size. It can help massively when using IPTV or a VPN
Dont worry, if you find its not for you or something else is wrong after applying it, you simply delete the script again from /etc/rc3.d and reboot and your image is back to how it was.

Here's a link to the script because I cannot figure out how to upload files here.

http://www.filedropper.com/s01networktuner

Please make a full backup of your image first though. I've never know anything go wrong, but I would hate for me to be the cause of it corrupting your image.
 
Last edited:
  • Like
Reactions: r0b
Blackhole your having a laugh right ? worst image there is for streaming with outdated libs and cant even accommodate Serviceapp and Extplayer3 properly.

@r0b

I would try hacking your TCP Stack by moving your eth0 over to core 2 and increasing your E2 TCP buffer size. Google it if your unsure, but most linux sites report is has positive results. This hack has been around for years and I use it still on my VU+ Solo 4K

To do this, issue cat /proc/interrupts and make a note of the IRQ numbers used for eth0 and then edit lines 6 and 8 of the script Ive uploaded accordingly.

Then simply send the script to /etc/rc3.d and chmod to 755 and then reboot, then issue cat /proc/interrupts again to check that your eth0 is now running on core 2

This helps things a lot, but by far the greatest benefits from doing this are the other network tweaks that the script applies. The main one being the increasing of the TCP buffer size. It can help massively when using IPTV or a VPN
Dont worry, if you find its not for you or something else is wrong after applying it, you simply delete the script again from /etc/rc3.d and reboot and your image is back to how it was.

Here's a link to the script because I cannot figure out how to upload files here.

http://www.filedropper.com/s01networktuner

Please make a full backup of your image first though. I've never know anything go wrong, but I would hate for me to be the cause of it corrupting your image.


I think you need to get a hobby mate hahah. You sound like you lost in your own world haha.
The main reason why people don't use Exteplayer because of framedrops in mpeg4-part2 and HLS streams are pixelated
Gstreamer gives you higher frame rates it's consider the best.
Exteplayer uses less cpu but performance is much worse not recommended. It was one man project. The main plugin is GSTREAMER.

Other thing if you use VPN with IPTV don't expect good results ofcourse you'll get buffering issues. You already have shit internet in england so vpn not going to improve this haha.
 
Last edited:
Back
Top