•   
  • 1
  • 43
  • 44
  • 45
  • 46(current)
  • 47
  •   
Zap2xml for ATSC in OpenELEC
@edit4ever unfortunately that doesn't work as it is still referring back to the old link that zap2it used
Reply
(2018-12-09, 20:42)dsbalsak Wrote: @edit4ever unfortunately that doesn't work as it is still referring back to the old link that zap2it used
 Are you saying that zap2xml does not currently work for you?  It was recently updated so it should be working.  The developer is responsive to emails for help as well.
Current Kodi addon projects: zap2epg, sd4tvh and tvh2kodi (tvh config from inside Kodi)
Testing ATSC single and dual tuners on RPi3 and the occasional s905 box
If you like my work you can buy me a coffee!
Reply
Yeah it try's and go to http://tvlistings.zap2it.com/ instead of https://tvschedule.zap2it.com
Reply
Just pushed an update for the zap2epg addon -  this adds the option to refresh the download cache days.  This is due to some of the guide data not being available or correct many days out, so this setting will re-download the data for x number of days out.  The default of 1 is probably best to keep data usage down and have the most up to date guide info before recordings begin.

https://github.com/edit4ever/script.modu...tag/v1.2.0
Current Kodi addon projects: zap2epg, sd4tvh and tvh2kodi (tvh config from inside Kodi)
Testing ATSC single and dual tuners on RPi3 and the occasional s905 box
If you like my work you can buy me a coffee!
Reply
Good to see you're still around and working on zap2epg. Still running just great (did finally upgrade my power source and installed it w/a 1TB HDD into its own box).

Curious about the most recent update....does it just download only those listings that have any changes compared to what was downloaded previously? Or does it do a secondary "short notice" full update X days before the actual recording(s)? If the 2nd one, why not just set the download to every x days and be done with it? Sounds like a lot of xtra network and download activity.

Thx and cheers....
Reply
@stephr1  I wouldn't say I'm actively working on zap2epg - but I'm happy to address issues or features as they come up.  As for the update, it downloads the full day of data again as there is no method to just get notified of changes as there is with a system like Schedules Direct.

The reason to add this feature is the following...if you like to have a full 14 days of guide data, you set the number of days to 14.  The first time you run zap2epg it downloads the entire 14 days of data.  After that, each time tvheadend runs the grabber (default is twice a day) it just downloads the additional information that is available - i.e. 14 days + 12 hours it just grabs the new 12 hours.  This is due to the system caching the original 14 days - which saves having the extra data download.  However, due to the way programmers update schedules, it is likely that some of the programs/time slots in the guide have the wrong information when you look at today or tomorrow.  This is because that information was actually downloaded 14 days ago.  The fix is to have zap2epg grab a new set of data for today, or for today + tomorrow, or today plus next 2 days, etc.  This deletes the cache data for those days and re-downloads the full day and updates the guide. 

In practice, you only really need to set this for the next 24 hours (1 day), but some may be fine downloading more data each time, so they want to set it to 2 days or more.  in my experience, more than 2 days and you're back to the problem of the guide data not being updated by the programmers.  The example that got this started was The Late Show with Stephen Colbert.  CBS doesn't update the guide with the guests info and episode number until they have recorded the show at the studio - which is usually two days out.  So the initial 14 days out info in the guide only showed the show in the timeslot - but didn't have any episode information. So re-downloading 1 day out updated with the full info.  Of course, setting the new option to more than 2 days in this case, still wouldn't grab the new info until it was available 2 days out - so you'd be downloading extra data for no difference on the guide display.  That's why I set the default to 1 day.  This should be the best of all worlds - updated guide info and smallest amount of data to download.

Hope this helps clarify - it's a bit wordy of an explanation!  :-)

BTW - if you only have the original number of days to download set at 1 or 2 days, then this really doesn't matter and you can set the new option to 0 days.  It's really for those who have a full week or 2 weeks of guide data set to download.
Current Kodi addon projects: zap2epg, sd4tvh and tvh2kodi (tvh config from inside Kodi)
Testing ATSC single and dual tuners on RPi3 and the occasional s905 box
If you like my work you can buy me a coffee!
Reply
Well, your response may not be immediate, but it's clear you are still working on it and haven't abandoned it. And for that we're all very appreciative  Smile

