New date/time formatting

[IanSav]

Hi PeterU,

Both the Beyonwiz master and OpenViX master versions behave as I described. You may have a development version in the pipeline that changes the behaviour, but what we are currently working with behaves as I reported and prl confirmed.

Anyway, no point wasting time on arguing this. Let's just work on the code to make it work with what can be tested - i.e. current version. The skin changes to fully support the new feature will need to be the same, regardless of what switches are used to turn it on/off.

I believe it would be more productive to move to the latest version of the code. Going with the interim version is only going to make more work for everyone when the next version arrives.

I am back from the doctor and completed my OpenViX obligations for the moment so I am going to start looking at getting the Beyonwiz code into shape.

Regards,
Ian.

[IanSav]

Hi Gully,

I look forward to seeing some way of configuring the front panel display on the T3 as since the change it has become too crowded and less readable IMHO.

Not that I use it a lot but the first time I saw it I wasn't sure if I had shut it down or had some sort of T3 message.

If the standard OpenViX solution is adopted the front panel will only have the time. To get the date and time you need a 12 character display.

Regards,
Ian.

[peteru]

The trouble, as of right now, is that OpenViX/master doesn't have those changes and OpenViX/Dev is in a state of flux, with commits and reverts flapping.

The options I see:

1. Wait for OpenViX to stabilise Dev and update master and then merge master once it is known to work
2. Try to cherry pick relevant commits from OpenViX/Dev
3. Get you to provide patches specific to Beyonwiz

I prefer option 1 because with option 3 it is rather difficult to come up with a patch set that is not going to cause merge issues down the track. Similarly, option 2 is bound to be more complicated both now and later, than simply waiting a little while for option 1 to happen.

I expect that the wait for option 1 should be a matter of days, not weeks.

[IanSav]

Hi PeterU,

I wish you said this earlier. I have just completed and compiled three commits and pull requests to specifically format the new OpenViX changes for the current Beyonwiz repository.

That is you have option 3 ready to go. If you go with option 1 the changes will be equivalent but not Beyonwiz ready. It also means that Prl should consider pausing his work on some of the skin changes until these items become available.

Regards,
Ian.

[prl]

...
I wish you said this earlier. I have just completed and compiled three commits and pull requests to specifically format the new OpenViX changes for the current Beyonwiz repository.
...

I don't seem to be able to see those commits in https://github.com/IanSav/enigma2, unless they're the ones for the front panel time formats in the DateTime-Update branch. I can't see corresponding pull requests in https://github.com/OpenViX/enigma2, either.

The DateTime-Update branch commits aren't relevant to what I'm working on at the moment.

[Gully]

If the standard OpenViX solution is adopted the front panel will only have the time. To get the date and time you need a 12 character display.

I guess that would be okay though we did have date and time before using a numeric approach didn't we?

[IanSav]

Hi Prl,

Look at the three new pull requests in https://bitbucket.org/beyonwiz/easy-ui-4/pull-requests/

Regards,
Ian.

[IanSav]

Hi Gully,

I guess that would be okay though we did have date and time before using a numeric approach didn't we?

Yes. The Beyonwiz T3 front panel skins used hard coded formats.

The problem is that the T3 used to have a 12 character display. Now that it is only an 11 character display things don't line up. The OpenViX options for VFDs are 8, 12, 14 and 18 character displays. 12 is the more common configuration.

The OpenViX skin use both hard coded and ClockToText based options. We are currently discussing what changes could / should be made. The new user selectable formats only become available if the skin is flagged to support the new formats and uses the ClockToText named options (not Format).

Regards,
Ian.

[IanSav]

Hi Prl,

I am unsure how to proceed. I don't see a point in creating pull requests to improve the Beyonwiz code if PeterU wants to wait for the OpenViX versions and then simply deletes my efforts. A total waste of my time and effort.

