Unicable and dropped recordings

[Arcy]

I'm still struggling with my GigaBlue UHD Quad 4K and Opticum Red Robust Unicable 2 LNB, despite the recent changes to OpenVIX and Huevos's advice on adjusting the Satellite Equipment Control plug-in.

If I launch a series of recordings from different transponders on 28.2E, I can successfully occupy all eight FBC virtual tuners simultaneously. This appears to confirm that my basic configuration is connect. (I notice, though, that one of the GigaBlue websites sternly advises daisy-chaining the tuners A to B, B to C, C to D, D to E etc., rather than connecting them all to Tuner A, which is the only possibility now offered by OpenVIX. But it may be that what happens behind the scenes amounts to the same thing.)

However, sometimes a channel selected may take six or seven seconds to appear, or even longer. I haven't been able to work out what circumstances lead to this extended delay. The 'Tuner failed' message appears almost at the end of the delay, just before the picture shows. I've tried increasing the relevant Satellite Equipment Control parameter as suggested by Huevos, but this does not eliminate the message -- it only extends the wait before it appears.

This I can live with. But a more serious problem has occurred on several occasions, when a timed recording on one transponder starts while a recording from a different transponder is already in progress: the recording in progress is immediately halted and abandoned. If I then try to switch to that transponder to restart the recording manually, I get a black screen, and the receiver seems to be more or less locked up, apart from the other transponder being recorded from. I can get it out of this state by forcing a GUI restart via the Web or app interface. Only the FBC tuners have been affected by this; recordings from ordinary LNBs connected to Tuners I and J always work as expected.

It's tempting to wonder whether this is another timing problem, causing the receiver to become confused. Looking at the logs, I notice that the system repeats one particular line many times when making a recording -- the one containing "UnicableTuningWord 0x809c." Like this:

<251680.579> [Timer] Record RecordTimerEntry(name=The Long View, begin=Tue Jan 21 09:01:00 2020, serviceref=1:0:2:288D:7FE:2:11A0000:0:0:0:, justplay=0, isAutoTimer=0)
<251680.582> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.582> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x88d7, guard_offset 0
70249502(?)
<251680.582> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.582> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.583> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.583> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.583> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.583> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x80ab, guard_offset 0
7023e500(?)
<251680.584> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.584> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.584> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.584> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.585> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.585> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x80ab, guard_offset 0
7023e500(?)
<251680.585> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.597> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.598> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.598> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.598> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.599> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.599> [eDVBSatelliteEquipmentControl] [prepare] UnicableTuningWord 0x809c, guard_offset 0
7023aa00(?)
<251680.599> [TimerSanityCheck] conflict not found!


This looks as though something is not responding as it should. Might some other parameter in Satellite Equipment Control have a bearing on it?

 

[abu baniaz]

A bug has crept in. Not sure if it is satellite equipment control, enigma2 or GB driver change.

 

[twol]

There has been a FBC bug around for a while where the recording starts but shows 0 recording time (which never changes) and in fact you have a null recording - originally it was thought that it happens when 2 FBC recordings start at the same time.
I can go for days without seeing the issue ... but then it just happens.

 

[Arcy]

I think I've seen that one, too, twol. But I never noticed recording failures with my Vu+ Solo 4K and Spaun Unicable matrix. On the other hand, that wasn't Unicable 2. Less to go wrong, perhaps.

 

[twol]

I think I've seen that one, too, twol. But I never noticed recording failures with my Vu+ Solo 4K and Spaun Unicable matrix. On the other hand, that wasn't Unicable 2. Less to go wrong, perhaps.

The 0 recording time bug was seen across both Vu+ and Gigablue with FBC.

 

[abu baniaz]

The 0 recording time bug was seen across both Vu+ and Gigablue with FBC.

They are the only two manufacturers with FBC, so technically could apply to all future FBC manufacturers. I personally have not experienced this, can you please start a bug thread for it.

I am only using one demodulator and still getting the tune failed message, so the daisy chaining isn't applicable for me.

 

[twol]

