Improving the built-in EPG Search and single-channel EPG skins

[prl]

At the moment in the built-in skins, the event information panel at the bottom of the EPG search and single-channel EPG screens shows the long description for a program if the long description is set, and the short description if it isn't. This means that for IceTV, for example, which uses the short description for the episode name and the long description for the program synopsis, only the program synopsis is shown.

OverlayHD shows both the short and long descriptions which works much better.

OverlayHD also puts the program title, star/end times, duration, classification and genre in the event information panel, as well as an icon showing whether it's the IceTV or FTA EPG.

The built-in skins should probably do something similar. I'm only not sure about putting the title there: it takes up a fair bit of room. If people want to have it there, perhaps not in quite so large a font?

[Grumpy_Geoff]

You bewdy - "Display Episode information in SingleEPG"

I don't need the title there, as it's the selected entry in the list

[prl]

You bewdy - "Display Episode information in SingleEPG"

I don't need the title there, as it's the selected entry in the list

That's my feeling, too, but the same could be said of the start/end times.

[Grumpy_Geoff]

That's my feeling, too, but the same could be said of the start/end times.

I was going to mention that, but then thought you were still going to display the other (or some other) entries on the same line in any case.

[IanSav]

Hi Prl,

The program title is there because this is a panel that is shared with other screens.

By the way, rather than fixing the legacy screens we could just make OverlayHD available by default (as the default skin)!

Regards,
Ian.

[prl]

...
The program title is there because this is a panel that is shared with other screens.

I'm aware that it is. I'd regard the way that it's shared as a minor design flaw.

By the way, rather than fixing the legacy screens we could just make OverlayHD available by default (as the default skin)!
...

I'm the wrong person to make the suggestion to. I think that it should be more readily available. Whether that's in the skin plugins section of the plugin downloads, as a built-in skin, or even as the default built-in skin. I still prefer the Full-Metal-Wizard skin, and I'll continue improving the current builtin skins.

De gustibus non est disputandum.

[IanSav]

Hi Prl,

I'm aware that it is. I'd regard the way that it's shared as a minor design flaw.

I would be happy to get feedback and any suggestions for ways to improve *any* aspect of OverlayHD.

Regards,
Ian.

[prl]

Hi Prl,

I'm aware that it is. I'd regard the way that it's shared as a minor design flaw.

I would be happy to get feedback and any suggestions for ways to improve *any* aspect of OverlayHD.

Regards,
Ian.

It's really nothing more than the observation that if you don't always want to have the title in the panel, it shouldn't be in the panel.

I also wonder whether it might be possible to "mask" the height of the panel by using the "size" attribute where the panel is "called", so that you can vary the effective height of the panel depending on the context it's used in. So you might make the list height and the panel's <screen> definition 50 pixels (2 rows) larger, and call the panel say, with <panel ... size="1180,175"> where there's no title and <panel ... size="1180,125>" where a title is placed above the panel to fit in equal-sized pieces of screen real estate for the combined title (if it's there) and details. I hope that makes sense. I have no idea whether it would work as I'd want it to, and even if it does work, it's a horrible misuse .

[IanSav]

Hi Prl,

It's really nothing more than the observation that if you don't always want to have the title in the panel, it shouldn't be in the panel.

From memory this repeat of the title comes in handy when long titles occur. The title in various data lists is often cut short and the panel version is long enough to display more of the title.

I also wonder whether it might be possible to "mask" the height of the panel by using the "size" attribute where the panel is "called", so that you can vary the effective height of the panel depending on the context it's used in. So you might make the list height and the panel's <screen> definition 50 pixels (2 rows) larger, and call the panel say, with <panel ... size="1180,175"> where there's no title and <panel ... size="1180,125>" where a title is placed above the panel to fit in equal-sized pieces of screen real estate for the combined title (if it's there) and details. I hope that makes sense. I have no idea whether it would work as I'd want it to, and even if it does work, it's a horrible misuse .

I haven't had much success in changing panel dimensions in different applications. I sort of had some success by putting panels within panels but that is messy and looked wrong. If you have a small skin fragment that works please let me know and I will look at adopting the approach in a few places.

Regards,
Ian.

[prl]

Posts about the Media Player (wrong screen) in the OverlayHD skin (wrong skin) have been moved to the OverlayHD topic.

