View Full Version : [ViX_Misc] Zap timers lock box
Don't know about that settings restore thing. This is a new installation, replacing the previous vti image. No settings were taken from the old installation apart from satellites.xml, tv bouquet favorites and oscam configuration.
Entering a timer seem to work fine regardless of type. However, when the timer is triggered the box completely locks up with zap and "zap and record" timers. Recording only timers seems to work, probably because it is then using the second tuner and no zapping is necessary.
The symptoms are:
* The "busy" animation is shown.
* All attempts to communicate with the box using the remote control are useless - nothing happens.
* If you are in some kind of menu when the timer triggers you can't get out of it.
* If you are watching TV, the channel continues running normally, apart from the "busy" animation. It's not possible to change channel, go to settings or anything else (at least not by using the remote control, haven't tried anything else).
The only ways I've found to get out of it is to do a hard reset, i.e. switch power off using the switch on the back, or to kill enigma by logging in via ssh and execute a console cmd.
This means I can only use one tuner for watching and one tuner for recording since I have to do all zapping manually. It also means I can't use a zap timer as a wake-up timer.
Apart from this issue (which is actually a biggie for me since I use it very frequently) I really like the vix image and I certainly prefer it to the vti and black hole images that I've tried before. It actually seems to be a strong contender for best image I've tried even if I include the images I used on my previous DM8000 unit.
My Vu+ Ultimo seems to suffer from similar symptoms at least with the current image 032.
DaMacFunkin
12-01-16, 10:20
I'll give you a tip that solved some problems on my solo4k and access to the hard drive after I had run other images on it, such as VTi... re-initialise your drive within vix and then mount it in vix as media/hdd.
Yes you will loose all data on the drive.
Hmmm, interesting input. My current disc is actually a legacy from my previous Dreambox unit (DM8000) but it is mounted as media/hdd and recording on the disc (and playback) has worked fine using the vti image and it seems to work fine on vix as well. I've had some sporadic problems with gui crashing when deleting from disc but if I remember correctly this was only on vti.
I don't want to lose the content on the disc but if I can find a way to backup and restore the contents it may certainly be worth a try to re-init the disc. If if works it would be an easy fix. However, since the disc *should* not be involved for zap timers it seems unlikely to be causing the problem (not impossible though in this strange world of ones and zeros).
I have now tried to re-initialize the HDD and it did not change anything. The problem remains unchanged.
Assuming there are no logs (do you have debug logs enabled?) then maybe you can telnet into the box, stop it (init 5) and display the log on the terminal (enigma2 command)
If debug logs not enabled, then enable and after problem reboot and have a look at the log.
Maybe it will show whats going on.
I attched a debug log from my Ultimo at the moment of endless spinning VIX after it was forced to zap due to the lack of free tuners (I suppose so). This may be something completely different from mrocm's problem, but I will give it a try.
You are right. I did not have logging activated but it was simple enough the activate it and recreate the problem. :)
This is pretty much what happens in my case. It seems it may in some way be connected to the timeshift function, which is strange since I am not using timeshift at all.
< 392.804208> [eConsoleAppContainer] Starting sdparm
< 393.510825> [eMainloop::processOneEvent] unhandled POLLERR/HUP/NVAL for fd 71(16)
[TIMER] activating state 1
[TIMER] prepare ok, waiting for begin
[SoftcamManager] oscam-latest already running
[SoftcamManager] Checking if oscam-latest is frozen
< 405.182730> [eConsoleAppContainer] Starting /bin/sh
< 405.293809> [eMainloop::processOneEvent] unhandled POLLERR/HUP/NVAL for fd 71(16)
[SoftcamManager] oscam-latest is responding like it should
job Components.Task.Job name=SoftcamCheck #tasks=1 completed with [] in None
[TIMER] activating state 2
< 413.725145> [eDVBServicePlay] timeshift
[TIMER] zapping
< 417.621475> [gRC] main thread is non-idle! display spinner!
When this happens the init command does not work. I guess it is also affected by the problem. To stop the gui I have to use the kill cmd. With debug logging deactivated the gui restarts automatically after killing it. However, with debug logging activated it seems I have to manually start the gui using "init 3" after killing the gui.
If there is any doubt I can also make it clear that even though I'm using a softcam I still have a "real" card with a payed subscription. :)
I have tried updating to the latest release version but not change, problem remains. I'm not saying I expected it to go away but every new version is worth trying just in case the cause of the problem have been located and remedied.
I'm not sure whether or not new version adress this issue or not but I thought I might as well add an entry here indicating whether nor not the issue has been solved.
Update was done through the software update menu option, not a complete USB installation. Not sure if this makes a difference.
I have now tried 3.2.036 and there was no change to this issue. Problem remains.
Updated to 3.2.037. Still no change. Problem remains.
abu baniaz
25-02-16, 18:32
Adding deug logs of issue may be to your advantage
Thanks for the tip. Log is already provided though (entry #8). That's all that ends up in the log. Behavior has not changed since then. Must admit I haven't checked for changes in the log since the behavior is still unchanged but I will check for it now.
Really like this image and the skin I'm using right now but this is a really annoying bug that may make me try my luck with some other image, perhaps the recently released OpenPLi (which I was using successfully on my DM8k box).
abu baniaz
25-02-16, 18:45
Thanks for the tip. Log is already provided though (entry #8). That's all that ends up in the log. Behavior has not changed since then. Must admit I haven't checked for changes in the log since the behavior is still unchanged but I will check for it now.
Really like this image and the skin I'm using right now but this is a really annoying bug that may make me try my luck with some other image, perhaps the recently released OpenPLi (which I was using successfully on my DM8k box).
That is not the debug log. That is little bit of your debug log.
True enough. Being a software developer myself I figured the log of the time when the error occurred would be enough. The entire log contains quite a lot of irrelevant information. Here's a bit more from the log. It's everything that happens from the point when I open the EPG to register a zap event until it hangs. Not sure if this actual
< 87152.998942> [eInputDeviceInit] 1 166 1
[InfoBarGenerics] KEY: 358 INFO
< 87153.330143> [eInputDeviceInit] 0 166 1
[InfoBarGenerics] KEY: 358 INFO
[Skin] processing screen GraphicalEPGPIG:
[Skin] Valign must be either top, center or bottom!, not centre. Please contact the skin's author!
[Skin] Valign must be either top, center or bottom!, not centre. Please contact the skin's author!
warning, skin is missing element key_blue in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element number in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element jump in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element key_red in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element primetime in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline2 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline3 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline0 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline1 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline4 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element timeline5 in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element change_bouquet in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element key_green in <class 'Screens.EpgSelection.EPGSelection'>
[Skin] Attribute not implemented: valign value: center
warning, skin is missing element key_yellow in <class 'Screens.EpgSelection.EPGSelection'>
warning, skin is missing element page in <class 'Screens.EpgSelection.EPGSelection'>
< 87153.398376> [gAccel] alloc failed
< 87153.398442> [gSurface] ERROR: accelAlloc failed
[Skin] processing screen GraphicalEPGPIG_summary:
< 87157.338680> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] DirectionActions down
< 87157.560126> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87157.738211> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] DirectionActions down
< 87157.960113> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87162.931043> [eInputDeviceInit] 1 67 1
[InfoBarGenerics] KEY: 103 UP
[ActionMap] DirectionActions up
< 87163.150173> [eInputDeviceInit] 0 67 1
[InfoBarGenerics] KEY: 103 UP
< 87164.713861> [eInputDeviceInit] 1 6a 1
[InfoBarGenerics] KEY: 106 RIGHT
[ActionMap] DirectionActions right
< 87164.940148> [eInputDeviceInit] 0 6a 1
[InfoBarGenerics] KEY: 106 RIGHT
< 87170.241525> [eInputDeviceInit] 1 18f 1
[InfoBarGenerics] KEY: 399 GREEN
< 87170.570102> [eInputDeviceInit] 0 18f 1
[InfoBarGenerics] KEY: 399 GREEN
[ActionMap] EPGSelectActions timerAdd
[ActionMap] unknown action EPGSelectActions/timerAdd! typo in keymap?
[ActionMap] ColorActions green
[Skin] processing screen TimerEntry:
[Skin] processing screen NumericalTextInputHelpDialog:
[Skin] processing screen SetupSummary:
[AutoTimer] Auto Poll
[AutoTimer] Auto Poll Started
< 87171.029234> [eEPGCache] event 1b23 not found in epgcache
< 87171.029386> [eEPGCache] event 08e6 not found in epgcache
< 87171.029470> [eEPGCache] event a0ed not found in epgcache
< 87171.029549> [eEPGCache] event 090f not found in epgcache
< 87171.029627> [eEPGCache] event 0955 not found in epgcache
< 87171.029709> [eEPGCache] event ed6c not found in epgcache
< 87171.029868> [eEPGCache] event 279e not found in epgcache
< 87171.029974> [eEPGCache] event 951c not found in epgcache
< 87171.030149> [eEPGCache] event 24c6 not found in epgcache
< 87171.030466> [eEPGCache] event 0a8c not found in epgcache
< 87174.940802> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] PiPSetupActions down
[ActionMap] unknown action PiPSetupActions/down! typo in keymap?
[Skin] processing screen NumericalTextInputHelpDialog:
< 87175.160148> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87175.344724> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] PiPSetupActions down
[ActionMap] unknown action PiPSetupActions/down! typo in keymap?
< 87175.570115> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87175.701361> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] PiPSetupActions down
[ActionMap] unknown action PiPSetupActions/down! typo in keymap?
< 87175.920117> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87176.050532> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] PiPSetupActions down
[ActionMap] unknown action PiPSetupActions/down! typo in keymap?
< 87176.270131> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87176.442051> [eInputDeviceInit] 1 6c 1
[InfoBarGenerics] KEY: 108 DOWN
[ActionMap] PiPSetupActions down
[ActionMap] unknown action PiPSetupActions/down! typo in keymap?
< 87176.660155> [eInputDeviceInit] 0 6c 1
[InfoBarGenerics] KEY: 108 DOWN
< 87179.992687> [eInputDeviceInit] 1 2 1
[InfoBarGenerics] KEY: 2 1
[ActionMap] SetupActions 1
[ActionMap] unknown action SetupActions/1! typo in keymap?
< 87180.210142> [eInputDeviceInit] 0 2 1
[InfoBarGenerics] KEY: 2 1
< 87180.883978> [eInputDeviceInit] 1 9 1
[InfoBarGenerics] KEY: 9 8
[ActionMap] SetupActions 8
[ActionMap] unknown action SetupActions/8! typo in keymap?
< 87181.210121> [eInputDeviceInit] 0 9 1
[InfoBarGenerics] KEY: 9 8
< 87181.854141> [eInputDeviceInit] 1 6 1
[InfoBarGenerics] KEY: 6 5
[ActionMap] SetupActions 5
[ActionMap] unknown action SetupActions/5! typo in keymap?
< 87182.080105> [eInputDeviceInit] 0 6 1
[InfoBarGenerics] KEY: 6 5
< 87182.375521> [eInputDeviceInit] 1 6 1
[InfoBarGenerics] KEY: 6 5
[ActionMap] SetupActions 5
[ActionMap] unknown action SetupActions/5! typo in keymap?
< 87182.600087> [eInputDeviceInit] 0 6 1
[InfoBarGenerics] KEY: 6 5
< 87184.026317> [eInputDeviceInit] 1 67 1
[InfoBarGenerics] KEY: 103 UP
[ActionMap] PiPSetupActions up
[ActionMap] unknown action PiPSetupActions/up! typo in keymap?
< 87184.250150> [eInputDeviceInit] 0 67 1
[InfoBarGenerics] KEY: 103 UP
< 87184.522751> [eInputDeviceInit] 1 67 1
[InfoBarGenerics] KEY: 103 UP
[ActionMap] PiPSetupActions up
[ActionMap] unknown action PiPSetupActions/up! typo in keymap?
< 87184.740118> [eInputDeviceInit] 0 67 1
[InfoBarGenerics] KEY: 103 UP
< 87185.048781> [eInputDeviceInit] 1 67 1
[InfoBarGenerics] KEY: 103 UP
[ActionMap] PiPSetupActions up
[ActionMap] unknown action PiPSetupActions/up! typo in keymap?
< 87185.270106> [eInputDeviceInit] 0 67 1
[InfoBarGenerics] KEY: 103 UP
< 87185.873259> [eInputDeviceInit] 1 69 1
[InfoBarGenerics] KEY: 105 LEFT
[ActionMap] SetupActions left
[ActionMap] unknown action SetupActions/left! typo in keymap?
[ActionMap] PiPSetupActions left
[ActionMap] unknown action PiPSetupActions/left! typo in keymap?
[ActionMap] SetupActions left
< 87186.090282> [eInputDeviceInit] 0 69 1
[InfoBarGenerics] KEY: 105 LEFT
< 87187.241931> [eInputDeviceInit] 1 160 1
[InfoBarGenerics] KEY: 352 OK
[ActionMap] SetupActions ok
[Config] getResolvedKey config.usage.remote_fallback empty variable.
e00000(DiSEqC reset)
e00003(DiSEqC peripherial power on)
e01038f0(?)
[Config] getResolvedKey config.usage.remote_fallback empty variable.
e00000(DiSEqC reset)
e00003(DiSEqC peripherial power on)
e01038f0(?)
[Config] getResolvedKey config.usage.remote_fallback empty variable.
e00000(DiSEqC reset)
e00003(DiSEqC peripherial power on)
e01038f2(?)
[Config] getResolvedKey config.usage.remote_fallback empty variable.
[Config] getResolvedKey config.usage.remote_fallback empty variable.
[RecordTimer] record time changed, start prepare is now: Thu Feb 25 18:54:40 2016
[RecordTimer] Record RecordTimerEntry(name=Vänner, begin=Thu Feb 25 18:55:00 2016, serviceref=1:0:19:1A91:43:46:E080000:0:0:0:, justplay=True, isAutoTimer=False)
< 87187.460156> [eInputDeviceInit] 0 160 1
[InfoBarGenerics] KEY: 352 OK
< 87189.198824> [eInputDeviceInit] 1 ae 1
[InfoBarGenerics] KEY: 174 EXIT
[ActionMap] OkCancelActions cancel
< 87189.420255> [eInputDeviceInit] 0 ae 1
[InfoBarGenerics] KEY: 174 EXIT
[RecordTimer] activating state 1
[RecordTimer] prepare ok, waiting for begin
[RecordTimer] activating state 2
< 87249.029079> [eDVBServicePlay] timeshift
[RecordTimer] zapping
< 87251.207485> [gRC] main thread is non-idle! display spinner!
abu baniaz
25-02-16, 19:26
I am just a moderator/tester.
From what I have gathered, you need to look for something amiss in the leadup to the event or something not quite right in the normal startup processes.
What is the service you are zapping to?
1:0:19:1A91:43:46:E080000:0:0:0:
Are you able to zap to it using CLI?
As a separate matter, what skin are you using? The center/centre issue ought to be reported and fixed.
Don't really know what to look for since I am unfamiliar with these platforms. I could of course supply the entire log file if it would change anything. Just figured it would be quite a lot of irrelevant, and to some extent personal, information to sift through.
I have tried zapping (via timers) to several different channels. Does not seem to matter which channel I try to zap to. It also doesn't matter if it's a zap timer or a zap-and-record timer. In this specific case I was trying to zap to "Kanal 5" from the provider Canal Digital (in Sweden). Don't know if that is the information you asked for.
I'm not sure what you mean by zapping using CLI. Zapping to any channel, including the one mentioned above, works without issues when done manually through either the simple channel list or the graphical EPG.
Zap timers work without issue using other images but I like this image and this skin so I would prefer staying with it if zap timers can be made to work.
The skin I am using is "YouViX-Blue".
abu baniaz
25-02-16, 20:09
I am guessing that this is what is happening:
You have set a zap timer to the channnel which has a service reference
1:0:19:1A91:43:46:E080000:0:0:0:
It is not finding the channel and hence the loop. I have checked the lamedb, the file that stores the services/channels, I cannot find that one. This is why I asked if you can zap to it by command line. There may be an issue with the 0.8w/1w debate. Some organisations use 1w, others 0.8w. Or you may have discovered a bug that needs to be resolved.
Can you issue the following command and see if the receiver zaps to it
wget -q -O - http://127.0.0.1/web/zap?sRef=1:0:19:1A91:43:46:E080000:0:0:0:
Before you do so, can you save the following files from you receiver and upload them here as attachments please? This will help in trying to reproduce the issue you are having.
"lamedb" located in /etc/enigma2
"satellites.xml" located in /etc/enigma2
"satellites.xml" located in /etc/tuxbox
Cmd line zapping works fine.
The problem is most likely NOT caused by unability to zap to a certain service because zapping manually by remote control or by cmd line works fine. All service settings are defined in the satellites.xml file and the same file works without issue with zap timers using other images.
I am guessing that this is what is happening:
You have set a zap timer to the channnel which has a service reference
1:0:19:1A91:43:46:E080000:0:0:0:
It is not finding the channel and hence the loop.I wonder whether:
1:0:19:1A91:43:46:E080000:0:0:0:
doesn't match
1a91:0e080000:0043:0046:25:0
(which is what lamedb has) because of the mis-match in leading zeroes?
(I can't test that directly, as I don't have any channels with leading zeros in lamedb)
Quite possible. I do not know much about the formats of these files so I haven't really looked at the contents. What I DO know is that the satellites.xml file originally supplied with the image did not work for me. I could find/watch some of my channels but not all of them. In order to find and watch all my channels I had to replace the satellites.xml file with the file used on my dm8k box (which is also the one I attached). I've also cleared away all the satellites I know I will never use.
I'm still thinking it should be related to some issue with the image since the same Vu+ box using the same satellites.xml file works fine with zap timers using VTi or Black Hole images.
I'm not sure whether the lamedb file is different in the different images since I haven't really looked at it before. If necessary I could always start my old dm8k box and get its lamedb file to see if that makes a difference. Won't have time for this until the weekend though.
I have now tried replacing the lamedb file with the one from my dm8k box but it did not change anything. It is not really all that surprising. The old dm8k file is a little bit larger so I guess it contains a few more services but the format seems to be the same so the information for each service does not seem to be different.
If it was an issue related to the rather new hardware platform (solo4k) I may have had a bit more patience with bugs like this. However, two of the most used images do not have this problem so it can't be a hardware problem. There must be something in the software or configuration that does not work properly. I have tried using the same configuration (at least the configuration files I know about) that works on other images but for some reason it still doesn't work with this image. Frustrating, especially since I normally use this function quite a lot to make sure I don't miss the programmes I want to watch. It also prevents me from planning more than one recording at a time unless the main tuner is already set to on of the channels I want to record (I can't make it zap on timer).
Trying OpenPLi is looking more and more appealing.... :-(
Tried OpenPLi today but unfortunately it's still buggy and didn't work as well as the OpenPLi version I was using on my dm8k. When going back to ViX I started afresh with a USB installation (3.2.37). This time it seems the original satellites.xml file works for locating all the channels I've tried so far. This means that I am now using the satellites.xml file and lamedb file supplied with the image. I reused the favorites bouquet and the oscam config files from previous installation. The problem with zap timers is still an issue.
abu baniaz
12-03-16, 22:14
I was able to reproduce your issue twice and was about to raise a bug report until I did one last test.
The two instances I had the issue I used your lamedb file. As you described, zap timer fails and you get a lock up. On my next test, I decided to use a lamdb file that was produced by a scan. On this occasion, the zap occurred fine.
I attach a copy of the timers file. The two failures are with orbital position "E083163", the succesful one is had "E080000"
<?xml version="1.0" ?>
<timers>
<timer begin="1457814600" end="1457814781" serviceref="1:0:1:40A:AF1:BB:E080000:0:0:0:" repeated="0" rename_repeat="1" name="Bournemouth - Swansea" description="Premier League" afterevent="auto" eit="14" tags="Bournemouth_-_Swansea" disabled="0" justplay="1" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="0">
<log code="15" time="1457814358">record time changed, start prepare is now: Sat Mar 12 20:29:40 2016</log>
<log code="5" time="1457814580">activating state 1</log>
<log code="6" time="1457814580">prepare ok, waiting for begin</log>
<log code="5" time="1457814600">activating state 2</log>
<log code="11" time="1457814600">zapping</log>
<log code="5" time="1457814781">activating state 3</log>
<log code="12" time="1457814781">stop recording</log>
</timer>
<timer begin="1457811420" end="1457811601" serviceref="1:0:1:49C:3:1:E083163:0:0:0:" repeated="0" rename_repeat="1" name="Labdarúgás" description="Serie A TIM, Internazionale-Bologna" afterevent="auto" eit="45093" tags="Labdarúgás" disabled="0" justplay="1" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="0">
</timer>
<timer begin="1457812200" end="1457812381" serviceref="1:0:1:400:2:1:E0831B3:0:0:0:" repeated="0" rename_repeat="1" name="Terminator: Genisys" description="(sua, 2015, SF acţ.) Cu: Arnold Schwarzenegger, Jason Clarke,..." afterevent="auto" eit="62206" tags="Terminator:_Genisys" disabled="0" justplay="1" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="0">
<log code="15" time="1457811849">record time changed, start prepare is now: Sat Mar 12 19:49:40 2016</log>
</timer>
</timers>
You made a statement earlier, "All service settings are defined in the satellites.xml file", I'll have to respect your opinion. My experience is as below.
OpenPLI and images that derived from them such as OpenVix, allow for user version of certain files such as satellites.xml, backdrop.mvi. These would be in /etc/enigma2. If a user file is present, that is used. Otherwise the system one in /etc/tuxbox is used. When updates occur, teh user file is not touched.
Satellites.xml has two aspects. One aspect defines the satellite positions/names. The other defines the transponders to be used for scanning.
For tuning, lamedb is used, not satellites.xml. The only part satellites.xml plays is validating the satellite. People find this very strange and seldom believe it. To convince yourself, please try the following: Backup the satellites.xml to restore afterwards. In the working copy, delete all transponders so that only the name remains. You will find that channels still work even though there are no transponders listed. Hope that convinces you.
<sat name="28.2E Astra 2E/2F/2G" flags="0" position="282">
</sat>
Your problem is caused by the 0.8/1W issue. We use the convention used on one website that keeps the data, others use another. he provider data on the satellite says 1w. We tried to change it to this but others objected. Addition of a dummy entry to validate the different position was rejected too. Not sure how you want to do the next stage. You will have to decide what xml you want to use and scan 0.8/1 west, select clear before scan to avoid issues.
Nonetheless, the box should not lock up so we will have to look at this.
Thanks for taking time to delve into this issue. I'm not sure what you want me to do though.
I have now tried to make a fresh installation once again (3.2.037). This time the only thing I restored from previous settings was the oscam config. After installation I added the oscam config, installed my skin and the oscam soft cam. Apart from this I did not touch anything so I am using the default satellites.xml file. I have not done anything to the lamedb file either. I made a complete service search. I noted that the search found about 200 less services than with my old satellites.xml file but I have not checked if this affects me in any way. After this I added only two channels to an empty favourites list and registered a zap timer. It still fails in the same way.
So....
1. Shouldn't at least the default settings provided with the image work properly. I did this to make sure I had not added or changed anything that caused the problem.
2. Why would the ViX image be sensitive to the 0.8/1.0W issue that you mention when other major images do not have the same issues? You mention that ViX is based on PLi. If this is that case it is strange that the Pli image works fine with zap timers on the dm8k. I did not get to try the zap timers on the PLi image for the Solo4k box. I got a couple of green screens when trying to set it up the way I wanted it so it felt way too unstable to be a realistic alternative at this point.
ViX combined with my chosen skin is my favourite combination so far. However, this is, in my opinion, a major problem for me. It also feels very strange that it should be an issue at all since other images do not have this problem. What is so special with ViX?
To be clear....
I don't really care if the problem is with the satellites.xml file, the lamedb file or anything else. By this I mean that it doesn't really matter if I have understood it incorrectly and you are completely right. There's no prestige here. I just want it to work. :)
Another weird thing is that it's only the zap timers that are affected. For a record timer it must be the same service settings used and they work fine in the background as long as there's no zapping involved. Why do recordings work when zapping does not work? Manual zapping by cmd line or by remote control also work fine. There is, for me, no obvious reason why timed zapping would cause a problem unless there is a bug somewhere, regardless of service configuration.
For tuning, lamedb is used, not satellites.xml.Which is where, to me, your argument breaks down.
As I read this thread, you can get to the channel/service using the remote, or it can record from it, but a zap timer hangs. In all three cases the same lamedb file would be used for the service tuning.
There is, for me, no obvious reason why timed zapping would cause a problem unless there is a bug somewhereIf there is a crash or a hang then there is a bug.
FWIW:
The "[TIMER] zapping" message is printed by RecordTimer.py (~ line 414).
Just after that is this loop to find the channel in the bouquet list (needed so that prev/next channel buttons and EPG listing makes sense after the zap).
Now, why this code is "in-line" here is a little odd - as all of the other code which zaps just calls failureCB(True) which has exactly the same code, except for one line (which, given it's the first line could be called before calling the function anyway).
The zap-only timer also calls:
NavigationInstance.instance.isMovieplayerActive()( which despite the name, doesn't return an answer and actually shuts down any MoviePlayer instance!).
Now, I have seen problems related to shutting down the MoviePlayer just before changing channel in this way (see http://www.world-of-satellite.com/showthread.php?50196-power-and-zap-timer-not-working-properly&p=390954&viewfull=1#post390954). But I think it would only happen if the MoviePlayer were actually running at the time.
Also, if there were something odd with the bouquets then this search could loop for ever (the loop is "while True", and the only exit condition is finding the service being searched for). However, you'd expect that to happen on any timer with enforced channel change.
It does happen with both zap timers and zap-and-record timers. It does not happen with record timers, regardless of whether the recording is done on the channel currently selected or in the background on another channel.
I guess it could be two different problems.
1. It fails to zap. This is strange since zapping works fine when triggering it manually by remote or by cmd line. Therefore, as birdman mentions, given that all zapping is using the same provider config (satellites.xml, lamedb, bouquet) it is most likely a bug.
2. When it fails it seems to enter an infinite loop that locks the user interface and the only way out of it is to kill the enigma2 process. I don't know anything about how these images are constructed and I don't know Python but being a programmer myself I would consider that bad error handling.
It does happen with both zap timers and zap-and-record timers.Ah, new info(?).
In which case I'd suspect the loop searching for the entry in the bouquet even more; if only because the bouquets and lamedb are not the same file(s) and hence could differ.
Could you upload your lamedb file and all *bouquet* files in /etc/enigma2?
cd /etc/enigma2
zip ch_info.zip lamedb *bouquet*
then upload ch_info.zip
abu baniaz
13-03-16, 16:10
I raised the bug report at 00:53 for two issues that have been thrown up by this issue.
It is not about who is right or wrong, but a matter of understanding the process, cause of issues/s and then fixing it/them.
In the debug logs atatched to the bug report whn there is an issue, there is a mismatch between E083113 and E080000. On the succesful zap timer, there was no such issue IIRC.
It's not really all that new information since the fact that the problem occurs on both zap and zap-and-record timers was stated in the very first entry. :)
Now I am really confused.
To make sure the files you requested would be as clean as possible I once again did a fresh installation. I have already done this twice today and each time the problem still remained. This is the third time I did the very same thing but NOW zap timers seems to work. I don't understand it. I have used the very same USB stick on all three re-installations today with no changes whatsoever to the content. It is of course very nice that zap timers now seem to work. I will continue to expand my bouquet and add the settings I normally use and check to see if this has any impact on the zap timers. I can't explain why it suddenly started to work, which is a bit annoying actually, but I surely hope it will continue to work.
In the debug logs atatched to the bug report whn there is an issue, there is a mismatch between E083113 and E080000. On the succesful zap timer, there was no such issue IIRC.Which is, I presume, a difference between the service reference as noted by lamedb and that noted by the bouquet files. That will lead to an infinite loop in the piece of code I mentioned (which is, I believe, looking for a match against all fields in the service ref).
It might not cause an issue when switching channels as it's possible(?) that this differing filed is ignored there.
I could (probably) upload a RecordTimer.py file to test this theory.
It's not really all that new information since the fact that the problem occurs on both zap and zap-and-record timers was stated in the very first entry. :)Sorry - a later one just mentioned zap timers and record timers.
Now I am really confused.That's just a state leading to enlightenment.
To make sure the files you requested would be as clean as possible I once again did a fresh installation.A pity. Once you have a state that shows the problem it can be useful to maintain it.
OK. So let's assume that the loop is it looking for an entry in the bouquets that isn't there.
Here is an updated copy of RecordTimer.py (and the patch of the changes) 47285 that should stop the loop. It might (will?) result in your location within the EPG/bouquets being "wrong" after the zap (but that should sort itself out as you switch channels later).
If this stops the loop you should see an entry in the debug log:
[RecordTimer] Reached end of bouquets..??
where it "saved" you.
A pity. Once you have a state that shows the problem it can be useful to maintain it.
I figured it to be "safe" since I had done the same thing twice already today without having any impact on the problem.
Well, the problem is back again. Don't know if it's something with the bouquet, the settings or any of the plugins now installed that causes the problem. I'm attaching the file you requested.
abu baniaz
13-03-16, 18:33
I would attach timers.xml too
Good point. Even though the contents I sent was the content birdman requested I might as well include all the files in the enigma2 directory, just in case it is useful in some way. :)
It's the first one (Michael McIntyre's Comedy Roadshow). The other one is a record timer (autotimer) that has not yet been triggered. Record timers seems to work fine so I don't expect any problems with it.
Now that I got it working once I will try another re-install from scratch to see if I can get it working again. If so I will try to add bouquet and settings in stages to see when it stops working. I hope this approach will narrow it down a bit. A problem with the bouquet is of course one possibility. I have a hunch it may be to some extent related to some of the chosen settings (or some plugin). I probably won't have time to do it until the weekend though.
I have now narrowed it down to a single setting. It has nothing to do with the bouquet itself. The problem is the setting to allow multiple bouquets or not. Since I am only using a single favourite bouquet I have always had this setting to "no", on my old dm8k box as well as my solo4k box (both using dual tuners). However, with the ViX image it seems zap timers fail if this is set to "no". If it is set to "yes" zap timers work fine. I'm not sure whether this is to be considered a bug but it is at least a problem I have not encountered in any other image on dm8k or solo4k.
Having found a way to get around the problem I will most likely stay with the ViX image. This setting is actually only an inconvenience when building a bouquet list. You then have the extra step of selecting a bouquet for every channel you want to add. After the bouquet is created you normally don't notice it so it is certainly something I can live with.
I have now narrowed it down to a single setting. It has nothing to do with the bouquet itself. The problem is the setting to allow multiple bouquets or not. Since I am only using a single favourite bouquet I have always had this setting to "no", on my old dm8k box as well as my solo4k box (both using dual tuners). However, with the ViX image it seems zap timers fail if this is set to "no". If it is set to "yes" zap timers work fine. I'm not sure whether this is to be considered a bug but it is at least a problem I have not encountered in any other image on dm8k or solo4k.Almost anything that results in a hang or a crash is a bug.
There is code to search through your bouquets to find the channel you are zapping to so as to fix up the up/down channels etc., so perhaps this fails ot seacrth everythign becuase of this setting.
I did post a patch and updated RecordTimer.py in a previous post (http://www.world-of-satellite.com/showthread.php?49834-Zap-timers-lock-box&p=394922&viewfull=1#post394922) which should fix this (at least stop it looping). Have you tried it?
Almost anything that results in a hang or a crash is a bug.
There is code to search through your bouquets to find the channel you are zapping to so as to fix up the up/down channels etc., so perhaps this fails ot seacrth everythign becuase of this setting.
I did post a patch and updated RecordTimer.py in a previous post (http://www.world-of-satellite.com/showthread.php?49834-Zap-timers-lock-box&p=394922&viewfull=1#post394922) which should fix this (at least stop it looping). Have you tried it?
Yes, personally I would consider it a bug. However, since it is now quite easy a avoid it I no longer see it as a reason to consider changing to some other image. :)
I'm sorry for not reacting to your suggestion and the modified py file. I wasn't 100% certain it was aimed at me but the main reason for not doing anything with it is that I am almost completely unfamiliar with the structure of these images and with Python as a programming platform. Where do I put the file? Do I need to compile or build something after the file is replaced (and how) or is it only a script file interpreted at runtime? I will surely try it if I can figure out how..... :)
abu baniaz
19-03-16, 13:59
With the python files it is easy to do.
The way I do it when experimenting (some stages you may feel are are un-necessary)
Make an image backup and save away from receiver. This is so that you can can reflash if your box does not boot.
Find the target location. It is usually /usr/lib/enigma2/python or a sub directory
Mame a backup of the orginal .pyo file (add .bak) at end of name. RecordTimer.pyo will become RecordTimer.pyo.bak
Transfer new .py
GUI restart. You can do this at commnd line "init 4 && sleep 10 && init 3". I add the 10 second wait to enable it to write files kept in RAM properly
After restart, the .py file will compile to .pyo
Delete the .py file so that it does not keep compiling after each restart.
If you leave the .py file in there, and there is an update, your version will replace the official file. This can cause crashes that nobody can replicate becuese they are not using the same files as you.
Submit a pull request on Github for the fix to be considered/applied.
If you get an Enigma bootloop with new file.
Stop Enigma2 from running with "init 4" command.
Check crashlog for issue (default location is home/root/logs)
Edit .py file with any fixes and restart. Not forgetting to let transfer complete before restart.
Should you wish to do more detailed analysis and in real time, you can start enigma2 in console mode
init 4
enigma2
To end console mode
ctrl & c
init 6
I will add the details of the multiple bouquets settings to the bug report. Being able to reproduce an issue makes testing fixes/avoidance easier.
I did post a patch and updated RecordTimer.py in a previous post (http://www.world-of-satellite.com/showthread.php?49834-Zap-timers-lock-box&p=394922&viewfull=1#post394922) which should fix this (at least stop it looping). Have you tried it?While this patch would be worth having (assuming it works) your comment in #43 indicates the fundamental cause, which should also be looked at.
When you say, "The problem is the setting to allow multiple bouquets or not..." is that an ABM setting, or somewhere else in the menus?
Menu --> Setup --> System --> Channel selection settings --> Enable multiple bouquets
If set to yes --> No problems
If set to no --> Zap timers lock box
abu baniaz
19-03-16, 15:32
It is a settings in the "channel selection settings". Default is yes.
config.epgselection.multi_showbouquet=true is in my settings.
abu baniaz
19-03-16, 16:10
Ouch, some nasty bug in the multiple bouquet section I think. Used Birdman's patch, channel zapped. Bouquets gone.
EDIT 1:
"Last scanned" and "favourites" are system bouquets and cannot be undone. I wonder if this is where the issue lies.
EDIT 2:
Bouquets are not deleted, they are still there. They show up when you set multiple bouquets to yes again.
config.epgselection.multi_showbouquet=true is in my settings.That seems to be, "Show bouquet on launch".
The entry in question is marked as, "Enable multiple bouquets" and shows up as the config.usage.multibouquet setting.
Ouch, some nasty bug in the multiple bouquet section I think. Used Birdman's patch, channel zapped. Bouquets gone.The code looks like this:
if config.usage.multibouquet.value:
bqrootstr = '1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "bouquets.tv" ORDER BY bouquet'
else:
bqrootstr = '%s FROM BOUQUET "userbouquet.favourites.tv" ORDER BY bouquet'% self.service_types
so if you have the setting set to "yes", it will use the results of an ABM scan, otherwise it assumes there is a userbouquet.
The EPG (which is what you set timers from) presumably uses some other test to find your channels.
My fix was just to add an exit clause to the bouquet scan, which cures the symptoms, not the real cause.
Also note that the scan only goes through the tv bouquet - I wonder if you'd have the same loop trying to zap to a radio channel (I wouldn't, as I have all of my radio channels in the TV bouquet - and vice versa, as I can't see nay reason to separate them - the service descriptor says what type it is).
And I've just come across setCurrent() in Components/ServiceList.py, which looks as though it would do a better job of finding the entry in the bouquets than the RecordTimer.py code does, as it does handle radio. Mind you, it doesn't do anything if config.usage.multibouquet isn't set. I have no idea what is supposed to happen in such a case.
..so if you have the setting set to "yes", it will use the results of an ABM scan, otherwise it assumes there is a userbouquet.AFAIK using ABM will produce a bouquets.tv file(?). If so the value should always be set to yes. Does ABM force this?
Basically there are several bits of code which will use bouquets.tv if the value is yes, and userbouquet.favourites.tv if it is set to no.
abu baniaz
19-03-16, 22:51
Ignore ABM. It is nothing to do with the issue.
If you install a new image and restart, you will get the a bouquets.tv file. It is the container for all other bouquet files. When you scan ( non-abm), you will get a last scanned bouquet too.
Ignore ABM. It is nothing to do with the issue.
If you install a new image and restart, you will get the a bouquets.tv file. It is the container for all other bouquet files. But if you have config.usage.multibouquet set to "no" then the code assumes, in several places, that the container (or at least the root) for bouquets is userbouquet.favourites.tv.
So I suppose the question is, "What function does this setting serve?".
abu baniaz
20-03-16, 00:05
Many thanks for your avoidance patch. Has been added.
In this screenshot, the last two bouquets are "favourites/userbouquet.favourites.tv" and "last scanned". Not sure how mrocm made his bouquets, but I could cause the crash without it being populated. Ideally if the bouquet does not exist, it should be called from the all services list method not bouquet list method.
abu baniaz
20-03-16, 00:09
But if you have config.usage.multibouquet set to "no" then the code assumes, in several places, that the container (or at least the root) for bouquets is userbouquet.favourites.tv.
I may be mistaken.
The bottom line is that if that bouquet does not exist/is empty, system should not crash/lockup.
The bottom line is that if that bouquet does not exist/is empty, system should not crash/lockup.But the code, at various places, makes a choice about how bouquets are set-up based on the setting of config.usage.multibouquet.
This strikes me as being wrong. What it should be doing is making that choice based on how the bouquets were set-up at the time the EPG code read them (all) in. Or, even better, use the bouquet structure that was created at that time.
My fix is a sticking plaster - 'it would be better to avoid getting cut in the first place.
Many thanks for your avoidance patch. Has been added.However, the same potential issue occurs in other places too (similar bouquet-searching code). That includes one other identical code sequence (but one level of indentation different) in the same file.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.