Updating the issue tracker - part 1

[prl]

Now that (I hope) the alpha testing of the large set of merges from upstream sources is getting close to being finished, I've started going through the outstanding issues in the issue tracker to weed out entries that no longer seem to be correct (i.e. fixed or implemented), or where I think they may need some further review.

This post covers what's currently in the last 3 of six pages of issues in the issue tracker "Open" list, issue numbers #337 and less.

Fixed or implemented:

• #11: Skip the network configuration screen in setup wizard
  #150: "Setup complete" and other message problems in setup wizard
  #187: Parental Control inappropriate for Australian use Largely fixed in upstream merge, but needs description of new, lesser, problems. Also see: #535: [ParentalControlSetup] Entering correct PIN gives error popup for non-error message. Australia-specific issues addressed in fix submitted for #548. Fix submitted for protected ".xxx" directory problem #534. Fix submitted for #535. IanSav to generate new issue to address remaining Parental Control screen problems.
  #241: Exiting from unchanged AutoTimer screens gives a "Really close...?" message
  #249: Time/Date Input in EPG does not always jump to specified time or date
  #295: Backup settings does not save Weather plugin settings
  #311: Using MENU>TV/Radio while playing recording places UI in inconsistent state
  #320: REC, "Timeshift save recording (stop after current event)" doesn't always save timeshift on zap
  #335: Removing WiFi dongle while in screen under Network Adapter Selection causes crash on screen exit
  #336: In several EPG styles "Sort EPG list" (long RED Button) does nothing
  #337: Help and implementation of "Skip forward/back (enter time)" confusing

Status unknown/can't test:

• #137: MKV playback leads to oom-killer
  #230: WiFi scanner display removes access points with existing SSID names Not fixed. Keep open.

Needs better replication information:

• #174: Graphical EPG highlights active timers, but does not offer to allow you to change them

Need discussion about whether they should remain:

• #205: Skin extension to allow for a control block Keep open. IanSav to revise.
  #206: Allow keymap definitions in the screen XML files Keep open. IanSav to revise.
  #213: Reversion! Mute icon no longer in top right corner Close?
  #275: Allow HELP screen information definitions in the screen XML files Close.
  #279: Add ability to specify colours and pixmaps by name in skin templates Keep open? It may be useful in the long term.

More detailed review needed:

• #231: The GUI does not honour itemHeight specifications in menus Close.

I'll mark all the items listed in "Fixed or implemented" as "resolved" in a week or so, unless there are objections. I think the others just need to be looked at and discussed before deciding whether they should stay as-is, need to be revised, or be marked as something other than "New/Open".

[IanSav]

Hi Prl,

Issue #187 is still a problem. In fact after the the OpenViX merges the UI is now quite broken. I will provide more details when I get a chance. This item should not be closed.

I still support the proposals listed in wishes #205 and #206. I would like these items to be retained.

Issue #230 is still a problem.

As I am now able to fix GUI issues as I discover them I am happy for the original problem report in issue #231 to be closed.

Issue #275 has been mostly addressed by your extensive work on fixing and enhancing the HELP system. The only element that could still be useful would be the ability to move and / or redefine the help text strings out of the Python code and into the skin as discussed in the issue text. Again, given your efforts in improving the language of the help system the justification for this request is considerably reduced.

Regards,
Ian.

[prl]

... Issue #187 is still a problem. In fact after the the OpenViX merges the UI is now quite broken. I will provide more details when I get a chance. This item should not be closed.

What are the remaining problems in the parental control over classifications under "Protect services", apart from the minor issues about the labels used for classification (3+, 4+, etc vs C, G, PG etc) and perhaps the name of the option? And #535.

I still support the proposals listed in wishes #205 and #206. I would like these items to be retained.

There is already an implementation for skin-relative spinners (getConfigCurrentSpinner() in main/enigma.cpp), though it's more restrictive than what's proposed in #205, and different again from what's done in the OverlayHD plugin to implement user choice of spinners. I also don't think that allowing multiple spinners in a single directory is necessary, but I don't have any particular objection to it, either.

