Quote Originally Posted by Huevos View Post
That is just not going to happen.
Bearing in mind that the bit you quoted is preceded by "In my opinion there were two ways in which a User Guide could have resolved this issue", I do not understand your response. I was suggesting some thing for inclusion in the user guide - did you think I was suggesting something in the code, or perhaps that you have a veto over the contents of the user guide, or that I am going to get so frustrated with these misunderstandings that I will abandon the whole thing?

Quote Originally Posted by Huevos View Post
Do users create a file on their own box, based on their own location and then think that file is magically going to become available from a remote source?
Again I fear you are looking at it from a programmer's point of viewpoint, and with the very specific knowledge that parts of the provider file are not used. In particular

(1) Update a file is NOT NECESSARILY mean the same thing to me as download a the complete file - it merely implies that at least parts are changed to match the latest version. For example, updating OpenVix via the menu system seems to replace the bits that have changed, not the complete image.

(2) If he thinks about it he will realise some parts are specific to his location, but how does he know all of it is specific to his location? In fact anyone with limited expertise looking at frequency_finder.xml will see elements that are not location specific, and it is only the fact that they are currently ignored that means that those parts of the file do not potentially need updating when Freeview service "shuffles" occur.

It was looking at frequency_finder.xml (without noticing the error in the section info for adults) that set me off investigating this area and finding the message that has caused so much controversy.

Incidentally I have just noticed the name change from "Update config files" to "Update provider files" (or similar - I can't access my PVR to check just now) in the ABM menu - a good move in my opinion in many respects, BUT frequency_finder.xml is a provider file, re-running DVB-T frequency finder appears to be the only way to update it other than by manual file editing, therefore this command logically should re-run DVB-T frequency finder! This illustrates quite clearly the problems (or even impossibility) of choosing 1/2/3 word phrases to describe what are actually quite complex issues, and in my view an important role of a user guide is to incorporate longer explanations where the short phrases can be misconstrued.

EMJB