Spinning VIX of death

[Erling]

My vuplus ultimo has got a problem where it becomes unresponsive with a spinning VIX in the up left corner of the screen. The box used to be rock solid before this problem started a month or so ago, when it was re-flashed with Helios. I have tried to revert to earlier VIX-versions, and even other images like BlackHole, VTI and the original vuplus image, but the problem persists. The issue seems to be worsened with Apollo 21, but it can be that something completely unrelated is developing, and that a revert to an earlier Apollo image would make no difference.

My setup is a plain ultimo with two S2-tuners, one T-tuner (LG), a hard-disk, the WiFi-dongle that came with the box, and Apollo 21, flashed via usb without restore of settings. No other software or hardware required to repeat the issue.

The log tail when the freeze happens is usually like this:

(2)fe event: status 0, inversion off, m_tuning 0
stateLostLock
OURSTATE: lost lock, trying to retune
(2)tune
OURSTATE: tuning
[SEC] startTuneTimeout 5000
[SEC] setVoltage 0
[SEC] setFrontend 1
setting frontend 2
main thread is non-idle! display spinner!

One way to deadlock the box for sure is to start a recording on the T-tuner, and then standby the box. Soon after, the REC indicator on the front panel will stop flashing and the box becomes unresponsive. By the way, there are often many more of these "lost lock"-entries in the log, but they seem to be transient, ie the tuning goes ok again:

(2)fe event: status 0, inversion off, m_tuning 1
(2)fe event: status 1f, inversion off, m_tuning 2
OURSTATE: ok

Another way to freeze the box is to switch from a T-tuner channel to a S2-channel. The display goes black, as usual, but instead of the S2-channel appearing, the spinner turns on and stays there forever on the black background. The log is different in this case:

opening frontend 0
(0)tune
RotorCmd ffffffff, lastRotorCmd ffffffff
prepare_sat System 1 Freq 11493750 Pol 0 SR 22000000 INV 2 FEC 2 orbpos 192 system 1 modulation 2 pilot 2, rolloff 0
tuning to 1743 mhz
OURSTATE: tuning
allocate Channel: res 0
[eDVBCIInterfaces] addPMTHandler 1:0:19:283D:3FB:1:C00000:0:0:0:
allocate demux
[SEC] set static current limiting
set sequence pos 3
set sequence pos 4
[SEC] setVoltage 2
[SEC] sleep 200ms
[SEC] invalidate current switch params
[SEC] sendDiseqc: e00000(DiSEqC reset)
[SEC] sleep 50ms
[SEC] sendDiseqc: e00003(DiSEqC peripherial power on)
[SEC] sleep 150ms
[SEC] sendDiseqc: e01038f6(?)
[SEC] sleep 50ms
set sequence pos 3
set sequence pos 3
[SEC] update current switch params
[SEC] startTuneTimeout 5000
[SEC] setFrontend 1
setting frontend 0
main thread is non-idle! display spinner!

A freeze can also happen just like that with me doing nothing, but watching a programme, and then the VIX spinner suddenly shows up, with the programme still running just fine. Lock is lost according to the log, so how can it be that the programme continues to display as if nothing has happened? It is as if the lost lock is actually false alarm, and that the handler dealing with this ends up deadlocked somewhere.

The signal quality here is good. There is no visible indication of tuning problems before the lockups, ie there are no tuning failed alerts or disturbances of any sort in the display.

Any help would be most welcome.


Regards,
Erling

[timofee]

Might be a tuner hardware fault. You could try to isolate the problem area by removing one of the tuners.

Try taking out the T-Tuner and running the box for a day or two to see what happens. If still a problem try taking out one of the S2 tuners and test again for a day or so.

[Erling]

Thank you for helping. I removed the T-tuner, and then re-tried all known ways to get the spinning VIX, with no luck. I installed the T-tuner again, and the lockup was back shortly after reboot. One should therefore think the problem is with the T-tuner.

