Mixed SCR / Universal Tuner management issue

[AlexWilMac]

After a lot of attempts with the new 4.2 and after having also restored a previous backup of 4.1.035, I’m now completely sure that 4.2 has a problem in managing a tuner configuration like mine.
Here is my system (I admit is a bit unusual, but it has always worked under OBH from its 0.6 till 4.1 and under many BHs):

I’ve got 3 LNBs: one is a SCR/Unicable one for 13E
2 are twin LNBs for 19E and 28,2E, so two cables, for each of my tuners.

I’ve got 2 DiseqC switches.
The first for
a) 13E by the SCR (Port A)
b) 19,2E (Port B)
c) 28,2E (Port C)

The 2nd switch for
a) 13E from a universal LNB (Port A)
b) 19,2E (Port B)
c) 28,2E (Port C)

(that means the two cables from 19,2E and 28,2E are normally connected by the two switches to their 2nd and 3rd input).

That said, I imagine the objection: you can’t manage a SCR/Unicable by a normal DiseqC switch. But this, I can assure you, is not true if you connect ONLY ONE SCR LNB to a normal switch.
As a matter of fact, I also tried to manage 2 SCRs by the same switch (on inputs 1 and 2, for instance) and there I had problems. But the mixed situation described above, with only one SCR and two Universal, has always worked in every images I’ve tried but OBH 4.2.

Now, instead, under OBH 4.2, if the Tuner A is engaged with a recording from port B or C, the virtual Tuner C has a lot of problems if I need to watch 13E from port A: it works for a couple of seconds, then the signal goes down to 0, then comes back and I can watch 13E for another couple of seconds, and so on.

I see that in 4.2 advanced tuner configuration there are some new options, for instance about voltage. But I wouldn’t go by attempts because I fear I can damage the LNBs.
So, if coders or HW experts know something relevant about the new implementations of 4.2 they might help.

 

[AlexWilMac]

Update: just to be sure, I reloaded the last backup of 4.1.035 perfectly working. I copied every tuner settings and the Miscellaneous section.
Then I reflashed with my current 4.2.002 and changed the few different configuration according to the ones taken from 4.1. Nothing changed: whenever I record from 19E or 28E, I can't tune 13E.

 

[el bandido]

It may be possible to find what was done by looking for log changes in the OE Alliance image structure. I would guess maybe the NimManager file and/or the UsageConfig file located at: /usr/lib/enigma2/python/Components has been changed or updated? You could test this idea by swapping these two files using ftp from the image that works to the image that does not. Then reboot the box and see if the problem is gone.

 

[AlexWilMac]

I'll surely try as soon as possible Obviously, as a temporary solution.
Sure that, if any images had the option to also choose what tuner to use, as I suggested a lot of time ago, it'd be great in many occasions.

 

[el bandido]

If you have time, See if the latest OpenATV image has the same problem. Updates from OpenATV usually end up in OBH because they are OE Alliance. So if you get something fixed or added in the ATV image, then it is usually fixed or added in OBH.

 

[AlexWilMac]

I hadn't the time for further experiments but... last update 4.2.006 seems having solved.

 

[AlexWilMac]

It seems I solved: for some strange reasons, 4.2 does not like the Priority of LNBs (that I had set in 4.1) and it works only with AUTO.

 

[AlexWilMac]

I want to update this old thread because, although I was sure I had reported that the problem of a mixed SCR/Universal configuration came back after 4.2.022 (or near), I hadn't.
I had also hoped that the new 4.3 could solve it, but it hasn't.

So, here I am: since that version, it occurred again this issue, never present in 4.1 or before and not even in the earlier 4.2 releases (up to 021 or so).

