Migrating to the new timezone settings...

[IanSav]

Hi PeterU,

Would you like me to look at trying to code something to do the transition conversion automatically?

Regards,
Ian.

[peteru]

Sure, if you have some ideas on how to approach this, please start a topic in the developers area and we can discuss the strategy before you go and put in the coding effort.

I suspect that this will be an issue for every distro, not just Beyonwiz. Maybe OpenViX have already started work on something?

[IanSav]

Hi PeterU,

Sure, if you have some ideas on how to approach this, please start a topic in the developers area and we can discuss the strategy before you go and put in the coding effort.

Too late, the code is almost complete. I will start a new topic for the details.

I suspect that this will be an issue for every distro, not just Beyonwiz. Maybe OpenViX have already started work on something?

Nope!

I suddenly noticed that all the times were wrong and that I had been teleported to England. I really don't see this as an issue as it was easy to fix. All that is needed is a note in the release notes to say select "Australia" as the area and then the most appropriate timezone from the list offered.

Regards,
Ian.

[peteru]

I really don't see this as an issue as it was easy to fix. All that is needed is a note in the release notes to say select "Australia" as the area and then the most appropriate timezone from the list offered.

That's probably an OK approach for developers and beta testers. Maybe even for some end users that read release notes. It won't do for the average user who is presented with an on screen message offering to download and install an update. As soon as they reboot, they (may) end up with the wrong time zone without a warning. In the Beyonwiz version, you won't get a very obvious discrepancy because the region default is Australia and Sydney is the default for the region. People in SA and WA are likely to notice, because there will be an obvious difference, but those on the east coast (Qld to be specific) may not even notice for half a year, until DST kicks in. There is another side effect, if the configuration contains a timezone in the old format, it will now be an invalid value.

I'm pretty sure that Jai would not appreciate the extra support workload this would create.

Anyway, it's probably best if I stop discussing the issue in this topic and, if required, we can continue this in a topic dedicated to the issue once you start it.

Oh and thanks for your work on this. The idea here is to give you more information to think about, rather than cast anything negative on your efforts.

[IanSav]

Hi,

Before we start can a moderator please move or copy the appropriate posts from the Merge Fix Request... thread here...

Regards,
Ian.

[Gully]

Before we start can a moderator please move or copy the appropriate posts from the Merge Fix Request... thread here...

I think that's all of them.

[IanSav]

Hi Gully,

Thank you.

Regards,
Ian.

[IanSav]

Hi,

I have attached a proposed python script to be run from the shell that will update the settings file timezone entry.

The program will use the existing timezone setting entry and the tuner location setting to try and work out the new style timezone setting. If there is no timezone setting the built in default is assumed. The program then edits the timezone field if it exists or adds it if it doesn't. The program also creates the new area setting.

The original format, if it exists, looks like:

Code: Select all

config.timezone.val=(GMT+08:00) Perth

The new format will look like:

Code: Select all

config.timezone.area=Australia
config.timezone.val=Perth

The program is currently very chatty to let testers see what is happening. This can all go away for production.

The idea would be to add this code as an Enigma2 startup script that deletes itself after the first run.

What do people think?

Regards,
Ian.

[IanSav]

Hi,

Another way to handle this would be to change the code, for both Beyonwiz and OpenViX, to leave "config.timezone.val" alone and create the new settings "config.timezone.area"and "config.timezone.region" to hold the new values.

In the enigma2 code you then take the following steps:

• Check if the two new settings "config.timezone.area" and "config.timezone.region" exist. If they both exist, skip further processing, we are done.
• If "config.timezone.area" exists but "config.timezone.region" doesn't then copy the value of "config.timezone.val" to "config.timezone.region" and then delete "config.timezone.val". (Validate that "config.timezone.val" does not start with "(".) This handles the bad move of reusing the old setting with new data.
• If "config.timezone.val" exists and starts with "(" then use some of the logic from the previously posted Python script to extract the best guess "config.timezone.area" and "config.timezone.region" and create the settings.
• Finally if none of the above works teleport to England as is currently done.

The benefit of this would be that any backups or plugins that have the old data will automatically be updated any time they are encountered. If the old "config.timezone.val" is left in place then any code that depends on that data will runs as expected. It is advisable that the value of this setting be updated using the new "config.timezone.area" and "config.timezone.region" settings to keep the actual value correct and in sync with the new settings.

Thoughts?

Regards,
Ian.

[peteru]

a proposed python script to be run from the shell that will update the settings file timezone entry.
...
The idea would be to add this code as an Enigma2 startup script that deletes itself after the first run.

That's not going to work if a user restores settings.

