Jump to content


Photo

Multistream tuner conflicts


  • Please log in to reply
80 replies to this topic

#1 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 20 August 2017 - 15:37

Report from another user... I can't confirm this on PLi because I don't have a TBS5925, but I can confirm this also affects all oe-a images using my SF4008. But there is definitely an indent error in TimerSanityCheck.py which someone who is familiar with the code needs to look at. Not sure if this "else" clause belongs to the outer or inner "if" clause.

https://github.com/O...tyCheck.py#L275

 

Report as follows:

 

 

If I start a recording on a DVB-S/S2 channel, I find I can't then record at the same
time from a multistream channel (such as on 5.0 W or 12.5 W) via another tuner. The
box displays the multistream channel, but if I try to record it, it pops up a
message: "Could not record due to a conflicting timer <programme title>".
Conversely, if I record a multistream channel, I can't then record anything else
(multistream or otherwise) until it has finished. It doesn't seem to matter which
tuner I make the recording from -- the effect is the same, whether it's on the same
stream as the channel being recorded, on a different transponder or even on a different
satellite. But no conflict arises with plain DVB-S/S2 channels -- I can record those
freely from up to three different satellites simultaneously, as you'd expect.

I hit this problem with my Vu+ boxes (Duo2 and Solo4K) when using a TBS5925 USB
tuner: recording a multistream channel from this tuner would prevent the box from
recording anything else.

 

Testing on SF4008, 2x DVB-S2 multistream tuners. Tuner B, USALS. Tuner A, 28E only:

Started recording multistream channel on 5W.

Switch to BBC1 HD on 28E.

Recording and current service working fine.

Try to start instant record opens a timer conflict message.

Log exert below starts on pressing record on BBC1 HD.

 

 