[adoxa]

I modified Full Metal Wizard's single-channel EPG to display the full description (at size 23) and show the small rating at the bottom right.

[prl]

I modified Full Metal Wizard's single-channel EPG to display the full description (at size 23) and show the small rating at the bottom right.

I never said it was hard to do. I'm more canvassing what people want.

[prl]

I've submitted a fix to the EPG Search and the single-channel EPG.

For the FTA guide it looks like:

And for IceTV it looks like:

IanSav has also said that I may use his icon set for classifications, and I intend to switch over the short form text versions to the icons wherever it works well, but I'll do that when all the EPG screens have the classification information.

[Grumpy_Geoff]

I'll repeat my opening remark of the 2nd post - "You bewdy".
Thanks.

[prl]

Currently adding the same information + title to the GraphicalEPG(non-PIG) and the Graphical Infobar EPG.

[prl]

Here are some samples of the other changes to the EPG display of event information details:

GraphicalEPG (non-PIG):

Graphical Infobar EPG:

In this Infobar EPG, the event information is only visible when you press INFO, as in the current Infobar Graphics Multi EPG and Text Multi EPG (grid layout).


Single Infobar EPG:

The event information is always visible in the Single Infobar EPG. This is a complete re-write of the skin, based on the Infobar (and using panels from the Infobar skin). I've kept the event info in the enlarged infobar, as in the old version, but it could be moved to the top of the screen. The status icons in this Infobar EPG now work.

I have Full-Metal-Wizard versions of the first two, but because the last one is a lot more complicated to do, and is the one I'm probably least satisfied with, I haven't yet done a Full-Metal-Wizard version version for it yet.

Any suggestions?

[MrQuade]

I do like that extended infobar in the last image!
Does it allow you to press DOWN to see the event info on the next event?

[prl]

I do like that extended infobar in the last image!
Does it allow you to press DOWN to see the event info on the next event?

Of course, and the next, and the next: it's the Infobar EPG. It just shares a lot of peripheral elements and some layout with the infobar. You can even change the number of rows in the EPG list (as you can in the current implementation).

I've been thinking of making the list display wider: there's plenty of room. It's currently the same width as the progress bar/event name & duration panel in the iinfobar, but It could easily use more of the available space.

[prl]

Single infobar EPG with wider progress bar and list (and for MrQuade, showing how the display looks with an extra row in the list and something other than the current event in focus):

[MrQuade]

and for MrQuade

Heh thanks. Sorry for mistaking it earlier. I had thought that this was some sort of inforbar replacement prior to your earlier reply. It threw me off since this is a radical consistency improvement of the existing Infobar Single EPG

[prl]

And now, duration, rating and genre added to the Graphical EPG PIG and the Multi EPG. There isn't enough room in the Graphical EPG PIG for the full rating name, so you just get PG/M/MA...

[prl]

...
Heh thanks. Sorry for mistaking it earlier. I had thought that this was some sort of inforbar replacement prior to your earlier reply. It threw me off since this is a radical consistency improvement of the existing Infobar Single EPG

That's the intention. The old one was a pretty much unmodified copy/paste from the default skin.

[prl]

I'm about to start changing the short-form rating information G/PG/M/MA... to use pixmaps of the normal classification logos.

Where there's currently enough room for both the short form and the long form, I intend to make it icon longname, like <PG icon> Parental Guidance Recommended.

Where there's currently only the short form I'm considering to do it as icon shortname, because the icons are small (40x20 pixels), and their body colours contain all the main colour blindness colours: red, green, yellow and blue.

So something like:

Thanks to IanSav for allowing the use of the ratings icons he made for the OverlayHD skin.

[prl]

I've submitted all the improvements to the EPG event information that I've outlined in this topic except the use of the ratings icons in a single pull request.

