View Full Version : Unicable and dropped recordings
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
16-01-20, 15:00
A bug has crept in. Not sure if it is satellite equipment control, enigma2 or GB driver change.
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.
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.
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
17-01-20, 16:13
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.
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
17-01-20, 18:13
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
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.
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
@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.
What SCRs have you allocated to what tuners?
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.
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
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.
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
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.
No idea why there is a delay. Never seen that on my FBC setup. Are you using the SEC plugin?
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.
Increase that delay to 2500. This is for test purposes.
Increase that delay to 2500. This is for test purposes.
Here I am using the Vu+ Ultimo 4K for testing and don't see any of your problems regarding tuning failed messages... but the Ultimo keeps the LNB permanently powered.
abu baniaz
24-01-20, 11:13
As per bug report and other thread, even 9900 does not solve problem
Increase that delay to 2500. This is for test purposes.
Here I am using the Vu+ Ultimo 4K for testing and don't see any of your problems regarding tuning failed messages... but the Ultimo keeps the LNB permanently powered.
The GigaBlue doesn't, and neither does my Inverto SAT>IP, which is fed via a splitter from the same LNB (it uses different SCRs).
Increasing that setting doesn't seem to make much difference, except possibly to make channel changes slightly slower. Switching between channels or even transponders on the same satellite normally happens almost instantly. But switching from a radio station on 28.2E to a radio station on another satellite takes 2-3 seconds. Switching from another satellite back to 28.2 takes about 7 seconds for radio, a little more for TV, and in either case I always see the 'Tune failed' message before the 28.2E channel appears. The only case I've found where switching to a different satellite produces 'Tune failed' occurs when switching to BFBS radio on 19.2E. This is odd. There may be other examples, of course.
So I'm wondering whether this receiver is just a bit buggy. I made several unsuccessful attempts this morning to reproduce the problem where a timer recording just starting kills a recording already in progress. But when I tried switching between BBC Radio (28.2E) and BFBS (19.2E) while a recording was in progress on BBC Radio 4, the receiver wouldn't play that or any other channel on the BBC transponder. It could nevertheless play radio channels on other 28.2E transponders, but only after a 7-8 second wait. Only the first three minutes of the recording were saved.
In another condition, which I've seen before, the TV picture blinks momentarily at irregular intervals. When this happens, I can no longer select from the channel list and many of the other keys on the remote control do not respond either. I can still change channels with the CH up/down buttons, but the blinking continues. To clear the problem, I reboot the receiver via the web interface.
Can you just try a simple setup without any plugins and the LNB set to normal mode as per post #14.......
On my Giga‘s I have 3 Sat dishes coming into the FBC tuners plus a plugin DVB-s2x tuner - and I don‘t get any of these issues and certainly no delays between switching - and the FBC tuner on this box is the same as the Vu+ and to the best of my memory (it was a long time ago now) power to the LNB is the same for both Vu+ & Giga (initially there were options in tuner setup to turn on/off power to the LNB)
I've the same delay problem as per thread https://www.world-of-satellite.com/showthread.php?62329-Tune-Failed which occurs when switching from motor to unicable.
"Delay after enable voltage before switch command" -> "Unicable delay after enable voltage before switch command"
I've the same delay problem as per thread https://www.world-of-satellite.com/showthread.php?62329-Tune-Failed which occurs when switching from motor to unicable.
Which receiver, which LNB, tuner config??
Which receiver, which LNB, tuner config??
Gigablue Ultra UE 4K - GT-Sat GT-dLNB1DY Unicable LNB, not at my receiver at the moment, but off the top of my head A is Unicable, B-H are linked to A, and I is my motor.
Gigablue Ultra UE 4K - GT-Sat GT-dLNB1DY Unicable LNB, not at my receiver at the moment, but off the top of my head A is Unicable, B-H are linked to A, and I is my motor.
When you have a chance, just for my sanity! Disable B and see what happens
I've the same delay problem as per thread https://www.world-of-satellite.com/showthread.php?62329-Tune-Failed which occurs when switching from motor to unicable.
"Delay after enable voltage before switch command" -> "Unicable delay after enable voltage before switch command"
Disabled tuner B, rebooted, no change.
Huevos - should the value be increased or decreased ?
Disabled tuner B, rebooted, no change.
Huevos - should the value be increased or decreased ?
I've just changed mine from 0200 to 0800, and my initial impression is that it has solved my problem as far as Unicable is concerned. Channel changes from one Unicable service to another now take less than one second. Switching from Unicable to a channel on an ordinary DVB tuner takes a couple of seconds -- but switching back to a Unicable channel takes much longer -- eight or nine seconds -- and the "Tune failed" message pops up briefly just before the picture appears. But at least it gets there. I'm now hoping that this will have solved my problem with dropped recordings.
Much thanks to Huevos!
If you still get the message switching back to the Unicable LNB, add some more delay. You should never get a tune failed message.
I've doubled my 'Unicable delay after enable voltage before switch command' to 1600, and it simply increases the delay before the 'Tune failed!' message appears. So it doesn't seem to have helped. My other Satellite equipment setup parameters are all at the default values.
The delay is not a major nuisance, since the selected channel does appear at the end of it. But I wonder there's some other setting that might have an influence on it.
In my case, switching between Unicable channels hasn't been a problem, its only switching from the motor back to a unicable channel which causes the 'Tuner failed' message before displaying the channel.
Changing the parameter doesn't seem to be having any change.
This has only occured since updating the VIX version (as per my original post).
In my case, switching between Unicable channels hasn't been a problem, its only switching from the motor back to a unicable channel which causes the 'Tuner failed' message before displaying the channel.
That makes two of us, then.
abu baniaz
30-01-20, 20:28
Try using 2700 value. When you are using the motor, i.e not using unicable LNB, the Unicable LNB goes to sleep. Needs more time to wake up.
2700 has stopped the tune fail message, takes a while to display channel but it's acceptable.
Looks like I gave up increasing the value a bit too soon. I've now found that with a value of 1700 I still get the long delay and the 'Tune failed!" message. But with 1800, the message no longer appears and the delay on switching back to Unicable is roughly halved :-) So I've set it to 2000 to allow a bit of a margin.
As a postscript to the above, I decided to disconnect everything and start all over again, using an Inverto 32-band Unicable II multiswitch (IDLU-UWT110-CUO10-32P). This now feeds 28.2E to all three receivers (GigaBlue UHD Quad 4K, Vu+ Solo 4K and Inverto Multibox SAT>IP server, connected via a three-way Dur-line splitter with power pass) -- which occupy 20 User Bands in all. And I was thrilled to find that they all worked straight away, with (so far) no tuning problems or other interactions, and no interrupted recordings. I am powering the Unicable switch over the downlead, using the supplied PSU and injector, to avoid uncertainty over relying on the receivers for power.
I don't know what was causing the problems I had earlier, though it can't have been any of the receivers or the Spaun Unicable I switch. Misconfiguration seems the most likely explanation, though I checked my settings no end of times. My thanks to posters in this thread for their advice.
abu baniaz
26-02-20, 22:20
Just for reference, the devices now have the wake time coded into the image. I've been meaning to post updates to the threads.
abu baniaz
01-07-20, 00:13
This thread is now closed. The posts for the Gigablue issue as a result of the 12 March drivers moved to their own thread. Link below
https://www.world-of-satellite.com/showthread.php?63060-Gigablue-Unicable-problem-12-March-2020-drivers
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.