They are the only two manufacturers with FBC, so technically could apply to all future FBC manufacturers. I personally have not experienced this, can you please start a bug thread for it.

I am only using one demodulator and still getting the tune failed message, so the daisy chaining isn't applicable for me.

@Abu - raising this again is not an issue, but it was beaten to death between Littlesat and Huevos some time ago on OpenPli and the best solution (?) that they came up with was code to prevent 2 recordings starting at the same time (delay the 2nd) - but it was never (to my knowledge) added.

 

[abu baniaz]

That was not specific to unicable IIRC, I may be wrong. If it is still happening, best we get it resolved if possible. As with any bug, it is easier to fix when reproduceable. That is not always the case with some equipment

 

[Arcy]

Delaying the second recording won't help if, as has happened here more than once, starting a second recording halts the first. I haven't seen that happen with the ordinary tuners, but only with the FBC tuners and Unicable 2.

 

[twol]

Can you post your tuner setup as post #1 (which I have now read again confuses me as to how you are daisy chaining)
I have no issues (usually apart from the 0 issue) either using Unicable switches (Giga UE 4K) or Unicable switch plus Unicable LNB (Giga UHD 4K) where my Unicable LNB is an Opticum Robust LNB ... and I constantly use that LNB for recordings for 27.5W (UK FTA)
Originally ( because of Vu issues) you had A -> B , B-> C etc thats not how you now do it (apart from perhaps OpenATV who use a different setup) .
I do not need a Satellite equipment plugin.

The only delay I ever see on the Unicable Opticum LNB is on a reboot due to the softcam (Oscam) being initialised - after that its instant

... and my 27.5W signal is without doubt weaker than anything on 28.2E

 

[Huevos]

@Abu - raising this again is not an issue, but it was beaten to death between Littlesat and Huevos some time ago on OpenPli and the best solution (?) that they came up with was code to prevent 2 recordings starting at the same time (delay the 2nd) - but it was never (to my knowledge) added.

The bug was unique to FBC, the fix was universal. Not seen a record failure on the Ultimo 4K in a long time.

 

[Huevos]

What SCRs have you allocated to what tuners?

 

[Arcy]

Oh dear... embarrassment... the LNB I've been using is not what I said above but is a Maclean MCTV-785, with no DiSEqC. But my tuner setup is, I think, the recommended one:
Tuner A: connected to Unicable LNB (on 28.2°E) via Input A; User Band 5 (985 MHz)
Tuner B: connected to Tuner A; User Band 6 (1050 MHz) -- nothing connected to Input B
Tuner C: connected to Tuner A; User Band 7 (1115 MHz)
Tuner D: connected to Tuner A; User Band 8 (1275 MHz)
Tuner E: connected to Tuner A: User Band 9 (1340 MHz)
Tuner F: connected to Tuner A: User Band 10 (1485 MHz)
Tuner G: connected to Tuner A: User Band 11 (1550 MHz)
Tuner H: connected to Tuner A: User Band 12 (1615 MHz)

Tuner I (on input C): connected to 10 LNBs via DiSEqC 1.1/1.0 switches
Tuner J (on input D): equal to Tuner I

User Bands 1 to 8 of the Maclean LNB support both EN 50494 and EN 50607; User Bands 9 to 16 support EN 50607 only. I'm feeding User Bands 1 to 4 to a separate Inverto Sat>IP receiver, using a splitter; I've had no reception problems with that receiver, and disconnecting it doesn't resolve the problems with the GigaBlue. I've also tried using bands 9 to 16 on the GigaBlue receiver, to make it fully Unicable II, but I had problems that way too. Another permutation would be to set the Inverto receiver to Unicable II and run the GigaBlue wholly in Unicable 1 mode, but I haven't tried that yet.

I have no Oscams or indeed any cams.

 

[twol]

I am sure others will jump in if I am talking rubbish but try putting a splitter on the Maclean MCTV-785, and connecting one side to physical tuner A input and the other to physical Tuner B Input and then setup both A and B as 28.2E inputs with C,D,E connected to A and F,G,H connected to B

 

[Arcy]

