[ChristianW]

Please remember that a lot of European channels do NOT use 15/30/45/60 slots and often start shows at 20:25, 19:05, 14:40 etc.
The typical american EPG-grid concept does not easily lend itself to a lot of European channels. But there is not much alternative.

-C-

[Jezz_X]

Please remember that a lot of European channels do NOT use 15/30/45/60 slots and often start shows at 20:25, 19:05, 14:40 etc.
The typical american EPG-grid concept does not easily lend itself to a lot of European channels. But there is not much alternative.

-C-

Then the blocks just start halfway through or where ever their time is not that hard on the concept really. The bits at the top are just to show the current time frame

[Gamester17]

Might it be smarter to just make the blocks as short as 5-minutes?
For 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, and 60 minute blocks

[Jezz_X]

The blocks would be as big as the show is the top is just a guide for the time frame you are in

[ShortySco]

This is how the Sky digital TV guide works in the UK.

Half hour time slots, so if a programme starts at 19.45 then, in the guide, it will be half way between 19.30 and 19.45.

It's fairly highly regarded too i think, very clean and easy to use.



Shorty

[jmarshall]

Obviously this is exactly how things will be done. Programs can start 3 minutes and 28.5 seconds after the hour and it's box will be offset as such.

There is no need for time blocks at all. The only thing we have is a time scale across the top, which can be whatever we like.

[deeceefar2]

This is how the Sky digital TV guide works in the UK.

Half hour time slots, so if a programme starts at 19.45 then, in the guide, it will be half way between 19.30 and 19.45.

It's fairly highly regarded too i think, very clean and easy to use.



Shorty

Please do not follow the sky tv guide. It leaves alot to be desired. A good reference guide I've seen is the Dish tv guide, both the old and new one have very good information organization, though they don't look that pretty they are one of the most functional I've used.

An example of onscreen one line guide:


An example of onscreen program information:


An example of program guide with current channel scaled in top right corner:

[freezy]

another example of a tv guide imho pretty well implemented:

http://tvprogramm.sf.tv/

although it's probably better having the time line as y-axis and the channels in x, so there is more space for channels.

looking forward to the whole pvr-thing!

cheers

[dteirney]

another example of a tv guide imho pretty well implemented:

http://tvprogramm.sf.tv/

although it's probably better having the time line as y-axis and the channels in x, so there is more space for channels.

looking forward to the whole pvr-thing!

cheers

I think it is much better using the other models presented with the channels and shows on a grid. A grid allows the overlapping shows to be seen more easily to therefore identify potential conflicts.

Having said that, seeing overlapping conflicts is hard if they aren't all on the screen. Here in NZ there's less than a dozen free-to-air channels and less than half a dozen channels with content I typically watch so that's not so much of a problem. I can see how that would get to be a challenge when there is a much larger number of channels.

[alcoheca]

[..]
Having said that, seeing overlapping conflicts is hard if they aren't all on the screen. Here in NZ there's less than a dozen free-to-air channels and less than half a dozen channels with content I typically watch so that's not so much of a problem. I can see how that would get to be a challenge when there is a much larger number of channels.

I take it you're talking about recording schedule conflicts? I hope that important status messages such as schedule conflicts, available disc space, signal quality etc will be made available by as many backends as possible. In that case it will be simple enough to alert the user using XBMC. It's not the job of this frontend to handle any schedule logic, and in fact that would probably just complicate matters.

XBMC will always reflect the recordings that are scheduled on the backend. If the PVR app is smart enough to re-schedule one of your recordings automatically, XBMC will adjust accordingly. There will also be a list of timers (scheduled recordings) available to allow easy detection of schedule conflicts, and deletion. Perhaps in the future more sophisticated timer management can be abstracted from the backend.

[dteirney]

I take it you're talking about recording schedule conflicts? I hope that important status messages such as schedule conflicts, available disc space, signal quality etc will be made available by as many backends as possible. In that case it will be simple enough to alert the user using XBMC. It's not the job of this frontend to handle any schedule logic, and in fact that would probably just complicate matters.

My sentence was perhaps too literal because the computer doesn't have to do everything.

Assume the backend supports two tuners. If we can see in the EPG that there are 2 shows already scheduled to record for a particular timeslot, we know that we have to bump/override one of the existing shows before we schedule a new overlapping show to record.

This of course assumes that recording status for a show will be shown in the EPG (as pulled from the backend). It's also easy to see with a small number of channels...

If you haven't already, I'd recommend having a look at the MythTV EPG to see what it supports because it's probably similar to most PVRs.

[alcoheca]

Hi there dteirney,

Recording status will be shown by either an overlaid icon, coloured background, or whatever means. The info will be available for the skinners to do what they want with it. Just like the mockups Jezz_X & I made.

[alcoheca]

Here is a screenshot of the current working TV guide



Right now this is all contained within the new container CGUIEPGGridContainer, that way it's easy to sync up the horizontal scrolling of the grid with the ruler above and the vertical scrolling of the grid with the channels column. However I have been thinking I could use 2 CGUIListContainers and 1 CGUIEPGGridContainer in a GUIControlGroup. That way the elements could be positioned more independently from - though keeping things lined up is still a primary function of a tv-guide. I just thought maybe there would be more scope for interesting layouts if the page was more modular. Happy to hear anyone's views on this.

here's a link to the skin paramaters for the GridContainer:
http://pastecode.com/?show=f6e536e53

points worth noting:
a 'block' is the unit of measurement inside the grid - it represents 5 minutes (subject to change) ...so:

Code:

<timeblocks>36</timeblocks>

is the number of blocks visible on screen at any one point - 36 * 5 gives us 3 hours.

Code:

<rulerunit>12</rulerunit>

is the number of blocks that makes up a unit of the ruler/timeline along the top. so if you give me 12, you get three listitems per page (representing 1 hour each), with <rulerunit>3</rulerunit> you get 12 which is 12 quarter hour slots and so on.

Everything is calculated automatically from these two values and the following pixel values:

Code:

<control type="epggrid" id="20">
      <width>656</width>
      <height>437</height>
</control>
<rulerlayout height="29" width="40">
<channellayout height="34" width="80">
<itemlayout height="34" width="40">

"But how does this work?" I hear you ask.. with help from a new function CGUIListGroup::EnlargeWidth which lets us resize elements of a ControlGroup by ID. So the background of the gridItems is resized along with the Label, but any element without ID of 1 or 2 stays the same size, useful for any overlay graphics skinners will use to signify upcoming recordings etc.

[Jeroen]

Looks awesome I'll sure be looking into this when I'll have a htpc set up. Keep up the great work!

[Rand Al Thor]

Looks great! Can't wait to test it