Still trying to sort this out (maybe just one of my off days Sad 

If I'm downloading 14 days worth of data every night at 3AM, aren't I essentially getting the most recent programming info anyways? It would seem I am capturing any programming changes/updates each time the grabber downloads another 14 days (once every 24 hours).

Seems like I won't see much of any benefit. In fact, maybe even redundant for me. However, those folks who have their chrono set up to act less often than 1/day (once/week?) would have a good use for this. True?
Reply
No worries on the confusion.  The way I built the original process is to save the downloaded data files.  So - let's use the example of March 3rd.  If you are set to download 14 days data at 3am...the system first checks to see if you've already downloaded files for March 3rd at 3am until March 17th at 3am.  Since you have it set for once a day, on March 3rd it downloaded all those files (in 3 hour increments - that's why there are so many files).  Now on March 4th, it runs at 3am and looks for files for March 4th at 3am until March 18th at 3am.  Since you already have the March 3rd through March 17th data downloaded, it only downloads the new March 17th at 3am to March 18th at 3am data (1 day).  That's how it saves bandwidth - by only downloading the new data since the last download.

However - this means that on any given day, your information is 14 days old.  Which has been an issue for some shows.  So the new function, using the example above with the new setting "number of days to delete cache" set for 1 day, on March 4th at 3am, the system check first deletes any cached files for March 4th 3am through March 5th at 3am.  Then it runs as normal, first looking for cached files for March 4th 3am through March 18th at 3am.  Since it doesn't find the files for March 4th 3am through March 5th at 3am and it also doesn't find the files for March 17th at 3am to March 18th at 3am (since that data didn't exist when it ran on March 3rd) - it just downloads those 2 days of data.

I realize this was a bit confusing because of the 3am reference - but I hope it makes sense.

You can also think of it like this.
Starting from a fresh install using the old system with number of download days set to 14: 

On day 1 - it downloads the following days: 1,2,3,4,5,6,7,8,9,10,11,12,13,14
On day 2 - it downloads the following days: 15
On day 3 - it downloads the following days: 16
...
On day 13 - it downloads the following days: 27
On day 14 - it downloads the following days: 28

But the data for 14 is 14 days old (it was downloaded on day 1 and never refreshed. Day 15 data is 13 days old, Day 16 is 12 days old, etc)

With the new system set for with number of download days set to 14 and number of days to delete cache set to 1:
On day 1 - it downloads the following days: 1,2,3,4,5,6,7,8,9,10,11,12,13,14
On day 2 - it downloads the following days: 2,15
On day 3 - it downloads the following days: 3,16
...
On day 13 - it downloads the following days: 13,27
On day 14 - it downloads the following days: 14,28

Now the data your viewing for day 14 is less than 1 day old (it was downloaded on the last run. Day 15 data is still 13 days old, Day 16 is still 12 days old, etc)

Maybe this helped clarify??
Current Kodi addon projects: zap2epg, sd4tvh and tvh2kodi (tvh config from inside Kodi)
Testing ATSC single and dual tuners on RPi3 and the occasional s905 box
If you like my work you can buy me a coffee!
Reply
Appreciate it. It did help.

I had made an assumption that each 14-day download every 24 hrs. (3AM for me) retrieved a new full 14 days of data. If it did that then I would have a constant 14 day download and all the programming info would be the most recent for the next 14 days.

Instead, you've designed the grabber to do incremental updates which explains why the data for 14 days out can become 14 days stale.

Nice and makes sense.

I'll download and try it out the grabber update and let you know if I run into any glitches. Thx.
Reply
I know this is an old posting but I am having a problem. When TVHeadend executes the grabber, it fails:

 cat zap2xml.log
/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py:589: UserWarning: gzip transfer encoding is experimental!
  br.set_handle_gzip(True)
Reading config file: /storage/.kodi/addons/tools.module.zap2xml/.zap2xmlrc

Logging in as -p

http://tvschedule.zap2it.com/tvlistings/...tvschedule

Exception
error<class 'urllib2.URLError'>
Traceback (most recent call last):
  File "/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py", line 1931, in <module>
    main()
  File "/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py", line 1838, in main
    data = getURL(url)
  File "/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py", line 205, in getURL
    login()
  File "/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py", line 602, in login
    loginZAP(br)
  File "/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py", line 536, in loginZAP
    br.open(urlRoot + 'ZCLogin.do?method=getStandAlonePage&aid=tvschedule')
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_mechanize.py", line 203, in open
    return self._mech_open(url, data, timeout=timeout)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_mechanize.py", line 230, in _mech_open
    response = UserAgentBase.open(self, request, data)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_opener.py", line 193, in open
    response = urlopen(self, req, data)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_urllib2_fork.py", line 344, in _open
    '_open', req)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_urllib2_fork.py", line 332, in _call_chain
    result = func(*args)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_urllib2_fork.py", line 1142, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/storage/.kodi/addons/script.module.mechanize/lib/mechanize/_urllib2_fork.py", line 1118, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [Errno -2] Name or service not known>

Can someone help me with this error?
Reply
(2019-07-20, 22:32)dschlic1 Wrote: I know this is an old posting but I am having a problem. When TVHeadend executes the grabber, it fails:

 cat zap2xml.log
/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py:589: UserWarning: gzip transfer encoding is experimental!
  br.set_handle_gzip(True)
Reading config file: /storage/.kodi/addons/tools.module.zap2xml/.zap2xmlrc 
zap2xml is an old addon and is not supported - try using zap2epg: https://github.com/edit4ever/script.modu...g/releases
Current Kodi addon projects: zap2epg, sd4tvh and tvh2kodi (tvh config from inside Kodi)
Testing ATSC single and dual tuners on RPi3 and the occasional s905 box
If you like my work you can buy me a coffee!
Reply
(2019-07-20, 22:55)edit4ever Wrote:
(2019-07-20, 22:32)dschlic1 Wrote: I know this is an old posting but I am having a problem. When TVHeadend executes the grabber, it fails:

 cat zap2xml.log
/storage/.kodi/addons/tools.module.zap2xml/zap2xml.py:589: UserWarning: gzip transfer encoding is experimental!
  br.set_handle_gzip(True)
Reading config file: /storage/.kodi/addons/tools.module.zap2xml/.zap2xmlrc  
zap2xml is an old addon and is not supported - try using zap2epg: https://github.com/edit4ever/script.modu...g/releases 
Installed zap2epg. First try at configuring, it wouldn't work. Reset to defaults, reconfigured it and now is working. Thanks.
Reply
I am sure this is operator error so i hope you can help.

I am running LibreElec  9.1.002 on a Chromebox.
TVheadend (4.2.8-31) is on a asus laptop Kubuntu 18.04
I installed Zap2epg v 1.3.0  (Thank you!)
Tvheadend is enabled and configured.

The Zap2epg Grabber does not appear to install in TVheadend. Not present in EPG grabber modules list.

Any idea what step i have missed?
I even installed Kodi and zap2epg on the Tvheadend system hopeing it would work. No Go.

thank you for the addon and the help
Reply
(2019-09-02, 18:35)mxlance Wrote: I am sure this is operator error so i hope you can help.

I am running LibreElec  9.1.002 on a Chromebox.
TVheadend (4.2.8-31) is on a asus laptop Kubuntu 18.04
I installed Zap2epg v 1.3.0  (Thank you!)
Tvheadend is enabled and configured.

The Zap2epg Grabber does not appear to install in TVheadend. Not present in EPG grabber modules list.

Any idea what step i have missed?
I even installed Kodi and zap2epg on the Tvheadend system hopeing it would work. No Go.

thank you for the addon and the help

Since your Kodi is not in the TVH server, the zap2epg installation guide will not work for you. You need to add zap2epg addon to your laptop not chromebox. I was in a similar shoe and I manually copied the file to /usr/bin and gave permission. Forgot the details, tho.
Reply
@acegolfer
thank you for the reply and the tip.
I will look into this.
thanks again
Reply
  •   
  • 1
  • 43
  • 44
  • 45
  • 46(current)
  • 47
  •   
 
Thread Rating:
  • 4 Vote(s) - 4.5 Average



Logout Mark Read Team Forum Stats Members Help
Zap2xml for ATSC in OpenELEC4.54