search

tvgrabbers / tvgrabnlpy

Deze versie is deprecated zie: tvgrabpyAPI
https://github.com/tvgrabbers/tvgrabpyAPI
GNU General Public License v2.0
27 stars 8 forks source link

horizon.tv issues with some programs already in progress #56

Open kyl416 opened 8 years ago

kyl416 commented 8 years ago

There seems to be an issue with the horizon.tv grabber where it doesn't include programs already in progress at the time of the grab

It's most noticible on channels like MTV Music 24 (5-24443943214) where the schedule is 24 hour blocks that start at 12am CET (11pm UTC), so the listings for the channel don't start until 12am CET the following day.

hikavdh commented 8 years ago

You mean like the default tvgids.nl html view (which we don't use), where the listing for the current day starts at the current time? If so then that's no big issue. First, for most channels that will get caught by the other sources. Second, if there are no other sources, it will still be in your program-listing (in MythTV, TVheadend) from the grab on the previous day. Third normally you do your main grab in the early hours, not at the times you are recording. Or am I missing something?

kyl416 commented 8 years ago

Unfortunately Kodi doesn't support caching of only previous data, their cache function is an all or nothing thing, so if I turn cache on I won't get any fresh data like updated times and details for the current day.

This is one of the channels that are only available from horizon.tv, since this is also a channel with a 24 hour block it's most noticible on this one.

The data is there on horizon's site, it's just that the byStartTime flag only delivers programs with a StartTime during that range. However, if you change it to byEndTime, it delivers programs with a EndTime during that range. As a quick test I just changed it to use byEndTime and I got the currently airing block:

https://www.horizon.tv/oesp/api/NL/nld/web/listings?byStationId=24443943214&byEndTime=1455841815000~1455928215000&sort=startTime

byStartTime gives me the block for tommorow

https://www.horizon.tv/oesp/api/NL/nld/web/listings?byStationId=24443943214&byStartTime=1455841815000~1455928215000&sort=startTime

Another example is for Slam!TV (5-24443943138) With byEndTime the first progam is the currently in progress "Most Wanted"

https://www.horizon.tv/oesp/api/NL/nld/web/listings?byStationId=24443943138&byEndTime=1455841815000~1455928215000&sort=startTime

With byStartTime the first program is "SLAM!NL" which starts about 2 hours from now at 3am CET:

https://www.horizon.tv/oesp/api/NL/nld/web/listings?byStationId=24443943138&byStartTime=1455841815000~1455928215000&sort=startTime

It looks like the fix is to use byEndTime instead of byStartTime

kyl416 commented 8 years ago

As a test I changed it to use byEndTime on my local copy and it worked great, no errors

hikavdh commented 8 years ago

Good! I'll check it and if it indeed goes OK, Ill release a 2.2.10 version. I was anyway planning on looking deeper into Horizon if I can get it to deliver all programs in one without the 100 items limit. It would make the code much simpler, as I don't need to catch the timing of item 100.

hikavdh commented 8 years ago

This is a timezone thing. With byStartTime it does exactly what it should do. If I grab MTV Music 24 with offset 0 for three days, I get the listing starting today at 0:00 CET for three days, including the first one for day 4. If I set it to byEndTime the listing includes the last one for day -1, which means the listing from yesterday. Possibly my calculation for the starting moment fails because you are in a different timezone.

hikavdh commented 8 years ago

This is probably to complex to address in the current version, but should go right with the changes to timezone management in version 3. Probably it comes from my earlier adaptation on the calculation of current_day to address your earlier timezone issue.

hikavdh commented 8 years ago

Check in the current 3.0 alfa what happens in your timezone. Both with self.output_tz = pytz.timezone('Europe/Amsterdam') in tv_grab_nl.py unchanged and set to your own timezone. These two should give the same listings, but only displayed in your timezone in the second one. If the issue persists I look into it. I anyhow have not jet looked at Horizon.tv for the new framework. It all depends on whether I use the sources timezone or the output timezone for the calculation of current_day.

hikavdh commented 8 years ago

As said before: If you add --cache='program_cache3' to your initial configuration call and change the line:

        self.name ='tv_grab_nl_py'

in tv_grab_nl.py to for instance:

        self.name ='tv_grab_nl_py3'

it won't byte your current configuration and cache files..

kyl416 commented 8 years ago

I'll try it out this weekend

hikavdh commented 8 years ago

Thanks, I knew you would find it. I do not know how, but thanks. Probably in 1 or 2 month we have to revert back. Kan I ask you to keep an eye on the availability of the old url?
Oh I wish I could finish my development to version 3. It would make these issues so much simpler. At present I have to mainly cut down on overhead. Due to the more generalistic approach it has become a lot slower. I am thinking of a more selective detail download as with all the source those do not add.. .