Unified PVR front-end: Skinning the EPG TV-Guide GUI (feedback from skinners wanted)

[alcoheca]

So from what I've found out it looks like new controls will be needed to skin the EPG (tv-gude) gridview.

I'd also like to investigate setting the horizontal time span by aspect ratio. (To avoid having the grid compressed for 4x3 display owners. In their case it makes more sense to display less hours than to try and display the same amount of info in a reduced screen area.

Could we let the user choose the number of channels vertically? Does this make life much harder for skinning?

I'd welcome the skinner's POV on these points, let me know what you want or need..



Proto-crappy mockups

http://xs128.xs.to/xs128/08255/epg1935.jpg.xs.jpg (http://i286.photobucket.com/albums/ll90/alcoheca/epg1.jpg)

http://xs228.xs.to/xs228/08255/epg2719.jpg.xs.jpg (http://i286.photobucket.com/albums/ll90/alcoheca/epg2.jpg)

http://xs228.xs.to/xs228/08255/epg3333.jpg.xs.jpg (http://i286.photobucket.com/albums/ll90/alcoheca/epg3.jpg)

[NineT9mustang]

Love it, I hope it takes advantage of a 720p display and shows many channels at a time :)

Id say more, but we've already talked :P

[alcoheca]

Love it, I hope it takes advantage of a 720p display and shows many channels at a time :)

Id say more, but we've already talked :P

That's basically the main thing for me, having the grid scale in a smart fashion for the big variances in available screen space.

[Rand Al Thor]

Looks quite nice so far. Without being able to see what is going on "behind the scenes" I would say if you had an option to select how many time blocks are visible on the screen that it *shouldn't* effect skinning. The time block unfocused and focused colors could just be 1px images that would fill the area as required. This might not work, as I said I don't really know what or how you have coded the thing. It seems like the easiest way to do it would be to have predefined areas, ie focused button, unfocused, panel width, panel height, genre(sports), genre(comedy), button locations etc. Then the skinner can just edit the xml to match their skin. That would still allow the skinner to edit the layout of the epg to match their skin. It would also make it easy to add a PMIII epg to skins that the skinner has stopped working on as you could just copy the default from PMIII. They would be missing some textures but it would work. The only thing i worry about is that if the skinner changes the width/height of the panel the epg would have to do the math dynamically to put in the proper amount of rows/columns as selected in the epg settings menu. Unless you want to leave the rows/columns # up to the skinner which I personally think would lead to users have less choices. Just my random thoughts on it. Cheers.

[alcoheca]

BTW These are compositions made in photoshop, not actual skins

[alcoheca]

..[snip]..It seems like the easiest way to do it would be to have predefined areas, ie focused button, unfocused, panel width, panel height, genre(sports), genre(comedy), button locations etc. Then the skinner can just edit the xml to match their skin. That would still allow the skinner to edit the layout of the epg to match their skin. It would also make it easy to add a PMIII epg to skins that the skinner has stopped working on as you could just copy the default from PMIII. They would be missing some textures but it would work. The only thing i worry about is that if the skinner changes the width/height of the panel the epg would have to do the math dynamically to put in the proper amount of rows/columns as selected in the epg settings menu. Unless you want to leave the rows/columns # up to the skinner which I personally think would lead to users have less choices. Just my random thoughts on it. Cheers.

I *do* want to leave the numbers of rows & columns up to the skinner.
For instance with a 1080p skin with acres of room, they can have 15 channels vertically, whereas with PAL 4x3 you wouldn't want more than 6 maybe, text would get too small.

Or another way: you have a 1080p skin with two views. One where the EPG fills the whole screen, the other where the EPG is half the screen height, with the rest transparent showing the video underneath. Ideally these decisions would be made in the skin, not the coding.

All I need to know is howmanychannels*howmanyhours of EPG to queue up, otherwise you'd get the same in both circumstances, and the skin would have to squash the layout for the second scenario.

[Gamester17]

I'd also like to investigate setting the horizontal time span by aspect ratio. (To avoid having the grid compressed for 4x3 display owners. In their case it makes more sense to display less hours than to try and display the same amount of info in a reduced screen area.Yes that is why XBMC skinning-engine suppors using different XML files for each resolution and aspect-ratio. For example the Project Mayhem 3 skin takes advantage of a 16:9 widescreen non-HDTV display in by displaying one more colum of movie-covers when in 16:9 mode compared to 4:3 mode (IIRC PM3 displays 4 movie-covers horisontally while in 16:9 mode, and only 3 movie-covers horisontally in 4:3 mode). Also in 720p (which is always 16:9 aspect-ratio) the PM3 skin displays even more covers both horisontally and vertically, and in 1080i/1080p even more than 720p (I think).

