52 replies to this topic

[Dimitrij]

I already have (although I admit that the patch file was the debug one until an hour ago - I'd forgotten to update it).

Look at:

http://birdman.dynal...ck.py.patch.033

the GML:2 pair.  The GML:1 part is an efficiency improvement for boot time.

 

first

+#GML:1 - A timer which has already ended (happens during start-up check) can't clash!!
+#      NOTE: that when adding a timer it also cannot clash with:
+#       o any timers which run before the latest period of no timers running
+#         before the timer to be added starts
+#       o any timers which run after the first period of no timers running
+#         after the timer to be added ends
+#      Code to handle this needs to be added (it is *NOT* here yet!)
+#
+		from time import time
+		if (self.newtimer is not None) and (self.newtimer.end < time()):
+			return True
+

This may cause an error.

When loading the receiver of the deep standby mode, the time may not be correct(in some cases).

local time = 01.01.1970 00:02

self.newtimer.end < time()

Edited by Dimitrij, 4 February 2016 - 09:17.

[littlesat]

It seems that someone has put a hard-wired workaround into the TimerSanityCheck.py source for this (the -6, errAllSourcesBusy problem).

 

What is the problem?

 

 

A timer which has already ended (happens during start-up check) can't clash!!

+# NOTE: that when adding a timer it also cannot clash with:
+# o any timers which run before the latest period of no timers running
+# before the timer to be added starts
+# o any timers which run after the first period of no timers running
+# after the timer to be added ends
+# Code to handle this needs to be added (it is *NOT* here yet!)

 

I think what is described here does not really fix a "bug".... it only ignores timers that are already finished in the past that can't conflict anymore... so in fact the added code is only there for making it more complicated... See the extra lines required later on...

 

And what Dimitrij said.... it will be most time used at bootups.... and then it is not working anyway...

 

As far I can see it has no real added value... 

 

Please let me know when I really miss something!

Edited by littlesat, 4 February 2016 - 09:59.

[Dimitrij]

birdman

second ...
Explain to me how this solve the problem(-6, errAllSourcesBusy)?

		for event i(n self.nrep_eventlist:
			cnt += event[1]
			if event[2] == -1: # new timer
				timer = self.newtimer
			else:
				timer = self.timerlist[event[2]]
			if event[1] == self.bflag:
				tunerType = []
				ref = timer.service_ref and timer.service_ref.ref
				fakeRecService = NavigationInstance.instance.recordService(timer.service_ref, True)
				if fakeRecService:
					fakeRecResult = fakeRecService.start(True)
				else:
					fakeRecResult = -1
				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
				if not fakeRecResult: # tune okay
					if hasattr(fakeRecService, 'frontendInfo') and hasattr(fakeRecService.frontendInfo(), 'getFrontendData'):
						feinfo = fakeRecService.frontendInfo().getFrontendData()
						tunerType.append(feinfo.get("tuner_type"))
+						feinfo = None
				else: # tune failed.. so we must go another way to get service type (DVB-S, DVB-T, DVB-C)

					def getServiceType(ref): # helper function to get a service type of a service reference
						serviceInfo = serviceHandler.info(ref)
						serviceInfo = serviceInfo and serviceInfo.getInfoObject(ref, iServiceInformation.sTransponderData)
						return serviceInfo and serviceInfo["tuner_type"] or ""

					if ref and ref.flags & eServiceReference.isGroup: # service group ?
						serviceList = serviceHandler.list(ref) # get all alternative services
						if serviceList:
							for ref in serviceList.getContent("R"): # iterate over all group service references
								type = getServiceType(ref)
								if not type in tunerType: # just add single time
									tunerType.append(type)
					elif ref:
						tunerType.append(getServiceType(ref))

				if event[2] == -1: # new timer
					newTimerTunerType = tunerType
				overlaplist.append((fakeRecResult, timer, tunerType))
				fakeRecList.append((timer, fakeRecService))
				if fakeRecResult:
					if ConflictTimer is None: # just take care of the first conflict
						ConflictTimer = timer
						ConflictTunerType = tunerType
+				fakeRecService = None
+				fakeRecResult = None
			elif event[1] == self.eflag:
				for fakeRec in fakeRecList:
					if timer == fakeRec[0] and fakeRec[1]:
						NavigationInstance.instance.stopRecordService(fakeRec[1])
						fakeRecList.remove(fakeRec)
				fakeRec = None
				for entry in overlaplist:
					if entry[1] == timer:
						overlaplist.remove(entry)
			else:

[birdman]

This may cause an error.
When loading the receiver of the deep standby mode, the time may not be correct(in some cases).
local time = 01.01.1970 00:02

self.newtimer.end < time()

Thanks - I'll bear that in mind.

[birdman]

 

It seems that someone has put a hard-wired workaround into the TimerSanityCheck.py source for this (the -6, errAllSourcesBusy problem).

What is the problem?

 

• It's a workaround. It doesn't make any attempt to cure the root problem.
• It doesn't actually catch all false conflicts caused by that root problem. In my tests I used 3 timers. A (06:00 - 09:15), B (06:00 - 06:45) and C (07:05 - 07:55) on 3 different Freeview muxes (I have 2 tuners).  Adding these in the order B, C, A resulted in C being reported as clashing with A and B. The same happened if the order was C, B, A.  Note that this means C is reported as clashing with a timer that has completed before it starts.
  Your workaround would not catch this case.

A timer which has already ended (happens during start-up check) can't clash!!
+# NOTE: that when adding a timer it also cannot clash with:
+# o any timers which run before the latest period of no timers running
+# before the timer to be added starts
+# o any timers which run after the first period of no timers running
+# after the timer to be added ends
+# Code to handle this needs to be added (it is *NOT* here yet!)
 
I think what is described here does not really fix a "bug".... it only ignores timers that are already finished in the past that can't conflict anymore... so in fact the added code is only there for making it more complicated... See the extra lines required later on...
 
And what Dimitrij said.... it will be most time used at bootups.... and then it is not working anyway...
 
As far I can see it has no real added value... 
 
Please let me know when I really miss something!

It speeds up the Sanity check. As an obvious case, if all of you current timers are for the evening and you add a timer for the morning it can't clash with any of them, yet the current code will still run the check against every timer you have set.

The added code would be short and simple (I have a rough draft).

Edited by birdman, 6 February 2016 - 21:47.

[birdman]

birdman
second ...
Explain to me how this solve the problem(-6, errAllSourcesBusy)?

The three added lines all unset references to (C++) objects that are used denote assigned tuners/frontends etc.. Without these lines they stay active until the next timer begins and re-assigns values (which is too late for the check).  So if the timer that last began is also the timer that next ends its tuner resources have not been freed when the next timer goes looking for a free tuner.

 

They are the equivalent of the "fakeRec = None" line in the self.eflag block at the end. that is there to free the last assignment in the loop above it (as Python doesn't have block-scoping of variables).

Edited by birdman, 6 February 2016 - 21:56.

[birdman]

 

This may cause an error.
When loading the receiver of the deep standby mode, the time may not be correct(in some cases).
local time = 01.01.1970 00:02

self.newtimer.end < time()

Thanks - I'll bear that in mind.

 

Although it occurs to me that it won't actually fail, as if the clock is still set at the start of the Epoch then none of the timers will be deemed to have ended and we fall back to the current situation - so it just takes longer again.

[Dimitrij]

birdman

I think so.
Or am I wrong?

http://git.opendream...820740ed7766f39

						overlaplist.remove(entry)
			else:
				print "[TimerSanityCheck] bug: unknown flag!"
			self.nrep_eventlist[idx] = (event[0],event[1],event[2],cnt,overlaplist[:]) # insert a duplicate into current overlaplist
+			feinfo = None
+			fakeRecService = None
+			fakeRecResult = None
			idx += 1

		if ConflictTimer is None:
			print "[TimerSanityCheck] conflict not found!"
			return True

Edited by Dimitrij, 8 February 2016 - 12:55.

[littlesat]

So dream did steal it somehow a bit..... But they only added two lines...

 

self.newtimer.end < time()

->

As far I understand we check now on timer status ended... en that is what I think smarter... This part is only required for speeding the check a bit up...

Edited by littlesat, 8 February 2016 - 16:45.

[littlesat]

I just checked... but it seems we have it in our code 

 

https://github.com/O...8a1060f022a986e

[birdman]

birdman
I think so.
Or am I wrong?

Well, that will work - but it is mis-leading, so anyone coming along and looking at the code later may be confused.
The idea of my patch was to unset these variables within the indentation level (it's not a block - as Python doesn't have those) where they are set (as was already being done for fakeRec). The comments were also there to help with why the setting to None is done (in case someone comes along and decides that such a setting for something that isn't used again later in the loop anyway is superfluous and can be removed).
You are unsetting all 3 at the end of the loop - which removes that setting from where it needs to be seen to be done.

Edited by birdman, 9 February 2016 - 04:36.

[littlesat]

You made big comments in your orriginal patch... But also they are not clear But I fully agree that in needs some remarks as it is very tricky what is done here... Therefore it can indeed be consider to add comments there... But it can be a simple one liner right to the point...

Edited by littlesat, 9 February 2016 - 07:49.

[birdman]

You made big comments in your orriginal patch...

Not really. There was a big comment at the top to remind me about things that could be done further, but the comments for reference-freeing lines were essentially one-liners. They were wrapped to two lines as I always like to wrap before column 72, and I'd put my initials at the front to help me get to my code changes easily in an editor.