To update the last part of the post#1, with the configuration reported there the issue is this:
-if the Tuner A STARTS a recording from LNB2 or 3 (port B or C, connected to a Universal LNB, as from post#1) while I'm using the same tuner but on LNB1, the recording simply does not work (it produces a file of length zero);
-if the recording starts on LNB2 or 3 while I'm watching it, it works (obviously) but as soon as I zap to a channel using LNB1 (the SCR), I now can watch from LNB1 but the recording SEEMS to go on (because the symbol REC is active and the file is in red in the rec list) whilst, actually, it is playable only till the moment I had zapped.

I've tried everything in the LNB priority, in the DiSEqC protocol, in its options.... nothing works as it did before.

Another bug I've reported several times, it's the BIG PiP issue for Solo4K (it does not affect other models).
Some admins said it is a driver problem by Vuplus, but I'm a bit puzzled, because BH, which is based on vuplus code, does not have the Big PiP feature.

So, update after update and, now, after an upgrade, too, my hopes to see this issues solved are let down

 

[Ev0]

I want to update this old thread because, although I was sure I had reported that the problem of a mixed SCR/Universal configuration came back after 4.2.022 (or near), I hadn't.
I had also hoped that the new 4.3 could solve it, but it hasn't.

So, here I am: since that version, it occurred again this issue, never present in 4.1 or before and not even in the earlier 4.2 releases (up to 021 or so).

To update the last part of the post#1, with the configuration reported there the issue is this:
-if the Tuner A STARTS a recording from LNB2 or 3 (port B or C, connected to a Universal LNB, as from post#1) while I'm using the same tuner but on LNB1, the recording simply does not work (it produces a file of length zero);
-if the recording starts on LNB2 or 3 while I'm watching it, it works (obviously) but as soon as I zap to a channel using LNB1 (the SCR), I now can watch from LNB1 but the recording SEEMS to go on (because the symbol REC is active and the file is in red in the rec list) whilst, actually, it is playable only till the moment I had zapped.

I've tried everything in the LNB priority, in the DiSEqC protocol, in its options.... nothing works as it did before.

Have you tested your setup in other OE-A images to see if it works in them ?

If not can you try ViX 5.3 please to see if you have the same problem with that image.

Another bug I've reported several times, it's the BIG PiP issue for Solo4K (it does not affect other models).
Some admins said it is a driver problem by Vuplus, but I'm a bit puzzled, because BH, which is based on vuplus code, does not have the Big PiP feature.

So, update after update and, now, after an upgrade, too, my hopes to see this issues solved are let down

What is there to understand ?

BH is not OBH. Big PiP doesn't work on Solo4K so there is no Big PiP feature in BH.

OBH has the code applied as that is how it's setup in OE-A.

 

[AlexWilMac]

I wanted to try several other images but, before installing 4.3, my OMB didn't work any longer. Now, after having flashed OBH 4.3, I'm again able to use it and it's my intention, in the few spare time I lately have, to finally try other images. I'll let you know.

 

[AlexWilMac]

So I finally had, thanks to my omb working again, the chance of trying two other images, about both behaviours: OpenVix and OpenAtv.
Well... the work even worse than OBH. At least, in OBH, if a recording starts from ports B o C (the Universal LNBs), it simply doesn't record if you are watching from the SCR on port A or, it stops working, if you were watching a channel from the same LNB and the you zap.
But you are able to watch the channel.
By those two images it's... a mess, particularly by OpenAtv.

By the way: even if they worked, it was the hundredth occasion to understand why I can't be a user of those images! Particularly, OpenAtv: in a few minutes it showed a lot of absurd behaviours. And they are SO ugly, too.

 

[Ev0]

Ok, so it's an OE-A issue and not an OBH issue then.

 

[AlexWilMac]

Il'try, just for curiosity, also OpenPli and, obviously, as it is already installed in OMB, BH 309, although I'm sure BH works.

 

[AlexWilMac]

Well, it seems I found a satisfactory solution, as a workaround, though, because the AUTOmatic options don't work.
So, the trick was to set the priority for the six LNB, 4 gained from the SCR's user bands (in my case for 13E, but it doesn't matter) and the other two Universal LNBs (in my case on 19,2E and 28,2E).
My theory is that is not important the priority value set for each (I'll do more tries when possible) but just not to leave them as AUTO. Summarising, this is how I configured this mixed configuration SCR/Universal and DiseqC commands:

TUNER A
LNB1
13E
SCR (Band1)
Priority=1 (lower than any auto)
DiseqC 1.0
Port A
(accordingly to my DiseqC switch)

LNB2
19,2E
Universal
Priority=2 (lower than any auto)
DiseqC 1.0
Port B

LNB3
28,2E
Universal
Priority=3 (lower than any auto)
DiseqC 1.0
Port C

TUNER C - FBC
(because Tuner B is used by other cables, it doesn't matter in this discussion)
13E
SCR (Band2)
Priority=4 (lower than any auto)
DiseqC 1.0
Port A

TUNER D - FBC
13E
SCR (Band3)
Priority=5 (lower than any auto)
DiseqC 1.0
Port A

TUNER E - FBC
13E
SCR (Band4)
Priority=6 (lower than any auto)
DiseqC 1.0
Port A

Actually, I need more tries, but I managed many recordings at the same time without the many issues I had before (simply, after a recording started on a satellite from tuner A, the other didn't work or stopped).
I did up to 9 recordings from different transponders.

Hope this can help other users.

 

[AlexWilMac]

Reading today the "Release notes" of 4.3.019 and its bug fix about SCR LNBs and Universal ones, I had hoped the issue about recording from one of them and watching from the other type of LNB by a normal DiSEqC switch would have finally been solved.
But it's not so.

 

[AlexWilMac]

I finally had the time to try also by BH in flash and it happens the same thing by 3.0.9. So it's a general problem or due to my Switch... but it's a good Spaun.

 

[AlexWilMac]

I wanted to update this post because there have been other users with the same "mixed" system and I found a way to trick the system.

In brief, summarizing the situation, the scenario is made of:
1) ONE Unicable/SCR LNB
2) some Universal LNBs
3) A normal DiSeqC switch.

Then there is a variant as in my case, because maybe you want to take advantage of having a double output Universal LNBs with two tuners, in order to watch/record/PiP/Stream from different transponders also for those satellites received by a Universal LNB.

As I wrote before, here and in another thread, answering a user, the real problem, with a mixed configuration and a normal DiSeqC switch, is not the zapping, that is managing all the different LNBs of different types.
The problems is, in case, the simultaneous watching/recording etc...

I solved not using the default AUTO option in the priority field of tuner configuration. So here is my configuration.
Remember that tuners' names may differ from a VU+ to another. In my case, I have two SAT tuners, which are A and B.
The FBC virtual ones are C, D, E (and that's all in my case, as my SCR is only a 4-channel one). For those who have a 8, 16 or 32, a slight adjustment will be needed, but I suppose that following the logic I used, may help with these systems.

===============================

That said, my system has got, in particular:

1) ONE Unicable/SCR LNB for 13E
2) 3 Universal LNBs, 13E, 19,2E and 28,2E
3) A normal DiSeqC switch.