I *do* want to leave the numbers of rows & columns up to the skinner.
For instance with a 1080p skin with acres of room, they can have 15 channels vertically, whereas with PAL 4x3 you wouldn't want more than 6 maybe, text would get too small.Great!

[alcoheca]

Hi Gamester17,

I still need to know the size of the numChannels*numTimeUnits grid which would make up the on screen EPG. Those values would be used while navigating up/down/left/right.

I could retrieve the values during the xml loading stage. At the moment this seems like the most sensible way.

On a related note, what about allowing the user to fine tune this? The space in the skin allocated would not change size, but the griditems (the coloured blocks representing programs in a timeline) would then expand or reduce, including the text. Only reason I want to mention this is I don't mind small text on screen, when others get headaches looking at them. Might be good to allow for this. (More useful than just increasing the font size alone).

[Jezz_X]

OK well here are my ideas on looks and use that I discussed with alcoheca on irc just now (forgive the broken english just pasting bits of the chat)
First the mockups

http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup1.png

http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup2.png

http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup3.png

here is how it work work nav wise

start with this http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup1.png press A get this http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup2.png exit out of dialog press Y get this http://i13.photobucket.com/albums/a273/Jezz_X/tvguide_Mockup3.png press Y again back to first one

you could even add a context menu (right click button thing) for selecting days in the EPG

from a skinner side the things that would need to be set is the position / size of the whole thing the colors/images used for the background squares, the fonts and font collors for each sections, and any extra icons we plan on using

[Rand Al Thor]

Hi Gamester17,

On a related note, what about allowing the user to fine tune this? The space in the skin allocated would not change size, but the griditems (the coloured blocks representing programs in a timeline) would then expand or reduce, including the text. Only reason I want to mention this is I don't mind small text on screen, when others get headaches looking at them. Might be good to allow for this. (More useful than just increasing the font size alone).

That is what i was talking about in my post. The skinner makes the dimensions of the main window which would stay static. Then the user would have an option in the settings menu to select # of columns and # of rows. The skinner would just provide a color for onfocus, unfocus, text, etc. but the program would dynamically scale the boxes per the users preference and fill them appropriately. I think this would lead to more options for the user. Cheers.

[Rand Al Thor]

Ahh, one more thing. Can't edit my previous post. You might want to leave the column that shows channel # and logo static and up to the discretion of the skinner so that that column doesn't get scaled too small to see the channel logos. Just a thought.

[pike]

@ Rand Al Thor, you can now ;)

[Rand Al Thor]

Nice one Pike. Thanks!

[alcoheca]

Ahh, one more thing. Can't edit my previous post. You might want to leave the column that shows channel # and logo static and up to the discretion of the skinner so that that column doesn't get scaled too small to see the channel logos. Just a thought.

I totally agree - I doubt that column will scale at all with these user options. What I'm talking about is a +/- 1 unit of fine tuning for number channel rows vertically and number of time units horizontally. The emphasis firmly being on fine tuning. I think you were suggesting more control to choose more extreme grid dimensions?

[jmarshall]

To be honest, I'd tend to be a little hesitant to allow users to change the layout too much. The skinners know what they're doing and what looks good within their skin and works well from a usability point of view (for the most part). This is what they do "for a living" after all.

I guess it depends on the resolution to some extent though. Larger numbers of pixels to play with allows more options in some respects.

Navigation-wise, I'm thinking we can show 24 hours at a time (i.e. from the start of the current timeblock), with free scrolling horizontally within the 24 hours and then a jump to the next block, or, if we can get away with it memory + loading-wise free scrolling right up to the end of the EPG information.

