EPG Enhancements Requests and EPG Bug Reporting

[jpp]

Do we really need current recording or zap timers (active now) to be highlighted in something other than their normal colours?

I am inclined to partially agree with you on this one.

I only suggest that in the case where you have two adjacent recordings, one being the current event and the other is the next event (I show this in my diagram). If they are not different colours, then the two will blend into each-other, which is what jpp is complaining about.

I'm not really that fussed over this one. In my sample shots posted earlier, you can see that when the boxes are highlighted, i.e. the Record boxes are RED, it's much easier to see the break between the boxes. That's because a black line between 2 fairly bright colours is MUCH easier to spot than a black line with a background that is almost nearly black already.

My suggestion is to just add two new colours to the current scheme, so not overly complex or confusing.

I'm with Ian on this one. Try to avoid adding ANY new colours. Shading is preferred (and shading is NOT a new colour - it's the saturation level of the same colour). Shading of the same colour leads to a look that is much less busy.

I would also like to see the yellow (current event) highlight be used for any event even if it is a recording or zap timer that is the currently selected event. That is, a user is used to seeing the cursor as yellow so it should always be yellow.

Agree with this.

While I do agree that less complexity is better, this suggestion does make it much much harder to identify if the selected even is a zap/recording event. The colours are much faster to identify (more attention grabbing) than the icons.

True, but it makes for a busier EPG. Agreed, you have to balance the two - full "reporting" for each event vs ease of use and simplicity.

[IanSav]

Hi,

In regard to the current event always being yellow. I do not feel very strongly about this and would be okay with the current version of a current recording or zap timer keeping the base colour and simply becoming a lighter shade of that colour. I felt that the yellow would be a good idea so that users can easily track the currently selected event no matter what it was. The icons in the event would always reveal if there was anything special about that event.

Given that most of the colours being described are defined in the skin then I am open to anyone's colour preferences as I can change them to suit myself. What I don't currently have is the control to colour the current events that are not currently selected. This used to be available and was removed. This change was the primary thrust of this thread and is the one main issue for which there is no control in the skin. I would like to have this feature restored.

Regards,
Ian.

[jpp]

OK, a sample shot of the OzTV app (iOs and Android). You can clearly see how well the black shading works here. Highlighting current/now programs in this manner (shading) is universally used in all the time-line EPGs I've come across .

[simoncasey]

