Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[TM-TWIN-OE] Intermittent "Tune Fail" - receiver sometimes selects wrong tuner

Maybe, but it is the use of tuner B that always goes wrong. This is connected directly to a universal LNB. There are no switches or motors to send commands to. The signals to select band and polarisation are, I believe, static signals, so there can be no concept of repeating them.
Voltage and tone are used to command the LNB. Just connect this coax to tuner A to see if the issues swap as well.
 
Voltage and tone are used to command the LNB. Just connect this coax to tuner A to see if the issues swap as well.

Swapping over the functions of A and B is certainly on my list of things to try when I have time. Obviously I will need to interchange the configurations as well as the cables.

I can't think of anything else to try at the moment, so yes I will give it a go.
 
I have now done the experiment of interchanging the tuner configurations and LNB cables, so I now have the fixed dish on A and the motorised dish on B.

The effect of this change became apparent almost straightaway. The problems I observe have now moved to the motorised dish. I have had several failures when recording from the motorised dish from standby, or when streaming a signal from the motorised dish when the box is in standby. Although it's early days, I have not yet had a recording failure from a channel which can come from the fixed dish. As before, once the box is properly awake and both tuners have been exercised, there are no further problems.

In other words, the problem has remained associated with the use of tuner B from standby. I think this eliminates my LNBs and cabling as the source of the problem.

Having the problem this way round is perhaps slightly preferable, as most of the recordings that I actually care about, as opposed to test recordings, will come from the fixed dish. But it is still a very annoying issue.

Given my earlier observation that selecting tuner B sometimes took the actual signal from tuner A, I'm sure this is not simply a "dodgy tuner" problem. It must surely be something to do with the initialisation that is done when tuner B is the first one used after the box comes out of standby.
 
It looks like that the cabling/lnb's etc are OK.
Please don't assume anything; that won't make you any wiser.
Please state your complete tuner config and problem as it is now.
 
It looks like that the cabling/lnb's etc are OK.
Please don't assume anything; that won't make you any wiser.
Please state your complete tuner config and problem as it is now.

I am trying quite hard not to make assumptions. At every stage in this thread I have tried to give the evidence that leads to the conclusions I am making.

I suspect a software bug, yes, but no, I am not assuming it.

Would it help if I attached my "settings" file?

The current configuration is:

Tuner A connected to one port of an octuple LNB on a Sky minidish (other ports go to a standard Sky box and a PC tuner card)

Tuner B connected to a totally separate motorised dish with DisEqC motor, using USALS, universal LNB.

When the receiver is up and running, both tuners work fine; I can jump between the tuners, choose satellites, record one thing whlle watching another, stream from the web interface, exactly as you would expect.

The symptom I observe only occurs when the receiver is coming out of standby, either because I've switched on to watch something, or to make an unattended recording, or to stream from the web interface. It does not go wrong every time - it's hard to quantify but perhaps 1 in 3 attempts goes wrong. The nature of "goes wrong" is that if (and only if) the channel it needs causes it to select tuner B, then I see "tune failed" or a failed recording. There is strong evidence (yes, evidence, not an assumption - see earlier in the thread) that what is actually happening is that despite choosing tuner B, it is actually taking the data stream from tuner A. Whether it actually yields a usable signal or not depends on whether the "wrong" dish happens to be pointing at the "right" satellite.

Once the receiver is in the "bad" state, it stays that way until I choose a channel that uses tuner A, and then go back to B. After that it works perfectly until the next standby.
 
Debug logs from the failed recording state might help shed some light on your issue.
 
1) "Standby is actually standby or deep sleep?
2) Preferred tuner i snow set to 'auto'?
3) Preferred tuner for recordings is now set to 'disabled'?
 
1) "Standby is actually standby or deep sleep?
2) Preferred tuner i snow set to 'auto'?
3) Preferred tuner for recordings is now set to 'disabled'?

1) Yes, standby. I don't use deep sleep.
2) Yes, "auto".
3) No, "auto" (I did say that, earlier in the thread). Would "disabled" be better? I haven't been able to find out anywhere what these options actually mean!
 
