[ViX_Misc] Zap timers lock box

[mrocm]

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.

 

[mrocm]

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.... :-(

 

[mrocm]

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]

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.

 

[mrocm]

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.

 

[mrocm]

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.

 

[birdman]

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 somewhere

If there is a crash or a hang then there is a bug.

 

[birdman]

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/s...rking-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.

 

[mrocm]

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.

 

[birdman]

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]

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.

 

[mrocm]

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.

 

[birdman]

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.

 

[birdman]

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.

 

[birdman]

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) View attachment RecordTimer.zip 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.

 

[mrocm]

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.

 

[mrocm]

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]

I would attach timers.xml too

 

[mrocm]

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.

 

[Huevos]

So which timer failed?