Try to avoid adding ANY new colours. Shading is preferred (and shading is NOT a new colour - it's the saturation level of the same colour). Shading of the same colour leads not a look that is much less busy.

In the context of how hard it is to programme, which is what I was replying to, adding a shade is no different to adding a new colour. But I agree that it is visually preferred.

[tonymy01]

The Toppy's format shows yellow for current cursor position - just ignore that. It's the shading of the grey background that I want to draw your attention to.

Topfield EPG.png

Is that really the Topfield stock EPG format? God, it looks terrible, I prefer the old DP-P/S series to that, where does it show you the event description? I think they make that EPG for blind people, barely any information presented, so few channels!
My 5cents...
I prefer the current event to be lightly shaded, like the old DP series. A vertical progress line is good too.
I like the red for a timer, and light red perhaps for an extended timer into another timeslot (to show that the next show has a bit recorded but not the full timeslot).
I think blue can be for any others, like zap, non-recording etc, because honestly, who cares so much about zap timers showing up in the EPG?
And perhaps for current channel/event highlight when moving the cursor around can be either yellow (as mentioned.. because if you are wondering if it is a recording slot, just move the cursor one up/down/left/right, and you will get the original colour!), or a highlight around the event box if you insist on keeping the event some colour to show it's uniqueness to other events (recording,zap,etc).

I would also please please please like for scrolling to be 1 unit at a time, not when you get to the end of a page to page in a the next page (both in time, and in channel listings). If people really like going page by page, I am sure there are buttons assigned to that.

[simoncasey]

OK, a sample shot of the OzTV app (iOs and Android). You can clearly see how well the black shading works here. Highlighting current/now programs in this manner (shading) is universally used in all the time-line EPGs I've come across .

I don't think anybody is debating whether it is useful to format the current on now shows differently, the complexity is how to deal with the recordings and the selected event. Maybe post what the topfield epg looks like in those scenarios or mock up something.

[prl]

... and shading is NOT a new colour - it's the saturation level of the same colour ...

While that's correct in the colour space world and probably almost true in the GUI world*, it's not where the bits hit the road.

Each "shading" is a different colour definition in the skin and code for the text versions of the EPGs, and in the graphical EPG versions, each different shading is a new pixmap, and the pixmaps are internally shared, so changes in shading need to allow that internal shading to continue to look cleanly integrated.

* Having too many, or otherwise difficult-to-distinguish, shadings is also a GUI problem. For example in the old main menu, there were three different highlight shadings, but two of them were indistinguishable to my eyes.

[prl]

I've amended my post about skinning EPG entry borders after looking at the code in some more detail and experimenting a bit, and discovering it's more complicated than I originally posted.

[prl]

... I don't think anybody is debating whether it is useful to format the current on now shows differently, ...

I certainly am. And I may be a useful person to convince that it's a good idea (or IanSav or peteru), unless you want to go DIY

[simoncasey]

... I don't think anybody is debating whether it is useful to format the current on now shows differently, ...

I certainly am. And I may be a useful person to convince that it's a good idea (or IanSav or peteru), unless you want to go DIY

But aren't you debating based on the fact that you know it will be difficult and complicated to implement (which is a valid argument). If it was easy to implement, I would imagine you would feel differently or it probably wouldn't have been removed in the first place.

[prl]

... I think the separation is much more subtle in full metal skin.

Both use the default widths, colours and border pixmaps. But there's probably more contrast between the border colour and the cell backgrounds in the blue-themed easy-skin than in Full-Metal.

I use the Full-Metal skin on our in-use T4, and I don't really have a problem there, either, but maybe that's just care factor.

I'd much prefer to have the end time shown in the show info part of the screen for the show in focus than I'm bothered about boundaries.

Here's what the Full-Metal GraphicalEPGPIG looks like in graphical mode with just the border width bumped up to 2. The only problem is that it squeezes the vertical height of the EPG text a bit. Going more than 2 would probably mean squeezing the font size down a bit, and it starts to look a bit ugly with the current border pixmaps.

[IanSav]

Hi Prl,

I'd much prefer to have the end time shown in the show info part of the screen for the show in focus than I'm bothered about boundaries.

Like in OverlayHD?

Regards,
Ian.

[simoncasey]

Here's some mock ups of the default skin shaded

[simoncasey]

Here's what the Full-Metal GraphicalEPGPIG looks like in graphical mode with just the border width bumped up to 2. The only problem is that it squeezes the vertical height of the EPG text a bit. Going more than 2 would probably mean squeezing the font size down a bit, and it starts to look a bit ugly with the current border pixmaps.

I actually think that looks better. Also, you could edit your channel names to be smaller and reduce the size of the epg reserved for picon and service name and get more text in.

But all of these screenshots are a great way of demonstrating that everybody has their epg configured slightly differently, The double edged sword of the beyonwiz configurability.

[prl]

... I don't think anybody is debating whether it is useful to format the current on now shows differently, ...

I certainly am. And I may be a useful person to convince that it's a good idea (or IanSav or peteru), unless you want to go DIY

But aren't you debating based on the fact that you know it will be difficult and complicated to implement (which is a valid argument). If it was easy to implement, I would imagine you would feel differently or it probably wouldn't have been removed in the first place.

It's partly the implementation. I'll post more about that later.

It's not that this wasn't discussed at the time the decision was made to get rid of the "now" shading. I can't remember where it was discussed, but probably on the beta forum. Anyway, at the point where I realised that having different "now" colour/shading for all possible "now" items (unselected normal now, unselected record timer now, unselected zap timer now, selected normal now, selected record timer now, selected zap timer now & throw in a couple more if you want to add separate record-and-zap colouring), with the corresponding fill pixmaps, I asked peteru about colour schemes, and whether he could prepare the pixmaps (I don't have the tools), and we ended up agreeing that it would look too "busy". It's interesting that the posted OzTV app only shows two shadings, not the much larger number of colour/shading combinations that the T series needs, and I still don't like the "irregular masonry" look.