I'll put the ratings icons updates in a separate pull request. They're different enough to warrant a separate submission, and there are some bugs in the Service/Event source|EventName:RatingIcon | ValueToPixmap:Path | Pixmap render chain that prevent the rating icon from being cleared if you move from an EPG item that has a ratings picon to a channel that has no EPG (like SBN or Aspire in Canberra FTA EPG, or if the FTA EPG has been cleared and isn't yet fully loaded).

That bug is in the code, not in the skin, so its effect should be visible in OverlayHD, but it's not one you'd encounter often.

[IanSav]

Hi Prl,

I'll put the ratings icons updates in a separate pull request. They're different enough to warrant a separate submission, and there are some bugs in the Service/Event source|EventName:RatingIcon | ValueToPixmap:Path | Pixmap render chain that prevent the rating icon from being cleared if you move from an EPG item that has a ratings picon to a channel that has no EPG (like SBN or Aspire in Canberra FTA EPG, or if the FTA EPG has been cleared and isn't yet fully loaded).

That bug is in the code, not in the skin, so its effect should be visible in OverlayHD, but it's not one you'd encounter often.

I rarely have blank entries in the EPG but I think I may have seen this issue. When I last saw it I was busy and never got around to investigating. I welcome any fix you can provide.

Regards,
Ian.

[prl]

I'll write it up in the issue logger. I don't think it's terribly hard to fix.

[prl]

I'll write it up in the issue logger. I don't think it's terribly hard to fix.

Bug #627: Incorrect ratings icons sometimes displayed

I've submitted the addition of ratings icons to the EPGs, Event Viewer, Media Player and Channel Selection screen in the pre-loaded skins.

I am testing a fix for #627. I'll try to submit it upstream to OpenVix (the fix for #267 also fixes a bug in Components.Converter.ValueToPixmap that could cause a crash), but as far as I can tell, the default OpenViX skins don't use ValueToPixmap. The underlying cause of the problem is in Components.Renderer.Pixmap, which doesn't update on CHANGED_CLEAR.

Thanks to IanSav for allowing the use of the OverlayHD ratings icons in these skins.

[IanSav]

Hi Prl,

Thanks to IanSav for allowing the use of the OverlayHD ratings icons in these skins.

Thank you for fixing the code bugs behind the incorrect icon issue.

If you would like a tester for the code change please let me know.

Regards,
Ian.

[prl]

Thanks for the offer. I'll post a patch here tomorrow.

[prl]

Hi, Ian.

Here are the update installer and uninstaller. Usual installation instructions and warnings about online updates while running patched firmware apply.

I've tested the patch on 20180310 with OverlayHD 1.64, but neither version should be critical. The changes are to files that haven't been modified for a long time (2014 for one, 2011 for the other).

For anyone else who'd like to try it, the bug it fixes is currently only visible in OverlayHD, because only OverlayHD currently makes use of the broken code. If you don't know how to do the installation or what the "usual warnings" are, it's probably best not to install it.

The link to the bug report that contains replication steps to see the bug is a few posts up topic.

The name of the patch ZIP and directory is a bit off, because I've been using the same patch generator setup to test a number of changes to the pre-loaded skins.

[IanSav]

Hi Prl,

The fix appears to be working well. Would you like me to test the changes on OpenViX as well?

Regards,
Ian.

[dRdoS7]

Hi,

Here are the update installer and uninstaller. Usual installation instructions and warnings about online updates while running patched firmware apply.

I've tested the patch on 20180310 with OverlayHD 1.64, but neither version should be critical. The changes are to files that haven't been modified for a long time (2014 for one, 2011 for the other).

For anyone else who'd like to try it, the bug it fixes is currently only visible in OverlayHD, because only OverlayHD currently makes use of the broken code. If you don't know how to do the installation or what the "usual warnings" are, it's probably best not to install it.

No more orphan ratings icons!

Also, no crashes.

Tested on 20180216 FW & 1.64 OHD.

Thanks,

dRdoS7

[prl]

Hi Prl,

The fix appears to be working well. Would you like me to test the changes on OpenViX as well?
...

Thanks, Ian, dRdoS7.

Ian, do you know of any OpenViX skin that uses them? Neither ViX-Night-HD/skin.xml and the skin files in ViX-Common that it uses, nor the skin_default.xml use the Event/EventInfo > EventName:RatingIcon > ValueToPixmap:Path > Pixmap source/convert/render chain that causes this problem in the Beyonwiz skin elements that use ratings icons. The key part of the fix is in the Pixmap converter, so it's possible that the error may come up somewhere in OpenViX, but you'd have to dig for it unless you find a skin that uses that uses that kind of widget and that also triggers the bug.

The Beyonwiz patch installer/uninstaller should work on OpenViX, though, but I haven't yet tried them.

[IanSav]

Hi Prl,

The EventName:RatingIcon is an item of my creation so this will probably be unused elsewhere (yet). I will ask Rob to see if he has used it yet or knows of anyone who has.

Rob may also know if ValueToPixmap is in active use for anything else.

EDIT: Question asked,waiting for Rob to wake.

Regards,
Ian.

[prl]

Hi Prl,

The EventName:RatingIcon is an item of my creation so this will probably be unused elsewhere (yet). I will ask Rob to see if he has used it yet or knows of anyone who has.

Rob may also know if ValueToPixmap is in active use for anything else.

EDIT: Question asked,waiting for Rob to wake.
...

The ValueToPixmap converter isn't used in any of those OpenViX skins, in any context. While the bug isn't in ValueToPixmap, it's indicative of the sort of source/render/convert chain that might trigger the bug.

[IanSav]

Hi Prl,

I haven't heard from Rob yet but my testing of the fix with OverlayHD on OpenViX has gone well.

Regards,
Ian.

[IanSav]

Hi Prl,

Rob doesn't remember seeing ValueToPixmap used anywhere but this is not something that would attract his attention. I would submit the correction and see what happens.

Regards,
Ian.

[prl]

OK. Thanks.

I'll try to submit the changes to both tomorrow.

[prl]

Well, the day after...

I've submitted the fix to the Pixmap renderer that fixes the "hanging" ratings icon display to both the Beyonwix and OpenVix repositories.

I've also submitted a simple fix to a potentially fatal, but unlikely to be triggered, bug in the ValueToPixmap converter to both repositories.

[prl]

Well, the day after...

I've submitted the fix to the Pixmap renderer that fixes the "hanging" ratings icon display to both the Beyonwix and OpenVix repositories.

I've also submitted a simple fix to a potentially fatal, but unlikely to be triggered, bug in the ValueToPixmap converter to both repositories.

Those fixes have been merged into the OpenViX repositories.

[IanSav]

Hi Prl,

I don't think they were merged. There was a small problem with the submissions. (The pull requests were made to the master branch and not the dev branch so they were closed with a request to resubmit them.)\

Regards,
Ian.

[IanSav]

Hi Prl,

Your changes to OpenViX have been merged. The code you submitted to OpenViX is different from the code you posted here for testing.

I just upgraded my OpenViX test system and the changed code is NOT working as you intended. The rating image still remains visible when you move to an EPG cell where there is no data. This was working on OpenViX when I applied your original code patch.

Would you also consider making the same changes to OpenPLi? If you don't wish to update OpenPLi then would you mind if I submit the changes and credit you?

Regards,
Ian.

[prl]

...
Your changes to OpenViX have been merged. The code you submitted to OpenViX is different from the code you posted here for testing.

I just upgraded my OpenViX test system and the changed code is NOT working as you intended. The rating image still remains visible when you move to an EPG cell where there is no data. This was working on OpenViX when I applied your original code patch.

I just tested my change in OverlayHD 1.64 on the OpenViX version I have access to (Dev-2017-07-12). It works just as I intended it to. I hadn't previously tested that it worked as intended in OpenViX (didn't think to test it with OverlayHD), only that it didn't have any ill effects.

I changed the way I did it to better align what the CHANGE_CLEAR action appears to be intended to do (unilaterally clear the display item) rather than re-fetching the image from upstream (which in this case should have the same effect - setting the displayed pixmap to None).

Would you also consider making the same changes to OpenPLi? If you don't wish to update OpenPLi then would you mind if I submit the changes and credit you?
...

I'm limited in the amount of time I want to spend keeping up to date with, and updating upstreams. I'm happy for you to submit any of my changes upstream to OpenPLi.

[IanSav]

Hi Prl,

I am running OpenViX 5.1.021.001 (Developer) and OverlayHD 1.64. The OpenViX update was released on 2018-03-16. I am using the image as installed via the update process and the EPG is still showing a rating icon when moving from a populated EPG cell to an empty EPG cell.

Regards,
Ian.

[peteru]

The Beyonwiz repository is just a normal open source git repo, just like all the other repos. It should be trivial for the other maintainers to add the Beyonwiz repository as one of their remotes and cherry-pick useful commits as they see fit. This way there is no need to make multiple submissions. No OpenPLi, OpenViX or OpenATV developer is required to prepare special submissions for Beyonwiz, it should not be required the other way. By all means, sing the praises of your code changes and encourage the maintainers to cherry-pick your commits so they too can benefit. If they run into merge difficulties they can not resolve on their own, help them.

[IanSav]

Hi PeterU,

Does this mean you will now allow me to file pull requests on the Beyonwiz repository so that I can simply point OpenViX and OpenPLi developers here?

What you suggest about getting OpenViX and/or OpenPLi to pull from the Beyonwiz repository is fine in theory but while you do not accept my pull requests in a timely manner the theory breaks down. Further you haven't allowed me to submit my bigger changes here. This means I need to try and update all the other builds in various ways to match many of the Beyonwiz enhancements before the new code can even be tried.

I am currently working on a refactored Setup.py that does everything that the Beyonwiz, OpenViX and OpenPLi Setup.py does and more and it does so between 4 to 50 times faster. Would you consider allowing a direct Beyonwiz pull request?

Regards,
Ian.

[prl]

...
Your changes to OpenViX have been merged. The code you submitted to OpenViX is different from the code you posted here for testing.

I just upgraded my OpenViX test system and the changed code is NOT working as you intended. The rating image still remains visible when you move to an EPG cell where there is no data. This was working on OpenViX when I applied your original code patch.

...

Even if I use the current OpenViX source for all the Python source files involved in ratings icon display in the EPG and ChannelSelection lists where this problem occurred:
Components/Converter/EventName.py
Components/Sources/Event.py
Components/Sources/EventInfo.py
Components/Renderer/Pixmap.py
Components/Converter/ValueToPixmap.py

ratings icon display works as I intended it to. I can't see any obvious differences between the C++ ePixmap class that might explain any change in behaviour. The last change in the OpenViX version of either gui/epixmap.py or .h was in April 2015, so that can't account for the differences in behaviour between my original fix and the newer one.

The only thing I can think of is that the firmware release you're testing doesn't have my update to Renderer/Pixmap.py for some reason.

[IanSav]

Hi Prl,

The pull request is there but it is different from the code you posted for testing. The ValueToPixmap.py code is identical to the code you posted here but the Pixmap.py code differs. When I use the Pixmap.py code you posted here things work as expected.

Here is the current diff from the code you posted here and the code as it now exists on OpenViX:

Code: Select all

diff Pixmap.py PixmapViXNew.py
15,17c15,20
< 		if self.source and hasattr(self.source, "pixmap"):
< 			if self.instance:
< 				self.instance.setPixmap(self.source.pixmap)
---
> 		if what[0] != self.CHANGED_CLEAR:
> 			if self.source and hasattr(self.source, "pixmap"):
> 				if self.instance:
> 					self.instance.setPixmap(self.source.pixmap)
> 		elif self.instance:
> 			self.instance.setPixmap(None)

Regards,
Ian.

[prl]

...
The pull request is there but it is different from the code you posted for testing. The ValueToPixmap.py code is identical to the code you posted here but the Pixmap.py code differs. When I use the Pixmap.py code you posted here things work as expected.

Here is the current diff from the code you posted here and the code as it now exists on OpenViX:

Code: Select all

diff Pixmap.py PixmapViXNew.py
15,17c15,20
< 		if self.source and hasattr(self.source, "pixmap"):
< 			if self.instance:
< 				self.instance.setPixmap(self.source.pixmap)
---
> 		if what[0] != self.CHANGED_CLEAR:
> 			if self.source and hasattr(self.source, "pixmap"):
> 				if self.instance:
> 					self.instance.setPixmap(self.source.pixmap)
> 		elif self.instance:
> 			self.instance.setPixmap(None)

...

I know that the code I checked in is different from what I posted for you to test. I've already posted that fact and why I did it. The change is intentional. The new version is also what I submitted for to the Beyonwiz repository.

The test I'd like to see is whether if the source of my later version is placed in your test system, it operates correctly.

Probably the simplest way for me to proceed would be to accept your offer of a recent USB update for the Beyonwiz version of OpenViX so that I can run the same code as you and try to work out why it's failing to work for you the way it's intended.