Enigma2 IPTV auto-reconnect

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.
Thanks Ian

Command line is not one of my strong points but will give your script a go. It would just be the chmod 755 I'd have might have problems doing but have googled it and found a couple of beginner guides.

I have a vu+ Duo 4k running openatv 6.3. What benefits have you found running this hack?

Cheers
 
The moving of eth0 over to core 2 is not as important these days, but it does still help if you are for example streaming from IPTV whilst also downloading something in the background using wget or curl. Its the other network tweaks that are more important with today's faster more modern boxes. These tweaks can have a massive impact in preventing freezing and stuttering from IPTV or when using a VPN. I only suggested you try this to see if it helps with the Bigmac plugin, because mine works pretty flawlessly and I'm using this TCP stack mod and have done for years and I thought it maybe possible it would help you too.

Chmod is nothing sinister lol its just the attributes that you grant certain files and folders in your box. 755 is read, write and execute ( full permissions ) which are required because this is a script that the image needs to read and then execute. Whatever FTP program that you use will allow you to change these permissions usually by just right clicking on the file in your box and then selecting your chosen attribute.

This mod may not address your problems when using the Bigmac plugin, as there are many factors governing the images ability to monitor the RXQ traffic which the plugin uses, such as the image used ( I'm also using ATV 6.3 ) drivers or even your ISP, but it certainly cannot do any harm in trying it. I would also try turning on QoS in your router too as this may also help.
 
Last edited:
  • Like
Reactions: r0b
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.

Agreed.

However, until the image writers increase the connection timeout used by Gstreamer, its always going to be a pain with slower IPTV servers. I think the current timeout is about 1 second. So if the IPTV server doesn't respond in 1 second or less, Gstreamer just gives up trying to connect resulting in the stream not starting and the user having to repeatedly zap away and then back again to get the stream to start. I think the timeout with Exteplayer3 is around 5 seconds, which gives plently of time for the IPTV server to respond, resulting usually, in first time connection every time, This is of course just a personal choice by the user, and they will always use what they find works best for them. But its nice to have this choice and because Blackhole cannot use Serviceapp or Exteplayer3, then this user choice is taken way. As for the ancient libs used in Blackhole, this cannot be addressed by the image writers, because of the image being so closely tied to VU+

In other words, the image is always going to lag behind other images until VU+ offer certain updates to the BH team.

Again though if users like BH then use it. I just dont and consider it outdated.
 
However, until the image writers increase the connection timeout used by Gstreamer, its always going to be a pain with slower IPTV servers. I think the current timeout is about 1 second. So if the IPTV server doesn't respond in 1 second or less, Gstreamer just gives up trying to connect resulting in the stream not starting and the user having to repeatedly zap away and then back again to get the stream to start. I think the timeout with Exteplayer3 is around 5 seconds, which gives plently of time for the IPTV server to respond, resulting usually, in first time connection every time,

That's interesting to know, I never really looked at gstreamer that carefully - where's this timeout set? What I could find for OpenATV suggests it's 10 seconds... (openatv/enigma2, same for 6.3).
 
I believe its located in dvbmediasink so its in C++ and cannot be adjusted by us in python. I could be wrong though. wherever it is located though its definitely only about 1 second, before Gstreamer gives up trying. At least with IPTV in bouquets anyway.
 
Last edited:
I'll take a look this weekend, to see what gives. I really really really don't want to go and do plugins that have binary dependencies, it really ticks me off that they've SWIG'ed so much but still not enough.
 
The moving of eth0 over to core 2 is not as important these days, but it does still help if you are for example streaming from IPTV whilst also downloading something in the background using wget or curl. Its the other network tweaks that are more important with today's faster more modern boxes. These tweaks can have a massive impact in preventing freezing and stuttering from IPTV or when using a VPN. I only suggested you try this to see if it helps with the Bigmac plugin, because mine works pretty flawlessly and I'm using this TCP stack mod and have done for years and I thought it maybe possible it would help you too.

Chmod is nothing sinister lol its just the attributes that you grant certain files and folders in your box. 755 is read, write and execute ( full permissions ) which are required because this is a script that the image needs to read and then execute. Whatever FTP program that you use will allow you to change these permissions usually by just right clicking on the file in your box and then selecting your chosen attribute.

This mod may not address your problems when using the Bigmac plugin, as there are many factors governing the images ability to monitor the RXQ traffic which the plugin uses, such as the image used ( I'm also using ATV 6.3 ) drivers or even your ISP, but it certainly cannot do any harm in trying it. I would also try turning on QoS in your router too as this may also help.
Thanks mate. I thought changing permissions of the file had to be done by command line. Have set it to 755 via filezilla and seems to be working ok but unfortuanately hasn't fixed the issue of Bigmac not reading the data on certain channels. For now I've added part of the url to the exceptions in Bigmac to just ignore that service.
 
Whats the DNSand port of the Server ?

I will see if I can hack it to obtain a login and then try it on my box for you to see if its just a provider that's never going to work.
 
I'll take a look this weekend, to see what gives. I really really really don't want to go and do plugins that have binary dependencies, it really ticks me off that they've SWIG'ed so much but still not enough.

Cursory look: no setting for timeout is passed via ServiceApp, and couldn't really verify if it's several seconds or 1 second. What bugged me was that my providers working via HTTPS (after an HTTP->HTTPS redirect) seem to have trouble establishing the secure connection... Oh, well. Works great for some others, but nothing conclusive out of it. Image quality wise, I may be blind, but can't really tell the difference between exteplayer3 and gstreamer, so... I'll stick to the first.
 
Nah I couldn't conclusively find the timeout setting either, my best guess was its controlled by dvbmediasink when using Gstreamer from Bouquets, and therfore written in C++ and built with the image, so not adjustable except in the source code before the image is built. I came to this conclusion, because any simple streaming plugin can easily control this setting in python when Gstreamer is called that way. but when its called from Bouquets it simply gives up trying to connect if the IPTV Server doesn't respond in around 1 second. It really does need to be increased to prevent the user having to often zap to a given channel several times to get it to start streaming and this is obviously worse when the IPTV server is under load and slower to respond, say on a Saturday during the footie. As I stated though this issue is fixed when using Exteplayer3 as the timeout is around 5 seconds and most likely the default setting in ffmpeg.

However, Exteplayer3 is also not without annoyances. If you zap to a dead stream, establish its dead and then move on to the next channel, Exteplayer3 will without fail, give you the spinner for several seconds before beginning to play the next stream. Gstreamer doesn't have this issue and instantly starts to play the next stream when leaving a dead stream. So its swings and roundabouts with the user having to use whichever annoys them less. This begs the question though, is this the reason that the Gstreamer timeout setting is around 1 second ? In order to secure an almost instant disconnect when there is no response from a Server.

I have not tried GSTPlayer (5001) from Bouquets and perhaps I will as this controls Gstreamer externally without having to go through dvbmediasink, but the last time I tried it from a streaming plugin it was not good as its now very old and has not been updated in years.
 
Last edited:
I came to this conclusion, because any simple streaming plugin can easily control this setting in python when Gstreamer is called that way. but when its called from Bouquets it simply gives up trying to connect if the IPTV Server doesn't respond in around 1 second.
...
I have not tried GSTPlayer (5001) from Bouquets and perhaps I will as this controls Gstreamer externally without having to go through dvbmediasink, but the last time I tried it from a streaming plugin it was not good as its now very old and has not been updated in years.

I've only looked at gstremer/player from the 5001/bouquets perspective, can you provide (source code) examples of plugins that call onto gstreamer and control it via dvbmediasink? From bouquets/via serviceapp, there's quite a few settings that can be controlled, but none related to timeouts, unfortunately.
 
No thats my point. I dont believe anything else goes through dvbmediasink except things added to Bouquets.

I believe that Gstreamer is only called through dvbmediasink when you start a stream from Bouquets using 5002, 4097 or 1.
I think its called on externally from any other plugin and doesnt go through dvbmediasink, which I also believe is the case when using GSTPlayer

This is why I was thinking of trying GSTPlayer as I believe it also bypasses dvbmediasink too, to see it the timeout is longer when using it.
 
Last edited:
I could be wrong here, but I thought they all did ?
I was under the impression that dvbmediasink was only ever used when a stream was started from Bouquets.

So any other streaming plugin, Mediaportal for example or E2iplayer would therefore bypass dvbmediasink when using Gstreamer. Sorry I don't have the source code.

I will contact Eddie from the BH team on Skype and ask him.
 
Last edited:
This is from Eddie.

It doesnt really help because he's Italian and the language barrier is a problem. I'm still not even sure he actually understands what I was asking, but here's his reply anyway.


Eddi, [10.11.19 15:43]
Well all the video get decoded by /dev/dvb/adapter0/video device

Eddi, [10.11.19 15:43]
Enigma have it's mediasink

Eddi, [10.11.19 15:44]
Ext3player have it's direct sink

Eddi, [10.11.19 15:44]
And GST have it's sink plugin

Eddi, [10.11.19 15:45]
Maybe when you play a stream from the bouquet it pass thru enigma2 sink with it's default timeout
 
Pushed out QuarterPounder, a new plugin which intends to replace BigMac, using a completely different approach - kept very simple for now, let me know if/how it works for you folks (remember to disable BigMac if testing QuarterPounder and vice-versa).
 
Cheers keep up the good work oottppxx :)

Can we access the debug log like in big mac via putty? I looked in the tmp folder but couldnt see the log there.
 
Back
Top