There is also a problem where the Beyonwiz code and plugins differ from that in OpenViX. Some of the current Beyonwiz code need some updates. Are those differences going to be eliminated with OpenViX merges? Again, I am over spending lots of time and effort creating commits and pull requests just to have them summarily deleted.

Do you have any suggestions?

Regards,
Ian.

[prl]

...
I am unsure how to proceed. I don't see a point in creating pull requests to improve the Beyonwiz code if PeterU wants to wait for the OpenViX versions and then simply deletes my efforts. A total waste of my time and effort.
...
Do you have any suggestions?
...

Since what you've said might(?) happen hasn't happened, as far as I can see (the pull requests have been neither deleted nor commented on), I'm not sure what I should suggest.

[IanSav]

Hi Prl,

Since what you've said might(?) happen hasn't happened, as far as I can see (the pull requests have been neither deleted nor commented on), I'm not sure what I should suggest.

I will not create any more Beyonwiz specific code until I/we get further direction.

In the interim if you want any information or help please ask.

Regards,
Ian.

[Gully]

Yes. The Beyonwiz T3 front panel skins used hard coded formats.

The problem is that the T3 used to have a 12 character display. Now that it is only an 11 character display things don't line up. The OpenViX options for VFDs are 8, 12, 14 and 18 character displays. 12 is the more common configuration.

The OpenViX skin use both hard coded and ClockToText based options. We are currently discussing what changes could / should be made. The new user selectable formats only become available if the skin is flagged to support the new formats and uses the ClockToText named options (not Format).

Did the change from 12 to 11 happen within a firmware update?

I know there was an earlier front panel fix/update which I never applied so just wondering.

That aside I would have thought one option is to allow a display format where the time comes first and then the date. If the month is 3 letters as no you lose the last one with 11 characters but it still makes sense. And if of course with a two figure representation it would fit.

[prl]

... Did the change from 12 to 11 happen within a firmware update?

I know there was an earlier front panel fix/update which I never applied so just wondering.
...

It was most likely in the front panel fix you never applied. It's to get around the problem that the rightmost digit in the VFD fades quite badly on some units.

[Gully]

... Did the change from 12 to 11 happen within a firmware update?

I know there was an earlier front panel fix/update which I never applied so just wondering.
...

It was most likely in the front panel fix you never applied. It's to get around the problem that the rightmost digit in the VFD fades quite badly on some units.

Yes I figured that - mine fine, fingers crossed but no reason why it should change still.

[IanSav]

Hi Gully,

I know there was an earlier front panel fix/update which I never applied so just wondering.

That aside I would have thought one option is to allow a display format where the time comes first and then the date. If the month is 3 letters as no you lose the last one with 11 characters but it still makes sense. And if of course with a two figure representation it would fit.

If you still have all 12 characters on your display then when Beyonwiz updates to my latest code your VFD should return to a spaced time display (unless you select a 12 hour clock for the front panel).

Regards,
Ian.

[Gully]

If you still have all 12 characters on your display then when Beyonwiz updates to my latest code your VFD should return to a spaced time display (unless you select a 12 hour clock for the front panel).

Thanks, Ian.

[prl]

When the time & date formats are changed, the infobar and second infobar time and date formats don't all change. The entries for the format changes in MENU>Setup>System>Time should probably have the "* Restart Required" footnote added.

[prl]

The time format of the time tickmarks in the Graphical EPG timeline doesn't change with the setting of MENU>Setup>System>Time>Time style. It still uses its own setup in the Graphical EPG setup screen, even though the description of the EPG setup screen says "This setting is not used if the global time format settings are available."

The date on the left of the timeline does change with the global date setting.

The times on the timeline tickmarks should probably do what the description says.

[IanSav]

Hi Prl,

When the time & date formats are changed, the infobar and second infobar time and date formats don't all change. The entries for the format changes in MENU>Setup>System>Time should probably have the "* Restart Required" footnote added.

When I developed the code on the Beyonwiz I had the asterisks. OpenViX asked me to remove them as they never found a case where the restart was required.

