0xFFFF just means the tuner is maxed out. Why does that deserve a warning message for a box with broken drivers? That message is going to pop up on everyone's box that is working correctly with a maxed out tuner.Originally Posted by EMJB
You're welcome to send a pull request for that. I don't have the STB so I can't test.
TSID is unique on a network. So in theory if you find 2 muxes with the same TSID on 2 different frequencies they should be identical in every way. And that means for certain the SI tables will be wrong on at least one of them.
Is that true with relay transmitters? The relay may just copy all the information from the main transmitter from which it gets its data and then re-transmits on a diffent frequency.
Xtrend ET10K, 2 x satellite tuners 28.2 (Sky FTA), 2 x hybrid (UK Freeview), Zgemma H9S (satellite)
That is what a repeater is. It receives on one frequency and retransmits on another. Nothing is processed. That means the SI tables correspond to the master mast, not the repeater. In such a case if ABM reads the SI tables all the frequency data corresponds to the main mast so the channels are saved with the wrong frequency data. Custom transponder is to correct this problem, or any other situation where the frequency data might be wrong or missing.
Last edited by Huevos; 26-09-18 at 23:15.
I was not aware that 0xFFFF SHOULD (just) be generated with maxed-out tuners. However it is also generated when a Si2169 tuner is used, irrespective of signal strength. However perhaps even that maxed-out tuners arguably merit a warning as signal comparisons may not be valid.
You keep referring to broken drivers, but as at least one other parameter generated by frontend.cpp from the driver info is changing it appears to me that frontend.cpp is a possible source of the problem. Have you investigated to locate the source of the problems?
The Si2168 tuner leads to a return value zero, so I believe my message is valid in those circumstances
As adm's initial post did not immediately generate a response that he had driver etc problems, it is not reasonable for the user to realise that he has an inadequately supported tuner. I therefore consider it highly desirable that the user is advised when there is a problem with the tuner information How about:
(1) If returned value is zero, display warning & abandon option with message along the lines of: "Failed to collect signal quality data from your %s tuner, so unable to find best transmitter if more than one is found, which appears to be due to problems with support for this tuner type. If you have other tuner types, try disabling this one and trying again. Do you want to continue with this tuner?" % self.tuner_type"
(2) If returned value is 0xFFFF, display message along the lines of: "Apparently very strong signal reported by your %s tuner. However if you do not live near a transmitter this could be caused by problems with support for this tuner type, which would prevent correct selection of transmitter if more than one is found, so if you do not expect very strong signals and have other tuner types, try disabling this one and trying again. Do you want to continue with this tuner?" % self.tuner_type"
EMJB
Xtrend Xt10000 with 3 Freeview tuners
(1) That did not quite answer the question "So when the DVB-T frequency finder claims to find unique muxes, it means unique in terms of TsId and rather than unique in terms of services carried?" - you could have signals from different transmitters with the same services yet different TsIds (especially if "same services" ignores regional variants).
(2) The COM muxes seem to have the same TsId for all regions. All muxes carry the EPG data for all the other muxes in at least the same region. If the TsId really means they are identical in every way then all COM muxes must carry the EPG data for all the regional variants of the regional programmes. Do you believe that is the case? (I understood not, but have not found any evidence to support either view).
EMJB
Xtrend Xt10000 with 3 Freeview tuners
Excuse my ignorance of Github protocols, but isn't a "pull request" suggested new code, rather than just an allegation that something is wrong? I started off trying to trace the source of the problem, but hit a number of problems such as my ignorance of C++, lack of definitions as to what should be happening in each stage, and lack of the appropriate tools to monitor what is going on or test any change.
Would raising an "issue" against OpenVix/frontend.cpp be an appropriate starting point?
EMJB
Xtrend Xt10000 with 3 Freeview tuners
@EMJB,
1) Frequency finder has nothing to do with services. All it does is match TSIDs to frequencies. Then when ABM reads the SI tables it knows which frequency corresponds to which TSID. If a TSID is on more than one frequency the one with the better signal quality will be selected. In the case of identical signal quality the lower frequency will be selected.
2) The COM 7 and COM 8 are national muxes. I can't be more specific as I don't live in the UK. If you want to know more about what is in the SI tables on any particular mux do a full transport stream recording and read the SI tables with a software such as Transedit or DVBInspector.
3) Yes a pull request means send code. You are the one with the hardware, not me, so I am not in a position to write and test the code that would correct the arithmetic for your tuner.
https://github.com/OpenViX/enigma2/b...ntend.cpp#L901
4) A zero value means we don't save the transponder. No need for an error message. Also if 2 muxes with the same TSID are maxed out it doesn't matter which is selected as the content will be the same on both, so also no need for an error message.
It may matter to the user as one signal may be from a transmitter that over a period of days/weeks gives unreliable reception while the other may give rock solid reception throughourt the year.
To put ths into context: I have no problem recieving all MUXs from the Bluebell Hill transmitter using the information in the current terrestrial_uk_freeview.xml file which I'm using but a test of the DVB-T frequency finder shows the potential problems someone may have if they have no knoleldge of their transmitter and they have a box (ET10000) with flawed tuner drivers and/or can receive signals from more than one transmitter and/or can recieve signals from an unwanted transmitter with strong signals but unreliable reception.
Xtrend ET10K, 2 x satellite tuners 28.2 (Sky FTA), 2 x hybrid (UK Freeview), Zgemma H9S (satellite)
There are xml files for different purposes. Please be specific as to what you are referring to.
I lose track of the of times that it has been posted:
ABM locks onto the the mast using the specified frequency.
The data on the stream is used for obtaining the tuning data to add to lamedb for services.
The custom transponders are there when users report and supply data to add to ABM:
The custom transponders fulfill two purposes:
Add DVB-T2 data that is not on the stream
Correct/add data
Huevos and PeterJ are not in the UK.
I don't receive from more than one mast.
You are not going to get one fix for everything plugin without people knowing their mast or supplying data.
If they don't know, the simple solution is do not use ABM. Change "ignore dvb-subnet". Scan UK all regions (not using ABM) You will then avoid the issue of a service on two frequencoes not being only registered on one.
Last edited by abu baniaz; 28-09-18 at 16:24. Reason: formatting corrections
Huevos (27-09-18)
Please supply the data you want added and it will be added.
That is the problem. You only test for signal quality if lock is achieved. To achieve lock you need a SNR > ~20dB, so a return value of zero indicates an error. There is a very high probability (and a certainty in the cases found so far) that the same value will be returned for every mux however good, so one can reliably predict that some minutes after the first occurrence the user will receive a message saying no muxes found irrespective of how many are in fact OK.
The user is almost certainly going to get one a few minutes later that gives him no help whatsoever in determining the source of the problem. My message identifies the source of the problem, a possible work-round of an alternative tuner, and the possibility of proceeding if duplicated muxes are not expected.
Apologies - I did not make it clear that there is a different problem with maxed-out signals - too strong signals can affect reception just as effectively as too weak ones. Without detailed knowledge of individual tuners it is difficult to say how close to that point is to the point where maximum SNR is reported, but maxed-out signals should be considered as a warning that other muxes may have even stronger signals causing failure to lock, and therefore being ignored. (To be pedantic the overloading is a function of signal strength, not SNR but a high SNR must imply a strong signal, even if the reverse is not true.
EMJB
Xtrend Xt10000 with 3 Freeview tuners
So now the plugin is supposed to second guess on a crap tuner that gets flooded when signal is strong?
(1) Why do you think a tuner is crap because it gets flooded? Every practical solid state electronic device has an upper limit of signal it can handle - at its most basic how do you expect the output of an amplifier have higher voltages than its power supply? If someone lives close to a transmitter and has too good an aerial (perhaps because the transmitter power has been increased) they will suffer problems.
(2) There is no question of "second guessing" - I thought I made it clear how the plug-in detects that the signal is at or near the limit - by detecting that the SNR has maxed out. If the plug-in detects a situation that could lead to problems, surely it is only sensible to warn the user, even if that is only indirectly related to the primary purpose of the plug-in.
I suspect, however that your comment is much more a reflection of a difference in approach between us:
(a) You seem to want to write a plug-in that operates in an ideal world where the rest of Openvix and the hardware meet your expectations of perfection, even though so often the functionality of other OpenVix elements such as frontend.cpp are not properly defined (or certainly I have failed to find such definitions - for example where do I find the statement that 0xFFFF means maxed-out other than that's what the code sometimes seems to do?). Furthermore you seem happy with the resulting work for yourself and abu baniaz trying to sort the resulting problems, some of which such as adm's get left unresolved.
(b) I take a more practical view of others' code and real hardware, and judge ABM or any other plug-in on how well it works with OpenVix and the supported hardware as they currently are. To me every involvement by the author or allied expert is a sign that something need to be changed to stop it recurring - for example if OpenVix is considered to be at fault and cannot be changed quickly then the plug-in should do its best to work round the problem or advise the user of what action to take. I also expect the plug-in author to take an active interest in any changes apparently required elsewhere, as others may disagree. I expect my PVR to have a life of ~10 years, during which I may move house and/or major Freeview transmitter changes may occur, but will you & abu baniaz be around to update the relevant transmitter files if the Si2168/9 support issues have not been resolved (I may be able to cope, but if I fall under a bus where will my son get help from?)
Of course you are entitled to take the former approach, but expect continued signs of frustration from me if you do so!
EMJB
Xtrend Xt10000 with 3 Freeview tuners
birdman (28-09-18)
Posting Permissions
