Jump to content


Photo

Possible race condition when tuning alternative services?

vu+duo2 openpli4

  • Please log in to reply
17 replies to this topic

#1 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 19 December 2013 - 18:07

Vu+duo2 running openpli4 (with latest updates).

 

I have several alternative services defined. All alternative services follows the pattern:

1. DVB-T service

2. DVB-S(2) service

 

Alternative services tuner priority is: DVB-T/DVB-S/DVB-C, so tuning to alternative services should result DVB-T tuner activation (assuming no simultaneous recordings, streaming, transcoding or whatever).

 

And it works like this when I switch to alternatives from regular DVB-S(2) service. The problem is when I switch from one alternatives services to another alternatives services and DVB-T service in "from" alternatives is on another multiplex than DVB-T service in "to" alternatives.

 

Let's have two DVB-T multiplexes, M1 and M2; I have in my bouquet:

Channel 1. Alternatives (DVB-T on M1 + DVB-S2)

Channel 2. Alternatives (DVB-T on M2 + DVB-S2)

Channel 3. Alternatives (DVB-T on M2)

Channel 4. DVB-S2

 

When I switch from 4 to any of 1, 2, 3 than DVB-T is activated - OK.

When I switch from 3 (DVB-T M2) to 2 (DVB-T M2) or vice-versa then DVB-T is still activate too - OK.

When I switch from 1 (DVB-T M1) to 2 or 3 (DVB-T M2); or switching from 2 or 3 (DVB-T M2) to 1 (DVB-T M1) then DVB-S2 is activated instead of DVB-T.

 

It looks like the tuner selection is does not take into account that DVB-T tuner will be freed, or tuner selection is made too early, before the tuner DVB-T finishes broadcasting the old service.

 

There was no such problem on my old DM8000 with openpli3.

 

Attached is the a log with Channel 3 -> Channel 2 -> Channel 1 switching.

 

Please solve this problem as DVB-T broadcast is of higher quality than corresponding DVB-S2 services (DD+ original soundtrack on DVB-T while DD soundtrack with a person reading a translation in DVB-S2).

 

Thanks in advance, Regards.

Attached Files



Re: Possible race condition when tuning alternative services? #2 HaZzard

  • Member
  • 2 posts

0
Neutral

Posted 27 December 2013 - 23:51

Hi,

 

I have exactly the same Problem, but my Setup is:

 

Tuner A: DVB-S

Tuner B: DVB-T (USB)

 

Tuner Priority: DVB-S/T/C

 

Channel configuration is always:

 

1: DVB-S

2: DVB-T (Alternative)

 

if I change from one channel to another channel it changes from Tuner A to B to A to B....

 

 

Regards Marc



Re: Possible race condition when tuning alternative services? #3 Dimitrij

  • PLi® Core member
  • 7,767 posts

+252
Excellent

Posted 28 December 2013 - 09:56

I can confirm the bug.
One important question to address.
It just was not there before?


Duo 4K/Lunix3-4K/Solo 4K


Re: Possible race condition when tuning alternative services? #4 littlesat

  • PLi® Core member
  • 53,184 posts

+614
Excellent

Posted 28 December 2013 - 10:14

The whole alternatives implementation in enigma2 is a bug....
As far I know nothing changes recently regards alternatives....

Edited by littlesat, 28 December 2013 - 10:16.

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


Re: Possible race condition when tuning alternative services? #5 Dimitrij

  • PLi® Core member
  • 7,767 posts

+252
Excellent

Posted 28 December 2013 - 11:08

The whole alternatives implementation in enigma2 is a bug....
As far I know nothing changes recently regards alternatives....

The error occurs when you select the free service in getBestPlayableServiceReference.

1)first zap to alternatives services - OK.

2)second or third zap to alternatives services - Error.


Duo 4K/Lunix3-4K/Solo 4K


Re: Possible race condition when tuning alternative services? #6 Dimitrij

  • PLi® Core member
  • 7,767 posts

+252
Excellent

Posted 28 December 2013 - 11:19

Switch alternatives services.

Spinning the spinner and the same log:

stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0
stateLostLock
(2)fe event: status 76a4b3c0, inversion off, m_tuning 0


Duo 4K/Lunix3-4K/Solo 4K


Re: Possible race condition when tuning alternative services? #7 Dimitrij

  • PLi® Core member
  • 7,767 posts

+252
Excellent

Posted 28 December 2013 - 12:12

Done :D

Navigation.py-->  def playService

		if not checkParentalControl or parentalControl.isServicePlayable(ref, boundFunction(self.playService, checkParentalControl=False, forceRestart=forceRestart)):
			if ref.flags & eServiceReference.isGroup:
+				oldref = self.currentlyPlayingServiceReference
				if not oldref:
					oldref = eServiceReference()