Vertical scrolling would be like the normal list controls today. Whether or not we need to be able to navigate away from the grid (i.e. we'd currently be trapped if we use the dpad to navigate) needs to be considered as well.

Cheers,
Jonathan

[alcoheca]

To be honest, I'd tend to be a little hesitant to allow users to change the layout too much. The skinners know what they're doing and what looks good within their skin and works well from a usability point of view (for the most part). This is what they do "for a living" after all.

I guess it depends on the resolution to some extent though. Larger numbers of pixels to play with allows more options in some respects.

I suppose we could wait and see if there's an outcry for it, I don't mind retro-fitting it if the need exists.

Navigation-wise, I'm thinking we can show 24 hours at a time (i.e. from the start of the current timeblock), with free scrolling horizontally within the 24 hours and then a jump to the next block, or, if we can get away with it memory + loading-wise free scrolling right up to the end of the EPG information.

Vertical scrolling would be like the normal list controls today.

Sounds like good values to start with.

Whether or not we need to be able to navigate away from the grid (i.e. we'd currently be trapped if we use the dpad to navigate) needs to be considered as well.

I guess this depends on where we want to have the "extra" info and controls that we will need for the day to day runnings of a backend. If there was a status bar beneath Jezz_X's grid then that could show contextual information. For example - you hit record on a grid item and the subsequent available recording space is printed to the status bar.

If we go for tight integration with current XBMC way, then options to force an EPG update/reboot the machine/reload drivers could be placed in TV Settings page. The tuner strength, general server status would be found in the system information window.

Alerts could be used to warn the user of problems.

[Livin]

my $.02,
There are some great guides avail free on the internet that have gone through several iterations and tweaking over the years... two of the biggest are zap2it.com & TitanTV.com (IMO, the most flexible/useful/robust).

I suggest checking them out as it should give you some ideas.

[Rand Al Thor]

I totally agree - I doubt that column will scale at all with these user options. What I'm talking about is a +/- 1 unit of fine tuning for number channel rows vertically and number of time units horizontally. The emphasis firmly being on fine tuning. I think you were suggesting more control to choose more extreme grid dimensions?

I was thinking something similar to what myth currently uses. In my mythweb page I have 6 columns going across and it is split up into 30 min increments so I can see 3 hours worth of information at a time. In the myth settings you could change either of those numbers to fill the screen with as much or as little information as you feel comfortable looking at. As you mentioned earlier some people don't mind smaller text. So, what I am envisioning is the skinner would specify the overall measurements of the grid and then the user could select what ever scheme they feel comfortable with. This is just a suggestion. Obviously since I am not coding it I will be more than happy with what ever you come up with ;)

As for extra info, I can see what you mean about getting "trapped" on the grid. On linux/windows you could use tab or something to jump between the two. I am sure you could find an unused button on the xbox controller to do the same specifically in the EPG. You weren't planning on making the locations of the extra info static where you? I can see a lot of really cool layouts coming out of this if the skinner can place the ep info, now playing window controls etc in a way that fits the specific skin. Hmm lots of cool stuff to think about. Cheers.

[Jezz_X]

here is a better explaination on how I think the concept interactions should work

http://img103.imageshack.us/img103/6386/tvguidemockup4lm2.png

[alcoheca]

I was thinking something similar to what myth currently uses. In my mythweb page I have 6 columns going across and it is split up into 30 min increments so I can see 3 hours worth of information at a time. In the myth settings you could change either of those numbers to fill the screen with as much or as little information as you feel comfortable looking at. As you mentioned earlier some people don't mind smaller text. So, what I am envisioning is the skinner would specify the overall measurements of the grid and then the user could select what ever scheme they feel comfortable with. This is just a suggestion. Obviously since I am not coding it I will be more than happy with what ever you come up with ;)

For the sake of simplicity what about an EPG size control, with condensed, regular or expanded. Wouldn't that suffice? I'm not totally convinced people need more control than that. The time is now for people to convince me otherwise ;)

As for extra info, I can see what you mean about getting "trapped" on the grid. On linux/windows you could use tab or something to jump between the two. I am sure you could find an unused button on the xbox controller to do the same specifically in the EPG. You weren't planning on making the locations of the extra info static where you? I can see a lot of really cool layouts coming out of this if the skinner can place the ep info, now playing window controls etc in a way that fits the specific skin. Hmm lots of cool stuff to think about. Cheers.

It would be nice to hear what any other skinners think they'd like from this window. It's hard for me to gauge opinion at the moment.

[Rand Al Thor]

well just a few thoughts... A skin like Aeon could have the now playing video full screen behind the Aeon Glass. The episode info could exist in the diffused area across the bottom. The epg could fit into the existing glass panel with controls across the top matching the Aeon theme. Some other skins might prefer to have the now playing window on the lower left in a small window with episode info right below the epg. I could even see making the epg nice and big to fill most of the screen then if you hover on an item you get the episode info instead of having it showing at all times. Are these the kind of ideas you are looking for from skinners? I'm sure there are other skinners out there willing to throw some creative horsepower at the layout.

[alcoheca]

The layout will always be the skinners territory, and so I don't really mean to get into that... I'd rather hear if people want all the extraneous crap I included in my mockup. How sophisticated do people want their skins to look, all bells and whistles; minimalist; somewhere in between?

My third mock up tried to cover all bases, and so its cluttered as a side effect. I was trying to think of all the likely contenders for inclusion in an EPG. I've used some truly awful EPGs in my life, and so the idea is to try and do something worthwhile this time. Striking the balance between having a sophisticated EPG that makes remote management of your PVR app all but unnecessary and getting something solid and simple to use seems pretty crucial.

[Nuka1195]

The more info you provide, the more options skinners have.

If you provide this information by using properties, they can choose to use it or not.

[alcoheca]

hi nuka1195.

That's the plan as of now, I hadn't noticed the whole SetProperty method until you mentioned it.

So each programme will be contained in a CFileItem, with the PVR specific stuff set as properties. Skinners can then choose whether or not to include the description property for the current selected programme in their layout.

[lingenfr_xbmc]

Don't want to make anyone mad, but I think the EPG provided by the xbmcmythtv script is pretty good. If I could use it to select/play livetv, it would pretty much meet my needs.

[alcoheca]

Don't want to make anyone mad, but I think the EPG provided by the xbmcmythtv script is pretty good. If I could use it to select/play livetv, it would pretty much meet my needs.

and you're mentioning this in the skin development forum because....?!

;)