I am sure others will jump in if I am talking rubbish but try putting a splitter on the Maclean MCTV-785, and connecting one side to physical tuner A input and the other to physical Tuner B Input and then setup both A and B as 28.2E inputs with C,D,E connected to A and F,G,H connected to B

Hmm... I thought you were about to suggest connecting Tuner A to tuners C, E and G, and Tuner B to tuners D, F and H -- on the basis that successive tuning selections or recordings claim the next available virtual tuner, and that choosing them alternately them might relieve any timing-related problems. So I'd like to try this too -- and I'd also like to try the Maclean LNB in Unicable 1 mode (available on the bottom eight user bands). But to do so I'll need to edit the Unicable settings for this LNB -- and unfortunately I can't now find the file formerly known as unicable.xml . I imagine that its contents have been merged into something else in the latest OpenVIX releases. But I looked at /etc/enigma/settings , which seemed the most likely place, and there's no sign of them there.

Incidentally, in upgrading to the latest OpenVIX today, I noticed that the tuner setting "SCR (Unicable/JESS) type" does not restore itself correctly from a VIX settings backup. It defaults to Switch rather than to LNB, and consequently picks up the first switch in its list, which is an Ankaro. So if you don't happen to have an Ankaro switch, it's necessary to change this setting manually on each FBC tuner.

 

[twol]

Hmm... I thought you were about to suggest connecting Tuner A to tuners C, E and G, and Tuner B to tuners D, F and H -- on the basis that successive tuning selections or recordings claim the next available virtual tuner, and that choosing them alternately them might relieve any timing-related problems. So I'd like to try this too -- and I'd also like to try the Maclean LNB in Unicable 1 mode (available on the bottom eight user bands). But to do so I'll need to edit the Unicable settings for this LNB -- and unfortunately I can't now find the file formerly known as unicable.xml . I imagine that its contents have been merged into something else in the latest OpenVIX releases. But I looked at /etc/enigma/settings , which seemed the most likely place, and there's no sign of them there.

Incidentally, in upgrading to the latest OpenVIX today, I noticed that the tuner setting "SCR (Unicable/JESS) type" does not restore itself correctly from a VIX settings backup. It defaults to Switch rather than to LNB, and consequently picks up the first switch in its list, which is an Ankaro. So if you don't happen to have an Ankaro switch, it's necessary to change this setting manually on each FBC tuner.

/usr/share/enigma2 -------> unicable.xml

 

[Arcy]

So far, I've got Tuners A, B, C and D operating in Unicable 1 mode, on User Bands 5 to 8, in the expectation that Unicable 1 is less complex and probably less troublesome. I did this by adding a second instance of my LNB to the unicable.xml file, with the JESS statement and the top eight SCRs deleted. (User Bands 1 to 4 are still being used by my SAT>IP box.)

Like this, I can start recordings on all eight User Bands (see attached screen-grab, which also includes a recording running on Tuner I, an ordinary LNB). Oddly, the tuners haven't kept to strict alphabetical order. I haven't seen this happen before, and I wonder whether the system jumped tuners because it thought they were busy, but returned to them later.

However, switching from a channel on Tuner I to a channel on the FBC takes eight or nine seconds. The "Tuner failed" message appears briefly a second or two before this interval ends. Switching the other way again takes just two or three seconds. On the SAT>IP receiver, selecting a channel takes a couple of seconds.

It looks as if the FBC tuners are getting bogged down in some negotiation which really ought not to take that long.

 

[Huevos]

No idea why there is a delay. Never seen that on my FBC setup. Are you using the SEC plugin?

 

[Arcy]

No idea why there is a delay. Never seen that on my FBC setup. Are you using the SEC plugin?

Yes, I am. The only SEC setting I've altered is "Delay after enable voltage before switch command", which I've increased to 0800, as recommended. I've tried increasing it further, but it only delays the appearance of the "Tuner failed" message (the selected channel normally appears a second or two after that). That's why I wondered whether signalling and timings might also be behind the problem I've had when the start of a timer recording sometimes kills another timer recording that's already in progress.

 

[Huevos]

Increase that delay to 2500. This is for test purposes.