Personally, I think that #205 and #206 would add to the difficulty in assisting users with problems since it would mean that it would be harder to work out what is supposed to happen in a context where, say, a user presses RED and something unexpected happens. That's now not only context-dependent, but also skin-dependent.

I'd like to see clearer motivation for them, and a better description of how they are to function.

#205 needs correction about "~/" being skin-relative. It's not. Where it's used (which is rarely in the Beyonwiz "official" skins, and as far as I can see, always incorrectly), it's relative to the "skin_path" attribute of the current skin screen. Plain relative paths with SCOPE_ACTIVE_SKIN are first checked against /etc/enigma2, then the current skin path, and then against /usr/share/enigma2/skin_default, then against /usr/share/enigma2. That means that they're skin-relative unless over-ridden by skin files in /etc/enigma2, and have fallback lookups in the two default areas if they're missing in the current skin.

In #206, there's an important element missing from the proposed
<key id="KEY_NEXT" mapto="deleteForward" flags="mr" />
form, in that keymap entries exist in a context (which is supplied by the surrounding <map context="..."/> element). It's not clear how a skin screen <key/> element would interact with that. The context is an important part of how individual keys are bound to ActionMaps.

I definitely agree that if #205 and #206 (and #275) are to be implemented, they (also) need to be implemented upstream.

Issue #230 is still a problem.

As I am now able to fix GUI issues as I discover them I am happy for the original problem report in issue #231 to be closed.

OK.

Issue #275 has been mostly addressed by your extensive work on fixing and enhancing the HELP system. The only element that could still be useful would be the ability to move and / or redefine the help text strings out of the Python code and into the skin as discussed in the issue text. Again, given your efforts in improving the language of the help system the justification for this request is considerably reduced.
...

I don't understand the motivation of #275, apart from as a response to #205/#206, which would, I think, make something like #275 unavoidable. But otherwise, if my improvements to the help system removed most of the need for #275, it seems that #275 mostly served to paper over code problems that were perhaps better addressed by fixing the code.

#275 also assumes that keys always have constant help text. That's not the case. In any help screen, any help entry that's marked with a "(C)" (for "configurable") has help text that's generated by calling a function (well, by calling a "callable", which is a bit more general).

Even though it's been marked as "resolved", I still regard #301: Help menu in main screen errors as a continuing project (that I haven't worked on for some time).

[IanSav]

Hi Prl,

For issue #187:

1. The first option on entering "Parental control" is "Enable parental protection" but there are no settings shown on the right.
2. As noted, the icon on the message box for a successful PIN change is incorrect.
3. The "Change PIN" option has no listed options shown on the right (probably appropriate) and no instructional text in the help box to tell the user what to do.
4. None of the settings have any help text.
5. As noted, the age settings and prompt need to be localised.
6. The change PIN option should be last in the list.

This screen is based on a cut and paste of code from "Setup.py". I am currently refactoring a number of screens, including this one, to become sub classes of "Setup". Perhaps this code should only receive minimal fixes to overcome the issues in 1, 2 and 5 until I can get a fuller rework accepted.

For #205 and #206:

• I accept that support could be made more difficult by allowing skin defined settings. Perhaps the fact that some of these options are used could be reported in the various logs.
• The section on skin relative is incorrect and was written a very long time ago. OverlayHD has long since been updated to properly access skin relative components.
• The short comings you highlight for #206 are accepted. Perhaps the wish is impracticable it definitely needs more thought .
• I agree that this change is quite structural and needs to be in more than just the Beyonwiz build.
• At the moment there are far bigger fish to fry. These wishes are low priority and can wait.

For #275 my intent was to move more of the text out of the code and into a text/XML file that can be maintained without needing to modify the source code. This request was created quite a while ago. The issue of variable help content based on the code and settings was not apparent when this item was created.

Given your ongoing efforts with the help system I think this wish can be closed for now. If any elements remain they can be raised when your efforts are complete.

Regards,
Ian.

[prl]

...
For issue #187:

1. The first option on entering "Parental control" is "Enable parental protection" but there are no settings shown on the right.
2. As noted, the icon on the message box for a successful PIN change is incorrect.
3. The "Change PIN" option has no listed options shown on the right (probably appropriate) and no instructional text in the help box to tell the user what to do.
4. None of the settings have any help text.
5. As noted, the age settings and prompt need to be localised.
6. The change PIN option should be last in the list.