However, I removed the hard disk to figure out if that had any effect, and it did. Not only is the spinner out of sight, the repeating re-tuning on the T-tuner is gone too, ie there are no "lost lock" entries in the log after 7 hours up time, while they occur every few minutes with the hard drive installed.

Thus it seems like the box does not have what it takes to support 3 tuners and a hard drive anymore, as if something has dried out after 18 months. Are there any known problems with the power supply design in the ultimo?


Regards,
Erling

[timofee]

You have probably stressed your old VU+ Ultimo to the limit of it's hardware capability.

Might be time to get one of the latest models like the VU+ Duo2.

[Erling]

You have probably stressed your old VU+ Ultimo to the limit of it's hardware capability.

Old? This puppy is 18 months young. I'd expected a longer service life.


Might be time to get one of the latest models like the VU+ Duo2.

Newer boxes doesn't offer anything significant over the ultimo, and according to other threads here, they seem to come with their own set of problems. The ultimo is my favorite viewing box, and it would be much more rewarding to get it up and running again.

Anyway, I got hold of another ultimo (new a year ago) to test with. Hope was that moving the PSU from the newer box to mine would eliminate the problem, but this had no effect. To shorten a rather long story of moving things between the boxes: the problem moves with my tuners, ie not 1 or 2 of them, but all 3, installed in the same slot order in the newer box. With this setup, the newer ultimo also looses tuner lock frequently and gets the spinning VIX of death within minutes.

Here comes the weird part: the tuners were installed in the recommended slot order (according to the manual), ie the S2-tuners in slot A and B, and the T-tuner in slot C. If I swap the T-tuner with the S2-tuner in slot A, then the problem is gone, the ultimo is back to rock solid. The same is true for the newer box. BTW, both boxes are running Apollo 22.

While this solves the problem, how can the observed phenomenon be explained?


Regards,
Erling

[twol]

Can only assume T tuner takes more power and that there is a power supply drop off across the 3 slots.
What happens if you record on both S2 cards whilst taking picture fom T tuner, assuming you retain S2/T/S2 tuner sequence?

[ronand]

Whats written in the manual may not be relevant now as the drivers have been updated many times. Have a read of this thread as it may give a clue http://www.world-of-satellite.com/showthread.php?8830-New-Vu-Hardware-Drivers

[twol]

Whats written in the manual may not be relevant now as the drivers have been updated many times. Have a read of this thread as it may give a clue http://www.world-of-satellite.com/showthread.php?8830-New-Vu-Hardware-Drivers
Makes me happy not to have a VU:)

[Erling]

Whats written in the manual may not be relevant now as the drivers have been updated many times. Have a read of this thread as it may give a clue http://www.world-of-satellite.com/showthread.php?8830-New-Vu-Hardware-Drivers

I may have missed something obvious, but I find nothing there indicating that the tuner order has to be changed after the driver update.

Anyway, in order to stress test the new tuner order (T/S2/S2) with Apollo 22, I tried 3 concurrent recordings, one on each tuner, then watching a 4th channel on the T-mux already in use by the recorder, together with top running on telnet via WiFi and tail -f on the detailed log in another telnet session. Also retried the scenario many times.

It turns out the ultimo is humming along nicely at approx 40% CPU with this load, no spinning VIX.

There is one disturbing log message though:

[Dish] tuning failed

This happens for sure when switching from a T channel to an S2 channel, immediately before closing the T front-end, but it seems the message can show up in other situations as well. The message is in almost all cases nearby (ie short after) another message about "gotPMT", whatever that means, for example:

...
[eDVBCIInterfaces] gotPMT
poll: unhandled POLLERR/HUP/NVAL for fd 64(16)
sdt update done!
[Dish] tuning failed
...

The few messages between gotPMT and tuning failed varies, and in some cases they are absent. There is no visible problem that I can see when the message is logged.


Regards,
Erling