I find the "now" line completely OK for finding what's on now in the EPG. In fact, though, if I want to know what's on now, I generally don't use the EPG, I use the channel list, which I've set up to show all my favourites list in a single screen.

[prl]

... But all of these screenshots are a great way of demonstrating that everybody has their epg configured slightly differently, The double edged sword of the beyonwiz configurability.

I don't have my EPG configured that way (two-pixel borders). I just posted it as an example of what might be done. I'm happy with the current single-pixel borders and keeping the extra two pixels for text.

[MrQuade]

It's not that this wasn't discussed at the time the decision was made to get rid of the "now" shading. I can't remember where it was discussed, but probably on the beta forum. Anyway, at the point where I realised that having different "now" colour/shading for all possible "now" items (unselected normal now, unselected record timer now, unselected zap timer now, selected normal now, selected record timer now, selected zap timer now & throw in a couple more if you want to add separate record-and-zap colouring),

What are your thoughts of my proposal that there be no differentiation between a selected event if it is "now" or "not-now"? It cuts down on the colour combinations significantly and addresses the complexity you mentioned in the quoted text above.

[prl]

... What are your thoughts of my proposal that there be no differentiation between a selected event if it is "now" or "not-now"? It cuts down on the colour combinations significantly and addresses the complexity you mentioned in the quoted text above.

My main thought is that it's entirely unnecessary. Removing the differentiation of now/not-now selected shading reduces the number of colours without really affecting what I think about the "busyness" of the suggested layout.

[madmax]

Here's some mock ups of the default skin shaded

That first image looks great, a big +1 from me.

[MrQuade]

My main thought is that it's entirely unnecessary. Removing the differentiation of now/not-now selected shading reduces the number of colours without really affecting what I think about the "busyness" of the suggested layout.

If it is a matter of personal preference, then would the feature be a good candidate to for an EPG setting "Highlight now events" which can simply be toggled on or off?

[peteru]

I've been watching this discussion for a while and now that there are visual examples that confirm my initial reservations, I'll chime in briefly...

-24 from me.

It's going to take a lot to convince me (certainly more than a couple of users making a lot of noise) to merge something that uses this approach. The code complexity does not warrant the results and making this a configurable option would increase the code complexity even more for what is essentially an uglification of the user interface.

The vertical timeline tells the whole story. It's accurate and visualising the current event as an intersection between a bounding rectangle and a vertical line through it is not hard in any way.

Try a different approach. Perhaps one that uses a layered look, where the current events use a heavier brighter text, rather than huge blocks of colour. Try to keep the various criteria that need visualisation orthogonal so that the implementation complexity does not blow out.

[fastcars]

It's going to take a lot to convince me (certainly more than a couple of users making a lot of noise) to merge something that uses this approach. The code complexity does not warrant the results and making this a configurable option would increase the code complexity even more for what is essentially an uglification of the user interface.

The vertical timeline tells the whole story. It's accurate and visualising the current event as an intersection between a bounding rectangle and a vertical line through it is not hard in any way.

For my 2 cents worth, I would have to agree with Peter.

[simoncasey]

I've been watching this discussion for a while and now that there are visual examples that confirm my initial reservations, I'll chime in briefly...

-24 from me.

It's going to take a lot to convince me (certainly more than a couple of users making a lot of noise) to merge something that uses this approach. The code complexity does not warrant the results and making this a configurable option would increase the code complexity even more for what is essentially an uglification of the user interface.

The vertical timeline tells the whole story. It's accurate and visualising the current event as an intersection between a bounding rectangle and a vertical line through it is not hard in any way.