[lingenfr_xbmc]

Well... since Rand was making a comparison to AEON (a fine skin) and the title of thread references the EPG, I thought the developers might want to take a look at the EPG in xbmcmythtv as a starting point or an example. In the future if you have a problem with a post, you might try a PM rather than cluttering up the thread. Cheers.

[alcoheca]

hey there,

I really didn't have a problem with your post, truly sorry you felt that. I do welcome all input. I was just curious... or looking for some more clues. To my very sleepy eyes it almost looked like a feature request for a script. Now of course, I can totally see it's not.

downloading xbmcmythtv to have a play with it as it's been a while since I last tried it out. I'm working on the epg grid right now, so all going well I'll have something up and running really soon. (then the abuse begins ;) )

[deeceefar2]

My thoughts on some configuration areas for the EPG. I've seen alot of bad EPGs in the tv apps I've tested and only a few good ones. So I set the bar pretty high, obviously all of these things don't have to be implemented on the get go, and perhaps some of these options are niche. None the less I figured I should list out all features and information I've seen in guides, and let you choose what you think fits. Main thing to nail down is storing all the information that is required so there doesn't need to be updates to the DB schema to get more information added into UI.


EPG INFO:


guide display configuration:


time units, 24 hours or 12 hour time
number of channels to display in rows
number of time slots to show for columns on the top
size of time slots: 15, 30, 60 minutes etc.
pixels per time slot
icons indicating scheduled to be recorded or scheduled to tune to
which language of the guide should it retrieve?
sort options, ascending descending: channel name, number
perhaps sort popup to choose which way to sort
display icons or channel abbreviations?



channel information:


channel icon
channel abbreviation: KWTV, FOX, FOXMO, HBOW
channel name
channel number
channel description
type of station i.e. radio, tv, PPV, dvr
categories: sports, local, movie, etc.
arrow indicating if the program goes past the edge of the display



Program information:


Duration, start time, end time, next showing
feature icons or text abbreviations: Close Captioning, Dolby Digital, tv rating, alternate languages, etc.
program description
program title
program genre
program rating
record, schedule, tune buttons
preview button? (keeps tuned channel in memory, pops up small window with new channel starts streaming, if selected, becomes current channel, if not tells tuner to go back to old channel)


features:


program slots don't have to match time slots i.e. 1:45 minute movie lasts 1 3/4 1 hour slots
number of programs in cache set as a function of channels time time slots (perhaps an advanced configuration option)
program information is configurable enough to be able to be displayed as scrolling through channels in a mini display the top of the screen, as well as in a pop up window with full information and tuneing buttons
selecting channel while on main epg display has option to tune directly to channel or to pop up question of schedule, tune, or record
is recording a sub option of schedule, or its own separate entity i.e. do you first click schedule to record something or do you display the option to record along side scheduling? perhaps call it schedule event i.e. record event, tune event
categories of channels: sports, favorites, locals, etc
multiple sources on 1 guide, but separated into sources: OTA, DVB



