View Full Version : [VU+ Duo2] Crashing when zapping through IPTV channels
I have an issue when zapping through IPTV channels
It's not consistent, I can sometimes zap through 3 or 4 channels and sometimes 10+. I can browse the bouquet list and when I select the channel to view is when the crash occurs. It's not on any particular channel, seems random, ie I can try again and select the channel that it previously crashed on.
This started with 5.1.003, previously, I would get the spinner for a few seconds and then it would go to the channel, now it crashes instead.
Now had an opportunity to do a full armchair reflash and also a reflash without a settings restore, just added the IPTV bouquet + EPG to the base image and have the same issue of crashing when browsing/zapping through IPTV channels.
< 492.586> [eDVBDemux] open dvr /dev/dvb/adapter0/dvr8
< 492.586> [eDVBServicePlay] cutfile not found!
< 492.586> [eDVBServicePlay] no cue sheet
< 492.592> PC: 77470040
< 492.592> 00000000 019982bc 775af3d0 775e57b4
< 492.592> 00000000 575ba1b0 00000000 56d53fd9
< 492.592> 666e6f63 752e6769 65676173 64656c62
< 492.592> 5f65746f 6c6c6166 6b636162 00690000
< 492.592> 575ba1b0 7748357c 5d85d5f8 575ba1b0
< 492.592> 7f9842c8 763e22d0 00100000 00001000
< 492.592> 0068e8a4 77470004 00000000 00000000
< 492.592> 775de2e0 56bfec70 56bfee78 7751aad0
< 492.593> Backtrace:
< 492.593> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x461F8C]
< 492.593> /usr/lib/libpython2.7.so.1.0(PyObject_Call) [0x77470042]
< 492.593> -------FATAL SIGNAL (11)
Same error here Fatal Signal!
i would reflash from new and setup everything again.
i would reflash from new and setup everything again.
What difference would that make over the 2x reflashes already done?
Andy_Hazza
21-12-17, 15:08
Are you mixing the IPTV channels and 28.2 channels together in the same Bouquets?
Sent from my iPhone using Tapatalk
No, this is a bouquet of just IPTV channels from a single provider. The last flash I tried was just a raw image flash then restored just the one bouquet, no scan, so no Sat or Cable channels or any other addons or plugins
There was a post on a forum (this week), where the user fixed an issue where the IPTV channels had varying ID'S 1 & 4097 (I think) changing them all to the same ID fixed it.
I have them all at 1, did have some at 5002 (Exteplayer3 is better than Gstreamer IMO)but the last test was with a smaller bouquet (80kb) with all set to 1's
Could this be the cause? https://github.com/OpenViX/enigma2/commit/ef1b39f50a1ecdf8451255213402fc9f8fd2e332
Are you using a list direct from the supplier or the suls plugin ... if the former, see if you can use the suls plugin or get them to add your supplier, as there is some guarantee that everything is valid with Suls.
Don't use Suls, I have edited a bouquet received direct from supplier. I use a custom EPG I generate myself for US channels
There was definitely a change between 5.1.002 and 5.1.003, could be the mod mentioned on Github as previously I got the spinner rather than a crash, but I don't have fallback tuner enabled
Well, I can only see the mentioned change & the one to FF/RW some streams - try enabling fallback tuner to see if it makes a difference:)
Having looked at the log again, there are some really long & strange url redirects to „other“ web sites... just wondering if the issue is that one of them is not valid or there is a connect error thats not handled in time... with you zapping around?
If you mean the redirects to the IPTV streams, then that's normal for an IPTV stream.
I've just tried again with a clean install, no settings restore, just added the IPTV streams this time created by the suls plugin, no EPG import and the same fatal signal crash is happening. I have tried with both the fallback tuner set to off and on.
If you mean the redirects to the IPTV streams, then that's normal for an IPTV stream.
I've just tried again with a clean install, no settings restore, just added the IPTV streams this time created by the suls plugin, no EPG import and the same fatal signal crash is happening. I have tried with both the fallback tuner set to off and on.
„If you mean the redirects to the IPTV streams, then that's normal for an IPTV stream.“ OK, just never seen it in my debug logs:)
„Suls“ I run with a version of suls plugin (I converted it to run on my system) and have never had an issue, even flipping between IPTV services or sat/IPTV services ... BUT I am running on the next OEA, so hard for me to say where the problem may lie.... or whether your issue may be fixed when the next ViX version jump occurs.
Obviously the issue is there, but it might just be timing, I run on Arm receivers that are faster than your current receiver ... ....
Willing to try your bouquet if that is possible, as that may be the only way of seeing where the issue resides.
I've gone back to 5.1.002 for now but will try new releases when available
I may modify the suls output to match my generated EPG and use that as the bouquets look pretty good
I've gone back to 5.1.002 for now but will try new releases when available
I may modify the suls output to match my generated EPG and use that as the bouquets look pretty good
Thats one of the Suls benefits, standardised bouquets, that can be easily tailored/sequenced to suit your needs and matched up to your EPG
Just an update, tried today with build 5.1.006 and get the same issue
< 597.775> [eEPGCache] next update in 2 sec
< 597.776> [eDVBServicePMTHandler] ok ... now we start!!
< 597.776> [eDVBDemux] open demux /dev/dvb/adapter0/demux8
< 597.776> [eDVBSectionReader] DMX_SET_FILTER pid=0
enigma2: ../Python-2.7.13/Objects/frameobject.c:671: PyFrame_New: Assertion `f->f_code == code' failed.
< 597.846> PC: 761c7b88
< 597.846> 00000000 fffffffe 00000000 00000020
< 597.846> 00000003 7ffe6e48 00000000 00000000
< 597.846> 00000000 00000000 000771de 00000001
< 597.846> 00100073 ccd23db8 00000000 61586540
< 597.846> 00000000 7ffe6e48 00000006 7ffe6f80
< 597.846> 76907d80 61586540 00000000 006b1b78
< 597.846> 761e3404 761c86a4 00000010 00000000
< 597.846> 762f7e00 7ffe6db0 6158b578 761c7b14
< 597.846> Backtrace:
< 597.847> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x461F8C]
< 597.847> /lib/libc.so.6(gsignal) [0x761C7B8A]
< 597.847> -------FATAL SIGNAL (6)
I'm treating myself to an Ultimo 4K, so will see how that goes.
I've now got the Ultimo, thanks to eBay's 20% off voucher :)
I can confirm that this problem does not manifest in the Ultimo4K, even with the same settings imported from the Duo2.
abu baniaz
31-12-17, 02:42
Are you still able to conduct some tests? If so, you have a PM
There were only two Dev builds between 5.1.002 and 5.1.003.
Not right now M8 as I'm onto the Ultimo4k. I can say that using the same 5.1.007 build on the Ultimo4k as on the Duo2, the problem does not manifest, so it looks like it's Duo2 (or maybe Vu+ V2 boxes) specific. I have tried the same IPTV list on an unsupported receiver running ViX and it's also good on that.
Did you get the issue resolved? I am having exactly same issue on my duo2 with image 5.1.018. Box just crashes at will on IPTV channel zapping...
Did you get the issue resolved? I am having exactly same issue on my duo2 with image 5.1.018. Box just crashes at will on IPTV channel zapping...Debug logs would be helpful :)
The log, as posted in post #18, is fatal signal. I've seen this error, albeit rarely (at least for me), on other boxes including my Solo2.
This, for me, happened even before I started using IPTV so I don't believe it's IPTV issue. I don't think this error is limited to duo2 neither.
Is this same error you're getting?
Still get occasional crashes, less so since changing to an Ultimo4K. I don't have any logs but from memory it's a fatal signal related to libc.so.6
Had a crash tonight that looks like it's ExtEPlayer3 related. I've trimmed the log and obfuscated the IPTV addresses
abu baniaz
16-03-18, 01:03
For search/references purposes
<260105.323> [eDVBServicePlay] cutfile not found!
<260105.323> [eDVBServicePlay] no cue sheet
<260105.324> Traceback (most recent call last):
<260105.324> File "/usr/lib/enigma2/python/Navigation.py", line 89, in dispatchEvent
<260105.324> File "/usr/lib/enigma2/python/Components/PerServiceDisplay.py", line 17, in event
<260105.324> File "/usr/lib/enigma2/python/Components/Sources/CurrentService.py", line 26, in serviceEvent
<260105.324> File "/usr/lib/enigma2/python/Components/Element.py", line 86, in changed
<260105.325> File "/usr/lib/enigma2/python/Tools/RedirectOutput.py", line 7, in write
<260105.325> UnboundLocalError: local variable 'args' referenced before assignment
<260105.325> [ePyObject] (CallObject(<bound method Navigation.dispatchEvent of <Navigation.Navigation instance at 0x9114f9b8>>,(10,)) failed)
Debug logs would be helpful :)
The log, as posted in post #18, is fatal signal. I've seen this error, albeit rarely (at least for me), on other boxes including my Solo2.
This, for me, happened even before I started using IPTV so I don't believe it's IPTV issue. I don't think this error is limited to duo2 neither.
Is this same error you're getting?
Thanks for your response.
I have never had channel zapping crash until last week and I have been using IPTV for about 4 years now.
I had the fatal signal in the log too, posting below for any eagle-eyed person that can help debug the log. (Please note that any IPTV connection details in the log are just dummy data)
Cheers
Thanks for your response.
I have never had channel zapping crash until last week and I have been using IPTV for about 4 years now.
I had the fatal signal in the log too, posting below for any eagle-eyed person that can help debug the log. (Please note that any IPTV connection details in the log are just dummy data)
CheersJust looks like fatal signal that I and others have had. I personally don't worry about it because it's rare for me. I don't think anyone has ever come up with reason for it or how to solve the issue (that I know of).
How often does it happen for you?
Has anything changed since last week when it started happening like install/remove plugin or image update?
Had a crash tonight that looks like it's ExtEPlayer3 related. I've trimmed the log and obfuscated the IPTV addressesTotally different issue - you should open a new thread.
And ExtEPlayer3 (presumably) seems to be logging to syslog, rather than just printing to stderr. So it's filling up the system log (it's also far too verbose).
Just looks like fatal signal that I and others have had. I personally don't worry about it because it's rare for me. I don't think anyone has ever come up with reason for it or how to solve the issue (that I know of).
How often does it happen for you?
Has anything changed since last week when it started happening like install/remove plugin or image update?
Nothing has changed really and it happens all the time, I can reproduce it.
And I wouldn't have worried about it too but just that it crashes the box and cause a restart. I have a SoloSE with the same setup as the duo2 and never had a reboot on that. I will go for clean flash and see if the issue get resolved.
Edit: The SoloSE I haven't updated in a while and still on 5.0.020 (About June 2017 image)
Cheers
yortiz1979
16-03-18, 18:51
I have VU+ZERO4K running latest openvix 5.1.019 and i have the same problem while zapping using the channel changer on the remote. for what i can read on this threat its an old known error but not solition just yet :(
bluepassat
16-03-18, 20:13
mines doing the same i have Xtrend ET8500 was running openvix ver 5.1.016 you can flip iptv channels then crash.....so gone back to 5.0.016 as thats whats on another box to try
seems to only crash when in the bouquets as you can channel change fine in XC plugin
I'm on .18 and not yet had this fatal error. As I've said the fatal signal error, has occurred on really old versions in past even before I started using IPTV.
It does, for me anyhow, appear totally random.
I was updating my IPTV bouquets today and whilst I had a steam playing, I did an init 4 in preparation for uploading a new bouquet and I got the fatal signal crash. This leads me to believe the fatal signal is when leaving a stream rather than when going to a stream - maybe that will help someone that's smarter than me to fix the problem :)
yortiz1979
27-05-18, 14:34
adding more info on this threat to see if we get to the bottom of this problem. while zapping my iptv folder created by telnet using putty command the IPTV channels does not crach, this folder does not have any epg assignment, they only crash on the bouquet created by xtream editor if the EPG are present. also tested the bouquet created by xtream editor wihtout epg and it does not crach, is then when imported the epg when it crashes. SO I CAN CONFIRM THE PROBLEM IS DUE TO THE EPG assignment.
The problem seems to have been fixed for me from build 25, not had a crash since then.
The problem seems to have been fixed for me from build 25, not had a crash since then.It's intermittent I believe and rare at that.
I'm still on .18 and not had crash at all whether switching from/to an IPTV channel on a IPTV bouquet or not. I've had this happen previously on normal DVB channels.
It's hard to re-produce reliably which makes it all that harder to actually get to the bottom of it.
yortiz1979
28-05-18, 07:57
ok i have the solution for me using openvix on vu+zero 4k, the problem happens only while using DVB (1) with EPG. i had to change the stream type. i used the system plugging SERVICEAPP and im using exteplayer3 and all IPTV stream works fine and while changing channel it does not crash. hope this can help anybody having the same issue.
I use Gstreamer, type 4097, rather than 5001/5002 (as used by ServiceApp/Exteplayer3).
Last time I looked into 5001/5002, I'm sure I couldn't record (not even manual record) these streams but was fine on 4097.
Using type 1 for IPTV, for most I assume, means a lot of glitching as other service types are more suited for IPTV and other streams.
yortiz1979
28-05-18, 17:49
Thanks for this advise bbbuk, on my serviceapp gstreamer is not install only exteplayer, do you know how to add gstreamer to serviceapp?? any help will be much appresiated!!
yortiz1979
28-05-18, 20:21
I use Gstreamer, type 4097, rather than 5001/5002 (as used by ServiceApp/Exteplayer3).
Last time I looked into 5001/5002, I'm sure I couldn't record (not even manual record) these streams but was fine on 4097.
Using type 1 for IPTV, for most I assume, means a lot of glitching as other service types are more suited for IPTV and other streams.
is weird that while using DVB 1 all channels work fine while using iptv 4097 there are some channels that image looks in slow motion and some other channels the sounds is not sync with the image!
Thanks for this advise bbbuk, on my serviceapp gstreamer is not install only exteplayer, do you know how to add gstreamer to serviceapp?? any help will be much appresiated!!gstreamer is in each image - well it's in main oe-a images. It's what is used when using 4097 service type.
1 = using box SoC (chip). Generally used for DVB as most of time can't cope with glitches, etc in IPTV streams.
4097 = Gstreamer
5001/5002 = ServiceApp (Exteplayer3, etc)
Thanks to @Abu for above info
yortiz1979
28-05-18, 23:17
gstreamer is in each image - well it's in main oe-a images. It's what is used when using 4097 service type.
1 = using box SoC (chip). Generally used for DVB as most of time can't cope with glitches, etc in IPTV streams.
4097 = Gstreamer
5001/5002 = ServiceApp (Exteplayer3, etc)
Thanks to @Abu for above info
Thank for your advice on this.
i managed to install gstreamer through iptvplayer, however using 4097 and gstreamer on serviceapp most channels works really slow like in slow motion. so far using 4097 and extrplayer3 workd fine just cople of channels workd weird. if i use dvb 1 with original enigma2 player works the best however this is what cause the crash while changing channels on iptv
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.