View Full Version : [ViX_Misc] TimerSanityCheck can report a failure when it should be OK
I'm having problems with getting a recording to be enabled.
There are two existing timers:
20:57 to 22:45
20:57 to 22:05
The one I'm trying to add is for:
22:27 to 23:20
i.e. after the latter of those first two timers has finished I should have a free tuner for that next recording to run; but TimerSanityCheck reports otherwise.
I've added some debug statements to TimerSanityCheck.py to see what is going on. All I can see is that
the fakeRecService.start(True) produces an abnormal result (True not False?), so then
if not fakeRecResult: # tune okayfails. The code then goes on to add an item of "DVB-T" to tunerType. This still leaves it as a failure, though.
I haven't (yet?) been able to find what handles that fakeRecService.start(True) call. (EDIT: eDVBServiceRecord::start() in lib/service/servicedvbrecord.cpp?)
The odd thing is that if I edit the start time of one of those timers to be 20:55 then the sanity check passes OK (so is it cause by having timers starting up at the same time?). However, since these are set by autotimers, when that runs again it resets the start times and then on the following autotimer scan it throws up the clash again.
However, since these are set by autotimers, when that runs again it resets the start times and then on the following autotimer scan it throws up the clash again.I know it's only a workaround, but you could always change the "custom offset" for one of the autotimers, or even disable it after editing one of the timers.
I've always wondered what the green tick next to an autotimer meant - it shows that it is "enabled".
It's a pity it doesn't indicate if any timers have been set as well.
Hope you can find a proper solution.
I know it's only a workaround, but you could always change the "custom offset" for one of the autotimers, or even disable it after editing one of the timers.That was going to be step 2.
Step 1 was to edit the timers.xml file to swap the two timers around that start at the same time (so the one which finished first is first in the file).
And that works!!!
It might be a simpler "solution", as that file is written out in python (so I can sort it there) whereas the TimerSanityCheck issue is somewhere unknown in C++ code.
I've always wondered what the green tick next to an autotimer meant - it shows that it is "enabled".
It's a pity it doesn't indicate if any timers have been set as well.I don't think anything actually knows which timers have been set by which autotimers (read on....)
Hope you can find a proper solution.Well, I'll sort equal-string timers on finish times shortly....
Now, about timers and autotimers. I've been working on the AutoTimer code to make the similarity level (for titles and descriptions) be configurable, add the ability to remove
flags (and any other text you want) from the end before checking for similarity, and also configuring timegroups (time spans) such that any programmes that fall into different ones will be considered as different even if their description are the same (== "sufficiently similar).
Once I'd added the timegroups I was wondering whether the other two bits would be useful, as the timegroups seemed to discriminate everything for me.
But, in a timely reminder that it helps to have as many options as possible, this coming weekend Channel 5 decided to split the Football League Tonight into two programmes, running consecutively. The programmes are all repeated (and also on Ch5+1, Ch5+24 and Spike). Given that I usually (but not always) have clashes with the first broadcasts I have to set it up so that it will find any of them. The first broadcasts all have "New:" at the start, but the repeats do not.
Now, "New: The Championship: Football..." and "The Championship: Football..." are 0.920634920635 similar, but "New: Goal Rush: Football League..." and "Goal Rush: Football League Tonight" are only 0.764705882353 similar, which is below the 0.8 test for titles. So I'd get two recordings of the Goal Rush done each time (one with New:, one without). However, I can now configure that level, so I lowered it to 0.6 (this was before I did a test of the similarity levels), and at that point I got none, as there is actually a 0.617647058824 similarity between the different programmes, and since there is no indication of which autotimer set which timer, you can get a match between programmes that would be set by different autotimers.
Anyway, I've managed to set a level that works.
I've figured out where to make the changes so that all new timers (anything added to the timer_list) get added sorted by a primary key of the start time and a secondary one of the end time.
It replaces insort() calls with an append and keyed sort (of the start and stop times).
Patches are available under the Timers-EndSort at:
http://birdman.dynalias.org/OpenVix/
The odd thing is that if I edit the start time of one of those timers to be 20:55 then the sanity check passes OK.Not actually what is happening.
I've gone back to the original code and done some testing. The issue happens when the the longer timer comes first, even if the start times are different (presumably when I changed one yesterday I altered things such that the order changed).
So:
20:57 to 22:45 (New: The Young Montalbano, BBC Four)
20:57 to 22:05 (New: The Championship: Football..., Channel 5)
results in a clash for:
22:27 to 23:20 (QI XL, BBC TWO HD)
but if the order of the first two recordings changes (either by modifying start times by a minute, or sorting timers such that equal starters are sorted by end times) the the clash doesn't happen and the third timer adds OK.
This happens whether creating a new timer or trying to enable a disabled one (which is much quicker to do when testing...)
Not actually what is happening.
Thanks for finally explaining the issue in simple steps.
20:57 to 22:45 (New: The Young Montalbano, BBC Four)
20:57 to 22:05 (New: The Championship: Football..., Channel 5)
results in a clash for:
22:27 to 23:20 (QI XL, BBC TWO HD)
Set the same 3 recordings & issue is obvious.
Issue should be moved out of [MB Premium Twin HD] as it happens on all ViX images.
abu baniaz
15-01-16, 02:35
Issue should be moved out of [MB Premium Twin HD] as it happens on all ViX images.
Done. Changed to "Vix Misc"
It's just occurred to me that since this can occur with timers starting at different times (see #5), it should be able to happen at any time. So I'm surprised I haven't seen it before...but when I have multiple concurrent timers they tend to be on BBC1/BBC2/ITV/Ch4 HD, which are all on the same FreeviewHD mux, so no conflicts - this set seems to be abnormal for me.
I've set the conditions up again and added code to see what fakeRecService.start(True) is actually returning.
The answer is -6.
I've had a look at the code in eDVBServiceRecord::start() and can't see anything that would do that (only -1, -2, -3 and -4 are defined in the enums). Hmmmm......
It's just occurred to me that since this can occur with timers starting at different times (see #5), it should be able to happen at any time.
I've just set:
13:00 -> 18:00 BBC2 Snooker
14:00 -> 15:00 ITV Judge Rinder
then tried to add:
16:06 -> 16:40 ITV3 Man About the House
and the latter reports a clash with the Snooker. So this seems to be a general problem when you have a long running recording with multiple shorted ones overlapping.
Looks like I may have to compile debug versions of enigma2 itself....
but when I have multiple concurrent timers they tend to be on BBC1/BBC2/ITV/Ch4 HD, which are all on the same FreeviewHD mux, so no conflicts - this set seems to be abnormal for me.At 21:00 on Sunday I have all 4 of those channels recording. I can also add a fifth on a separate mux OK.
The failing example above is three different muxes.
So, my "sort on end times as well" is only a workaround for the case I had.
Looks like I may have to compile debug versions of enigma2 itself....I've made the first step along that path - I've just produced a (working) build of enigma2 (or rather, all of Openvix), so should now be able to add debug statements in the C++ code to help figure out what is going on.
Various mutterings along the way, as some people think you can put bash extensions into /bin/sh scripts (which doesn't work on a Debian/Ubuntu-based system). Also, the minidlna SourceForge CVS server was broken, so I looked for another source, found one (looks like the development site has moved off SourceForge?), but then had to work out what to do to the *.bb build configuration file to get it to download and use a *.tar.gz file instead of a CVS repository.
Along the way I was hit by two bugs in the text editor I've used for the last >20 years. It never did much bother with buffer size checking. So, one more fix, and one more larger buffer size (with a test in at least one place). At least some debugging got done today.
ccs has pointed out that there is a similar issue reported on the OpenPLi forum:
http://forums.openpli.org/topic/39306-problem-with-timer-sanity-check/?view=findpost&p=511785
I've made the first step along that path - I've just produced a (working) build of enigma2 (or rather, all of Openvix), so should now be able to add debug statements in the C++ code to help figure out what is going on.Hmm....well, so I though, but....
If I edit either of the two copies of servicedvbrecord.cpp (well, 3 - but 2 are hard-linked) and run a rebuild then the enigma2 executable doesn't get rebuilt. How do I make that happen?
I've set the conditions up again and added code to see what fakeRecService.start(True) is actually returning.
The answer is -6.
I've had a look at the code in eDVBServiceRecord::start() and can't see anything that would do that (only -1, -2, -3 and -4 are defined in the enums). Hmmmm......
Something else is getting -6 as an error too:
http://www.world-of-satellite.com/showthread.php?49834-Zap-timers-lock-box&p=388337&viewfull=1#post388337
Set the same 3 recordings & issue is obvious.By "obvious" do you mean you know what the cause of the problem is?
By "obvious" do you mean you know what the cause of the problem is?
Nope, just that obvious = easier to reproduce it, so hopefully easier to find a solution.
Obvious bugs get fixed faster, so better to make them as obvious & easy to reproduce as possible.
I've just set:
13:00 -> 18:00 BBC2 Snooker
14:00 -> 15:00 ITV Judge Rinder
then tried to add:
16:06 -> 16:40 ITV3 Man About the House
and the latter reports a clash with the Snooker.
I've just tried the above (same times, all on different mux's), and I don't see any sanity errors.
A 4th recording 16:06->16:40 on a 4th mux is ok as well.
4 enabled T2 tuners.
I've just tried the above (same times, all on different mux's), and I don't see any sanity errors.
A 4th recording 16:06->16:40 on a 4th mux is ok as well.
4 enabled T2 tuners.I only have 2, so it's a different scenario.
Given that it depends on the order of the first two recordings I suspect it's dependent on having just 2.
Although if you had another 2 recording starting before and ending after these that might trigger it.
You'd need to have a 5 recordings scenario before you had any change of a conflict/
I only have 2, so it's a different scenario.
OK, I didn't realise.
If I do the same again with 2 tuners enabled, I get the sanity check error.
If I try with 4 tuners enabled.....
timer1, timer2, and timer3 all set to 14:00->18:00
timer4 set to 15:00->16:00
timer5 set to 17:00->17:30, I get sanity error conflicts on timer1/timer2/timer3, (all 3 are flagged as conflicts).
If I try with 4 tuners enabled.....
timer1, timer2, and timer3 all set to 14:00->18:00
timer4 set to 15:00->16:00
timer5 set to 17:00->17:30, I get sanity error conflicts on timer1/timer2/timer3, (all 3 are flagged as conflicts).Thanks. That looks like the same problem. You have n tuners, but a conflict is reported against n-1 of them (which "can't" happen when all of the tuners are the same).
Now, if someone can tell me how to make the build process (uses bitbake) re-build enigma2 when I edit its source files I might be able to find out more...
if you run the build process again it will just update e2
If I try with 4 tuners enabled.....
timer1, timer2, and timer3 all set to 14:00->18:00
timer4 set to 15:00->16:00
timer5 set to 17:00->17:30, I get sanity error conflicts on timer1/timer2/timer3, (all 3 are flagged as conflicts).
Not sure it this proves anything, but if timer3 is set to 15:00->16:00 it works ok....
timer1 and timer2 both set to 14:00->18:00
timer3 and timer4 both set to 15:00->16:00
timer5 set to 17:00->17:30, works ok.
if you run the build process again it will just update e2It didn't when I tried it - hence the question.
See #12 in this thread (http://www.world-of-satellite.com/showthread.php?49866-TimerSanityCheck-can-report-a-failure-when-it-should-be-OK&p=388636&viewfull=1#post388636).
Not sure it this proves anything, but if timer3 is set to 15:00->16:00 it works ok....
timer1 and timer2 both set to 14:00->18:00
timer3 and timer4 both set to 15:00->16:00
timer5 set to 17:00->17:30, works ok.Sort of fits with what is in my mind.
If a timer starts and takes the last tuner, then it stops and another recording comes along to take that last tuner (as the others are still occupied with what was there for the first timer) then a conflict is signalled.
Mind you, this is all in the "simulate" code. Not sure what happens if you let the timers actually run in this state (and I can get them into "all active, but conflict reported" by changing the start time of one to allow them all, then changing it back).
But now is not the time for me to test it (lots of real timers coming up).
It didn't when I tried it - hence the question.
See #12 in this thread (http://www.world-of-satellite.com/showthread.php?49866-TimerSanityCheck-can-report-a-failure-when-it-should-be-OK&p=388636&viewfull=1#post388636).
then you will have to explain to me how your attempting to do it.
as always on a rebuild if e2 has been updated, it gets updated, you must be doing something wrong.
you must be doing something wrong.That's what I suspect..
I use a script which does:
git clone git://github.com/oe-alliance/build-enviroment.git oe-alliance
git clone git://github.com/OpenViX/enigma2.git ssh-enigma2
It then runs (for my config)
cd oe-alliance
MACHINE=mbtwin DISTRO=openvix make update
cd -
cd ssh-enigma2
git pull --ff-only || git pull --rebase
to populate things and finally
cd oe-alliance
MACHINE=mbtwin DISTRO=openvix make image
to create a full OpenVix image. Along the way it has built the enigma2 executable, which is all I'm actually interested in.
But if I then edit servicedvbrecord.cpp (which is in oe-alliance/builds/openvix/release/inihdx/tmp/work/mbtwin-oe-linux/enigma2/enigma2-5.1+gitAUTOINC+a33e2d4525-r2/package/usr/src/debug/enigma2/enigma2-5.1+gitAUTOINC+a33e2d4525-r2/git/lib/service/) and run the make image again, it doesn't rebuild enigma2.
It doesn't rebuild it if I edit the servicedvbrecord.cpp in ssh-enigma2/lib/service either.
I've set the conditions up again and added code to see what fakeRecService.start(True) is actually returning.
The answer is -6.
I've had a look at the code in eDVBServiceRecord::start() and can't see anything that would do that (only -1, -2, -3 and -4 are defined in the enums). Hmmmm......
I've found another reference to the -6 result code on OpenPLi......
http://forums.openpli.org/topic/23062-timer-bug/?view=findpost&p=500533
I've figured out where to make the changes so that all new timers (anything added to the timer_list) get added sorted by a primary key of the start time and a secondary one of the end time.
It replaces insort() calls with an append and keyed sort (of the start and stop times).
Patches are available under the Timers-EndSort at:
http://birdman.dynalias.org/OpenVix/Which have resulted in a few unexpected failures.
I've had two crashes, with
Traceback (most recent call last):
File "/usr/lib/enigma2/python/timer.py", line 250, in calcNextActivation
self.processActivation()
File "/usr/lib/enigma2/python/timer.py", line 323, in processActivation
self.doActivate(self.timer_list[0])
File "/usr/lib/enigma2/python/RecordTimer.py", line 848, in doActivate
if w.activate():
File "/usr/lib/enigma2/python/RecordTimer.py", line 545, in activate
if (abs(NavigationInstance.instance.RecordTimer.getNe xtRecordingTime() - time()) <= 900 or abs(NavigationInstance.instance.RecordTimer.getNex tZapTime() - time()) <= 900) or NavigationInstance.instance.RecordTimer.getStillRe cording():
File "/usr/lib/enigma2/python/RecordTimer.py", line 1011, in getStillRecording
if timer.isStillRecording:
AttributeError: 'RecordTimerEntry' object has no attribute 'isStillRecording'
< 2596.449457> [ePyObject] (CallObject(<bound method RecordTimer.calcNextActivation of <RecordTimer.RecordTimer instance at 0x724900f8>>,()) failed)
]]>
Both were for timers that woke the box up, ran in Standby and tried to go to Deep Standby.
I also had two recordings consecutive recordings on the same channel which, instead of running on two tuners with an overlap (there were no other timers at the time) ran consecutively on one tuner - the second starting up as soon as the first completed.
So I've reverted my code....
Still trying to figure out how to build a version of enigma2 I can use for debugging.....
I also had two recordings consecutive recordings on the same channel which, instead of running on two tuners with an overlap (there were no other timers at the time) ran consecutively on one tuner - the second starting up as soon as the first completed.
Wouldn't it normally record the 2 programmes using the same tuner (and with overlap)?
What you saw should only happen if only one tuner is available to record consecutive programmes and they are on different channels (mux's).
.... and aren't there issues doing this anyway?
I must say that this does surprise me.
Does this mean that a box with a single tuner can't record consecutive programmes (one ends when the other one starts, no padding) on different mux's (or whatever the terminology is), without a clash being generated?
Yes, that is what it means.
Wouldn't it normally record the 2 programmes using the same tuner (and with overlap)?
What you saw should only happen if only one tuner is available to record consecutive programmes and they are on different channels (mux's).
.... and aren't there issues doing this anyway?Precisely. Which in itself is odd (it really did switch on the second recording ~2s after stopping the first). All my added code did was to sort the programmes based on end time iff the start time was the same. So it shouldn't have affected this anyway. Perhaps it didn't and the oddity would have happened anyway, but since the problem the code was added for isn't specific to timers with equal starting times anyway, I decided I might as well remove it.
Well, I appear to have found a way to rebuild enigma2 quickly.
The front-end script to bitbake I have builds everything in the entire OpenVix image. It ends up with the image and a complete set of *.ipk files, but deletes all intermediate files. So not much use for debugging.
I do have a Debian mips system running (as a qemu chroot environment on a x64 VirtualBox VM system) so tried building it on that. Eventually I found the right files under the bitbake build to figure out what options to give to configure, and also installed of the *.ipk files for missing/iupdated packages c.f. the Debian mips setup (just copied all of the package files into place by hand - I have a copy of the original chroot environment to go back to at the end).
Running with those configure options (I'd tried some others while searching, but couldn't get the resulting image to run) results in an image which, although a little larger than the standard enigma2 image (after stripping), does actually run.
So it looks as though I have a a working (albeit unconventional) debugging environment.
Just noticed a new version of OpenVix (034) is out, so I'm going to upgrade to that, then recreate my debug environment from scratch using that, and make tidier notes along the way.
abu baniaz
20-01-16, 03:02
......Just noticed a new version of OpenVix (034) is out.
035 is being built.
035 is being built.So I now notice - and this is what I'd downloaded before updating to 034. I'm now on 035 and the build has just been started - I'm off to the gym while it runs....
I can now run debugging versions of enigma2.
In the process of checking that an eDebug statement got to the log file I noticed this:
[TimerSanityCheck] Possible Bug: unknown Conflict!and it turns out I've been getting this for 5 days. The first entry is in the last log before the [TimerSanityCheck] tag was added to that text.
At least I now know what the -6 error is:
errAllSourcesBusy
returned by allocateFrontend in dvb.cpp.
Now I "just" need to know why it's losing track of things, so need to find out how it de-allocates channels (done it once, but didn't make notes...). It seems to reckon it has a slot in use when there are no recordings taking place (1 in use - add another, remove 2, still reckons 1 in use, but no active recordings at that point...).
I haven't found the cause, but I'm getting information.
I've also found a bug/mis-feature in the process.
At the moment, when the box starts up each timer, as it gets added to the timer list, gets run through the TimerSanityCheck, where it gets checked against all timers currently on the list for unhandleable tuner conflicts.
Nothing wrong with that, apart from the fact that all completed timers are run though the same code, as when they first get added at boot time all timers have a state of StateWaiting (0).
So all completed timers (which come at the end of the list) get checked against all waiting timers.
I've added code to TimerSanityCheck.py (~line 75) to ignore timers whose end time has already passed.
It might make more sense to set their state to StateEnded as they are read in, but that is all done in resetState(), which does other things and it wasn't clear to me whether this would affect other parts of the code (such as discarding them completely when read in rather than after the configured time).
################################################## ################################
# process the new timer
self.rep_eventlist = []
self.nrep_eventlist = []
if ext_timer != 1:
self.newtimer = ext_timer
#GML - A timer which has already ended (happens during start-up check) can't clash!!
from time import time
if (self.newtimer is not None) and (self.newtimer.end < time()):
return True
As for the actual bug.
For some reason my box decided this evening to start reporting a clash on Saturday evening (again) for timers that have been in place, untouched, all week without any such reporting.
I can see that it has 1 of 2 tuners in use, and adds a (simulated) timer.
It then removes two recordings, but neither of these ends up calling dec_use() (which it should) .
However, while checking that, I noticed that I'd forgotten to add the current (simulated) recording count as they were removed. So I added that line and the problem has gone away (dec_use() is now being called)!
Commenting out that line (it's in python code) doesn't make it come back either!?
However, the dec_use() call is in a destructor, so I'm wondering whether there is an issue with when an object gets destroyed, involving how different thread run?
However, the dec_use() call is in a destructor, so I'm wondering whether there is an issue with when an object gets destroyed, involving how different thread run?Slow "progress".
It's definitely to do with when the destructor gets run. I can't find any evidence of threads being involved, but if I add a 1s delay after removing each check timer from the list (it then takes several minutes to get the box to start) I still end up with the same clash.
(And without this I can get a recording this evening and one next morning to "share" a channel, because the destructor is late so the channel is still marked as in use...)
The services added to the list do keep their own reference count (of something) using AddRef and Remove. Hmmm.....more work yet.
Is this an INI driver bug?
Is this an INI driver bug?I doubt it. It's a generic problem. See http://www.world-of-satellite.com/showthread.php?49866-TimerSanityCheck-can-report-a-failure-when-it-should-be-OK&p=388678&viewfull=1#post388678
I can't see the code getting near any drivers, as it isn't doing anything real to any hardware when it goes wrong - it's simulating everything.
I *might* have solved it!!!!
It's sufficiently obscure to be the actual problem, and fixing it does end up with a "missing" destructor running at the same time that it should run (based on adding timers in a way that doesn't produce clashes).
Just need to do some more testing - and at the moment I've have imminent recordings.
Although the issue is about reference counts, the bug (and hence fix) is in the TimerSanityCheck.py code....
FIXED!!!! (I believe...).
Just need to do some more testing - and at the moment I've have imminent recordings.Just as well I did, as I'd put in two parts to fix it. Part1 didn't work, so I added part2, which did. So I was just going to remove part1, but a test showed that although that did allow my test recordings to be added without clashes, it was clear from the log that it was "working but still wrong" (the destructor was still called late, but not so late that the clash was reported).
So, both parts are needed.
After several days of adding lots of debug statements to the C++ code (and having to turn on RTTI [or rather, turn -fno_rtti off], so that I could print debug info for just the 3 types of ePtr I needed, not all 114 of them) I was able to set up just 3 timers in one order which worked, and one order which didn't. Looking at the debug output it seemed that there was a destructor call missing as the code went back into TimerSanityCheck.py. So I finally had a look at that and, indeed, there are 3 variables that hang on to references as timers are added. The result of this was that if the timer that is ending is the same one as was last started up, its FrontEnd (tuner) doesn't get released when it should, and hence continues to be "busy".
Setting the three variables to None at the end of the start-up tests clears this problem. Interestingly the end timer code already had such a var = None setting.
So I've managed to learn a lot more about C++ templates, and about Python's (lack of) variable scoping.
The patch is at
http://birdman.dynalias.org/OpenVix/under SanityCheck. It also includes the test for completed timers, so that the Done timers passed in at boot time aren't check (there is no way they can clash) - and also mentions a possible way to speed up the check in general, but I haven't coded that yet.
Quite a few changes to TimerSanityCheck.py coming up on OpenPLi...
https://github.com/OpenPLi/enigma2/commit/0557b78ca2cc2fd29994d363a092b5ee29bc8b58
Quite a few changes to TimerSanityCheck.py coming up on OpenPLi...
https://github.com/OpenPLi/enigma2/commit/0557b78ca2cc2fd29994d363a092b5ee29bc8b58Interestin g.
A lot of it seems to be related to the timer type changing, but it also includes this:
+ if fakeRecResult == -6 and len(NavigationInstance.instance.getRecordings(True )) < 2:
+ print "[TimerSanityCheck] less than two timers in the simulated recording list - timer conflict is not plausible - ignored!"
+ fakeRecResult = 0 which is a hard-code workaround (==kludge) for what I have just fixed.
Looks like I need to post to the relevant OpenPli thread as well....
The patch is at
http://birdman.dynalias.org/OpenVix/under SanityCheck.Well, it is now. I'd left the debugging patch in place (although TimerSanityCheck.py itself was "correct").
Thanks Birdman. Changes so far are here:
https://github.com/OpenViX/enigma2/commit/55aacdf7c5ebdaa5204e90137870657b62d109ea
Thanks Birdman. Changes so far are here:
https://github.com/OpenViX/enigma2/commit/55aacdf7c5ebdaa5204e90137870657b62d109eaThat highllights something...
An extraneous ";" has crept in (to my code...now removed) on this line:
208: + feinfo = None;Just habit.
It doesn't seem to affect python, but it might be best to remove it.
What language do you normally work in?
What language do you normally work in?Most of my scripting would have been in Perl.
Hi Birdman, can you look at the latest commit to this file on OpenPLi. Also to do with "done" timers.
I can't see anything to do with done timers on the History page of changes for the master branch.
https://github.com/OpenPLi/enigma2/commits/master/lib/python/Components/TimerSanityCheck.py
Some activity also on the OpenPLi/Dutch forum. :)
Some activity also on the OpenPLi/Dutch forum. :)Dutch?
I know there's been activity on the Deutsch one, since I was doing (a lot of) the posting.
Dutch?
I know there's been activity on the Deutsch one, since I was doing (a lot of) the posting.Yes, the Dutch forum, fortunately most of the relevant thread is in English.
http://forums.openpli.org/topic/40505-timer-uitgeschakeld/
Yes, the Dutch forum, fortunately most of the relevant thread is in English.
http://forums.openpli.org/topic/40505-timer-uitgeschakeld/Thanks. I've added a note to that pointing to the explanation I put on the German thread.
Everything else seems to be about wishing to turn the conflict checking off when you can see it's wrong, rather than actually fixing the problem.
Its always easier to take the easy option :) especially if the "problem" then seems to "disappear" ... But I always thought the Openpli crowd thought themselves above doing things like that:)
Its always easier to take the easy option :) especially if the "problem" then seems to "disappear" ... But I always thought the Openpli crowd thought themselves above doing things like that:)It was those suffering/reporting the clashes who wanted to be able to turn it off (as far as I could tell).
Birdman, here is the commit,
https://github.com/OpenPLi/enigma2/commit/6e41e91cc6a5b5b0170581b7913ba7767eabca90
Here is the discussion,
http://forums.openpli.org/topic/39299-timer-conflicts/page-4#entry529571
The reason for turning off sanity check is so remote (uncheckable) tuners can be used for recordings. For anyone who wants reliable recordings this is obviously madness.
Thanks Huevos, I must admit I have been looking at the fallbacktuner & timer conflicts thread ..... From my Wetek experiences running as a client to one of my ET8500,s there are many situations where the streaming from the remote has been broken up ... It is just difficult (for me at least) to get any debug info as to why it happens between the 2 boxes (I am also aware of issues between other non like receivers eg VU/xtrend)
Are you aware of any flags you can set to force more debug msgs? ... Purely on the streaming side.
Not sure. I use my boxes as satellite receivers, and only ever stream occasionally. Never had any problems over wired LAN.
BThe reason for turning off sanity check is so remote (uncheckable) tuners can be used for recordings. For anyone who wants reliable recordings this is obviously madness.I wondered what the '%3a//' check was for. Not having a second box I've never used them (and can't see why you wouldn't do the recording on the other box directly - but no doubt someone does).
Given that I was going to write code to greatly reduce the amount of conflict checking that needs to be done (most of the current checks are unnecessary) I can filter out remote ones as well, since I assume that they are "hope and pray" attempts. I have the pseudo-code written (somewhere...).
Thanks Birdman. Changes so far are here:
https://github.com/OpenViX/enigma2/commit/55aacdf7c5ebdaa5204e90137870657b62d109eaI see it didn't make 037, though.
It has made it into 4.0_002.
(At first I though it hadn't, but I was looking at the diff the wrong way round).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.