"Rating" in cached event details xml

[zehd]

Without genre in the EPG_EVENT table, it would mean nothing to me. Sub has said he didn't want to add this so I can live with this for me it is was a nice to have. In SearchLite I distinguish movies from sports and other shows using the unique_id information here in North America, and that would be good enough for me for the EPG

Martin

You're right... getting used to the new format... yeah the genre would need to be in the EPG EVENT Table to show up in the TV Guide..

But isn't the 'slowness' of genres related to linking several tables at TV Guide Display time? Oh well

[zehd]

sub had said before that GBPVR's method of handling genres was complicated, due to multiple tables and trying to tie all the relationships back together. That's why I thought a simpler - hardcoded - solution might be better.

I'm maybe misunderstanding it, but why can't EPG_EVENT just have an extra couple of columns for genre and colour. It could then be up to plugins, externals tools, etc to populate that if sub doesn't want to. Then all the TV Guide would have to do is look at the entry for each title it has to paint anyway, and change its colour only if required (on the assumption that most people wouldn't pick a custom colour for every genre type).

I can't see how any lack of table normalization really matters in this case. So what if the table contains 10,000 fields all labelled "movie"? Search plugins could still find them all searching every row. I doubt performance would really be an issue, would it?

Iain

From what I understand... I agree... There be other reasons...

[sub]

The issue was really the one to many relationship. For example, Schedules Direct and xmltv files would often provide 4 or 5 Genre's per show (for example, 'movie' 'comedy' 'romantic'). To support this GBPVR had a couple of extra tables (one for the genre's, one for the relationship mappings between show and genre). This relationship complicated the act of loading or saving listings, and slowed things down significantly, and complicated the behind the scenes code (adding stuff like demand-loading to work around the slow downs, updating multiple tables when saving listings etc).

I did consider NPVR adding a 'genre' field to the EPG_EVENT table, and just have a comma separated list of genre values for those plugins that want to use it. I decided against this. Users often have a couple of hundred thousand listings, so this could be painfully slow to do searches on (even to get the list of genre names that have been seen to-date).

[mvallevand]

Is there confusion we might be agreeing. I am always been 100% in favour of a genre field in EPG_EVENT and if it was transferred to event_details field in SCHEDULED_RECORDING, some plugins might use it. Like you I don't feel sub needs to populate them. If you are saying that sub also needs to respect user fields I think it is his prerogative to decline.

Martin

[imilne]

I did consider NPVR adding a 'genre' field to the EPG_EVENT table, and just have a comma separated list of genre values for those plugins that want to use it.

I'll admit this is something I hadn't considered. But colours could still work with it by having them assigned by priority, eg, if a field contained "movie" and "drama", then it could get the movie colour if that was a higher priority to the user than drama.

Users often have a couple of hundred thousand listings, so this could be painfully slow to do searches on (even to get the list of genre names that have been seen to-date).

Hmm. Obviously without trying it I have no idea how long it would take to search through 200,000 rows, but I still can't see it being that bad would it? Regarding the list of genre names, couldn't they just live in a separate table with no links back to the listings. It could just be refreshed with all the genre types seen during an EPG update (and it would be easy to track unique entries with a simple hashtable). Then that list could be used to offer the user possible genres types to search on.

Like you I don't feel sub needs to populate them. If you are saying that sub also needs to respect user fields I think it is his prerogative to decline.

Absolutely, but hey, I'm ever the optimist

Plus I still enjoy discussing how things might be implemented even if they don't happen. Who's to say sub won't turn around in a year's time and think: "mmm, genres".

Iain

[mvallevand]

I like talking theory too. If we ignore the really common noise values of Series Episodic, and Other, at least for my gbpvr.db3 it would be very fast

Code:

select genre_name,count(genre_name) from genre,programme_genre,programme where programme.oid = programme_oid  and genre_oid = genre.oid group by genre_name order by count(genre_name) desc

Series|19826
Episodic|9920
Other|7597
Comedy|2679
Children|2027
Reality|1903
Talk Show|1511
Drama|1233
Educational|1101
Public Affairs|876
Home and Garden|854
Animated|687
Documentary|615
Movie|606
Cooking|569
Action/Adventure|564
Religious|511
Game Show|506
Sports|442
Special|432
Current Events|332
Travel|247
Music|191
Science|180
Soap Opera|168
Adventure|159
Health|124
Hockey|113
Suspense|111
Action and Adventure|10
Weather|101
Interview|98
How-to|75
Basketball|61
Arts|54
Romance|49
Exercise|39
Fantasy|38
Awards/Event|37
Baseball|36
Outdoor|36
Science Fiction|35
Horror|34
Racing|27
Business|24
Miniseries|22
Western|20
Biography|17
Collectibles|14
Golf|13
Boxing|10
Mystery|10
Holiday|8
Soccer|6
Tennis|5
Outdoors|3
Musical|2
Football|1

Martin

[zehd]

I'll admit this is something I hadn't considered. But colours could still work with it by having them assigned by priority, eg, if a field contained "movie" and "drama", then it could get the movie colour if that was a higher priority to the user than drama.

Hmm. Obviously without trying it I have no idea how long it would take to search through 200,000 rows, but I still can't see it being that bad would it? Regarding the list of genre names, couldn't they just live in a separate table with no links back to the listings. It could just be refreshed with all the genre types seen during an EPG update (and it would be easy to track unique entries with a simple hashtable). Then that list could be used to offer the user possible genres types to search on.

Absolutely, but hey, I'm ever the optimist

Plus I still enjoy discussing how things might be implemented even if they don't happen. Who's to say sub won't turn around in a year's time and think: "mmm, genres".

Iain

I thought about it as 'Can we have those columns in the EPG_Events (Genre, and aRGB) and a 3rd party would fill in the values?'... doing something like imiline suggested, where the program would use priorities to assign colours.

Yes it would be nice if there would then be a propagation of that data to the event xml in the recordings... but the third party app could do it too

Yes... the TV Guide would either need to be designed to use the Genres and the Colours... Of course the alt would be an alt TV Guide plugin..... It is my belief that if the colour is already picked and saved with the Record, the TV Guide display Cell would not need to think (or search) before it rendered...

I never suggested that Sub would confound the database by any more of the one to many relationships...

Anyway... I think that I've communicated my thoughts well enough.... if it's still something that can't/won't be done... I'll flog myslef

[sub]

I like talking theory too. If we ignore the really common noise values of Series Episodic, and Other, at least for my gbpvr.db3 it would be very fast

Code:

select genre_name,count(genre_name) from genre,programme_genre,programme where programme.oid = programme_oid  and genre_oid = genre.oid group by genre_name order by count(genre_name) desc

Thats the old multi-table approach though, which I'm definitely not doing in NPVR. I know the issues very well that came with that approach, and the complications it added to the code. The closest we'll get to genre in NPVR is a single column in the EPG_EVENT table, probably containing a comma separated list of values.

[mvallevand]

Thanks sub, I wasn't suggesting that method, I was just using that to show that I didn't think a single multi-valued field would be unmanageable from a search perspective. I would like the GENRE table too so plugins can use common oid's.

Martin

[mvallevand]

For some fun last night I tried simply attaching both NPVR and GBPVR tables to do genre searches in SearchLite and it actually is much faster than I thought it would be. Rather than adding a genre field with combined values, which will make it hard to create a list for user selection I think I prefer the normalized method used in GBPVR

Before sub adds a genre field I think it might be better to think this out further and come up with a design for a community secondary table that includes a standard genre carpeVideo extends NPVR.db3, UJB has his SchedulesDirect extended table and ailbert has TV Listing.

Martin