Try a different approach. Perhaps one that uses a layered look, where the current events use a heavier brighter text, rather than huge blocks of colour. Try to keep the various criteria that need visualisation orthogonal so that the implementation complexity does not blow out.

I don't disagree with your suggestion about bold text and the vertical timeline but the issue here is that there are two separate issues trying to be resolved in one go. 1) showing what is currently on and 2) creating a better differentiation between the blocks so it is more obvious when the current events end. Not all solutions deal with both of those points - and it is a valid question as to whether they should.

However, for the what is currently on now option, I think the criteria that I suggested is quite clear. Shows that are on now and have no timer events and are not the selected event are shown in a particular style. Everything else remains the same. We would effectively add one extra style and it is consistent with other styling that it is a shading of the normal block background colour.

Also, I'm not saying this is something we should do, I'm just trying to put up a valid suggestion for discussion.

[prl]

The current different event states that affect colouring are: selected/not selected and no timer/rec timer/zap timer (rec+zap timer is treated as rec timer), 6 backgrounds in all.

Add a separate colouring for rec+zap timers would make it 8.

Add separate background colouring for all combinations of now events makes it 12 (or 16 if zap+rec is distinguished).

Add separate background colouring for only selected/not selected no timer entries adds only two backgrounds, so 8 (or 10 if zap+rec is distinguished).

[prl]

... 1) showing what is currently on and 2) creating a better differentiation between the blocks so it is more obvious when the current events end. Not all solutions deal with both of those points - and it is a valid question as to whether they should. ...

All the suggestions for 1 seem to be orthogonal to the suggestions for 2. In fact, what I think are reasonable mechanisms already exist for changing 2 solely in the skin.

Personally, I think both are well catered for in the existing skins, apart from my already stated preference to have the end time up with the program title/synopsis information in the PIG screens. I'm not the only one to want that (it may even be in the OvetlayHD skin, I can't remember), but it hasn't made it to the issues tracker as far as I can see.

[madmax]

I don't disagree with your suggestion about bold text and the vertical timeline but the issue here is that there are two separate issues trying to be resolved in one go. 1) showing what is currently on and 2) creating a better differentiation between the blocks so it is more obvious when the current events end. Not all solutions deal with both of those points - and it is a valid question as to whether they should.

However, for the what is currently on now option, I think the criteria that I suggested is quite clear. Shows that are on now and have no timer events and are not the selected event are shown in a particular style. Everything else remains the same. We would effectively add one extra style and it is consistent with other styling that it is a shading of the normal block background colour.

Also, I'm not saying this is something we should do, I'm just trying to put up a valid suggestion for discussion.

I'm heavily in your camp Simon. Keeps it simple (relatively ) and solves both issues, which I agree are issues worth addressing.

If some users like peteru really don't like, then an on-off switch will obviously be required.

[MrQuade]

The current different event states that affect colouring are: selected/not selected and no timer/rec timer/zap timer (rec+zap timer is treated as rec timer), 6 backgrounds in all.

When I was testing last night, the rec+zap events were not getting any shading at all. They just showed as normal events.

[simoncasey]

... 1) showing what is currently on and 2) creating a better differentiation between the blocks so it is more obvious when the current events end. Not all solutions deal with both of those points - and it is a valid question as to whether they should. ...

All the suggestions for 1 seem to be orthogonal to the suggestions for 2. In fact, what I think are reasonable mechanisms already exist for changing 2 solely in the skin.

Some are and some aren't. Making the current shows a different colour makes it clearer when the current shows will end as there is a colour change - but if a text font was used then it wouldn't help. The vertical timeline is also of limited additional help for item 2 but is obviously useful for item 1.

But I agree, there are options for 2 that are independent of 1 that are dispersed through this discussion, relating to the border colour and size as you posted. But there seems to be more passion about the current event colour.

[prl]

From much earlier in the discussion:

I can't add much to this conversation other than 'I also want it'. In the short term, I'd even settle for just the currently-watched 'now' cell being shaded. Obviously when you first open the EPG, this cell is shaded yellow, but once you move away from it there is no visual reminder of which service you are currently viewing in the PIG. ...