This is a Beyonwiz issue. On OpenViX *all* the screens, including the InfoBars and other pre loaded screens, all update. Is there any chance you could investigate why the Beyonwiz doesn't update these early loaded screens? If a solution is found then the asterisks will also be unnecessary for the Beyonwiz.

Regards,
Ian.

[IanSav]

Hi Prl,

The time format of the time tickmarks in the Graphical EPG timeline doesn't change with the setting of MENU>Setup>System>Time>Time style. It still uses its own setup in the Graphical EPG setup screen, even though the description of the EPG setup screen says "This setting is not used if the global time format settings are available."

The date on the left of the timeline does change with the global date setting.

The times on the timeline tickmarks should probably do what the description says.

This is a merge issue. The new code was not merged.

Regards,
Ian.

[prl]

...

When the time & date formats are changed, the infobar and second infobar time and date formats don't all change. The entries for the format changes in MENU>Setup>System>Time should probably have the "* Restart Required" footnote added.

When I developed the code on the Beyonwiz I had the asterisks. OpenViX asked me to remove them as they never found a case where the restart was required.

This is a Beyonwiz issue. On OpenViX *all* the screens, including the InfoBars and other pre loaded screens, all update. Is there any chance you could investigate why the Beyonwiz doesn't update these early loaded screens? If a solution is found then the asterisks will also be unnecessary for the Beyonwiz.
...

It may be that something in the OpenViX code causes the infobar fields to be updated when they aren't in the Beyonwiz code. The reason I think that is that the time of day format changes immediately in the infobar, but other fields, like start/end times don't update their formats.

Do you see the same effect in OverlayHD?

I'm currently putting my progress on updating the standard skins for the time formats into a repository branch sliced into more manageable pieces. When I've done that, I'll have a look at why those fields don't update their formats.

[prl]

...

The time format of the time tickmarks in the Graphical EPG timeline doesn't change with the setting of MENU>Setup>System>Time>Time style. It still uses its own setup in the Graphical EPG setup screen, even though the description of the EPG setup screen says "This setting is not used if the global time format settings are available."

The date on the left of the timeline does change with the global date setting.

The times on the timeline tickmarks should probably do what the description says.

This is a merge issue. The new code was not merged.
...

OK. Thanks.

[IanSav]

Hi Prl,

It may be that something in the OpenViX code causes the infobar fields to be updated when they aren't in the Beyonwiz code. The reason I think that is that the time of day format changes immediately in the infobar, but other fields, like start/end times don't update their formats.

Do you see the same effect in OverlayHD?

I have had to remove some of the update code in the OverlayHD plugin that you wrote for me as the matching skin code is not in OpenViX. OverlayHD appears to work fine on OpenViX but doesn't update on the Beyonwiz.

I'm currently putting my progress on updating the standard skins for the time formats into a repository branch sliced into more manageable pieces. When I've done that, I'll have a look at why those fields don't update their formats.

How are you finding making the changes? Any issues or concerns (other than things broken by the merge)?

Once I know that PeterU will accept my code fixes I will return to creating fixes to correct the merge problems and missing code.

Regards,
Ian.

[prl]

... How are you finding making the changes? Any issues or concerns (other than things broken by the merge)? ...

Adapting the skins to the new code has been straightforward, mostly tweaking sizes and positions, but as I find with all skin work, tedious.

I'm getting close to the point where the remaining problems are code, rather than skin, issues.

I've posted either here or in the beta forum about all the issues I've had where the code needs to be adapted to te new time formats, either by merging what's currently in OpenViX, by fixing OpenViX and then merging or by fixing the Beyonwiz code.

I'd really like to see font size proportional versions of the EPGSingleEPGColumnFormats and EPGMultiEPGColumnFormats parameters (preferably implemented in OpenViX and merged to Beyonwiz) so that the columns in the single channel and multi EPGs can be adjusted without changing the code otherwise.

