Page 5 of 5 FirstFirst ... 345
Results 61 to 70 of 70
  1. #61
    Moderator abu baniaz's Avatar

    Join Date
    Sep 2010
    Location
    East London
    Posts
    18,009
    Thanks
    4,777
    Thanked 7,048 Times in 4,758 Posts
    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.

  2. #62
    Moderator abu baniaz's Avatar

    Join Date
    Sep 2010
    Location
    East London
    Posts
    18,009
    Thanks
    4,777
    Thanked 7,048 Times in 4,758 Posts
    Thread closed for a week

  3. The Following User Says Thank You to abu baniaz For This Useful Post:

    Andy_Hazza (28-09-18)

  4. #63
    Forum Supporter
    Donated Member


    Join Date
    Dec 2014
    Posts
    150
    Thanks
    30
    Thanked 8 Times in 6 Posts
    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
    Xtrend Xt10000 with 3 Freeview tuners

  5. #64
    Forum Supporter
    Donated Member


    Join Date
    Dec 2014
    Posts
    150
    Thanks
    30
    Thanked 8 Times in 6 Posts
    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
    Xtrend Xt10000 with 3 Freeview tuners

  6. #65
    Moderator abu baniaz's Avatar

    Join Date
    Sep 2010
    Location
    East London
    Posts
    18,009
    Thanks
    4,777
    Thanked 7,048 Times in 4,758 Posts
    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/s...Finder-Niggles

  7. The Following User Says Thank You to abu baniaz For This Useful Post:

    Sicilian (05-10-18)

  8. #66
    Forum Supporter
    Donated Member


    Join Date
    Dec 2014
    Posts
    150
    Thanks
    30
    Thanked 8 Times in 6 Posts
    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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.

    Quote Originally Posted by abu baniaz View Post
    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
    Xtrend Xt10000 with 3 Freeview tuners

  9. #67
    Moderator abu baniaz's Avatar

    Join Date
    Sep 2010
    Location
    East London
    Posts
    18,009
    Thanks
    4,777
    Thanked 7,048 Times in 4,758 Posts
    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.

  10. #68
    Moderator abu baniaz's Avatar

    Join Date
    Sep 2010
    Location
    East London
    Posts
    18,009
    Thanks
    4,777
    Thanked 7,048 Times in 4,758 Posts
    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.

  11. #69
    ViX Beta Tester birdman's Avatar

    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    4,955
    Thanks
    111
    Thanked 1,056 Times in 845 Posts
    Quote Originally Posted by abu baniaz View Post
    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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  12. The Following User Says Thank You to birdman For This Useful Post:

    abu baniaz (05-10-18)

  13. #70
    ViX Beta Tester birdman's Avatar

    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    4,955
    Thanks
    111
    Thanked 1,056 Times in 845 Posts
    Quote Originally Posted by EMJB View Post
    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
    Many 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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  14. The Following User Says Thank You to birdman For This Useful Post:

    EMJB (06-10-18)

Page 5 of 5 FirstFirst ... 345

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.