< 11633.338> [eInputDeviceInit] 1 a7 1
< 11633.339> [InfoBarGenerics] KEY: 167 RECORD
< 11633.339> [ActionMap] InfobarInstantRecord instantRecord
< 11633.341> [eDVBServicePlay] timeshift
< 11633.344> [Choicebox] count 3
< 11633.349> [Skin] processing screen ChoiceBox:
< 11633.352> [Skin] processing screen ChoiceBox_summary:
< 11633.611> [eInputDeviceInit] 0 a7 1
< 11633.611> [InfoBarGenerics] KEY: 167 RECORD
< 11635.368> [eInputDeviceInit] 1 160 1
< 11635.369> [InfoBarGenerics] KEY: 352 OK
< 11635.369> [ActionMap] WizardActions ok
< 11635.374> [eDVBFrontend] isCompatibleWith system 1 is_id 1 pls_code 8 pls_mode 0 is_multistream 1
< 11635.374> [eDVBFrontend] isCompatibleWith system 1 is_id 1 pls_code 8 pls_mode 0 is_multistream 0
< 11635.374> [eDVBFrontend] isCompatibleWith NON MULTISTREAM TUNER!!!!!
< 11635.374> [TimerSanityCheck][getServiceType] DVB-S
< 11635.375> [eDVBFrontend] isCompatibleWith system 1 is_id -1 pls_code 1 pls_mode 0 is_multistream 1
< 11635.375> [eDVBFrontend] isCompatibleWith NON MULTISTREAM CHANNEL!!!!
< 11635.375> [eDVBResourceManager] allocateFrontend, score=15004
< 11635.375> [eDVBFrontend] isCompatibleWith system 1 is_id -1 pls_code 1 pls_mode 0 is_multistream 0
< 11635.375> [eDVBResourceManager] allocateFrontend, score=9983
< 11635.375> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x3e1cd, guard_offset 0
< 11635.375> **** Tuning JESS
< 11635.375> **** frequency_mhz: 10847
< 11635.375> **** lo_mhz: 9750
< 11635.375> **** T: 997
< 11635.375> **** position: 0
< 11635.375> **** ub: 31
< 11635.375> **** mode: 0
< 11635.375> **** JESS: 70 fb e5 00
70fbe500(?)
< 11635.375> [TimerSanityCheck] conflict detected!
< 11635.375> [RecordTimer] timer conflict detected!
< 11635.375> [RecordTimerEntry(name=†Songs of Praise‡, begin=Sun Aug 20 15:39:17 2017, serviceref=1:0:19:1B1D:802:2:11A0000:0:0:0:, justplay=False, isAutoTimer=False), RecordTimerEntry(name=L'Ispettore Barnaby, begin=Sun Aug 20 15:36:16 2017, serviceref=1:0:1:2C7:107:217C:DDE0000:0:0:0:, justplay=False, isAutoTimer=False)]
< 11635.376> [eDVBFrontend] isCompatibleWith system 1 is_id 1 pls_code 8 pls_mode 0 is_multistream 1
< 11635.376> [eDVBFrontend] isCompatibleWith system 1 is_id 1 pls_code 8 pls_mode 0 is_multistream 0
< 11635.376> [eDVBFrontend] isCompatibleWith NON MULTISTREAM TUNER!!!!!
< 11635.376> [TimerSanityCheck][TimerSanityCheck][getServiceType] DVB-S
< 11635.376> [eDVBFrontend] isCompatibleWith system 1 is_id -1 pls_code 1 pls_mode 0 is_multistream 1
< 11635.376> [eDVBFrontend] isCompatibleWith NON MULTISTREAM CHANNEL!!!!
< 11635.376> [eDVBResourceManager] allocateFrontend, score=15004
< 11635.376> [eDVBFrontend] isCompatibleWith system 1 is_id -1 pls_code 1 pls_mode 0 is_multistream 0
< 11635.376> [eDVBResourceManager] allocateFrontend, score=9983
< 11635.376> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x3e1cd, guard_offset 0
< 11635.376> **** Tuning JESS
< 11635.376> **** frequency_mhz: 10847
< 11635.376> **** lo_mhz: 9750
< 11635.376> **** T: 997
< 11635.376> **** position: 0
< 11635.377> **** ub: 31
< 11635.377> **** mode: 0
< 11635.377> **** JESS: 70 fb e5 00
70fbe500(?)
< 11635.377> [TimerSanityCheck] conflict detected!
< 11635.380> [Skin] processing screen MessageBox:
< 11635.387> [Skin] processing screen MessageBox_summary:
< 11635.641> [eInputDeviceInit] 0 160 1
< 11635.641> [InfoBarGenerics] KEY: 352 OK

 

If I override the timer conflict check both recordings work fine.



Re: Multistream tuner conflicts #2 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 20 August 2017 - 16:43

Also, when I start a recording of a multistream channel on 5W it's assigned to Tuner B (as this is the tuner allocated to 5W). While the recording is in progress, all other channels on 5W are greyed-out in the channel list except for those on the same stream as the one I'm recording. If I try to record one of those on the same stream at the same time, I get the conflict message. Meanwhile, I can view channels from other satellites, but I get the conflict message if I try to record from them.

 

So it would seem if a multistream channel is being recorded there will always be a timer conflict irrespective of whether the new timer is multistream or not.

 

Timers on a different DVB type do work. i.e. recording a multistream and a terrestrial channel works.



Re: Multistream tuner conflicts #3 Dimitrij

  • PLi® Core member
  • 10,323 posts

+350
Excellent

Posted 21 August 2017 - 09:35

It seems to me that it is not necessary at all.


		self.simultimer = [ConflictTimer]
		for event in self.nrep_eventlist:
			if len(event[4]) > 1: # entry in overlaplist of this event??
				for entry in event[4]:
					if entry[1] is ConflictTimer:
						break
-				else:
-					continue
				for entry in event[4]:

GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: Multistream tuner conflicts #4 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 21 August 2017 - 10:55

Ok. But that still leaves the problem that once a recording is started on a multistream service it is not possible to start any more recordings.



Re: Multistream tuner conflicts #5 Dimitrij

  • PLi® Core member
  • 10,323 posts

+350
Excellent

Posted 21 August 2017 - 12:26

I can not verify it.
 The parcel with the DVB-Sx tuner HD51 was lost between Holland and Latvia :( .


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K


Re: Multistream tuner conflicts #6 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 21 August 2017 - 13:19

I can verify any test you ask.

 

Look at this:

				for entry in event[4]:
					if entry[1] is ConflictTimer:
						break

That piece of code does nothing. All it does is break the inner loop, i.e. itself. Outer loop is still running. Doesn't set any variables. So what is the purpose of it?

 

And also if it is a non-multistream channel we don't even reach this piece of code. So there must be some coding error further before this point.

 

So now my file looks like this (debug added):

##################################################################################
# we have detected a conflict, now we must figure out the involved timers

        if self.newtimer is not ConflictTimer: # the new timer is not the conflicting timer?
            print "[TimerSanityCheck] test 16"
            for event in self.nrep_eventlist:
                print "[TimerSanityCheck] test 17"
                print "event 1", event
                if len(event[4]) > 1: # entry in overlaplist of this event??
                    print "[TimerSanityCheck] test 18"
                    kt = False
                    nt = False
                    for entry in event[4]:
                        print "[TimerSanityCheck] test 19"
                        if entry[1] is ConflictTimer:
                            print "[TimerSanityCheck] test 20"
                            kt = True
                        if entry[1] is self.newtimer:
                            print "[TimerSanityCheck] test 21"
                            nt = True
                    if nt and kt:
                        print "[TimerSanityCheck] test 22"
                        ConflictTimer = self.newtimer
                        ConflictTunerType = newTimerTunerType
                        break

        self.simultimer = [ConflictTimer]
        for event in self.nrep_eventlist:
            print "[TimerSanityCheck] test 23"
            print "event 2", event
            if len(event[4]) > 1: # entry in overlaplist of this event??
                print "[TimerSanityCheck] test 24"
                for entry in event[4]:
                    print "[TimerSanityCheck] test 25"
                    if entry[1] is ConflictTimer:
                        print "[TimerSanityCheck] test 26"
                        break
            
                for entry in event[4]:
                    print "[TimerSanityCheck] test 28"
                    if not entry[1] in self.simultimer:
                        print "[TimerSanityCheck] test 29"
                        for x in entry[2]:
                            print "[TimerSanityCheck] test 30"
                            if x in ConflictTunerType:
                                print "[TimerSanityCheck] test 31"
                                self.simultimer.append(entry[1])
                                break

        if len(self.simultimer) < 2:
            print "[TimerSanityCheck] test 32"
            print "self.simultimer", self.simultimer
            print "[TimerSanityCheck] possible bug: unknown conflict!"
            return True

        print "[TimerSanityCheck] test 33"
        print "[TimerSanityCheck] conflict detected!"
        return False

And my debug looks like this:

 

< 34501.022> [TimerSanityCheck] test 16
< 34501.022> [TimerSanityCheck] test 17
< 34501.023> event (1503313710, -1, 0, -1, [(-7, RecordTimerEntry(name=L'Aria Che Tira Estate, begin=Mon Aug 21 13:08:30 2017, serviceref=1:0:1:2C7:107:217C:DDE0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S'])])
< 34501.023> [TimerSanityCheck] test 17
< 34501.023> event (1503314419, -1, -1, -2, [(-7, RecordTimerEntry(name=L'Aria Che Tira Estate, begin=Mon Aug 21 13:08:30 2017, serviceref=1:0:1:2C7:107:217C:DDE0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S']), (0, RecordTimerEntry(name=†Bargain Hunt‡, begin=Mon Aug 21 13:20:19 2017, serviceref=1:0:19:1B1D:802:2:11A0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S'])])
< 34501.023> [TimerSanityCheck] test 18
< 34501.023> [TimerSanityCheck] test 19
< 34501.023> [TimerSanityCheck] test 20
< 34501.023> [TimerSanityCheck] test 19
< 34501.023> [TimerSanityCheck] test 21
< 34501.023> [TimerSanityCheck] test 22
< 34501.023> [TimerSanityCheck] test 23
< 34501.023> event (1503313710, -1, 0, -1, [(-7, RecordTimerEntry(name=L'Aria Che Tira Estate, begin=Mon Aug 21 13:08:30 2017, serviceref=1:0:1:2C7:107:217C:DDE0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S'])])
< 34501.023> [TimerSanityCheck] test 23
< 34501.023> event (1503314419, -1, -1, -2, [(-7, RecordTimerEntry(name=L'Aria Che Tira Estate, begin=Mon Aug 21 13:08:30 2017, serviceref=1:0:1:2C7:107:217C:DDE0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S']), (0, RecordTimerEntry(name=†Bargain Hunt‡, begin=Mon Aug 21 13:20:19 2017, serviceref=1:0:19:1B1D:802:2:11A0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S'])])
< 34501.023> [TimerSanityCheck] test 24
< 34501.023> [TimerSanityCheck] test 25
< 34501.023> [TimerSanityCheck] test 25
< 34501.023> [TimerSanityCheck] test 26
< 34501.023> [TimerSanityCheck] test 28
< 34501.024> [TimerSanityCheck] test 29
< 34501.024> [TimerSanityCheck] test 30
< 34501.024> [TimerSanityCheck] test 31
< 34501.024> [TimerSanityCheck] test 28
< 34501.024> [TimerSanityCheck] test 23
< 34501.024> event (1503315300, 1, 0, -1, [(0, RecordTimerEntry(name=†Bargain Hunt‡, begin=Mon Aug 21 13:20:19 2017, serviceref=1:0:19:1B1D:802:2:11A0000:0:0:0:, justplay=False, isAutoTimer=False), ['DVB-S'])])
< 34501.024> [TimerSanityCheck] test 23
< 34501.024> event (1503400819, 1, -1, 0, [])
< 34501.024> [TimerSanityCheck] test 33
< 34501.024> [TimerSanityCheck] conflict detected!



Re: Multistream tuner conflicts #7 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 14:41

Tested with based on PLi6rc image. Timer conflict.
With dreamos image no Timer conflict.

 



Re: Multistream tuner conflicts #8 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 14:53

Tested with openATV 6.1 image. Timer conflict.



Re: Multistream tuner conflicts #9 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 15:22

even when channel was not greyed out. You can watch channel but no recording.



Re: Multistream tuner conflicts #10 littlesat

  • PLi® Core member
  • 57,159 posts

+698
Excellent

Posted 21 August 2017 - 16:02

That piece of code does nothing. All it does is break the inner loop, i.e. itself. Outer loop is still running. Doesn't set any variables. So what is the purpose of it?

 

->

 

It is doing something.. it breaks with a specific value of entry. But it is never used that way later.... So indeed this loop make no sense...


Edited by littlesat, 21 August 2017 - 16:04.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Multistream tuner conflicts #11 littlesat

  • PLi® Core member
  • 57,159 posts

+698
Excellent

Posted 21 August 2017 - 16:03


dreamos 

It could be they solved it in cpp... and not in python where everyone looks now for a solution/work-a-round.... And if so they made it closed source...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Multistream tuner conflicts #12 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 16:07

I don't know, you can find opendreambox TimerSanityCheck.py here, to compare:
http://git.opendream...0d3bfb0055772b6



Re: Multistream tuner conflicts #13 littlesat

  • PLi® Core member
  • 57,159 posts

+698
Excellent

Posted 21 August 2017 - 16:17

It looks there like approx the same spaghetti code.... So I'm afraid it should be solved in cpp....

 

See from line 249...

 

http://git.opendream...0d3bfb0055772b6


Edited by littlesat, 21 August 2017 - 16:18.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Multistream tuner conflicts #14 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 21 August 2017 - 16:19

That piece of code does nothing. All it does is break the inner loop, i.e. itself. Outer loop is still running. Doesn't set any variables. So what is the purpose of it?

 

->

 

It is doing something.. it breaks with a specific value of entry. But it is never used that way later.... So indeed this loop make no sense...

Exactly. "event" is overwritten by the second loop. And even more confusing is what the else clause was supposed to be doing.

 

And I'm not sure why we even reached this code.



Re: Multistream tuner conflicts #15 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 21 August 2017 - 16:31

A short test  only for info without deep research of the problem on the zgemma h7s (2xDVB-S2/S2X + DVB-T tuners) develop image.
 
When I record a multistream channel (ZeonBud from Astra 4A 4,8E), then I can not record any other dvb-s channels because a timer conflict message appears. But I can record dvb-t channel.
I can see all channels at the same time. I do not have any inaccessible gray channels in the channel list.
 
The same thing when I record dvb-s channel. I can not record a multistream channel because a timer conflict message appears. But I can record another dvb-s channel.

Edited by Taapat, 21 August 2017 - 16:32.


Re: Multistream tuner conflicts #16 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 16:51

Did the same recording test on 4.8°E multistream channels + satellite channels

on dm900 with dmm oe2.5 image. Recordings all OK



Re: Multistream tuner conflicts #17 littlesat

  • PLi® Core member
  • 57,159 posts

+698
Excellent

Posted 21 August 2017 - 17:17

Telling dmm's oe does work does not help here... I'm afraid this is not solveble in python code... it needs to have a patch required in cpp.... DMMs stuff there is closed source and that is why mentioning it does not help at all...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Multistream tuner conflicts #18 display name

  • Senior Member
  • 627 posts

+26
Good

Posted 21 August 2017 - 17:30

Sorry, it was just for info. If i didn't test it, you couldn't know it works on other image.



Re: Multistream tuner conflicts #19 Huevos

  • PLi® Contributor
  • 4,654 posts

+162
Excellent

Posted 21 August 2017 - 19:27

. I'm afraid this is not solveble in python code... it needs to have a patch required in cpp....

Why does it need a patch in CPP? If you skip the Python check the recording works fine.

 

And, IMO, even if the code in CPP does need a patch, the code in TimerSanityCheck.py needs a lot of sorting out. Currently it is unreadable... at least for me.



Re: Multistream tuner conflicts #20 Dimitrij

  • PLi® Core member
  • 10,323 posts

+350
Excellent

Posted 21 August 2017 - 19:55

Huevos

Please make a test.


GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K



2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users