Debug log: View attachment debug.log
Settings file: View attachment settings.txt

I changed the record preference setting as recommended. I also upgraded to build Apollo.118. Neither seems to have made any difference :(

I have attached a couple of files - my /etc/enigma2/settings file and the debug log since the box rebooted. It's a bit hard to follow the log without timestamps, but I think the interesting bit begins at line 6295 where a test recording that I set up earlier starts up and fails. The same channel worked fine later.
 
I've not read through all of this thread, but if you unit is under warranty why dont you simply contact Technomate or your supplier, point them towards this thread and ask if you can exchange the unit.
 
I've not read through all of this thread, but if you unit is under warranty why dont you simply contact Technomate or your supplier, point them towards this thread and ask if you can exchange the unit.

It's out of the supplier's declared warranty. Supplier was this forum's sponsor, which is kind of why I'm here. I could try playing the "EU regulations" card and claim extra time, but I don't think I have the energy.

In any case, the box is working well enough to be useful and other things being equal I'd prefer not to have to send it away.
 
If it where me I'd re-flash the receiver, setup fresh as below to test.

1) Disconnect all other receivers connected to Sky Octo LNB. Ensure the Twin is the only receiver connected to ANY LNB even the motor LNB.
2) Set A to Fixed Dish.
3) Check alignment of motor dish with engineers meter.
4) Check all coax and f connectors.
5) Set B to motor dish.

Test completely as free to air, no softcams, no plugins nothing, pure virgin flash.

If you still have an issue take to another property and test there, if thats in anyway possible.
 
What exactly do posts 16 & 17 refer to? Has the unit been modified in anyway?

Posts 16 and 17 refer to a recent and sudden failure of the +5S power supply rail, which drives the front panel display, IR receiver etc. The symptom described in this thread predates this failure by over a year. I understand that it is a fairly common power supply fault. Even with this power rail missing, the receiver runs and can be controlled from the web interface, and I actually used it that way for several days.

I have now worked around the problem by providing an auxiliary power supply, so in that sense, yes the receiver is modified. It hasn't changed the manifestation of this symptom in the slightest.

If the current issue turns out to have a fix, I will get a replacement PSU board. Otherwise it's just throwing good money after bad. It's quite tempting to ditch this receiver and start again...
 
Not sure. The log does show the errors, but why?
Well, at least some of them because "remote_fallback failed". This is surprising, as your settings do not show that remote fallback has been enabled.
Where do you settings stem from?

I also noticed in your settings that both tuner A & B uses DiSEqC; is that correct? Can you show a screenie of the tuner configs please?
And also tell in your own words what the LNB setup is?
 
Not sure. The log does show the errors, but why?
Well, at least some of them because "remote_fallback failed". This is surprising, as your settings do not show that remote fallback has been enabled.
Where do you settings stem from?

I also noticed in your settings that both tuner A & B uses DiSEqC; is that correct? Can you show a screenie of the tuner configs please?
And also tell in your own words what the LNB setup is?

I don't even know what remote_fallback means! Certainly I have not knowingly set it.

My settings were all, I think, set manually from the remote control after I reflashed as I described at the very start of this thread. I might have set the odd thing from the web page, but nothing to do with the tuner config.

Tuner A should not be using DiSEqC. Could this be a remnant of the earlier config when the LNBs were the opposite way round? Earlier in the thread you will see that in response to a suggestion I swapped the functions of A and B which demonstrated that the symptom stuck with the tuner and not the LNB.

I can't get a screenshot right now because I'm not at home, but can get one later.

Current set up is:

A: direct connection to 1 port of an octuple LNB on a Sky minidish. No DiSEQC devices at all. Other ports connected to Sky box and a PC card (all working perfectly).

B: Connected via DiSEqC H-H positioner to a Universal LNB on a totally separate 1m dish. USALS used for positioning, which is working perfectly.

At the start of this thread, it was the opposite way round. In both configurations, I see problems with whichever dish is connected to tuner B.
 

OpenViX Feeds Status

Back
Top