Tuner B is the one that uses only Unoversal LNBs, so it is simply configured as
Configuration mode: simple
Mode: DiSeqC A/B/C/D (or less, in case you have less LNBs. If you have more than 4, you'll need an ADVANCED configuration, of course)


TUNER A
(is the one where are connected either the Unicable-SCR and 2 of the 3 Universal LNBs)
Satellite: (13E, in my case)
Configuration mode: ADVANCED
LNB: LNB 1
Priority: 1
Type of LNB: Unicable/SCR

(then you must, of course, choose your manufacturer and model, or discover the SCR channels of your LNB.)

Connected to: NONE
DiSeqC mode: 1.0
DiSeqC 1.0 command: Port: A (or AA, for non-open images), that's input 1 in the switch
Force legacy signal: YES (but this is a parameter I think it's not influent)

----------------------------
TUNER A
(for the 2nd LNB)
Satellite: 19,2E (in my case)
LNB: LNB 2
Priority: 33
Type of LNB: Universal
DiSeqC mode: 1.0
DiSeqC 1.0 command: Port: B (or AB, for non-open images), that's input 2 in the switch

the remaining options like in previous case.


----------------------------

TUNER A
(for the 3rd LNB)
Satellite: 28,2E (in my case)
LNB: LNB 3
Priority: 34
Type of LNB: Universal
DiSeqC mode: 1.0
DiSeqC 1.0 command: Port: C (or BA, for non-open images), that's input 3 in the switch

the remaining options like in previous case.

=============

TUNER C (FBC)
(now, the FBC virtual tuners to be connected to Tuner A by the SCR configuration)

Satellite: (13E, in my case)
Configuration mode: ADVANCED
LNB: LNB1
Priority: 2
Type of LNB: Unicable/SCR and the related options like in Tuner A - LNB 1

Connected to: Tuner A
DiSeqC mode: 1.0
DiSeqC 1.0 command: Port: A (or AA, for non-open images), that's input 1 in the switch

----------------------------

TUNER D (FBC)

Everything like for tuner C, except

Priority: 3

and the same idea for the remaining FBC tuners, with priority set to 4, 5, 6.... as the Universal LNB are set from 33 onwards (because the 1-32 values are for the SCR LNBs)

I'm also sure you can assign to ALL SCRs LNBs the same priority. But, just to be sure...