This screen is based on a cut and paste of code from "Setup.py". I am currently refactoring a number of screens, including this one, to become sub classes of "Setup". Perhaps this code should only receive minimal fixes to overcome the issues in 1, 2 and 5 until I can get a fuller rework accepted.

I have fixes to 2 and 5 (and also #534*) ready to commit. I'll probably generate a pull request this afternoon. I mostly agree about the rest, though I think that all 1 needs is supporting description text. I'll leave the rest, since you intend to look at them. Perhaps I could close #187 and you could do a new issue for the remaining problems (since #187 refers to the feature not existing at all) and/or an issue to cover the refactor of the various screens to use Setup.

For #205 and #206:

• I accept that support could be made more difficult by allowing skin defined settings. Perhaps the fact that some of these options are used could be reported in the various logs.
• The section on skin relative is incorrect and was written a very long time ago. OverlayHD has long since been updated to properly access skin relative components.
• The short comings you highlight for #206 are accepted. Perhaps the wish is impracticable it definitely needs more thought .
• I agree that this change is quite structural and needs to be in more than just the Beyonwiz build.
• At the moment there are far bigger fish to fry. These wishes are low priority and can wait.

For #275 my intent was to move more of the text out of the code and into a text/XML file that can be maintained without needing to modify the source code. This request was created quite a while ago. The issue of variable help content based on the code and settings was not apparent when this item was created.

Given your ongoing efforts with the help system I think this wish can be closed for now. If any elements remain they can be raised when your efforts are complete.
...

OK. I'll close #275 and leave #205 and #206 open. It may be useful for you to revise them at some stage.

* referring to the issue tracker discussion in #534, I have made the exception to PIN control on entering Trash folders to make the test more explicit.
That is, to not use
name.startswith(".Trash")
but be a bit more flexible than
name == ".Trash".

The test is currently
name not in (".Trash", ".trash", ".Trashcan")

[prl]

Is anyone able to test #137? Peteru?

[peteru]

Is anyone able to test #137? Peteru?

I'll give it another shot when I can.

[prl]

Is anyone able to test #137? Peteru?

I'll give it another shot when I can.

Thanks.

I'll start checking off the agreed "fixed" items in the next few days.

[prl]

I've closed (as resolved) all of the agreed fixed problems that I'm able to. However, I don't have the ability to close issues I didn't create.

Could either the issue author or peteru mark the following issues as resolved (or will not fix, in the case of #213):

Submitted by peteru: #11

Submitted by IanSav: #187, #249, #231, #275

Submitted by IanB: #213

[IanSav]

Hi Prl,

Submitted by IanSav: #11, #187, #249, #213, #275

#11 and #213 are not mine.

#187, #249 and #275 and a few others are now flagged as Resolved or Closed.

Regards,
Ian.

[prl]

Hi Prl,

Submitted by IanSav: #11, #187, #249, #213, #275

#11 and #213 are not mine.

#187, #249 and #275 and a few others are now flagged as Resolved or Closed.

Regards,
Ian.

Quite right. Thanks. #11 is from peteru, and I had the "ownership" of #213 and #231 reversed. You've already marked #231 as fixed.

I've fixed my original post.

Thanks for fixing the others.

[IanSav]

Hi Prl,

No problems.

Thanks for taking on the clean up task.

Regards,
Ian.

[prl]

Thanks.

It makes it a bit easier to look for what to fix next if there isn't a clutter of stuff that's already fixed

[IanSav]

Hi Prl,

Is #241 (Exiting from unchanged AutoTimer screens gives a "Really close...?" message) really fixed? I just tried it with yesterday's firmware and it is still broken. I haven't installed today's update yet.

Regards,
Ian.

[Grumpy_Geoff]

Hi Prl,

Is #241 (Exiting from unchanged AutoTimer screens gives a "Really close...?" message) really fixed? I just tried it with yesterday's firmware and it is still broken. I haven't installed today's update yet.

Regards,
Ian.

I guess you were adding one from the Graphical EPG?
From the issue -
"Reproduction steps
Create an Autotimer or have an existing one, then go to MENU>Autotimer, navigate to a timer, press OK, then press EXIT or RED Cancel without making any changes. An incorrect "Really close...?" popup appears.
Go to the Graphical EPG, navigate to a program, press BLUE Add AutoTimer, then press RED Cancel without making changes. You also get the "Really close...?" popup."

Fixed for the first step, but not for the second.

[IanSav]

Hi Geoff,

I just used Live TV > MENU > AutoTimer > MENU > 6 Setup > EXIT and received the alert. I am sure that this was working not all that long ago.

I just updated my T3 and the issue is still there.

Regards,
Ian.

[Grumpy_Geoff]

Hi Geoff,

I just used Live TV > MENU > AutoTimer > MENU > 6 Setup > EXIT and received the alert. I am sure that this was working not all that long ago.

I just updated my T3 and the issue is still there.

Regards,
Ian.

Weird.
I don't get the alert if I do the same (or via Live TV > BLUE > 3 AutoTimer ...)

[prl]

... I just used Live TV > MENU > AutoTimer > MENU > 6 Setup > EXIT and received the alert. I am sure that this was working not all that long ago. ...

That's a bug, for sure, and I can confirm it, but it's not #241.

[prl]

...
I guess you were adding one from the Graphical EPG?
From the issue -
"Reproduction steps
Create an Autotimer or have an existing one, then go to MENU>Autotimer, navigate to a timer, press OK, then press EXIT or RED Cancel without making any changes. An incorrect "Really close...?" popup appears.
Go to the Graphical EPG, navigate to a program, press BLUE Add AutoTimer, then press RED Cancel without making changes. You also get the "Really close...?" popup."

Fixed for the first step, but not for the second.

I agree. I've re-opened #241 with a note that it's partially fixed.

[IanSav]

Hi Prl,

... I just used Live TV > MENU > AutoTimer > MENU > 6 Setup > EXIT and received the alert. I am sure that this was working not all that long ago. ...

That's a bug, for sure, and I can confirm it, but it's not #241.

Sorry, I am doing so much at once. I am looking at AutoTimer for the OpenWebif people and saw the bug. I noticed the closed Beyonwiz issue and added 1 and 2 and came up with 4.

(At the moment I am rewriting the AutoTimer Setup screen for OpenWebif and one of the AutoTimer maintainers.)

Regards,
Ian.

[Grumpy_Geoff]

... I just used Live TV > MENU > AutoTimer > MENU > 6 Setup > EXIT and received the alert. I am sure that this was working not all that long ago. ...

That's a bug, for sure, and I can confirm it, but it's not #241.

That's weird, as I said I don't get the alert from -- AutoTimer list > MENU > 6 Setup > EXIT
Yet you and Ian do.

[prl]

I was able to get rid of it. I did MENU>AutoTimer, MENU>Setup, disable Poll automatically, GREEN OK, MENU>Setup, enable Poll automatically, GREEN OK.

Now when I do MENU>AutoTimer, MENU>Setup, EXIT, I don't get the popup. It may have to do with restored settings messing with the "before" state of the setup screen.

I had something similar in MENU>Setup>System>Button settings, and I got rid of it in the same sort of way.

I'm not exactly sure what is going wrong.

[IanSav]

Hi Prl,

Followed the sequence you suggested and I have the same result.

I haven't restored settings on this box since I wiped all my settings and started fresh with the 16.1 builds.

Regards,
Ian.

[prl]

Odd.

[peteru]

One of the recent merges had some changes to do with the stringification of some config values. It's probably a side effect.

I think it would make more sense to open new bugs each time issues like this re-surface. Re-opening the same bug is not useful when it comes to tracking it through git.

[prl]

One of the recent merges had some changes to do with the stringification of some config values. It's probably a side effect.

I think it would make more sense to open new bugs each time issues like this re-surface. Re-opening the same bug is not useful when it comes to tracking it through git.

I re-opened the bug for a reason unrelated to settings. I re-opened it in the interim because it hasn't been fully fixed. I'll create a new bug report that only contains the unfixed part.