In the Graphical EPG (both PIG and -non-PIG) versions, the current service being viewed in the main screen is highlighted in the service name/picon column on the left.

The name of the current service being shown in the EPG PIG is always displayed across the top of the PIG.

The current EPG PIG channel isn't necessarily the same channel as the channel being watched on the main screen.

(Only talking about the skins in the standard distributions. I haven't checked OverlayHD.)

[simoncasey]

I'm heavily in your camp Simon. Keeps it simple (relatively ) and solves both issues, which I agree are issues worth addressing.

If some users like peteru really don't like, then an on-off switch will obviously be required.

Just to clarify, I'm not in either camp and don't mind if this doesn't happen. But I am interested in anything that will improve the overall experience without over complicating and putting in the effort to describe and discuss what that might look like.

[jpp]

I'm heavily in your camp Simon. Keeps it simple (relatively ) and solves both issues, which I agree are issues worth addressing.

If some users like peteru really don't like, then an on-off switch will obviously be required.

Just to clarify, I'm not in either camp and don't mind if this doesn't happen. But I am interested in anything that will improve the overall experience without over complicating and putting in the effort to describe and discuss what that might look like.

Sorry guys, been absent for a few hours - and it's interesting and gratifying to see so much interest in this topic.

In summary, I agree with both Simon and Madmax - keep it as simple as possible - see posting.php?mode=quote&f=47&t=9804&p=132814#pr132768. This also keeps the 2 Peters in a happier frame of mind .

My only suggestion to make the EPG a bit easier on the eyes and appear less busy, is to use shading rather than a new colour for the now events. Maybe that was what you intended to show anyway Simon.

So, for the Easy default EPG a lighter shade of blue - the Auto Timer's slightly lighter blue button seems appropriate or perhaps a little lighter, and for the Metal EPG a lighter shade of grey.

[simoncasey]

My only suggestion to make the EPG a bit easier on the eyes and appear less busy, is to use shading rather than a new colour for the now events. Maybe that was what you intended to show that anyway Simon.

So, for the Easy default EPG a lighter shade of blue - the Auto Timer's slightly lighter blue button seems appropriate or perhaps a little lighter, and for the Metal EPG a lighter shade of grey.

I was using a blue as a version of the blue that is already in easy aus skin. It's not really a shade of the current blue, just a blue I like. For the full metal, it should be a shade of grey (there's at least 50 to choose from ). The other point is that it only really needs one new colour for the specific option of not selected/no timer/current show. All other formatting remains the same.

[simoncasey]

The current different event states that affect colouring are: selected/not selected and no timer/rec timer/zap timer (rec+zap timer is treated as rec timer), 6 backgrounds in all.

When I was testing last night, the rec+zap events were not getting any shading at all. They just showed as normal events.

When using the text epg they show as red like a record timer but when I switch to graphics epg they are shown without a coloured background, so I agree that this appears to be a bug.

[madmax]

Sorry guys, been absent for a few hours - and it's interesting and gratifying to see so much interest in this topic.

EPG functionality is a primary issue for me, probably #1 issue of any PVR. So yes, I'm passionate about it.

I commented earlier in this thread about the 'keep EPG history' function giving unexpected and sub-optimal behaviour, does anyone have any thoughts on this?

[prl]

The current different event states that affect colouring are: selected/not selected and no timer/rec timer/zap timer (rec+zap timer is treated as rec timer), 6 backgrounds in all.

When I was testing last night, the rec+zap events were not getting any shading at all. They just showed as normal events.

When using the text epg they show as red like a record timer but when I switch to graphics epg they are shown without a coloured background, so I agree that this appears to be a bug.

Agreed. It has the right background when selected, but the wrong one when not selected.

[IanSav]

Hi Madmax,

I commented earlier in this thread about the 'keep EPG history' function giving unexpected and sub-optimal behaviour, does anyone have any thoughts on this?

I think we were very spoilt by the Classic Beyonwiz devices. They have set an feature and expectation level that surpasses the norm for other such products.