It would also be good to know whether the Beyonwiz code is going to continue with needing a larger EPGList.weekday_rect for the single channel EPG than the OpenViX code does. This difference has impacts on getting compact columns in the EPGSearch screen on the Beyonwiz. The EPGSearch screen uses the same data content in EPGList.weekday_rect on both Beyonwiz and OpenViX as OpenViX uses in the single channel EPG.

This means that if that column is wide enough on the Beyonwiz for the the single channel EPG screen, it's much wider than necessary in EPGSearch.

Beyonwiz single channel EPG: strftime("%a %d %b", t)
OpenViX single channel EPG: strftime("%a", t)
Both EPGSearch: strftime("%a", t) or strftime(config.usage.date.dayshort.value, t) if the new time formats are enabled.

The EPGList.datetime_rect for the two screens is different, too, but the Beyonwiz data fits reasonably well in the space that the common code reserves for it.

And, of course, the single channel EPG should be using the appropriate enhanced format config variables, rather than fixed conversion strings.

[prl]

Hi Prl,

It may be that something in the OpenViX code causes the infobar fields to be updated when they aren't in the Beyonwiz code. The reason I think that is that the time of day format changes immediately in the infobar, but other fields, like start/end times don't update their formats.

Do you see the same effect in OverlayHD?

I have had to remove some of the update code in the OverlayHD plugin that you wrote for me as the matching skin code is not in OpenViX. OverlayHD appears to work fine on OpenViX but doesn't update on the Beyonwiz.
...

In the Beyonwiz code the start/end times in the infobar and second infobar update when there is an EIT update event. This happens on change of service or on a new event starting.

After the time format is changed, either of those will trigger an update of the fields. They cause a new EventInfo event to be pushed down the pipeline, and the resulting update also changes the display format.

The time-of-day clock in the infobar is updated every second by a timer, so it always has the right date format, because it's continually being written.

Is this different from what happens in the OpenViX infobar?

[IanSav]

Hi Prl,

In the Beyonwiz code the start/end times in the infobar and second infobar update when there is an EIT update event. This happens on change of service or on a new event starting.

After the time format is changed, either of those will trigger an update of the fields. They cause a new EventInfo event to be pushed down the pipeline, and the resulting update also changes the display format.

The time-of-day clock in the infobar is updated every second by a timer, so it always has the right date format, because it's continually being written.

Is this different from what happens in the OpenViX infobar?

I just tested this myself on the Beyonwiz build of OpenViX and see exactly what you describe. Once the time format is changed the current InfoBar formats are not immediately updated. There wasn't an event change due so I simply changed the channel and saw the start/end times immediately update both the content and format.

In the OpenViX forum conversation I understood that the formats updated immediately but on doing my own testing I suspect that an event change or channel change was also involved.

Regards,
Ian.

[prl]

Thanks. It's good to have it confirmed that the Beyonwiz and OpenVIX codes do the same thing.

What, if anything, do you think needs to be done about it?

[MrQuade]

Thanks. It's good to have it confirmed that the Beyonwiz and OpenVIX codes do the same thing.

What, if anything, do you think needs to be done about it?

From what you describe, does it also mean that if the broadcaster were to transmit updated start/end information that modified the end time of the current event, that information would not be reflected in the Infobar time fields until the event ended or the service was changed as well?

If that's the case, then those fields should probably be updated regularly as well (at the same period as the clock assuming it constitutes a trivial overhead?). It would probably also necessitate adjusting the progress bar duration/fill to match?

[IanSav]

Hi Prl,

Thanks. It's good to have it confirmed that the Beyonwiz and OpenVIX codes do the same thing.

Agreed.

What, if anything, do you think needs to be done about it?

First I need to confirm things I am told by the OpenViX team members. Personally I would not accept that this was an automatic update. It is an "eventually" update. I do agree that the reboot flag is not really required.