CURRENT CHANNEL INFO:


current channel bar:


info and icons from program information in epg
icon indicating pending scheduled event within configured duration of current time, configurable check frequency?
resolution mode: strech, normal, custom, etc.



scrolling channel bar:


scrolling channels and programs on a channel



information pop up:


pretty much identical to program epg popup
has tune/schedule event buttons if it is not the current channel


I ran out of steam for tonight, more on scheduling soon as I can.

[dteirney]

I've been looking forward to finding out how the MythTV integration with XBMC will go. I found this so here's my $0.02 for the EPG.

I'm a big fan of user stories - I have a personal dislike of feature lists because they don't have enough context and you can't tell if the feature will actually help you do something useful. These coarse user stories are based on how I currently use the EPG in the native MythTV client on the MythTV backend server and through the the old xbmcmythtv Python script which is now more or less dead with the new myth:// protocol support.

As a user within the EPG:

I want to find out what shows are on now on so I can choose which one to watch right now. Close integration with Live TV would be great. Perhaps Live TV goes straight to EPG at the current time?
I want to find a program in the EPG so I can schedule it to record (with all of the options, ie. once only, once every week, every week in this timeslot etc.) Please don't only allow me to scroll across the screen half an hour at a time - sometimes I just want to scroll quickly through to Thursday (from Monday) to schedule the new Lost series - I don't want to scroll past whole nights of informercials. As an aside, MythTV has an awesome interface for finding a program if you know it's name. You should probably have a look at that and see if that is in scope for what is being proposed for this PVR frontend stuff in XBMC. I would have thought so as that's really the only other part of the MythTV interface we use, but who knows...
I want to see which programs are scheduled to record and which ones can't be because there is a conflict (possibly because there are not enough tuners available) so I can make sure a show is going to record (lest the WAF factor decrease) and to potentially override which show doesn't get recorded in the case of conflicts.

Below are some of the irritating things from other EPG implementations:

Trying to show too much at once. I really don't care too much about seeing the synopsis of the show directly on the screen. If I care I'll drill down somehow. Use that real estate to show the first order information that really matters - channels, programs and statuses of programs.
Not formatting dates and or times usefully. This is a pet peeve of mine. Most people know that Lost is on Thursday night at 8:30. Yet the EPG and other areas showing when it is on or will record never show the day of the week, just the date. Please consider using the day of the week in the EPG dates and remove all the other repeated stuff, i.e. show "Sat 16" and "Sun 17" instead of "13/06/2008" and "14/06/2008". I know it's 2008 and I can probably guess it's June because the EPG only ever holds 8 days of data (here in New Zealand at any rate). As a bonus it takes up less space and you don't have to worry about those of us who prefer dd/MM/yyyy rather than MM/dd/yyyy.

Below are some of the great things from other EPG implementations:

Icons for the channel. These are great and quick visual cues that work well when finding the right row in the EPG.
Fast!. The MythTV EPG is really fast to load, whereas the xbmcmythtv one could take up to 10 seconds to load. I stopped using the xbmcmythtv one because of that.

That's pretty much it for me at the moment. I don't really care about things like color coding for categories of TV show (eg. sports, cartoons) because the EPG here in New Zealand is very sparse on information like that.

Cheers,
David