While I would love to have more of an EPG history I am not sure how easy it will be to code and deliver. Even if we do get more of a history I don't know if any of the Classic Beyonwiz EPG magic can be offered. (Like pressing RECORD on a past event automatically sets a timer for the equivalent event in the following week.)

I am definitely NOT a fan of moving the now bar to the right to pretend to be offering some history!

Regards,
Ian.

[jpp]

Sorry guys, been absent for a few hours - and it's interesting and gratifying to see so much interest in this topic.

EPG functionality is a primary issue for me, probably #1 issue of any PVR. So yes, I'm passionate about it.

I commented earlier in this thread about the 'keep EPG history' function giving unexpected and sub-optimal behaviour, does anyone have any thoughts on this?

Yep, I noticed . But, I didn't comment on it as I thought it best to keep us on the Now shading/colouring track .

Items (2) and (3) in my 1st post still need to be looked at. I think comments have been made that they are known bugs, so we just need to get to them sometime.

I agree that you can get more now and future program info real-estate by having it hidden "behind" the current time. But I fiddled with the time span period and the old EPG data parameters and came up with what I have now. Seems to work pretty well for me now - enough old EPG data and a not too long a now and future time span. When I scan the EPG for what I want to see next, I don't really need to be 3 hours ahead - that's often more than 2 shows. I have 15 min for Keep old EPG and 150 min for Time scale. The first option is set in the Master Menu under Setup and the second in the Menu whilst in the EPG. Using the Picons only (and not the service names) also helps to gain some real estate.

[prl]

The current different event states that affect colouring are: selected/not selected and no timer/rec timer/zap timer (rec+zap timer is treated as rec timer), 6 backgrounds in all.

When I was testing last night, the rec+zap events were not getting any shading at all. They just showed as normal events.

When using the text epg they show as red like a record timer but when I switch to graphics epg they are shown without a coloured background, so I agree that this appears to be a bug.

Agreed. It has the right background when selected, but the wrong one when not selected.

Bug #441: "Zap and record" timers are not coloured correctly in Graphical EPG

Fix submitted to the source repository. Coming soon to a beta update near you.

[simoncasey]

Sorry guys, been absent for a few hours - and it's interesting and gratifying to see so much interest in this topic.

EPG functionality is a primary issue for me, probably #1 issue of any PVR. So yes, I'm passionate about it.

I commented earlier in this thread about the 'keep EPG history' function giving unexpected and sub-optimal behaviour, does anyone have any thoughts on this?

Yep, I noticed . But, I didn't comment on it as I thought it best to keep us on the Now shading/colouring track .

Items (2) and (3) in my 1st post still need to be looked at. I think comments have been made that they are known bugs, so we just need to get to them sometime.

I agree that you can get more now and future program info real-estate by having it hidden "behind" the current time. But I fiddled with the time span period and the old EPG data parameters and came up with what I have now. Seems to work pretty well for me now - enough old EPG data and a not too long a now and future time span. When I scan the EPG for what I want to see next, I don't really need to be 3 hours ahead - that's often more than 2 shows. I have 15 min for Keep old EPG and 150 min for Time scale. The first option is set in the Master Menu under Setup and the second in the Menu whilst in the EPG. Using the Picons only (and not the service names) also helps to gain some real estate.

EPG showing past EPG and time span.png

It's interesting to see your timescale and epg settings as I think this may be exacerbating item no 2. I had it happen to me yesterday after the epg was open for a while. I think it occurs when the time moves forward into the next program and you can't go back to the previous day as it has lost that from the current timescale. Or something like that. It's hard to replicate as you have to time it just right, but with a smaller timescale it would be more obvious.
Next time it happens, try moving forward to the next page with the arrows and then go back a day.

[jpp]

It's interesting to see your timescale and epg settings as I think this may be exacerbating item no 2. I had it happen to me yesterday after the epg was open for a while. I think it occurs when the time moves forward into the next program and you can't go back to the previous day as it has lost that from the current timescale. Or something like that. It's hard to replicate as you have to time it just right, but with a smaller timescale it would be more obvious.
Next time it happens, try moving forward to the next page with the arrows and then go back a day.