Is there a simple way to ask the infobars (and the main menu) to redraw or, if needed, reload their skins automatically or on demand?

EDIT: MrQuade's suggestion of an update every second could be interesting if it doesn't create too much overhead. Alternatively what about a refresh when the Infobars (and main menu) are unhidden/shown?

(I must also port the window styles refresh code you wrote to OpenViX.)

Regards,
Ian.

[prl]

Thanks. It's good to have it confirmed that the Beyonwiz and OpenVIX codes do the same thing.

What, if anything, do you think needs to be done about it?

From what you describe, does it also mean that if the broadcaster were to transmit updated start/end information that modified the end time of the current event, that information would not be reflected in the Infobar time fields until the event ended or the service was changed as well?

That should send new events. If the time fields reflect that now, then they will get their formats updated at the same time.

If that's the case, then those fields should probably be updated regularly as well (at the same period as the clock assuming it constitutes a trivial overhead?). It would probably also necessitate adjusting the progress bar duration/fill to match?

That would update the formats, but it appears a bit excessive. There may be a better way (but I don't know what it is). There shouldn't be any need to do it to update the data that's being displayed.

[prl]

... Is there a simple way to ask the infobars (and the main menu) to redraw or, if needed, reload their skins automatically or on demand?

No. I seem to remember we've been around this one before

EDIT: MrQuade's suggestion of an update every second could be interesting if it doesn't create too much overhead.

That would be easy, but ugly.

Alternatively what about a refresh when the Infobars (and main menu) are unhidden/shown?

That may work better and be a bit cleaner. It would mean pushing a fake event into the source.

[IanSav]

Hi Prl,

That may work better and be a bit cleaner. It would mean pushing a fake event into the source.

Couldn't we simply do something like an invalidate, or a reload, on the onShow event for the screen?

By the way, this could also be a solution to the stale data issue in the ChannelSelection (FAV) screen.

Regards,
Ian.

[MrQuade]

If that's the case, then those fields should probably be updated regularly as well (at the same period as the clock assuming it constitutes a trivial overhead?). It would probably also necessitate adjusting the progress bar duration/fill to match?

That would update the formats, but it appears a bit excessive. There may be a better way (but I don't know what it is). There shouldn't be any need to do it to update the data that's being displayed.

[/quote]

Gocha. Given that the new event being sent from the broadcaster will update the times properly already, then I agree that a periodic update for the format is completely unnecessary.

[prl]

...

That may work better and be a bit cleaner. It would mean pushing a fake event into the source.

Couldn't we simply do something like an invalidate, or a reload, on the onShow event for the screen?

Invalidate what? Reload what? The InfoBar has direct access to the relevant Sources. The Renderers are relatively inaccessible. What's wrong with calling the Source's gotEvent() method? I haven't tested it, but it seems a reasonable way to go.

By the way, this could also be a solution to the stale data issue in the ChannelSelection (FAV) screen. ...

I haven't noticed that. Could you give a recipe?

[IanSav]

Hi Prl,

Invalidate what? Reload what?

The screen. Flag that it needs to be redrawn when ever it is shown (from being hidden).

The InfoBar has direct access to the relevant Sources. The Renderers are relatively inaccessible. What's wrong with calling the Source's gotEvent() method? I haven't tested it, but it seems a reasonable way to go.

You know this code far better than me. I will go with any improvements you can suggest.

By the way, this could also be a solution to the stale data issue in the ChannelSelection (FAV) screen. ...

I haven't noticed that. Could you give a recipe?

I can't always force the problem but generally:

• Select a channel and then press FAV to bring up the channel selection screen.
• Note the current event on the list of channels and the currently highlighted program details.
• Dismiss the channel selection screen.
• Leave the box alone and let it play the current channel for at least as long as it takes for the current event to end and a new program start. The longer you leave it the better (more chance for the problem to show).
• Press FAV and if the bug shows you should see the same screen as before with none of the events previously noted being updated to reflect the current information.

Regards,
Ian.

[IanSav]

Hi Prl,

I have filed 20 pull requests to bring the Beyonwiz build up to a reasonable standard and functionality of the new date / time code. The number of pull requests hopefully complies with PeterU's requirements for simpler commits and pull requests and will get them all quickly merged.

Once this is done we should re-evaluate the status of the code and the skin changes. I will run another scan of all the code to see if there are any other hard coded dates or times that should be migrated to the new system.

Regards,
Ian.

[IanSav]

Hi Prl,

I'm getting close to the point where the remaining problems are code, rather than skin, issues.

I have files 20 pull requests to try and bring the Beyonwiz code up to scratch.

I've posted either here or in the beta forum about all the issues I've had where the code needs to be adapted to te new time formats, either by merging what's currently in OpenViX, by fixing OpenViX and then merging or by fixing the Beyonwiz code.

Hopefully those 20 pull requests will be merged and address most of the issues.

I'd really like to see font size proportional versions of the EPGSingleEPGColumnFormats and EPGMultiEPGColumnFormats parameters (preferably implemented in OpenViX and merged to Beyonwiz) so that the columns in the single channel and multi EPGs can be adjusted without changing the code otherwise.

Please check the latest code and raise this again if it is still applicable and when I can focus more on your suggestion.

It would also be good to know whether the Beyonwiz code is going to continue with needing a larger EPGList.weekday_rect for the single channel EPG than the OpenViX code does. This difference has impacts on getting compact columns in the EPGSearch screen on the Beyonwiz. The EPGSearch screen uses the same data content in EPGList.weekday_rect on both Beyonwiz and OpenViX as OpenViX uses in the single channel EPG.

Check this out again when the latest pull requests are merged. If there is still a problem let me know.

OpenViX would like to take the Beyonwiz format but we have an issue organising the start / end time column alignment that makes everyone happy. I have the date centred at the moment but it still doesn't create a nice column. I wanted to use the "figure space" character to pad the times to create columnar data but unfortunately it is not in all the fonts.

This means that if that column is wide enough on the Beyonwiz for the the single channel EPG screen, it's much wider than necessary in EPGSearch.

Beyonwiz single channel EPG: strftime("%a %d %b", t)
OpenViX single channel EPG: strftime("%a", t)
Both EPGSearch: strftime("%a", t) or strftime(config.usage.date.dayshort.value, t) if the new time formats are enabled.

The EPGList.datetime_rect for the two screens is different, too, but the Beyonwiz data fits reasonably well in the space that the common code reserves for it.

And, of course, the single channel EPG should be using the appropriate enhanced format config variables, rather than fixed conversion strings.

Check this out again when the latest pull requests are merged. If there is still a problem let me know.

Regards,
Ian.

[prl]

...

I've posted either here or in the beta forum about all the issues I've had where the code needs to be adapted to te new time formats, either by merging what's currently in OpenViX, by fixing OpenViX and then merging or by fixing the Beyonwiz code.

Hopefully those 20 pull requests will be merged and address most of the issues.

Thanks, they appear to address almost all the issues I've raised, except this one:

I'd really like to see font size proportional versions of the EPGSingleEPGColumnFormats and EPGMultiEPGColumnFormats parameters (preferably implemented in OpenViX and merged to Beyonwiz) so that the columns in the single channel and multi EPGs can be adjusted without changing the code otherwise.

Please check the latest code and raise this again if it is still applicable and when I can focus more on your suggestion.
...

All that's changed for the Multi EPG is that a comment has been corrected (to something that I think is incorrect, anyway, it should be * 1.25 or perhaps * 1.5 rather than * 1.0). It should be changed to a sensible value and uncommented. I've added a comment to this effect to the pull request.

The default column widths for the Single EPG look like they might work.

Nothing has happened towards implementing font-proportional versions of either of the EPGSingleEPGColumnFormats or EPGMultiEPGColumnFormats parameters, which makes it hard for skin writers to specify different widths that take into account the user specification of font sizes in those screens.

[IanSav]

Hi Prl,

I'd really like to see font size proportional versions of the EPGSingleEPGColumnFormats and EPGMultiEPGColumnFormats parameters (preferably implemented in OpenViX and merged to Beyonwiz) so that the columns in the single channel and multi EPGs can be adjusted without changing the code otherwise.

Please check the latest code and raise this again if it is still applicable and when I can focus more on your suggestion.
...

All that's changed for the Multi EPG is that a comment has been corrected (to something that I think is incorrect, anyway, it should be * 1.25 or perhaps * 1.5 rather than * 1.0). It should be changed to a sensible value and uncommented. I've added a comment to this effect to the pull request.

The MultiEPG is a funny case. It is the one EPG view where the EPG data matches/relates to skin based column graphics. That is, the format of the columns is somewhat locked to the way the skin designer has painted the screen. You should note that the width of the column has been matched to the width of the graphic. You should also note that if the longer 12 hour clock formats are selected the separator changes from " - " to "-" to save space and fit within the graphic. Using the scaling factor would cause the column to grow and miss-align under the graphic. The code is provided but commented out until the skin layout of the MultiEPG changes and the separator is reset to " - ".

The default column widths for the Single EPG look like they might work.

That is no accident. It is hours of testing and refinement.

Nothing has happened towards implementing font-proportional versions of either of the EPGSingleEPGColumnFormats or EPGMultiEPGColumnFormats parameters, which makes it hard for skin writers to specify different widths that take into account the user specification of font sizes in those screens.

OpenViX is still on code freeze so please suggest how you would suggest this be improved.

Regards,
Ian.

[prl]

...
I'd really like to see font size proportional versions of the EPGSingleEPGColumnFormats and EPGMultiEPGColumnFormats parameters (preferably implemented in OpenViX and merged to Beyonwiz) so that the columns in the single channel and multi EPGs can be adjusted without changing the code otherwise.
...

I suggest changing the parameter extraction loop in skin.py to something like this (should be backwards compatible):

Code: Select all

	def paramConvert(val):
		return float(val) if '.' in val else int(val)

	for c in skin.findall("parameters"):
		for parameter in c.findall("parameter"):
			get = parameter.attrib.get
			try:
				name = get("name")
				value = get("value")
				parameters[name] = "," in value and map(paramConvert, value.split(",")) or paramConvert(value)
			except Exception, ex:
				print "[Skin] bad parameter", ex

Then allow for the use of scaled parameters for the column widths, something like:

Code: Select all

		if self.type == EPG_TYPE_MULTI:
			fontSize = self.eventFontSizeMulti + config.epgselection.multi_eventfs.value
			servScaledW = 5.9
			progScaledW = 6.8
			servScaledW, progScaledW = skin.parameters.get("EPGMultiEPGScaledColumnFormats", (servScaledW, progScaledW))
			servW = int((fontSize + 4) * servScaledW)  # Service font is 4 px larger
			progW = int(fontSize * progScaledW)
			servLeft, servWidth, progLeft, progWidth, progHeight, descLeft = skin.parameters.get("EPGMultiEPGColumnFormats", (0, servW, servW + 10, progW, height - 8, servW + progW + 20))
			if config.usage.time.wide.value:
				progW = int(fontSize * 1.5)

Code suggestions not tested.

The current EPGMultiEPGColumnFormats allow for column reordering. If the ability to reorder the columns was dropped, the parameters could be changed to set the inter-column padding sizes instead of the left edge, and that would work better with the scaled column formats, so the parameters might be:
(servPad, servW, progPad, progW, progH, descPad)
I'm not sure whether the padding in the ScaledColumnFormats should be pixel-based or font size scaled.

[prl]

...
The MultiEPG is a funny case. It is the one EPG view where the EPG data matches/relates to skin based column graphics. That is, the format of the columns is somewhat locked to the way the skin designer has painted the screen. You should note that the width of the column has been matched to the width of the graphic. You should also note that if the longer 12 hour clock formats are selected the separator changes from " - " to "-" to save space and fit within the graphic.

That's so, but in the easy-skin-aus-hd skin the 12-hour format text is still too wide to fit. The remaining/duration column is too narrow for 4-digit times remaining. I see those in the FTA EPG where there isn't a proper EPG for the channel (e.g. ishoptv, RACING.COM, GOLD). Those channels have one EPG entry per day, 1440min long.

Using the scaling factor would cause the column to grow and miss-align under the graphic.

I don't think they're particularly well aligned, especially not the progress/times column. The alignment of the left edge of the remaining/duration column is a bit lost because its text is a right-aligned. There are also 4 text columns and 3 header "buttons", so the rightmost column isn't aligned with anything particular.

[prl]

...

By the way, this could also be a solution to the stale data issue in the ChannelSelection (FAV) screen. ...

I haven't noticed that. Could you give a recipe?

I can't always force the problem but generally:

• Select a channel and then press FAV to bring up the channel selection screen.
• Note the current event on the list of channels and the currently highlighted program details.
• Dismiss the channel selection screen.
• Leave the box alone and let it play the current channel for at least as long as it takes for the current event to end and a new program start. The longer you leave it the better (more chance for the problem to show).
• Press FAV and if the bug shows you should see the same screen as before with none of the events previously noted being updated to reflect the current information.

...

I tried this a few times and I can't replicate it. How often would I need to try to expect to see the problem?

[prl]

...

• Dismiss the channel selection screen.

...

Start/end times and the event names don't update in the Channel Selection screen if I stay in the screen rather than leave it.

[IanSav]

Hi Prl,

That's so, but in the easy-skin-aus-hd skin the 12-hour format text is still too wide to fit. The remaining/duration column is too narrow for 4-digit times remaining. I see those in the FTA EPG where there isn't a proper EPG for the channel (e.g. ishoptv, RACING.COM, GOLD). Those channels have one EPG entry per day, 1440min long.

I don't think they're particularly well aligned, especially not the progress/times column. The alignment of the left edge of the remaining/duration column is a bit lost because its text is a right-aligned. There are also 4 text columns and 3 header "buttons", so the rightmost column isn't aligned with anything particular.

Can I please provide some screen captures to illustrate the issues.

Regards,
Ian.

[IanSav]

Hi Prl,

I tried this a few times and I can't replicate it. How often would I need to try to expect to see the problem?

If you can spare a machine try and leave it running, untouched, overnight and check the display the next afternoon.

I should not that I am yet to see the problem since the latest update. I have only been running the update for less than a day. It is always possible that something has changed to fix or change the problem.

Regards,
Ian.

[IanSav]

Hi Prl,

Start/end times and the event names don't update in the Channel Selection screen if I stay in the screen rather than leave it.

That is not how I trigger/found the problem. Still you have found an issue that may end up being related. Is this something you can fix?

Regards,
Ian.

[prl]

Hi Prl,

I tried this a few times and I can't replicate it. How often would I need to try to expect to see the problem?

If you can spare a machine try and leave it running, untouched, overnight and check the display the next afternoon.
...

I'll try it, though it will be a machine I'll want to start using tomorrow morning.

[prl]

... Can I please provide some screen captures to illustrate the issues. ...

Is that "I" a new way of writing "you"?

[prl]

...

Start/end times and the event names don't update in the Channel Selection screen if I stay in the screen rather than leave it.

... Is this something you can fix?
...

It depends on just what's meant by "this". There appear to be two bugs that may or may not be related. I'm not all that sure that the "no updates when you stay in the Channel Selection screen" bug is an issue that particularly needs an urgent fix. I haven't looked in any detail about possible causes of the problem you identified, because I'm yet to be convinced that it is a problem.