I'm not so sure about having a separate program that runs before enigma2 is started. There are pros and cons, but I think in this case there is no compelling reason to have a separate program.

I had a look at your Python implementation and I think it tries to do too much. All that is required for Beyonwiz is to check if config.timezone.val is set. If it is set and contains one of the old style entries, then create config.timezone.area = Australia and replace config.timezone.val with a matching new style entry.

A more generic solution would load the old timezone.xml file and use it to generate a lookup table that can convert any old valid value into the new area/val pair.

Perhaps a generic mechanism for upgrading the config file can be hooked into config.ConfigFile.__init__() or config.Config.loadFromFile()

Your other proposed alternative also seems very complex.

I still can't believe that OpenViX would have adopted these changes without having a sensible upgrade path, but it's difficult to discus this when the developer forums are not accessible.

[prl]

... All that is required for Beyonwiz is to check if config.timezone.val is set. If it is set and contains one of the old style entries, then create config.timezone.area = Australia and replace config.timezone.val with a matching new style entry. ...

That sounds like a clean method to me.

[IanSav]

Hi PeterU,

a proposed python script to be run from the shell that will update the settings file timezone entry.
...
The idea would be to add this code as an Enigma2 startup script that deletes itself after the first run.

That's not going to work if a user restores settings.

The script could be kept active to account for restored settings. I was not happy with this solution which is why I suggested alternatives in my follow up post.

I'm not so sure about having a separate program that runs before enigma2 is started. There are pros and cons, but I think in this case there is no compelling reason to have a separate program.

This was suggested so it could be a very separate Beyonwiz solution that doesn't need to become legacy code.

I had a look at your Python implementation and I think it tries to do too much. All that is required for Beyonwiz is to check if config.timezone.val is set. If it is set and contains one of the old style entries, then create config.timezone.area = Australia and replace config.timezone.val with a matching new style entry.

I felt that if the solution was too general and returned possibly incorrect results it would be shot down. The effort was expended to try and get the best version of the location given that Canberra, Melbourne and Sydney are all clumped in the same legacy setting timezone setting.

A more generic solution would load the old timezone.xml file and use it to generate a lookup table that can convert any old valid value into the new area/val pair.

How would you split the Canberra, Melbourne and Sydney entries? My first cut of the code did this and chose Sydney. I deemed it too course to be acceptable as an automated correction. It is almost as bad as OpenViX teleporting me to England.

Perhaps a generic mechanism for upgrading the config file can be hooked into config.ConfigFile.__init__() or config.Config.loadFromFile()

Your other proposed alternative also seems very complex.

It isn't at all complicated. If the new settings are found do nothing. If the old setting is found convert to the new settings. The logic for improved Australian results can't be used as this will become generic Enigma2 code.

I still can't believe that OpenViX would have adopted these changes without having a sensible upgrade path, but it's difficult to discus this when the developer forums are not accessible.

I am questioning the changes at the moment. So far I am being asked what is wrong with hard coding a new default. I am about to respond to that comment shortly. I will keep this thread updated with any useful information obtained.

Regards,
Ian.

[IanSav]

Hi Prl,

... All that is required for Beyonwiz is to check if config.timezone.val is set. If it is set and contains one of the old style entries, then create config.timezone.area = Australia and replace config.timezone.val with a matching new style entry. ...

That sounds like a clean method to me.

What about the Canberra, Melbourne, Sydney differentiation?

I thought the idea was to find an automated conversion what would minimise issues and user complaints.

Regards,
Ian.

[IanSav]

Hi,

While we are talking about this issue we should explore updating the area and region in the welcome wizard and then using the new region to reduce the tuner location options to a more appropriate subset.

Regards,
Ian.

[prl]

Hi Prl,

... All that is required for Beyonwiz is to check if config.timezone.val is set. If it is set and contains one of the old style entries, then create config.timezone.area = Australia and replace config.timezone.val with a matching new style entry. ...

That sounds like a clean method to me.

What about the Canberra, Melbourne, Sydney differentiation?

I thought the idea was to find an automated conversion what would minimise issues and user complaints.
...

The Canberra and Sydney zoneinfo files are identical. Translating Canberra, Melbourne, Sydney to "NSW/ACT" would simply emphasise the fact that the current time zone selection for Melbourne is wrong (it uses the NSW table).

All the current timezone names except Canberra, Melbourne, Sydney can be converted within the enigma2 code just by doing simple table lookup. Canberra, Melbourne, Sydney can be correctly mapped by looking up the scan location.

