Ian would you mind posting the script again to edit the tcp stack? I tried to find something via google but the commands didn't seem to work.
Ian would you mind posting the script again to edit the tcp stack? I tried to find something via google but the commands didn't seem to work.
Perfect! I have taken an easy route. created a channel and added timer to zap on to that channel just before starting my script.
Right, if you set it to false, nothing will happen, even if the plugin gets the event.
You can increase a bit if you find it difficult zapping around (namely selecting other channels from the EPG list) when the plugin is constantly trying to restart a service; but not too much, or you'll notice a lot more delay in restart, of course. If the current setting didn't bother you, leave it.
This tries to either be the default, when you generally see the InfoBar popup (like it happens when you zap, depending on the system settings), or None, where it tries to avoid the InfoBar popup on restart.
These 2 you can leave alone, they are a very specific feature I implemented on request: if you add some channel matching strings (matching on the service reference) to the "stuck channel hack" field, for those channels it will always try and restart those after the delay, when you zap to them.
Default settings should be OK, as stated. You can check what happens by activating debug, and checking the contents of the file created at /tmp/quarterpounder-debug.log - if you have a terminal session open on the receiver, you can check in real time by doing "tail -f /tmp/quarterpounder-debug.log" and see what gets logged and what are the differences when you tweak the settings (assuming you have some consistently bad channels you can test with).
No problem, glad it's useful.
I'm still having blackouts with no auto-reconnect, will check log and report back soon.
All seems to be fine at the moment, only issue I have encountered is that when I'm on the channel list preview and a channel requires constant restarts (stream wont start at all), it keeps going back to that IPTV channel in channel list view mode, and only way to get through it is if you go back on the channel in full screen and trying something else other than viewing the channel list in the bouquet.
Yeap, those problematic streams are a pain. Eventually I could think of implementing some exponential back-off.
That probably gets a lot more complicated than I want to make it - specially when accounting for different types of systems, that might do things slightly different - but maybe implementing a (configurable) exponential back-off can take care of it: maybe file a bug on git, so I won't forget? But it's indeed why you'd tune the restart delay, so it gives you some time to go about and move a bit/out of the problematic channel. Check the debug logs if you feel it's not restarting the stream at all, that shouldn't happen, it just takes [restart delay] longer to do it.
Yes, I know what you mean, I mentioned that before when describing the restart delay configuration parameter.
I do like keeping the restart delay set to 0 for minimal interruptions if the stream is most of the time working, so if there's anything that can be done about this in a future update that would be great.
You need some more context on the log, before and after... That should mean evEOF was received on a stream, QP is going to restart not immediately but in X seconds, and another evEOF is received before X seconds have elapsed (why?). Anyway, if 0 works for you for now, use it, I'll look into it again in January.
I personally use serviceapp, of course, but don't change the default players for stream types.
Apparently it doesn't quite work on at least oatv6.4, follow along on Ouarter Pounder: Don't restart stream if bouquet is open · Issue #30 · oottppxx/enigma2
I use openvix, not tested yet.
What would you say the best settings are for the GUI check?
Limited time offer