Don't get season and episode numbers imported from xmltv in program guide (1 Viewer)

[Christoph Conradi]

I am using MP1.5 just the latest release. I am living in Spain and one spanish provider at least includes the 'onscreen' element to include this information. Actually I couldn't find any other writing season information. Unfortunately the way it is written might not be compatible with the current implementation of MP. The information int the tvguide.xml reads:
<episode-num system="onscreen">Temporada 1 Episodio 47</episode-num>
Temporada you may guess is the season and Episodio means well you know. I tried manually overwriting this field with different delimiters (space, /, dot) without success. For my naive testing it will only import this field, if there is a plain number, like 32. To me it appears there is no logic to filter those values to make it a possible season.episode value.
Am I right or is this supposed to work? If it is not supposed to work is there a chance you might think to give it a best guess on the information provided rather than nothing? Does somebody know a converter from onscreen to xmltv_ns?

 

[mm1352000]

Hello and welcome Christoph

Unfortunately the way it is written might not be compatible with the current implementation of MP. The information int the tvguide.xml reads:
<episode-num system="onscreen">Temporada 1 Episodio 47</episode-num>
Temporada you may guess is the season and Episodio means well you know. I tried manually overwriting this field with different delimiters (space, /, dot) without success. For my naive testing it will only import this field, if there is a plain number, like 32. To me it appears there is no logic to filter those values to make it a possible season.episode value.

Yes, I think it is not compatible. The problem is that "onscreen" means "...to simply copy what the programme makers write in the credits". It could be anything!
For your reference, the XMLTV plugin code for parsing the episode info is here:
https://github.com/MediaPortal/Medi...brary/Plugins/XmlTvImport/XMLTVImport.cs#L636

For onscreen info, it supports entries like: "abcde #47" (meaning episode 47) or "47 / 50" (meaning episode 47 out of 50) or plain numbers like "47".
If the entry is not supported, you'll see these entries in your TV service log file:

XMLTVImport::CorrectEpisodeNum, could not parse '...' as plain number

Am I right or is this supposed to work? If it is not supposed to work is there a chance you might think to give it a best guess on the information provided rather than nothing?

We do already make a best guess and write to the logs when the guess fails. Unfortunately the standard is just "loose".

Does somebody know a converter from onscreen to xmltv_ns?

Sorry, I don't.

mm

 

[Christoph Conradi]

Thanks a lot for your fast response, impressive.
Do you think we break something if we give it a more generic approach? Understanding that this element is not meant to include anything specific but just a string to display 'onscreen', I still could imagine looking for 2 numbers and write an algorithm which just does that and assigns depending on the context their meaning like the following:
1. if there is just 1 number found, it means series information
2. if there found 2 numbers with a '/' as delimiter, it would reflect the current behavior like episode n of a total of x episodes
3. if there are just 2 separate numbers found, we give the first the season and the second the episode number

Do you think that could work? If so, do you want me to provide an approach based on your code bits? I never worked on an open source project, but would be willing to help (of course I am the most interested one ;-)), but would need some guidance.

CC

 

[Christoph Conradi]

Apparently the suggested approach wouldn't work with the information received. Fact is that the information sometimes just include series information and sometime episode information, so you never know based on just 1 number what it actually means. The only way to correctly parse the information is actually parsing the strings inside and giving it a meaning, that is absolutly region specific and unreliable if not using this specific EPG provider. Currently I modified this code for my purpose and it works, but I couldn't think of a generic approach.