WebEPG fixes (epoch time and episode handling) (1 Viewer)

[arion_p]

Hi,
I've been working on some minor bug fixes for WebEPG. While trying to build a new grabber for Star Channel (a Greek channel), I came across the following problems:

1. Epoch time is not handled correctly: If the site timezone is UTC-8 everything works fine, but for any other time zone, programs may be added to the wrong date. I have changed the conversion to epoch date/time to take into account the site timezone. WebEPG_EpochTime_Patch fixes this.

2. EpisodeNum / SeriesNum exporting to xmltv format: According to xmltv DTD the series/episode/part number can be in one of two formats xmltv_ns and onscreen (other format may be used but are not defined in xmltv DTD and TVServer does not support them). If no format is specified in the "system" attribute (which is the case with WebEPG), xmltv_ns is assumed.
Now according to the xmltv_ns system the value should be of the form [series].[episode].[parth], where [] denote an optional field. Note that the dots are NOT optional. WebEPG on the other hand exported episode numbers in the format [[part.]episode[.series]]
WebEPG_Episodes_Patch changes WebEPG fixthis

Also in xmltv_ns all numbering is zero-based whereas WebEPG uses whatever numbering is used in the site being grabbed. I have not yet fixed this because I am puzzled as to where it would be more appropriate to apply the offset: in ProgramData.ToTvProgram() where the numbers are already integers or in XMLTVExport.WriteProgram(...) where they have to be converted from strings to integer, offset and then back to strings.
Also I am not sure if it might be useful to make the offset configurable.


Panayotis

 

[Paranoid Delusion]

arion_p

Hi, have let James, the developer of the webepg know about this thread, so as soon as he gets a chance, i'm sure he will answer

 

[James]

Thanks arion_p for the contributions.

I have added both of your patches into the SVN.

/James

 

[vuego]

Also in xmltv_ns all numbering is zero-based whereas WebEPG uses whatever numbering is used in the site being grabbed. I have not yet fixed this because I am puzzled as to where it would be more appropriate to apply the offset: in ProgramData.ToTvProgram() where the numbers are already integers or in XMLTVExport.WriteProgram(...) where they have to be converted from strings to integer, offset and then back to strings.
Also I am not sure if it might be useful to make the offset configurable.


Panayotis

Thanks for the update but without the zero-based numbering this fix actually breaks episode support. Before SVN 22162 the episode was assumed "one-based" by for example For the Record and thus handled correctly. Now I have to manually reschedule all episode recordings or else I'll end up missing some recordings and others duplicated.

I don't see any use for a configurable offset.

 

[James]

thanks for the information vuego. I have reverted this change.

 

[esas]

I hope that either james or arion_p (or someone else with the skills) can fix the zero-based numbering rather than removing this fix. It's allways good to follow standards..

 

[arion_p]

Sorry for the delay, I had this patch ready but never seemed to find the time to post it here. Anyway I don't see any use for configurable offset either, but I had to ask - I don't know every single grabber.

So here it is, the patch for zero-based numbering.


arion_p

 

[esas]

Sorry for the delay, I had this patch ready but never seemed to find the time to post it here. Anyway I don't see any use for configurable offset either, but I had to ask - I don't know every single grabber.

So here it is, the patch for zero-based numbering.


arion_p

Is this patch now included in SVN?

 

[arion_p]

AFAIK it isn't. James has not responded since I posted the patch.

But since there is an effort to release MP 1.0.2 earlier in order to address some important issues in 1.0.1, I assume James is busy with that. So I don't expect it to be included before the release of 1.0.2