Feature #3753

xmltv category

Added by edit4ever ! about 1 year ago. Updated 13 days ago.

Status:NewStart date:2017-06-11
Priority:NormalDue date:
Assignee:Adam Sutton% Done:

100%

Category:EPG
Target version:4.4

Description

Would it be possible to just pass through the actual category information that is imported in an xmltv file? Currently it seems Tvh only recognizes the following content:

"Movie / Drama" 
"News / Current affairs"
"Show / Games"
"Sports"
"Children's / Youth"
"Music"
"Art / Culture"
"Social / Political issues / Economics"
"Education / Science / Factual topics"
"Leisure hobbies"
"Special characteristics"

Seems easier to pass through the original category info so the full genre text is displayed in an epg. The current short list creates a lot of "other" displays in Kodi and blank displays in the Tvh EPG.


Subtasks

Bug #4424: XMLTV not parsing category dataRejected

History

#1 Updated by Jaroslav Kysela about 1 year ago

Add missing string to '_epg_genre_names' array in src/epg.c . The xmltv strings are translated to DVB categories.

#2 Updated by edit4ever ! about 1 year ago

Jaroslav Kysela wrote:

Add missing string to '_epg_genre_names' array in src/epg.c . The xmltv strings are translated to DVB categories.

thank you - looks like it was a grabber issue! Now that I know where this is - if I find any additional genres I will submit.

#3 Updated by edit4ever ! about 1 year ago

Fixed the grabber and now I'm passing all the genre (category) names into the xmltv file.

After looking at epg.c it seems like this is a relatively short list compared to what is used here in the US for genre information. Is there a reason to not just pass through the genre names as they are in the xmltv file?

#4 Updated by Jaroslav Kysela about 1 year ago

TVH is being coded in Europe, so we're using the 8-bit value according the ETSI DVB standard - _epg_genre_names table follows this standard. Note that the table is splitted to major / minor part (and only major genre group is filtered in the web EPG window - we just realized that too many categories are not much helpful for the standard usage).

I see two ways to handle additional categories:

- extend the DVB table (handle the clashes which many come with DVB standard updates)
- use own categories mapping (create completely own table and map also DVB genre there)

Could you gather the names of missing categories ?

#5 Updated by edit4ever ! about 1 year ago

Jaroslav Kysela wrote:

Could you gather the names of missing categories ?

I have contacted Gracenote - provider of the data - to see if they can provide a complete list of categories used. I've checked the list in the ETSI TS 102 822-3-1 document and it is quite extensive. I'm happy to parse it and work on extending the table, but will a list that long have any impact on how the program performs? Also - I'm not sure just the major category is enough information. For example - the major category of "Movie" wouldn't tell you "Documentary" or "Western" or "Thriller" which is much more useful information to see in a guide. Seems like at least two levels of content should be passed on.

Another option would be for there to be a setting to select "enable all genre/category/content without filter" - this would just pass all the "category" data through to the frontend and then that system can decide how to filter the data. This takes the burden off Tvh and allows customization based on the frontend system a user chooses to run.

#6 Updated by Jaroslav Kysela about 1 year ago

The current genre scheme follows EN 300 468 - see 6.2.9 content descriptor table.

#7 Updated by edit4ever ! about 1 year ago

Jaroslav Kysela wrote:

The current genre scheme follows EN 300 468 - see 6.2.9 content descriptor table.

Correct - but without including the level 2 information, these genres are too vague to be relevant to the end user. I would be happy to build out the full table in order to enable the level 2 descriptors.

It is often these level 2 descriptors that are the only information input buy the content providers here in the US - therefore most of the epg content fields are empty in Tvh.

Should I rework the epg.c file, test and then submit for pull to enable level 2?

#8 Updated by Jaroslav Kysela about 1 year ago

Ok, let's look to "A.8 ContentCS", you're right that there are up to three level information in the newer standard:

3.1 - NON-FICTION/INFORMATION
3.1.1 - Time-sensitive information
3.1.1.1 - Daily news
3.1.1.2 - Special news/edition

While we have:

1[.1] - Movie/Drama
1.2 - Detective / Thriller
1.3 - Adventure / Western / War

I think that we should improve this and follow the new standard. We can probably use 16-bit unsigned int instead 8-bit value like:

5 bits - level 0 (major)
5 bits - level 1
6 bits - level 2

... and provide mapping from old genre value into this new one.

#9 Updated by Jaroslav Kysela about 1 year ago

  • Target version set to 4.4

#10 Updated by edit4ever ! 12 months ago

In the meantime - I've been experimenting with adding missing genres to the _epg_genre_names array in epg.c

This works well and actually displays the genres in the tvheadend content type field of the web epg. If we could take this string and pass it to kodi as the sGenre field - the string would be available in the epg in kodi. Right now tvheadend is not passing anything to the sGenre field.

Then all that would need to be changed is using a skin that has the option to use the sGenre string instead of the iGenreType and iGenreSubType fields.

This is what I would like to test next, but I need to figure out how to pass the content type string that is used in the tvheadend web interface to the sGenre field in kodi. Any thoughts?

Also available in: Atom PDF