View Full Version : [ABM-DVB-T/T2] ABM (UK-Terrestrail ): Add HD channels/regions REVISTED Bluebell Hill
I was seeing something very strange from the Bluebell Hill Terrestrial transmitter where nearly all the channels are devoid of a picture and sound and selecting them gives “Service not found – (SID not found in PAT)” The only channel that appeared to be working is a local Kent channel.
https://ukfree.tv/transmitters/tv/Bluebell_Hill
says transmitter frequencies change at the end of next month.
http://www.digitaluk.co.uk/coveragec...E5+9RD/NA/0/NA
Says they have already changed plus it gives some more information on transmitter channel numbers.
My investigation shows that the frequencies/MUX allocations have changed as per the second link PLUS a local mux on transmitter channel 21
I'm running ABM 3.1 and the latest terrestrail_uk_freeview.xml file is now out of date with regards the Bluebell Hill transmitter.
I have modified my copy (attached) and have got the Bluebell Hill transmitter working again in ABM. lamedb file also attached
57343
57344
Did you try "frequency finder"?
https://www.world-of-satellite.com/showthread.php?59815-ABM-(Terrestrail-)-Add-HD-channels-regions&p=472867&viewfull=1#post472867
It would be useful to see how you get on, with a clean flash of the latest image and a settings restore of your old Bluebell Hill transmitter values.
Did you try "frequency finder"?
https://www.world-of-satellite.com/showthread.php?59815-ABM-(Terrestrail-)-Add-HD-channels-regions&p=472867&viewfull=1#post472867
As an experiment I have tried it.
The results are not good
It found 12 unique MUXs which were those from Crystal Palace and an incomplete list of those from Bluebell Hill. In my location I can usually get signals from up to 4 different transmitters, weather dependant, with the aerial pointing to Bluebell Hill. Although I can get strong signals from Crystal Palace the proximity of nearby tall building makes them unreliable hence why I only want the Bluebell Hill signals where I have an unrestricted line of sight. Reflections from the tall buildings is probably the reason I can often see 4 transmitters as I have an aerial with a fairly narrow front reception angle and high back rejection.
The terrestrial_finder.xml file generated by the frequency finder contains the frequencies for both Crystal Palace and Bluebell Hill and likely would result in unreliable reception, perhaps not today but during an atmospheric change.
According to:
http://www.digitaluk.co.uk/coveragechecker/main/index/dummy/NA/yes.
Bluebell Hill had a "reception change" on August 1st. Perhaps that affected you?
Also:
BLUEBELL HILL transmitter - Freeview: BBC Digital (https://ukfree.tv/article/1107051421) TV Off Air from 18:14 on 17 Aug to 18:51 on 17 Aug, HD Digital TV Off Air from 18:14 on 17 Aug to 18:51 on 17 Aug. [BBC]
According to:
http://www.digitaluk.co.uk/coveragechecker/main/index/dummy/NA/yes.
A site that in the past decade has had much incorrect information :) It still tells me that my preffered tansmitter is a low power one that cannot be seen from my location.
Bluebell Hill had a "reception change" on August 1st. Perhaps that affected you?
Very possibly
i) I was away for the first couple of weeks in August
ii) I usually watch live (or delayed) TV via satellite
iii) I didn't notice the problem until a day or two ago when all my satellite tuners were busy recording and I was going to use a terrestrial tuner for another timer.
iv) Both my previous sources of reliable transmitter information both show no changes to the transmitter frequencies, or not until the end of next month.
v) I did wonder for a while if it was because ABM had gone to version 3.1. and a configuration update from the menus resulted in a non-compatible version error message. I updated ABM yesterday before proceeding further.
vi) With the current terrestrial_uk_freeview.xml file, configuring ABM for Bluebell Hill, deleting all Bouquets, the lamedb and epg files a subsequent scan did give a Freeview Bouquet that looked correct and the EPG populated again. It’s just there was no associated video or audio. Some of the transmitter frequency allocations are now being reused for different MUXs.
vii) This morning repeating the excersise with the frequency finder in ABM shows it would have been of zero value in my situation as it didn’t find (or maybe rejected) some of the Bluebell Hill MUXs, but all of the unwanted Crystal Palace MUXs. Yesterday I checked with a manual scan on all the documented “new” Bluebell Hill MUX frequencies that they were all active and each resulted in a representative number of expected TV channels being found.
abu baniaz
30-08-18, 08:05
Added here
https://github.com/oe-alliance/AutoBouquetsMaker/commit/8710a20010dff6a19ea74c66a271ee985094957e
So, no need for Custom transponders apart from the DVB-T2 ones.
Added here
https://github.com/oe-alliance/AutoBouquetsMaker/commit/8710a20010dff6a19ea74c66a271ee985094957eHmmm...an incorrect/out-of-date config file causing end user problems...
So, no need for Custom transponders apart from the DVB-T2 ones.
I suspect (have no proof nor inclination at present to further investigate) there is something that prevents T2 scanning when only one entry for the transmitter in the terrestrial_uk_freeview.xml file hence the reason I added the 3 entries to my custom transponder section.
Speculation about what may be happening based on some observations between 2am and 5am when I was sorting out my problems. I was a bit tired at the time so absolute recollection may be very suspect :)
I configure my tuner(s) for T2
I have one entry in the .xml file for the MUX with BBC1 and a subsequent scan doesn't find any T2 MUXs
I check with a manual scan for a single Predefined Transponder (T2 MUX transmitter channel number). The "system" default is DVB-T and not DVB-T2 and I change it to Auto and check that the MUX is active and I get the expected T2 channels.
If I now go back to ABM and scan I think it now finds all the DVB T and all of the DVB T2 MUXs
It's maybe when installing a new image the system thinks the tuner configuration is DVB T irrespective of what it says in Tuner Config/Tuner Setup and hence the ABM scan only finding DVB T MUXs and it required going to somewhere else (such as manual scan) to toggle the setting to DVB T2 (or using the custom entry in the terrestrial_uk_freeview.xm to do the same).
I seem to remember that at one time the tuner config used to have the options of DVB-C, DVB T and DVB T2 but the DVB T option was removed from later versions (or for different boxes).
abu baniaz
30-08-18, 13:44
We have to manually add the DVB-T2 frequencies for ABM. This is normal.
We also have to add frequencies where there are clashes/bad data. This used to be the case for your area/mast.
The terrestrial_finder.xml file generated by the frequency finder contains the frequencies for both Crystal Palace and Bluebell Hill and likely would result in unreliable reception, perhaps not today but during an atmospheric change.
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?
Is this also true of Terrestrial Scan?
EMJB
For info
Here is what frequency finder found for me (attached)
57345
Line numbers when using textpad, other editors may wrap lines.
Line 6 a frequency of 514000000 is channel 26 (entry repeated on line 14)
Line 10 Ch 21 Bluebell Hill Local Service
Line 11 Ch 22 Crystal Palace
Line 12 Ch 23 Crystal Palace
Line 13 Ch 25 Crystal Palace
Line 14 Ch 26 Crystal Palace
Line 15 Ch 28 Crystal Palace
Line 16 Ch 30 Crystal Palace
Line 17 Ch 32 Bluebell Hill
Line 18 Ch 34 Bluebell Hill
Line 19 Ch 45 Bluebell Hill
Line 20 Ch 55 Bluebell Hill
Line 21 Ch 56 Bluebell Hill
Missing is Ch40 Bluebell Hill
Missing is Ch43 Bluebell Hill
Missing is Ch46 Bluebell Hill
Even if a service is duplicated on Crystal Palace I don’t what a scan of CP frequencies which for me can be unreliable.
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?
Is this also true of Terrestrial Scan?
EMJB
Sorry, adm, my questions were aimed at Huevos or someone else who understands what these features are designed to do - I should have made myself clearer.
Looking at the file you posted, I notice that all the signal qualities are the same at $FFFF, as are the ones in my terrestrial_finder.xml on my ET10K. If all the signals are strong that is quite plausible, but in that case I would expect all the Bluebell Hill muxes to have been detected. Pity the signal strength is not logged also, as I assume the logic to determine the optimum mux version will take account of that when qualities are similar. On the other hand it could indicate a problem reporting signal quality by our tuners.
I have also noticed the layout of my file attached is very much simpler than yours, but lack the knowledge to understand the significance of the differences.
EMJB
Sorry, adm, my questions were aimed at Huevos or someone else who understands what these features are designed to do - I should have made myself clearer.
Looking at the file you posted, I notice that all the signal qualities are the same at $FFFF, as are the ones in my terrestrial_finder.xml on my ET10K. If all the signals are strong that is quite plausible,
Yes, the Signal to Noise (SNR) is at maximum (100%) on the MUXs from CP and BH and all the Bit Error Rates are reporting as 0.
The SNR on my ET10k is always 100% even when the freeview channel is hardy viewable due to atmospherics or whatever.
It used to vary considerably, but not anymore, probably for a year or more.
Had a look at the section of the log file relevant to the frequency scan, and see the following apparent error messages:
<01-19-57.380> [eDVBFrontend] FE_READ_BER failed: Operation not supported
<01-19-57.380> [eDVBFrontend] FE_READ_SNR failed: Operation not supported
<01-19-57.381> [eDVBFrontend] FE_READ_SIGNAL_STRENGTH failed: Operation not supported
which makes me wonder whether the signal quality values of $FFFF actually mean "quality unknown", in which case it would seem that DVB-T frequency finder is simply going to select the first "copy" of a mux it sees on ET10Ks.
EMJB
Had a look at the section of the log file relevant to the frequency scan, and see the following apparent error messages:
<01-19-57.380> [eDVBFrontend] FE_READ_BER failed: Operation not supported
<01-19-57.380> [eDVBFrontend] FE_READ_SNR failed: Operation not supported
<01-19-57.381> [eDVBFrontend] FE_READ_SIGNAL_STRENGTH failed: Operation not supported
which makes me wonder whether the signal quality values of $FFFF actually mean "quality unknown", in which case it would seem that DVB-T frequency finder is simply going to select the first "copy" of a mux it sees on ET10Ks.
EMJB
The box knows if the MUX is active or not. On non-active transmitter channels the SNR is reported as zero. Bit Error Rate is the measurement of quality and not necessarily SNR.
However, I think that you are probably correct in what is being reported is actually junk and as a result the frequency finder is possibly next to useless on a ET10K.
As an experiment I inserted another 22dB of in-line attenuation at which point the picture was at the point of break-up. The SNR bar always still reported 100% and the BER never moved from zero. The SNR figure fell from 301dB (no additional attenuation) to 190dB (22dB of additional attenuation).
Selecting the first MUX it sees with a decent SNR or signal strength is a poor way of selecting the MUXs to scan. As mentioned previously both Crystal Palace and Bluebell Hill give me a strong signal and reliable reception on many days but because the path to CP is masked by nearby tall buildings signals from this source have proved unreliable longer term. You need reliable signals for unsupervised recordings.
For info.
I inserted a 4G filter in my system (approx 4dB insertion loss)
The frequency finder now finds 11 discrete MUXs rather than the previous 12
There are still the 3 missing MUXs from Bluebell Hill and now an additional MUX from Crystal Palace.
The filter is allowing Channel 56 to be seen from Bluebell Hill.
https://www.blake-uk.com/home/534-f-type-external-masthead-lte-blocking-filter-35db-55db-upto-ch-57-proception.html
As I said before, the SNR is now stuck on 100%, I remember checking the april 2018 driver update to see if it was working again, because it used to show more realistic values. So it could be the last but one driver update which messed it up.
Thanks for the additional information adm & ccs. I have tried a USB tuner with a Si2168 chipset rather than the Si2169-based tuners supplied with the ET10K. When this is used by DVB-T frequency finder I get slightly different error messages, but still the same $FFFF quality value.
I have also tried setting "Force legacy stats" on the tuner configuration page to "yes", in the hope that might help, but it stopped DVB-T frequency finder from finding any muxes.
Incidentally, it has just occurred to me that the quality-generating code has probably been written in C, and $FFFF as a 16-bit word equals -1, which is what one might expect when no quality information is available.
EMJB
The issues identified in this thread would have a major impact on my proposed tuning guide if not fixed, so in the absence of response from elsewhere I have been investigating the code and identified what I think is the major issue and suggested fixes in the attached file.
Not all tuners give a useful response to the "self.frontend.readFrontendData(iFrontendInformatio n.signalQuality)" call, at least one (Si2168) returning 0 and another (Si2169) 0xFFFF to indicate no data available. As the quality is only interrogated after a lock is found, the actual SNR must be greater than ~20 dB when this call is made, so a received value of 0 must always indicate invalid information rather than just a very poor signal. Assuming the tuner does not change and does not provide valid data, the same value will be returned for each mux found. With the present logic a return value of zero will lead to wasted time searching all channels and finding no muxes, and a return value of 0xFFFF is treated as a large SNR and the first mux of each type found will be used, whether or not it is best. To be pedantic, the problem lies in the drivers for the various tuners and/or frontend.cpp, but it seems unlikely that these will be corrected in the short term, or that problems will not be found with any new tuners. To mitigate these issues I have made the following changes:
(a) When 0 or 0xFFFF is returned I have amended the logic to try 3 other measures of signal quality.
(b) If no valid measure of signal quality is found the user is given the choice of continuing (using the first version of each mux found), or abandoning the search with the following message:
57520
N.B. Ignore the actual tuner type in this message - the screenshot was generated by inhibiting the use of alternative measures.
The tuner selection is currently redone for each frequency, which raises (the rather remote) possibility of a major problem if it results in a different tuner models being selected, as the quality levels reported are not consistent between tuner models. There is a lesser problem if poor cabling or uneven distribution amps lead to different signal levels to otherwise identical tuners. I have therefore changed this to run just once at the beginning. The preference for the last tuner is perhaps non-ideal, as this will favour USB tuners which are arguably less likely to be properly supported than the normal ones, but I have not changed this.
If anyone would like to try it, as a minimum they need to copy the attached file to "/usr/lib/enigma2/python/plugins/SystemPlugins/AutoBouquetsMaker/scanner/", and reboot the GUI, but if they think they may need to revert to the old version they should rename the "frequencyfinder.pyo" file in that dierectory to something like "frequencyfinder.pyo.orig" before rebooting. The reboot will create a new "frequencyfinder.pyo" file. I would welcome reports of which tuners work and which do not.
57521
The tuner selection is currently redone for each frequency, which raises (the rather remote) possibility of a major problem if it results in a different tuner models being selectedThis assumption is false. On subsequent runs the same tuner is always selected.
First iteration here: https://github.com/oe-alliance/AutoBouquetsMaker/blob/master/AutoBouquetsMaker/src/scanner/frequencyfinder.py#L230
Subsequent iterations here: https://github.com/oe-alliance/AutoBouquetsMaker/blob/master/AutoBouquetsMaker/src/scanner/frequencyfinder.py#L244-L245
This assumption is false. On subsequent runs the same tuner is always selected.
Apologies for that misunderstanding of the code. Do you want to take on board the other changes, and if so do you want me to produce a version without the additional logging and explanations of my changes?
EMJB
As I said before, the SNR is now stuck on 100%, I remember checking the april 2018 driver update to see if it was working again, because it used to show more realistic values. So it could be the last but one driver update which messed it up.Can you post screengrabs of SignalFinder of an identical pair of transponders.
This could be significant.
CH22 bbc sd mux is showing values, but CH28 bbc hd mux shows no signal.
Can you post screengrabs of SignalFinder of an identical pair of transponders.I thought that the idea was that different chipsets produce different results (but could easily be wrong).
I have a box with 4-different DVB-T2 tuners in....
One of the problems I hit when investigating different tuners was that the different display features appear to use different data, and/or display the available data incorrectly. Using the logic I proposed for DVB-T frequency finder both Si2168 & Si2169 provide sensibly varying values. The Si2169 responds sensibly to the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.snrValue)", but the Si2168 does not and so the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.signalQualitydB) is invoked and gives values that appear to be in milliBels - i.e. 30 dB is reported as 3000.
The following SNRdB results from the webif "web/signal?AGC=" command may be of interest (the main figures are averages across 20 samples, and those in brackets are the lowest figures in those samples) :
<----------------- Signal SNR ----------------->
Name Status Tuner A Tuner B Tuner C Tuner D
Si2169 Si2169 Si2169 Si2168
1 PSB1 In Use 340 (334) 301 (301) 340 (340) 31 (31)
2 PSB2 In Use 348 (347) 341 (340) 340 (334) 32 (31)
3 PSB3 In Use 354 (353) 348 (347) 347 (308) 31 (31)
4 COM4 In Use 360 (353) 358 (353) 360 (360) 33 (32)
5 COM5 In Use 360 (360) 343 (340) 341 (340) 33 (33)
6 COM6 In Use 355 (353) 284 (275) 301 (301) 28 (27)
Note that the "HD" mux is being shown apparently correctly, unlike Signal finder where I have seen the same problem as reported by ccs.
It would also appear that the Si2169 reports are in centiBels, as they seem to be a factor of 10 larger than for the Si2168. However as DVB-T frequency finder is only interested in relative levels, that would not affect the results.
EMJB
I thought that the idea was that different chipsets produce different results (but could easily be wrong).
I have a box with 4-different DVB-T2 tuners in....
I would certainly be interested in what happens if you run my version for each tuner, and the log file would be even better as it would indicate which data item is being used for each chipset.
EMJB
@EMJB How do you run "webif "web/signal?AGC=" command"
@EMJB How do you run "webif "web/signal?AGC=" command"
"http://et10000/web/signal?AGC=" on your browser, changing the address as necessary of course.
EMJB
This could be significant.
CH22 bbc sd mux is showing values, but CH28 bbc hd mux shows no signal.
Something is seriously wrong with the arithmetic for that tuner. Someone needs to look at that.
CH 58 is not showing signal because the selected region does not correspond to your mast. If you switch into user defined mode you should be able to tune that mux.
do you want me to produce a version without the additional logging and explanations of my changes?I don't want to accept fixes for broken drivers. But I do appreciate your contribution. :thumbsup:
One of the problems I hit when investigating different tuners was that the different display features appear to use different data, and/or display the available data incorrectly. Using the logic I proposed for DVB-T frequency finder both Si2168 & Si2169 provide sensibly varying values. The Si2169 responds sensibly to the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.snrValue)", but the Si2168 does not and so the "signalQuality = self.frontend.readFrontendData(iFrontendInformatio n.signalQualitydB) is invoked and gives values that appear to be in milliBels - i.e. 30 dB is reported as 3000.
The following SNRdB results from the webif "web/signal?AGC=" command may be of interest (the main figures are averages across 20 samples, and those in brackets are the lowest figures in those samples) :
<----------------- Signal SNR ----------------->
Name Status Tuner A Tuner B Tuner C Tuner D
Si2169 Si2169 Si2169 Si2168
1 PSB1 In Use 340 (334) 301 (301) 340 (340) 31 (31)
2 PSB2 In Use 348 (347) 341 (340) 340 (334) 32 (31)
3 PSB3 In Use 354 (353) 348 (347) 347 (308) 31 (31)
4 COM4 In Use 360 (353) 358 (353) 360 (360) 33 (32)
5 COM5 In Use 360 (360) 343 (340) 341 (340) 33 (33)
6 COM6 In Use 355 (353) 284 (275) 301 (301) 28 (27)
Note that the "HD" mux is being shown apparently correctly, unlike Signal finder where I have seen the same problem as reported by ccs.
It would also appear that the Si2169 reports are in centiBels, as they seem to be a factor of 10 larger than for the Si2168. However as DVB-T frequency finder is only interested in relative levels, that would not affect the results.
EMJBSo we need to look at why Signal finder and OWI produce different outputs for AGC.
For me the values correspond 100%.
How are you testing this?
I thought that the idea was that different chipsets produce different results (but could easily be wrong).
I have a box with 4-different DVB-T2 tuners in....I don't understand your point. All tests are done on the same tuner and compared relatively.
Even if a service is duplicated on Crystal Palace I don’t what a scan of CP frequencies which for me can be unreliable.If you want to be in control of that you need to create your own file manually. No automatic process is going to know what transponder you want to prioritize and why.
Selecting the first MUX it sees with a decent SNR or signal strength is a poor way of selecting the MUXs to scan.The mux selected is the one with the best signal quality. If signal quality is maxed out on both transponders (possibly due to broken drivers) the transponder with the lower frequency is selected.
I suspect (have no proof nor inclination at present to further investigate) there is something that prevents T2 scanning when only one entry for the transmitter in the terrestrial_uk_freeview.xml file hence the reason I added the 3 entries to my custom transponder section.If you can't receive those muxes there is no need for custom transponders.
I have one entry in the .xml file for the MUX with BBC1 and a subsequent scan doesn't find any T2 MUXsWhich .xml file?
I check with a manual scan for a single Predefined Transponder (T2 MUX transmitter channel number). The "system" default is DVB-T and not DVB-T2 and I change it to Auto and check that the MUX is active and I get the expected T2 channels.
If I now go back to ABM and scan I think it now finds all the DVB T and all of the DVB T2 MUXsThis because what you have done is a pre-scan. That negates the need for a custom transponder.
It's maybe when installing a new image the system thinks the tuner configuration is DVB T irrespective of what it says in Tuner Config/Tuner Setup and hence the ABM scan only finding DVB T MUXs and it required going to somewhere else (such as manual scan) to toggle the setting to DVB T2 (or using the custom entry in the terrestrial_uk_freeview.xm to do the same).ABM only requires a tuner to be enabled.
Something is seriously wrong with the arithmetic for that tuner. Someone needs to look at that.
CH 58 is not showing signal because the selected region does not correspond to your mast. If you switch into user defined mode you should be able to tune that mux.… it's CH 28 - which is a valid mux, so there is still something odd happening.
"http://et10000/web/signal?AGC=" on your browser, changing the address as necessary of course.
Thanks, I guess there are lots of these gems hiding somewhere (I've never looked for them, mind.)
The command finds data for all mux's eg -
<e2frontendstatus>
<e2snrdb>373.55 dB</e2snrdb>
<e2snr>100 %</e2snr>
<e2ber>0</e2ber>
<e2acg>0 %</e2acg>
</e2frontendstatus>
Signal finder only finds data for SD mux's, nothing comes up on the HD mux's.
… it's CH 28 - which is a valid mux, so there is still something odd happening.It was a typo.
Signal finder only finds data for SD mux's, nothing comes up on the HD mux's.Signalfinder will open that mux if you enter the correct parameters.
Signalfinder will open that mux if you enter the correct parameters.
If I start at ch 22, and move slowly thru to 60, only the valid sd mux's give any values.
Am I using incorrect parameters, there's only one that needs changing?
If I'm tuned to ch 28, bbc1 hd, signalfinder fires up on ch 28, with nothing showing.
What I guess is happening is the values in terrestrial.xml don't correspond with your mast. In Signalfinder if you switch to user defined transponder and then to T2 it should show signal.
What I guess is happening is the values in terrestrial.xml don't correspond with your mast. In Signalfinder if you switch to user defined transponder and then to T2 it should show signal.
Yes - changing to T2 works.
SD channels work with user defined set to T or auto.
HD channels only work with T2.
If I start at ch 22, and move slowly thru to 60, only the valid sd mux's give any values.
Am I using incorrect parameters, there's only one that needs changing?
If I'm tuned to ch 28, bbc1 hd, signalfinder fires up on ch 28, with nothing showing.
If you are performing this manually as part of a test and have left Menu-> tuner config -> manual scan -> Sytem =DVB-T then you will only pick up SD MUxs when you slowly select each transmitter channel. If you change that setting to Auto or DVB-T2 you should pick up both SD and HD MUXs with a test manual scan.
I don't want to accept fixes for broken drivers. But I do appreciate your contribution. :thumbsup:
My suspicion is that it is frontend.cpp that is the problem, rather than the drivers, and it has a lot of tuner-specific code, but nothing for the Si2168/9. Who is likely to sort out what is wrong and fix it, and what sort of timescale is that going to take?
While I appreciate your position but:
In the short term you will continue to waste time responding to users with problems that my code avoids (e.g. incorrect terrestrial_finder.xml files being reported).
It does seem likely that new tuners will appear and suffer from the same problems, so you are in danger of creating work in the long term for yourself as problems keep arising.
It does seem to be pity to deny people with Si2168/9 tuners a working feature for what a suspect will be a significant time for the sake of a few lines of code that you could remove once the source of the problem has been fixed. N.B. I suspect the TerrestrialScan plug-in suffers from the same problems, so that is not a useful alternative as an interim measure for people with Si2168/9 tuners.
If you really are adamant not to include my fixes to get better data, I suggest the user advice along the lines of my warning message when data is missing, and a log of the tuner type in use, would be useful additions.
EMJB
If you are performing this manually as part of a test and have left Menu-> tuner config -> manual scan -> Sytem =DVB-T then you will only pick up SD MUxs when you slowly select each transmitter channel. If you change that setting to Auto or DVB-T2 you should pick up both SD and HD MUXs with a test manual scan.No, that is not correct. T2 should only select T2 muxes. T should only select T muxes. Auto should select either. Any diversion from this behaviour means the drivers are faulty.
If you really are adamant not to include my fixes to get better data, I suggest the user advice along the lines of my warning message when data is missing, and a log of the tuner type in use, would be useful additions.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.
Who is likely to sort out what is wrong and fix it, and what sort of timescale is that going to take?You're welcome to send a pull request for that. I don't have the STB so I can't test.
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?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.
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.
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 different frequency.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.
0xFFFF just means the tuner is maxed out.
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.
Why does that deserve a warning message for a box with broken drivers? 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
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.
(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
You're welcome to send a pull request for that. I don't have the STB so I can't test.
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
@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/blob/91c902c41255b7552ff9206d0522f3eabd32a5f5/lib/dvb/frontend.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.
. 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.
abu baniaz
27-09-18, 20:53
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.
abu baniaz
27-09-18, 21:05
Please supply the data you want added and it will be added.
@EMJB,
4) A zero value means we don't save the transponder. 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.
No need for an error message.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.
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. 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
So now the plugin is supposed to second guess on a crap tuner that gets flooded when signal is strong?
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
abu baniaz
28-09-18, 19:03
ABM is designed to get details from one mast. ADM is receiving from more than one mast.
No, we don't want the extra work. This is why the frequency finder was created. So people can have usable data independently. So all those post in the other threads to emphasise this have been ignored. Yet again.
Whether we are here or not is irrelevant. People can submit pull requests and they will be merged by whoever is active/has access at that time. I suspect whatever we do or processes are in place, won't be good enough for some people. The frequencies are listed in lamedb file. We even have the T2 xml creator that does it too although in need of a tidy up. Anybody can do it if they want to.
You have your own thread for highlighting inadequacies with ABM.
I will not be responding to your negative posts, I have better things to do.
abu baniaz
28-09-18, 19:04
Thread closed for a week
I am sorry if people think I was being unhelpful in my last post, but I just felt that our approaches are so different as to question the value of my continuing involvement, and it was better to bring the problem out in the open than continuing to waste each other's time. Hopefully the following summary of extracts from earlier in this thread will explain how I reached the those conclusions:
(1) adm started this thread with a report that the DVB-T frequency finder, WHICH IS PART OF ABM, was not working correctly, and in particular using the same value of signal quality for all muxes, and thus picking a mixture of signals from two transmitters rather that the best. Unfortunately:
(a) The only positive response from the ABM team was to suggest (in post 6) the use of the expert-generated transmitter file, and no suggestions were made to identify and eventually fix initial problem of incorrect signal quality values.
(b) Emotive terminology such as "crap hardware" and "second guess" has been used - usually a sign that a thread is going nowhere.
(c) Many of us raised more than one point or question in one post, leading to some of them being overlooked.
(d) The thread was side-tracked by various discussions on the nature of the Freeview system which might impinge on the frequency finder, but not the tuner-specific issues that caused adm's problem
(2) Various unchallenged statements have been made by abu baniaz SEEM to imply that that an expert-generated file via the forum is the only solution to problems such as adm's. These include:
* Post 6: A pointer to a transmitter file for adm's location. It is my understanding that such files can only be generic to the transmitter, and therefore lead to EPG data being displayed for all services from that transmitter, rather than just those that can in fact be received, and that part of frequency finder's role is to identify the latter and prevent the use of the rest.
* Post 9: "We have to manually add the DVB-T2 frequencies for ABM. This is normal."
* Post 56:"You are not going to get one fix for everything plugin without people knowing their mast or supplying data." He goes on to suggest use of other facilities, but as far as I can see they do not generate useful bouquets nor get round the problems of duplicated muxes. Huevos apparently actively endorsed this by thanking him for the post.
* Post 57: "Please supply the data you want added and it will be added", when I think running frequency finder has been suggested as the means of providing that data.
* Post 61: "ABM is designed to get details from one mast. ADM is receiving from more than one mast".
* Other threads repeatedly refer to keeping the transmitter database up to date, when it seems to me frequency finder makes it redundant - at best the database saves a few minutes for what might be an annual task, and at worst it introduces delays of days without Freeview reception while the database is updated after a frequency shuffle.
To the best of my knowledge every television sold in the UK manages to generate LCN-orientated service lists (and EPG data) limited to just those muxes that are actually received without any transmitter-specific data tables or expert intervention under any reasonable Freeview situation. I was under the impression that the frequency finder is intended to allow ABM to do likewise, and my work with adm has indicated that it should do so (I have a few concerns about operation under certain circumstances, but have no reason the believe these cannot be resolved easily if we all work together).
(3) Soon after the thread was started, I started looking at frequency finder in the context of my proposed user guide, and hit a different problem in that frequency finder failed to locate any muxes with no indication of what might be to blame, whereas I could watch programmes from all the muxes with no problem and Signal Finder reported all was apparently OK. When I forced the selection of the same type of tuner as adm had, I saw the same effect that he had seen. After further investigation with additional logging, I produced and posted (No 19) a new version of frequency finder with two major areas of change:
(2a) Change to one line of code and addition of another 6 lines (excluding the logging I added for test purposes) of code to use different measures of signal quality when the original appeared to be invalid. I had tested that the preferred alternative measure is suitable by changing my signal levels and checking the response. This logic seemed to fix the problems for the both types of tuner, and seemed to have a good chance of working for other tuner types that otherwise would show.
Post 30: Huevos responded with "I don't want to accept fixes for broken drivers"
(2b) As the effects of the "tuner problem" are not always obvious (possibly not noticed till large numbers of services are found to be missing) and the process is long at ~ 10 minutes, I felt is was important to warn the user when the logic I had added was not working, and advise him to try an alternative model of tuner if possible. I therefore added some logic to identify when the above changes were not working, and warn the user of the implications and giving him the option to proceed or give up.
* Post 44: I suggest that if my work-round is not incorporated, at least the warnings should be incorporated to avoid new threads such as adm's pending a fix and if further tuners types are found to exhibit similar problems.
* Post 46: Huevos responded that one of my tests for invalid data would be invoked when the signal level was very high, and the tuner "max-out", and asked "Why does that deserve a warning message for a box with broken drivers?"
* Post 58: I pointed out that when signals are at, or close to, the level where distortion causes the signal content to be no longer recognised. Thus if one mux is at this level another may be a bit stronger and so be missed completely, so a warning to the user is a useful feature. I therefore proposed a change to the wording to provide a warning that either signal levels are sufficiently high to potentially lose muxes or that there is a tuner-related problem when this test failed. I should perhaps have asked how otherwise the user could be expected to know he had broken drivers.
* Post 59: Huevos replied with the emotive : "So now the plugin is supposed to second guess on a crap tuner that gets flooded when signal is strong?"
* Post 60: I replied to the effect that the effect of strong signals is a fact of life, not a design deficiency, and that the term "second guess" was hardly a fair description of a very specific criteria based on his assertion of the significance of an 0xFFFF data return.
(The subject of the effects of limiting signals in receivers is a very complex subject and some very weird effects can be created, so avoiding limiting signals is as important as avoiding small ones, but of course much easier).
(4) The process of implementing a fix in OpenVix/Enigma/Linux seems to me to be fraught. If OpenVix/Enigma/Linux was a commercial project there would be specifications defining interfaces between modules, someone responsible for each module, and someone taking overall responsibility to sort out the inevitable ambiguities etc in real-world specifications (for large projects, this process is performed at several levels with a hierarchy of subsytems down to modules). Furthermore responsibilities would be re-allocated as necessary through the lifetime of the product, and the key players would probably know each other and even be co-located. However in this case it seems to me that such interface documentation seems to be often either non-existent or difficult to locate, authors can lose interest or simply disappear, and there is no one with overall responsibility, readily leading to everyone involved blaming someone else. The author of the code which experiences problems is therefore left with the problem of identifying the sources of the problem and negotiating the inclusion of a fix, but in cases such as this he could need an understanding of hardware and related topics such as the potential differences between "SNR" and "signal quality".
In post 44: Having had that sort of overall responsibility on large military projects, my first reaction to a problem such as this would have been to discuss it with the most likely "culprits" (at the next level down). Not knowing who might be the right person to fix the tuner problem nor personal contacts with any likely contenders, I asked "Who is likely to sort out what is wrong and fix it, and what sort of timescale is that going to take?", expecting guidance as to where to raise an "Issue" and hopefully a offer to contact the person(s) likely to implement the fix.
In post 47: Huevos replied "You're welcome to send a pull request for that. I don't have the STB so I can't test", without offering any alternative or indicating an expected timescale
In post 53: I pointed out that I lack the skills and facilities needed to implement and test a fix, and lack of information to avoid creating problems elsewhere.
In post 53 I asked "Would raising an "issue" against OpenVix/frontend.cpp be an appropriate starting point?" to which I have not found a reply.
In post 54 Huevos stated he did not have the hardware to test any solution. He did not suggest a co-operative approach where he provided the code (initially perhaps to provide additional logging) and I tested it - a slow and long-winded process but probably the only hope of producing a fix without the active assistance of the relevant code author.
In post 54: Huevos provided a link to the frontend.cpp (which I already had), but in the absence of extensive comments this only tells me what happens now, not what the author thought should happen, never mind enough information to establish whether the author's intended operation is in error.
In posts 30, 46 & probably others: Huevos pointed to the drivers as being the source of the problem, whereas I suspected that if there is at least part of the problem is in "frontend.cpp". My requests for clarification for the reason for his view (e.g. post 51) seem to have been ignored.
Excuse me if I interpreted those as indicating I am seen as the only route to clearance of the problems for which I had already identified a work-round, am ill equipped to address, have little prospect of help. That sounds like a long-winded way of saying it will never be fixed. Being the eternal optimist, however, I have since raised an "issue" against "frontend.cpp", suggesting that a first step should be a proper definition of the INTENDED outputs based on a series of questions, but as there are two other open issues with no responses dating back to 2011 & 2012 I have little faith in an answer in a reasonable timescale.
(5) Thus my perception of the situation is that we have two versions of frequencyfinder.py:
* The "official" version, with the following limitations:
(a) With some tuner types incorrect results (e.g. no muxes found or missing muxes) are generated with no obvious connection to the type of tuner, and no warnings generated that would help the user avoid the problem or avoid the necessity to start a forum thread such as adm did.
(b) With a subset of those tuners, it fails to locate any muxes under circumstances when a user could reasonably override its logic to get useful results
(c) Missing muxes could be caused by signal limiting in any tuner type, without user warning even though Huevos has indicated that the necessary information to provide a warning is available.
Those problems have been attributed to errors in OpenVix/Enigma/Linux requiring unique fixes for each tuner type, but if that is correct there seems to be no strategy that is ever likely to lead to such fixes, never mind in a reasonable timescale.
* My version, amended as in previous posts, which does not fail with the tuner types tested and should not fail with any of the others exhibiting similar symptoms, and should never lead to incorrect results without a user warning and indication of the action needed to resolve the problem. Specifically where relevant it advises the use of another tuner type if possible, and allows the user to override the logic that otherwise leads to no muxes being found.
I certainly do not claim my version is necessarily perfect, and the detection of the potentially overloading signals with an acceptable "false alarm rate" for the warnings depends on the accuracy of the Huevos statement "0xFFFF just means the tuner is maxed out". It could be a lower limit imposed by "frontend.cpp", for which I have ideas for work-rounds if necessary. However it works for adm and myself, and only more extensive testing arising from its endorsement here is likely find any shortfalls.
Of course it could be that the rather confused nature of this thread has led myself and Huevos to misunderstand each other, and I would be delighted to withdraw my remarks if Huevos:
(1) Disowns all implications that ABM (including frequency finder) should require expert-generated files other than as a palliative while problems in parts of ABM (e.g. frequency finder) are identified and fixed.
(2) Either incorporates a work-round for the "tuner problem", or identifies a way forward to fix the alleged OpenVix/Enigma/Linux problems in a reasonable timescale (say a month?).
(3) Accepts the principle that it would have been better if adm had received a warning that his problem could due to unsupported tuners with advice to try alternative tuners if he had them, and is willing to enter constructive discussions how such warnings can be implemented for all the anticipated conditions that could lead to erroneous ABM results.
(4) Accepts the principle that where the user can usefully override the normal logic based on knowledge such as probability of duplicated muxes, he should be advised of the possible adverse effects but given the chance to do so.
EMJB
The more I think about the tuner problem the more I suspect that there may be no major error in OpenVix/Enigma2/Linux and certainly not an "arithmetic error" as suggested by Huevos in post 54, just a limitation in certain hardware types (supplied by this site sponsor in the case of the Si2169 in case anyone is tempted to start using terms like "crap hardware") and inconsistency how that limitation is reported. If someone could tell me:
(1) What type(s) of tuner do work
(2) Give me an example of the terrestrial_finder.xml file produced with each of those tuners together with identity of the transmitter and approximate range, even if only one transmitter is detectable.
(3) Ideally provide a debug log taken when each of those tuners was tested with multiple transmitters
I might be in a better position to confirm or rule out this hypothesis.
EMJB
abu baniaz
05-10-18, 16:47
AGAIN. Stop linking EPG with bouquets/channel lists. If a service is in your lamedb, whether you can receive it or not, you will have the EPG data that is on the stream.
Raising an issue on Github is making "an announcement of a problem" Someone will have to fix it. Since you have made it your mission to add your comments to every ABM thread, there really is no point in raising the issue. We have made a post that you have decided to ignore because it does not fit your agenda as to why we cannot do anything.
There are no timescale. Nobody is paid for what we do, we are hobbyists.
If you want an image built with a modified cpp file, attach it IN YOUR THREAD and we can make a test image for you. Birdman is the only one who has an environment to make cpp changes to enigma2 binary without building an image. maybe he can assist if you don't want an image to be made.
You were meant to continue in your own thread. Link is here
https://www.world-of-satellite.com/showthread.php?59860-ABM-Frequency-Finder-Niggles
AGAIN. Stop linking EPG with bouquets/channel lists.
I did not say they were the same thing, I said they suffer from the same problem of referring to services that are not available.
If a service is in your lamedb, whether you can receive it or not, you will have the EPG data that is on the stream. Exactly and without running frequency finder ABM will insert "invisible" services into the lamedb file.
Raising an issue on Github is making "an announcement of a problem" Someone will have to fix it. Tell that to the person who raised an issue in 2011 and apparently has had no reaction never mind a fix! As you point out below, we are hobbyists so no one has to fix anything.
Since you have made it your mission to add your comments to every ABM thread, there really is no point in raising the issue. We have made a post that you have decided to ignore because it does not fit your agenda as to why we cannot do anything. I have no idea what you issue are talking about. As far as I am aware there is nothing you cannot do anything about, there are just things you don't want to do, and confusing statements such as "We have to manually add the DVB-T2 frequencies for ABM" when frequency finder does that.
There are no timescale. Nobody is paid for what we do, we are hobbyists. I raised the issue of timescales as I would expect them to affect the decision as to whether to implement a work-round. Clearly if a pukka fix is imminent then implementing a work-round does not make sense, but if it is years away the then implementing the work-round does make sense.
If you want an image built with a modified cpp file,..... Firstly, may I make the point that I don't WANT to do any such thing - it was Huevos who said "I don't want to accept fixes for broken drivers" as a reason for not implementing a work-round. There seems to be an assumption that I will pursue this, but first I would need to establish whether a fix is required, and if so where a fix needs to be applied, and I await Huevos's reasons for blaming the drivers and a response to post 64. I have merely postulated the cpp file as an alternative. Talk of implementing change to a specific file is therefore premature.
You were meant to continue in your own thread. The problems we are talking about here are certainly not "niggles" - they relate to how adm's problem can be resolved, and your apparent expectations that I am going to fix a problem affecting ABM.
EMJB
abu baniaz
05-10-18, 19:57
As we have the correct frequencies oin ABM for Bluebell Hill, this thread is now resolved and closed.
If you don't want to fix anything, why are you posting? We are not employed by you or your servants.
abu baniaz
05-10-18, 20:10
For any people who want to assist/contribute, please do not raise issues in Enigma2 image teams on GitHub if that team is no longer active or indeed defunct.
Birdman is the only one who has an environment to make cpp changes to enigma2 binary without building an image.Not really the case, as all I have is the standard build environment.
What I do have is the time and ability to hack together a few commands to achieve a specific end.
just a limitation in certain hardware types (supplied by this site sponsor in the case of the Si2169 in case anyone is tempted to start using terms like "crap hardware") and inconsistency how that limitation is reported. If someone could tell me:
(1) What type(s) of tuner do workMany do. As I said, I have four different ones in the same box, but haven't had any time to do any tests ion the last few weeks. (Mind you, one of those has been called "broken", as it has two frontends, despite that being how the DVB API is supposed to work - in my case you want to use the second one).
Part of the issue is that there appears to be no standard for how a tuner reports S/N or quality. Each one will return a number within a specific range and it's up to the caller (Vix code in frontend.cpp) to normalize it. So the frontend.cpp code has different conversions hardwired for some chipsets and a default, but that default may not be correct for all new chipsets. e.g. the driver for the mn88473 chipset (the drivers are in the Linux kernel - not OpenVix) originally got the result one way, but now gets it another (uses different chipset registers) but I can't track down why it ever changed.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.