Even the FreeTV Operational Practics OP-41 has an each-way bet on the Gold Coast/Northern Rivers region: "Broadcasts for the northern NSW regional market which includes the Gold Coast area in southern Queensland should broadcast a TOT which includes both the NSW/ACT and the Queensland country_region_ids."

If it's implemented inside enigma2, I don't think it needs to be a lot more complicated than something like:

Code: Select all

def fixTimezone():
    if config.timezone.val.value.startswith("(GMT+"):
        def fixCanSydMel():
            locations = []
            eDVBDB.getInstance.readTerrestrials(locations, {})
            location = locations[config.Nims.0.terrestrial.value][0]
            if location == "Geelong":
                location = "Melbourne"
            return (
                "Australia",
                location if location in ("Canberra", "Melbourne", "Sydney") else "Sydney"
            )
        (config.timezone.area, config.timezone.val.value) = {
            "(GMT+08:00) Perth": lambda: ("Australia", Perth"),
            "(GMT+09:30) Adelaide": lambda: ("Australia", Adelaide"),
            "(GMT+09:30) Darwin": lambda: ("Australia", Darwin"),
            "(GMT+10:00) Brisbane": lambda: ("Australia", Brisbane"),
            "(GMT+10:00) Canberra, Melbourne, Sydney": fixCanSydMel,
            "(GMT+10:00) Hobart": lambda: ("Australia", Hobart"),
        }.get(config.timezone.val.value, lambda: ("Australia, "Sydney"))()

[prl]

...
While we are talking about this issue we should explore updating the area and region in the welcome wizard and then using the new region to reduce the tuner location options to a more appropriate subset.
...

I think that's a good idea.

[IanSav]

Hi Prl,

At its core your code is not that different from what I wrote. By staying within Enigma2 you don't need all the file, XML and support processing that is part of my code. I also deliberately made the demonstration code far too chatty to show what was happening. Strip all that away and we are quite close.

I do acknowledge that your code does make most determinations more optimally than my code. I implemented too general a case and processed all the source data raw. I made few assumptions about what I may find in the data. It could all have been hard coded with the real data we know to exist in the Beyonwiz firmware.

I still think there is value in the simple logic of my second proposal. It creates a forward and backward compatible mapping between the old and new timezone formats. That is have three timezone variables. Leave the .val alone as the old style GMT offset style and then have area and region as the new versions. When the timezone is changed by the updated UI then immediately set the area and region and calculate and update the val version.

If the area and region settings are found we are up to date and have nothing to do. If a backup is restored that uses the old system then the area and region values won't be set so the conversion code will need to be run. In my mind it is really appears quite simple.

Regards,
Ian.

[IanSav]

Hi,

I have been posting in the OpenViX developers forum. I am questioning the change and the impact it is having. I have linked to this thread and outlined that the change could have been better implemented.

It is still very early days but I think some of the OpenViX team seem to be coming to realise that changing the timezone settings and not having them in the welcome wizard might have been a mistake.

I will update this thread if there are more updates.

Regards,
Ian.

[peteru]

Most of the above has way too much feature creep. All that is needed is a conversion from the old "name" string to the matching "zone" string as it was defined in timezone.xml

I figured that in the end it's simpler to just implement the conversion rather than spend a lot of effort on discussing what's needed.

I opened a pull request for OpenViX and we'll see how that goes.

[peteru]

I opened a pull request for OpenViX and we'll see how that goes.

Rejected.

I guess OpenViX either don't care about user experience or don't understand the implications of the code changes they implemented. With development team hiding in a closed forum, there's no way to engage them in a constructive conversation either.

Where to next? I guess we keep the upgrade conversion code in Beyonwiz fork and upstream will miss out. I've already expended way more effort than I wanted to, just to make the code generic and push an improvement upstream for all enigma2 users to benefit.

peteru grumbles something about leading horses to water, but not being able to make them drink.

[IanSav]

Hi PeterU,

I haven't given up. I am pursuing the matter in the forum and via Skype.

Regards,
Ian.

[peteru]

The pull request got an additional comment:

we are not adding backwards upgrade to new way, get used to it, just reset your TZ and be done with it.

As far as I am concerned, this is not an approach that would be acceptable for any updates in the 16.1 series.

I'm undecided about what to do next. It looks like the path of least resistance is to stop tracking OpenViX for the 16.1 series. Given the above attitude, trying to keep up with OpenViX is inviting trouble.

[IanSav]

Hi PeterU,

The pull request got an additional comment:

we are not adding backwards upgrade to new way, get used to it, just reset your TZ and be done with it.

As far as I am concerned, this is not an approach that would be acceptable for any updates in the 16.1 series.

I'm undecided about what to do next. It looks like the path of least resistance is to stop tracking OpenViX for the 16.1 series. Given the above attitude, trying to keep up with OpenViX is inviting trouble.

I am in a chat session to the UK at the moment expressing my concerns. So far it is not going well. It seems that they have lost all perspective. The mantra seems to be change the timezone and get over it. When I asked about invalidating all backups and creating issues if the backups are restored the session went quiet. I am awaiting further comment.

(I suspect another chat session with Andy is happening while I wait.)

Regards,
Ian.

[IanSav]

Hi,

Hmmm. I have been put on endless hold. I suspect that may mean "no further correspondence will be entered into". This appears to be a very touchy subject.

I'll stay online in case there is further communication.

Regards,
Ian.

[prl]

It seems an odd position that the OpenViX people are taking.

[IanSav]

Hi Prl,

It seems an odd position that the OpenViX people are taking.

It is quite a contradiction to previous sentiment.

There must be some other agenda of which we are unaware.

Regards,
Ian.

[IanB]

I believe the affliction they are experiencing is called "youth". As they say youth is wasted on the young.

Immature people suffer from tunnel vision when faced with providing legacy support, you see it in Micro$oft products all the time, e.g. every new version of word deliberately hides all the bread and butter useful features and actively promote all the glossy new but often useless features.

Mindsets like "just change the timezone and get over it" is strong evidence of the lack of life experience. Extended exposure to loving grandparents is often an effective cure.

[MrQuade]

Mindsets like "just change the timezone and get over it" is strong evidence of the lack of life experience. Extended exposure to loving grandparents is often an effective cure.

The other factor that springs to mind is the different attitude towards the Enigma2 STBs that the Vix team seems to have.

I recall a couple of years ago, a member of the Vix team joined the Beyonwiz forums to see what was happening down under, and was astonished that we considered the T3 as a STB to sell to mum-and-dad. PeterU rightly made the comment that quite a bit of work had gone into making the T3 easier to set up than the average Enigma2 user was probably used to (helped by the fact that it only has FTA tuners I guess), and this seemed to boggle him coming from Vixland

Changes on the Beyonwiz side tend to think about migration strategies for less-technical users, more so than Vix who probably rely on a more tech-savvy consumer.

[IanSav]

Hi MrQuade,

I recall a couple of years ago, a member of the Vix team joined the Beyonwiz forums to see what was happening down under, and was astonished that we considered the T3 as a STB to sell to mum-and-dad. PeterU rightly made the comment that quite a bit of work had gone into making the T3 easier to set up than the average Enigma2 user was probably used to (helped by the fact that it only has FTA tuners I guess), and this seemed to boggle him coming from Vixland

I don't believe he was a developer. From memory he was a tester. Huevos came here for a while. He is a developer and from my contact with him he tries to write quality code with users in mind.

Changes on the Beyonwiz side tend to think about migration strategies for less-technical users, more so than Vix who probably rely on a more tech-savvy consumer.

Normally I would not agree with you but this recent action has taken me by total surprise. I never saw it coming.

Regards,
Ian.

[MrQuade]

with users in mind.

What *sort* of user was my point.

[Huevos]

I guess OpenViX either don't care about user experience or don't understand the implications of the code changes they implemented.

Of course we understand. We will just push a message on update (via SoftwareUpdate.py) that they may need to reset their timezone.

[IanSav]

Hi Guys,

I have been chatting to Huevos and he has explained that OpenViX has a very nifty feature that allows the feed server send messages to the user's screen during updates. This is how the new timezone system will be introduced to OpenViX users when it goes into production.

That code has all been stripped or never included in the Beyonwiz versions of the online software update code.

With the OpenViX users aware that the timezone code has changed it was felt that no other protection or automatic conversion was required.

I have been asked if I would like to modify the welcome wizard to ask users to set the timezone on first load. (I made some changes to the welcome wizard screen position system for OpenViX previously.) I will have a look trying to add the timezone UIs for OpenViX and Beyonwiz. No promises at this stage.

There are options and difficulties with this as there are two ways to proceed:

• On OpenViX the RED button is always available and is used to set the language. I was thinking to simply add the GREEN button to set the timezone. This is fine for OpenViX but Beyonwiz has removed the on screen indication that this code also works on the Beyonwiz.
• The other way is to create and script a new wizard screen. This is much harder but should work on both systems.

I will have a look at the code when I get some time and see how I will proceed if I take up the task.

Would it be okay to restore the colour buttons for the Beyonwiz welcome wizard? On the Beyonwiz the only languages offered are English UK and English US (and, if you have my patches, English AU).

Regards,
Ian.