[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.

http://www.radioandtelly.co.uk/images/skyhd_epg.jpg

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.

http://www.radioandtelly.co.uk/images/skyhd_epg.jpg

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:
http://www.ideamaster.com/budget/1lineg.jpg

An example of onscreen program information:
http://www.ideamaster.com/budget/tinfo.jpg

An example of program guide with current channel scaled in top right corner:
http://www.ideamaster.com/budget/pipg.jpg

[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

http://img84.imageshack.us/img84/1097/latestepgxf3.th.jpg (http://img84.imageshack.us/my.php?image=latestepgxf3.jpg)

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:

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

<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:

<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 ;)

[deeceefar2]

Looks great alcoheca. Awesome job on the configuration options too; it seems to be very flexible which I'm sure skinners will appreciate. Keep up the good work.

Some features to consider for the future:
1. icons indicating a show goes past the edge of the display.
2. ability to set word wrap on title display boxes
3. elipses to indicate a title is truncated

[arkay]

Hi,

Great work so far!

Been watching this project with great interest and while I have no idea about the coding behind it I thought I'd mention some things you may wish to consider along the way. Even if they can be included much later on after GSOC.

This post probably doesn't belong in a skinning forum though the content would affect skin development. Apologies if ti's the wrong place to post it :blush:

One thing I find with XBMC is that it's just better than every other HTPC app in terms of it's intuitive behavior.

Most guide implementations are not intuitive and the vast majority of them follow a similar 24hr grid theme. It's a difficult thing to do well but it would be awesome if XBMC could do it better.

I've been thinking about viewing habits (mine in particular), but I would think they are relatively common.

The vast majority of the time I'm only interested in seeing what is on via the guide during prime time. say 7pm -> midnight. For anything else I would use search functions to find it as I'm not going to scroll through 24 hours of programming every day looking for a program. This is particularly relevant when I'm looking for content I might like to record for later viewing.

Would it be possible to code for customised easily switchable "views" of the guide. Even if only used for scheduling recordings. So you could for instance have channels listed across the x axis and display all programming between 7pm->midnight (user definable) down the y axis with say the "skip" right function on the remote jumping to the next "primetime" day. That way the end user could very quickly search through the entire weeks primetime viewing with only 7 presses of the remote? Only titles should be displayed but a full synopsis should be shown below as any individual title is highlighted.

It'd also be great if I were able to add exclusions to my guide. i.e. Instead of marking series I want to record I'd also like to mark series that I don't want the guide to show at all. So I could exclude any reference to reality TV shows, the news, etc etc.. With enough exclusions all that should be left is anything that is new or that I am interested in. It should be able to exclude entire categories like "Chick Flicks!" :) It's a reverse way of viewing the data but could be very powerful when set up correctly as the guide displayed on screen could potentially not have data for days, allowing that space to be reclaimed and I might get a list of days worth of shows I'm interested in all on one screen simultaneously. Maybe you could call it a "favorites" view allowing options to mark favorite shows, exclude disliked shows and display everything else as uncategorised until tagged as a favorite or excluded. It would take some work to set up but would make browsing for new and interesting content much much faster.

Could it work? Is it viable for an end user... I dunno. Just trying to think up some new innovative ideas to give XBMC the edge ;)

Having used many guide implementations I feel there has to be better ways of displaying the data than the 24 hour grid method they all adhere to.

Just some ideas at any rate. Keep up the great work, I'm very appreciative of what you're trying to achieve and the XBMC project as a whole!

Cheers,

Arkay.

[arkay]

On further thought maybe it could just be a rule generator similar to what myth has. i.e. Allow rules like:

1. List only programs in a specific category.
2. Only on in within a set time range.
3. Include tv shows
4. Include Movies
5. Exclude specific title via pattern match.

The end user could then define a guide view that displays only:

"All sci fi and police drama shows and movies on between 7am and midnight every day except those that match "X files" etc etc..

A quick and easy way to specify the content any specific user may want to record.

I admit it's probably way out of scope just yet but thinking early on about how something might end up can be advantageous.

Cheers,

Arkay.

[alcoheca]

Hi Arkay,

I definitely want to have filtered views, similar to Video library, but I was imaging the results being displayed in a regular list.

So you're looking at the tv guide grid, you push a button and you choose which view you want to focus on. 'All films starting in 3 hours' that sort of thing.

Actually messing with the grid in that it would only show certain time ranges is probably counter intuitive and would require the grid code to be reworked.

The grid *will* have an option to view favourite channels only though. (So for me it's bye bye to any shopping, or premium rate phone-in quiz channels etc)

[Freddo]

Obviously its a bit soon for feature requests but I was just thinking it'd be great if XBMC could keep track of how often/how much you watch particular channels, so you could sort it by watched time and have your most watched channels bubble up.

Just wanted to get that down somewhere before I forgot I thought of it.

[jhhbe]

hi,

If you are stuck for inspiration you may want to look at BigBellyBillies MyTV guide which can be extended with python plugins to provide guide data. He has also a plugin to set recordings. His setup is quite smart but a bit less ambitious than this project.

The good thing in getting the data from the backend is that in some cases the backend has given a program or show an identification. If you want to set a recording this id may be all it requires rather than channel; start; end.

I did a plugin for SageTV epg data for the MyTV guide and if your setup would allow python datasources then I certainly want to give this a try as well - currently we use the SageTV XBMC script for which epg functionality is not so great.

I'm really keen to see how far you get with this one - so far it looks very promising. It's a good idea to let the backend do what it is good at and same for the frontend as you are doing.

Good luck!
Jan