Yes, I have tried just doing that, but have never been able to get back to the current day. It seems to happen when you get close to the end of the current day, i.e. typically after about 9pm.

Whilst on manipulating/massaging the EPG, another issue I'm seeing is the random function of some of the other EPG format controls/selection that are accessed by using the numeric keypad.

For example, using 7 to toggle the number it items/lines on the EPG is a bit of a hit and miss. The first time you use it, it works properly and almost doubles the number of services, in my case from 8 to 13. Toggling this a few times eventually leads to the breakup or distortion of the text and often does not allow you to come back to the original 8 services. Note that it still shows 8 channels, BUT, they are compressed and don't fill the whole screen space any more. See below

Sometimes it works properly and you have the nice results as below. Note that this time, it only shows a total of 12 channels - not 13. Getting back to the normal EPG layout often requires a few Exits and EPGs and then sometimes a bit more fiddling with no 7 on the keypad to bring it back properly.

I've been playing around with some of the other numeric keypad selected EPG option and there are a few other gremlins with them as well. I'll document these later.

[simoncasey]

Ok. I can now reproduce the problem where you can't go back to today by using the channel buttons.
1 open epg and move to tomorrow using channel up
2 use channel down to successfully move back to today to confirm it works
3 use channel up to go to tomorrow
4 arrow left to move to a time that is before the current time
5 if you arrow right to a later time, you will be unable to channel down and get back to today.

[prl]

The way that time is represented when you move through the EPG is a bit weird. None of that surprises me a great deal.

I an getting a bit concerned, though, that this topic is turning into a monster that will eventually have every possible enhancement to the EPG and all the bugs that have ever existed in it, or will ever exist in it

[simoncasey]

The way that time is represented when you move through the EPG is a bit weird. None of that surprises me a great deal.

I an getting a bit concerned, though, that this topic is turning into a monster that will eventually have every possible enhancement to the EPG and all the bugs that have ever existed in it, or will ever exist in it

Do you want me to break out the reproducible issue where you cant get back to today as a separate topic?

[prl]

Maybe start a new topic on time navigation errors in the EPG, and start it with that one.

[simoncasey]

Maybe start a new topic on time navigation errors in the EPG, and start it with that one.

Done

viewtopic.php?f=47&t=9920#p132878

[jpp]

Ok. I can now reproduce the problem where you can't go back to today by using the channel buttons.
1 open epg and move to tomorrow using channel up
2 use channel down to successfully move back to today to confirm it works
3 use channel up to go to tomorrow
4 arrow left to move to a time that is before the current time
5 if you arrow right to a later time, you will be unable to channel down and get back to today.

Thanks for nutting this out Simon. I note that you have moved the EPG time issues to a new Topic.

[prl]

...
For example, using 7 to toggle the number it items/lines on the EPG is a bit of a hit and miss. The first time you use it, it works properly and almost doubles the number of services, in my case from 8 to 13. Toggling this a few times eventually leads to the breakup or distortion of the text and often does not allow you to come back to the original 8 services. Note that it still shows 8 channels, BUT, they are compressed and don't fill the whole screen space any more. See below. ...

I can replicate this, and I think I know how to fix it.

Bug #443: Repeated pressing of 7 in graphical EPG doesn't toggle item height cleanly

[prl]

Another EPG bug.

In the Graphical EPG, if you set MENU>Time scale to be not an even number of hours and greater than 180 min (e.g. 210 min), the time scale drawn at the top of the menu has 60-minute intervals, but is stretched so that there are only even one-hour intervals that incorrectly span the whole screen, instead of correctly scaled intervals, the last one being 30 min and the rest being 1 hour.

I've found the cause, and I think I should be able to generate a fix fairly easily.

[prl]

Bug #444: Time tick marks sometimes displayed incorrectly in Graphical EPG

I have a fix for this in test.