Duo 4K/Lunix3-4K/Solo 4K


Re: Possible race condition when tuning alternative services? #8 littlesat

  • PLi® Core member
  • 53,184 posts

+614
Excellent

Posted 28 December 2013 - 12:19

Just need to add then single line?

Can you also check
oldref = self.currentlyPlayingServiceReference or eServiceReference()
For me?

Edited by littlesat, 28 December 2013 - 12:22.

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


Re: Possible race condition when tuning alternative services? #9 HaZzard

  • Member
  • 2 posts

0
Neutral

Posted 28 December 2013 - 13:10

Hey,

 

how can i get this modification?

Will it be in the next Update?

 

Regards Marc



Re: Possible race condition when tuning alternative services? #10 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 28 December 2013 - 13:36

littlesat, on 28 Dec 2013 - 12:18, said:

Just need to add then single line?

Can you also check
oldref = self.currentlyPlayingServiceReference or eServiceReference()
For me?

 

Putting your line like this:

if ref.flags & eServiceReference.isGroup:
+    oldref = self.currentlyPlayingServiceReference or eServiceReference()
-    if not oldref:
-        oldref = eServiceReference()
    playref = getBestPlayableServiceReference(ref, oldref)
works as well. If you were thinking about replacing oldref = eServiceReference() with your line than the answer is no, it didn't worked.

 

But I think getBestPlayableServiceReference is a place to correct, it should handle alternatives correctly too.



Re: Possible race condition when tuning alternative services? #11 littlesat

  • PLi® Core member
  • 53,184 posts

+614
Excellent

Posted 28 December 2013 - 13:45

Sorry... I'm confused...

 

you tell works as well... and then later it didn't work...

 

What is it???


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


Re: Possible race condition when tuning alternative services? #12 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 28 December 2013 - 14:05

Sorry for being unclear.

 

The lines as in code section works (in my previous post).

 

What I was telling is that this code does not work:

 

if ref.flags & eServiceReference.isGroup:
    if not oldref:
-        oldref = eServiceReference()
+        oldref = self.currentlyPlayingServiceReference or eServiceReference()

 

Changes in both my posts refer to original Navigation.py code, not patched by Dima73 in post #7 above.


Edited by macnuts, 28 December 2013 - 14:05.


Re: Possible race condition when tuning alternative services? #13 littlesat

  • PLi® Core member
  • 53,184 posts

+614
Excellent

Posted 28 December 2013 - 14:07

But the results should be the same.... what is not working?


Edited by littlesat, 28 December 2013 - 14:09.

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


Re: Possible race condition when tuning alternative services? #14 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 28 December 2013 - 14:14

The problem is that 'ignore' parameter to getBestPlayableServiceReference is not converted to actual service being played for group-like service (alternatives as example). 

It is passed to eStaticServiceDVBBouquetInformation::isPlayable and that function uses getChannelID on 'ignore' parameter directly and not on a service that is being played actually.

That is why in this solution it alternative group must be converted from group to service ref.



Re: Possible race condition when tuning alternative services? #15 Dimitrij

  • PLi® Core member
  • 7,767 posts

+252
Excellent

Posted 28 December 2013 - 14:16

But the results should be the same.... what is not working?

if ref.flags & eServiceReference.isGroup:
+    oldref = self.currentlyPlayingServiceReference or eServiceReference()
-    if not oldref:
-        oldref = eServiceReference()
    playref = getBestPlayableServiceReference(ref, oldref)

work


Duo 4K/Lunix3-4K/Solo 4K


Re: Possible race condition when tuning alternative services? #16 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 28 December 2013 - 14:19

littlesat, on 28 Dec 2013 - 14:06, said:

But the results should be the same.... what is not working?

 

Only unconditional oldref assignment works. oldref is not NULL at this point (as you showed above) but in case of alternatives it does not point to channel being played but to the group itself.

 

I am sorry for all this commotion, in my original reply I was not sure what was interesting for you:

1. just a cosmetic code change of Dima73 patch (like the code that is working)

or

2. check what happens when we modify oldref assignment clause inside of the 'if' statement scope.

 

I was trying to answer both and that is why all that confusion came from.


Edited by macnuts, 28 December 2013 - 14:24.


Re: Possible race condition when tuning alternative services? #17 littlesat

  • PLi® Core member
  • 53,184 posts

+614
Excellent

Posted 28 December 2013 - 14:21

Thanks Dima.... committed....

 

This craziness was in there for years!!!!! ;)


Edited by littlesat, 28 December 2013 - 14:21.

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


Re: Possible race condition when tuning alternative services? #18 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 28 December 2013 - 14:37

Thank you both for fixing it.







Also tagged with one or more of these keywords: vu+duo2, openpli4

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users