MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (71):

aloril, Anssi, arescorpio, blahdodo, brfransen, Captain_Murdoch, ChanServ, Chutt, clever, davic, dblain, dekarl, dmfrey, dym, eharris, ElmerFudd, emm386, enyc, gary_buhrmaster, GhostOfRaven, ghoti, gregbert, GreyFoxx, Hydr0p0nX, ikevin, J-e-f-f-A, jab416171, jams, jheizer, jmcentee, joki, jpharvey, jst, jya, knightr, knowledgejunkie, lapion, lautriv_, lautriv__, libsci, logan-, mad_enz, markspieth, MitchCapper, MythBuild, MythLogBot, nephyrin, peper03, poptix, pppingme, purserj, rhpot1991, rich0, rkulagow, rmeden, saaki, seld, sphery, SteveGoodey, stuartm, tgm4883, tonsofpcs, tris, unforgiven512, vincent42, wagnerrp, Warped, XDS2010, xris, zz_CyberJacob, _charly_
Tuesday, May 17th, 2016, 00:03 UTC
[00:03:20] amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv
[00:31:22] arescorpio (arescorpio!~arescorpi@190.190.244.21) has joined #mythtv
[00:44:45] clever (clever!~clever@nwcsnbsc03w-047055226178.dhcp-dynamic.FibreOp.nb.bellaliant.net) has quit (Ping timeout: 276 seconds)
[00:45:27] clever (clever!~clever@nwcsnbsc03w-047055226178.dhcp-dynamic.FibreOp.nb.bellaliant.net) has joined #mythtv
[01:59:21] joki (joki!~joki@p54860FD5.dip0.t-ipconnect.de) has quit (Ping timeout: 265 seconds)
[02:04:16] joki (joki!~joki@p54860C1E.dip0.t-ipconnect.de) has joined #mythtv
[02:27:50] dmfrey (dmfrey!~dmfrey@65-78-126-51.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Ping timeout: 260 seconds)
[04:23:30] arescorpio (arescorpio!~arescorpi@190.190.244.21) has quit (Quit: Leaving.)
[04:37:42] bill6502 (bill6502!~bill@24-148-53-32.c3-0.alc-ubr1.chi-alc.il.cable.rcn.com) has left #mythtv ()
[04:39:44] seld (seld!~seld@217-209-54-168-no53.tbcn.telia.com) has quit (Remote host closed the connection)
[04:40:35] seld (seld!~seld@217-209-54-168-no53.tbcn.telia.com) has joined #mythtv
[05:52:05] dekarl1 is now known as dekarl
[06:03:19] Tobbe5178 (Tobbe5178!~asdf@h184n1-sv-a13.ias.bredband.telia.com) has joined #mythtv
[06:06:18] dekarl: jams, linhes has a custom addition to our mythutil? Is it good? should we upstream it?
[07:09:13] Roklobster (Roklobster!~Dirkka@ppp118-209-54-50.lns20.mel4.internode.on.net) has joined #mythtv
[07:16:30] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has joined #mythtv
[07:30:08] SteveGoodey (SteveGoodey!~steve@81.141.240.42) has joined #mythtv
[08:05:14] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:17:17] ShapeShifter499 (ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499) has joined #mythtv
[09:33:51] lautriv__ (lautriv__!~lautriv@funtoo/user/lautriv) has quit (Ping timeout: 276 seconds)
[09:46:11] lautriv__ (lautriv__!~lautriv@funtoo/user/lautriv) has joined #mythtv
[10:17:18] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Remote host closed the connection)
[10:38:38] willcooke (willcooke!~willcooke@host-2-103-246-54.as13285.net) has joined #mythtv
[10:38:53] willcooke (willcooke!~willcooke@host-2-103-246-54.as13285.net) has quit (Changing host)
[10:38:53] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has joined #mythtv
[10:46:37] willcooke_ (willcooke_!~willcooke@host-2-103-246-54.as13285.net) has joined #mythtv
[10:50:05] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Ping timeout: 260 seconds)
[10:50:35] willcooke_ (willcooke_!~willcooke@host-2-103-246-54.as13285.net) has quit (Client Quit)
[10:50:54] willcooke (willcooke!~willcooke@willcooke.plus.com) has joined #mythtv
[10:50:54] willcooke (willcooke!~willcooke@willcooke.plus.com) has quit (Changing host)
[10:50:54] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has joined #mythtv
[12:33:44] dmfrey (dmfrey!~dmfrey@68.170.18.123) has joined #mythtv
[13:04:38] dmfrey (dmfrey!~dmfrey@68.170.18.123) has quit (Quit: Ex-Chat)
[13:17:23] Roklobster (Roklobster!~Dirkka@ppp118-209-54-50.lns20.mel4.internode.on.net) has quit (Remote host closed the connection)
[13:21:25] amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!)
[13:36:20] amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv
[14:16:09] letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has joined #mythtv
[14:28:15] amessina (amessina!~amessina@unaffiliated/amessina) has quit (Ping timeout: 260 seconds)
[14:40:51] mad_enz (mad_enz!~mad_enz@2607:f090:488d:8d:9079:2833:babf:a440) has quit (Ping timeout: 276 seconds)
[14:49:59] jams: dekarl. Here is the patch for mythutil to save/restore/diff/export/import settings. Mostly we use it to load linhes default settings and keybindings for new installs. I use it to sync my own custom settings between systems http://cgit.linhes.org/linhes_pkgbuild/tree/a . . . ch?h=testing
[14:52:03] mad_enz (mad_enz!~mad_enz@2607:f090:488d:8d:ccec:6ae0:dead:35d0) has joined #mythtv
[15:56:56] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection)
[15:58:38] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[16:23:10] ShapeShifter499 (ShapeShifter499!~ShapeShif@unaffiliated/shapeshifter499) has quit (Ping timeout: 260 seconds)
[16:27:58] MitchCapper: nice:)
[16:33:53] letifosi_ (letifosi_!~letifosif@216.207.42.134) has joined #mythtv
[16:37:24] letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has quit (Ping timeout: 246 seconds)
[16:52:10] letifosi_ (letifosi_!~letifosif@216.207.42.134) has quit (Remote host closed the connection)
[17:05:14] CyberJacob is now known as zz_CyberJacob
[17:25:30] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:30:57] letifosiferrari (letifosiferrari!~letifosif@216.207.42.134) has joined #mythtv
[17:34:01] letifosiferrari (letifosiferrari!~letifosif@216.207.42.134) has quit (Remote host closed the connection)
[17:34:27] letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has joined #mythtv
[18:21:09] dekarl: @uk xmltv users... fyi https://metabroadcast.com/blog/changes-to-atlas-access fwiw a week after initial notice _uk_atlas is still unchanged :(
[18:22:40] dekarl: known users on smolt are 110x _uk_rt and 20x _uk_atlas
[19:17:25] gary_buhrmaster: I will note that I only received the emails from metabroadcast today, so any action/response/panic may not have yet started.....
[19:24:02] amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv
[19:27:02] stuartm: ah feck, no more RT feed :(
[19:27:40] dekarl: I first heard about it a good week ago https://sourceforge.net/p/xmltv/mailman/xmltv . . . #msg35075162
[19:28:31] JohnBergqvist (JohnBergqvist!~JohnBergq@host217-42-112-23.range217-42.btcentralplus.com) has joined #mythtv
[19:28:36] stuartm: and they are prohibiting fetching 14 days of data?
[19:28:42] JohnBergqvist: @Stuartm, do you use the Atlas XMLTV grabber?
[19:28:54] JohnBergqvist: oh, I see you've got the email too
[19:29:43] JohnBergqvist: if you look at the bottom, it says this: "One specific change required is that no call to the Atlas schedule endpoint should request more than 24 hours of data. Applications not following this rule will be revoked without further notice."
[19:30:10] JohnBergqvist: now does that mean I'm still allowed to make say 7 seperate calls of 24hours each, sequentially?
[19:30:44] stuartm: JohnBergqvist: no I don't because back when it first appeared I disagreed with the author's implementation – e.g. not marking programmes as HD etc
[19:31:13] JohnBergqvist: I see you're aware of this T&C change with atlas though?
[19:31:39] stuartm: they are talking about "user's immediate need" which to me sounds like they want you to fetch on-demand, if the user isn't looking at next Saturday then don't fetch next Saturday
[19:32:05] JohnBergqvist: hmmm... where does mythfilldatabase come into that?
[19:32:27] JohnBergqvist: Because at the very least, mythfilldatabase by default will return i think 2 days worth of data, if not more?
[19:33:07] stuartm: however I think they'd be OK with an update model similar to the one used for SD users, where it fetches updates only for the next day or two, plus the fourteenth day
[19:33:46] stuartm: so first run gets 14 days, second run updates the next two days and fetches one new days worth of data
[19:34:21] JohnBergqvist: "no call to the Atlas schedule endpoint should request more than 24 hours of data. "
[19:34:24] stuartm: mfdb can fetch one days worth at a time, it's up to the grabber to indicate the best way to retrieve the data
[19:34:51] stuartm: so to fetch those three days worth it would make three separate calls
[19:34:58] gary_buhrmaster: There was some wishy/washy language about the api keys will be expired after the trial periods of a few months. I have no idea what that really means in practice.
[19:34:59] dekarl: on friday I suggested to do something crazy and talk to MB about how to modify the grabber. It appears the maintainer chose to rely on "the grabber is ToS compliant" instead, so the ToS was extended... https://sourceforge.net/p/xmltv/mailman/message/35084274/
[19:36:06] dekarl: ^- the mail where knowledgejunkie suggested to comply with MB's request and the reply
[19:36:43] JohnBergqvist: So what are you saying? I don't need to do anything?
[19:36:57] JohnBergqvist: Currently I do request 14 days in a single mythfilldatabase run.
[19:38:28] dekarl: JohnBergqvist: just look at the log. does it process one day after another, telling you if it skips a day or that it must be fetched due to a reason?
[19:38:52] JohnBergqvist: it does yes. I run it with --refresh 0 --refresh 1 --refresh 2 etc.
[19:39:09] JohnBergqvist: so it'll say Requesting data for day x due to user request for example.
[19:39:39] dekarl: just running mfdb without anything special does "the right thing"
[19:40:04] stuartm: dekarl: it does? So the current grabber isn't using 'allatonce' then?
[19:40:34] JohnBergqvist: let me paste my logfile
[19:40:38] dekarl: stuartm: correct, _uk_atlas does not announce allatonce
[19:40:39] stuartm: but to the point, as dekarl said John, you shouldn't specify any arguments to mfdb
[19:41:38] JohnBergqvist: It doesn't do "the right thing", because unless i put in --refresh 0 sometimes it assumes the day old data is up-to-date, when it isnt.
[19:42:02] JohnBergqvist: also I use --only-update-guide because it'll mess about with my channel icons then.
[19:44:33] JohnBergqvist: see, if I run it without --refresh 0, it'll say "data already present for xxxxx" when in fact it may be a day out of date...
[19:45:07] davic (davic!~davic@unaffiliated/davic) has joined #mythtv
[19:46:19] dekarl: hmm, that may be an optimization depending on the runtime of the grabber. it always refreshes tomorrow. but if you run it in the morning hours (the default) there is a whole day between now and then
[19:46:52] stuartm: mfdb hasn't overwritten channel icons for at least two years, it only inserts if icons are missing
[19:47:39] stuartm: JohnBergqvist: as dekarl notes, it's a matter of timing – the grabber should indicate to mythbackend the best time to run it to get the most recent info
[19:47:48] stuartm: maybe Atlas is failing to do that
[19:48:33] JohnBergqvist: I run it at 6AM, because someone told me that the Press Assocation data that the grabber uses is published at approx 5:30AM.
[19:48:36] JohnBergqvist: daily
[19:48:51] JohnBergqvist: But you don't understand, Day 0 is TODAY, not tomorrow.
[19:48:56] JohnBergqvist: I want to get the latest data for TODAY
[19:50:21] dekarl: I understand :) mfdb defaults to skip today and start requesting tomorrow, unless data for today is missing
[19:50:44] JohnBergqvist: OK. Well that's why I force --refresh 0 at least, because I don't want it to skip today.
[19:50:46] dekarl: so --refresh 0 instructs it to change that behaviour and refresh today "due to user request"
[19:51:04] gary_buhrmaster: I would suggest that someone with the understanding about the MB details post to the -users list with the appropriate message (to shortcut the panic, or at least direct it to the right place).
[19:51:33] dekarl: I'm not sure where the default behaviours originated. maybe its back from the days of scraping where scraping past data is a big waste? maybe from a guide source that doesn't do last minute updates? I don'T know
[19:51:35] JohnBergqvist: there even saying that if I use my API key for more than 3 months, I have to pa anyway...
[19:51:38] JohnBergqvist: *pay anyway
[19:51:55] JohnBergqvist: Also, I need to accept to this: "You will only make requests in response to user's actions inside your application, and not on an automated schedule" and "You will not request more than 24 hours of schedule data in one call" this.
[19:52:30] stuartm: dekarl: I think that behaviour dates back to DataDirect, I never saw a need to change it since the RT grabber would fetch all days in one go and so I was unaffected
[19:52:36] JohnBergqvist: I see schedules direct now supports UK guide data. Where's it got this data from btw? Press Assocation?
[19:52:40] stuartm: but now it doesn't make sense to leave it
[19:52:46] JohnBergqvist: if so, given that's the same as Atlas, i'll switch to that.
[19:53:27] stuartm: if I switch to SD I'll be forced to write them an XMLTV grabber
[19:53:55] JohnBergqvist: I stopped using the RT grabber ages ago once they stoppped adding new channels to it
[19:54:59] dekarl: stuartm: that grabber was released 2 1/2 days ago ;) http://xmltv.cvs.sourceforge.net/viewvc/xmltv . . . rab/sd_json/
[19:55:17] JohnBergqvist: Where does SD get it's UK guide data from dekarl?
[19:55:45] stuartm: dekarl: oh, finally!
[19:56:05] dekarl: JohnBergqvist: from the same source they get the US data. its just another feed
[19:56:17] stuartm: Tribune Media Services
[19:56:31] JohnBergqvist: Oh right. Well where do THEY get the guide data for the UK from?
[19:56:39] stuartm: but Tribune have to be ingesting it from someone else
[19:57:15] stuartm: JohnBergqvist: only why to know if it's the same source would be to signup and compare the data
[19:57:17] gary_buhrmaster: TMS has changed their name to be Gracenote.
[19:57:37] JohnBergqvist: right
[19:57:47] JohnBergqvist: it quite possibly could be the same, the Press Association
[19:57:52] gary_buhrmaster: (not that the name really matters)
[19:57:56] dekarl: stuartm, https://sourceforge.net/p/xmltv/mailman/message/35064591/
[19:58:49] JohnBergqvist: Also, doesn't mythtv handle schedulesdirect data internally?
[19:59:10] dekarl: JohnBergqvist: that's the old API
[19:59:20] JohnBergqvist: Oh. So no?
[19:59:28] dekarl: old as in US only data
[19:59:45] JohnBergqvist: Oh OK
[20:00:02] JohnBergqvist: So i'd want the XMLTV grabber for it then, in my case?
[20:00:15] stuartm: JohnBergqvist: no, the internal grabber has been deprecated for a long time, we were standardising on xmltv rather than maintaining two different methods of ingesting data
[20:00:24] JohnBergqvist: right-o.
[20:00:27] JohnBergqvist: fine by me.
[20:00:42] JohnBergqvist: Anyone know about XMLTV channel IDs?
[20:00:55] JohnBergqvist: in the SD grabber i mean
[20:02:39] JohnBergqvist: argh maybe I should do a test migration over the weekend
[20:02:47] gary_buhrmaster: I do not know, but typically each grabber has their own idea of channel ids. There is a "standard", sort of (I can't remember the rfc number off the top of my head), but it is not (reliably) used since the channels themselves do not use it.
[20:03:01] JohnBergqvist: yeah.
[20:03:29] gary_buhrmaster: Typically the grabber uses their own consistent channel ids, which means you cannot (easily) just swap grabber sources.
[20:05:29] stuartm: xmltv mandates the format described by the rfc and while some of that still results in different interpretations it's better than Atlas which flat out ignored the xmltv spec
[20:06:23] stuartm: xmltv requires the use of a domain style identifier – e.g. bbcone.bbc.co.uk – using the broadcasters domain
[20:06:41] stuartm: iirc atlas used numeric ids or something
[20:08:49] JohnBergqvist: anyway, ignore that
[20:09:12] JohnBergqvist: do we still know if the current uk_atlas grabber implementation is safe for their load limits or not?
[20:10:31] stuartm: As I read it, yes, it should be OK
[20:10:55] JohnBergqvist: OK cool
[20:11:04] stuartm: it fetches no more than 24 hours worth of data in a single request, it doesn't fetch 14 days of data every time it runs, so ...
[20:11:11] JohnBergqvist: even with me going --refresh 0 --refresh 1 right up to 14?
[20:11:56] stuartm: JohnBergqvist: well no, run that way might be problematic – they are complaining that people are fetching huge amounts more data than they actually _need_
[20:12:05] JohnBergqvist: ok
[20:12:30] JohnBergqvist: well that's silly, because mythfilldatabase will ALWAYS fetch 2 days worth of data at least
[20:12:36] JohnBergqvist: -1 & -14
[20:12:48] JohnBergqvist: yet they say I can't fetch more than 1 day...
[20:13:00] stuartm: and fetching a full 14 days worth every day is more than you need since scheduling changes tend not to be a problem more than 48 hours into the future
[20:13:38] dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv
[20:13:42] stuartm: that aren't saying you can't fetch more than 1 day, just no more than 1 day in a single request and don't fetch more than is really necessary
[20:13:43] dekarl1: running with --refresh-all / or 0–99 you are still requesting one day at a time. thats a feature of mythfilldatabase, manually invoking the grabber will happily request 99 days in one request
[20:14:01] JohnBergqvist: right stop
[20:14:04] JohnBergqvist: this is getting confusing
[20:14:07] stuartm: dekarl: we should change the behaviour to always refresh the current day
[20:14:35] stuartm: unless you can think of any reason not to
[20:14:44] stuartm: I'll make that change this week
[20:15:17] dekarl1: stuartm: I agree, lets refresh today by default
[20:15:24] JohnBergqvist: going --refresh 1 --refresh 2 etc. etc. is that considered (as far as atlas is concerned) a SINGLE request of say 14 days, or 14 separate 1 day requests?
[20:15:35] stuartm: 14 separate 1 day requests
[20:15:46] JohnBergqvist: OK, so then i'm not breaking Atlas's T&Cs?
[20:15:52] stuartm: fine by rule #1, not so much under rule #2
[20:15:52] ** MythLogBot http://code.mythtv.org/trac/ticket/1 **
[20:15:52] ** MythLogBot http://code.mythtv.org/trac/ticket/2 **
[20:16:33] dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 240 seconds)
[20:16:37] JohnBergqvist: fml
[20:16:40] dekarl1: but the wording suggests that the >24h per requests are creating problems
[20:17:02] dekarl1: "it's now necessary to revoke any key making requests for more than 24 hours of data in a single call, without further warning."
[20:17:05] dekarl1 is now known as dekarl
[20:17:16] JohnBergqvist: but then again, "A single call" though
[20:17:24] gary_buhrmaster: I think the only correct answer to "is it compliant" is that MB will have make that determination (and they have the power to do so). Perhaps they will clarify, but if I was them, I would not.
[20:17:45] JohnBergqvist: i'm only getting 1 days with of info in each call, just in 14 calls however :P
[20:18:29] dmfrey (dmfrey!~dmfrey@68.170.18.123) has joined #mythtv
[20:20:18] stuartm: the blog post follows the bit about requesting 14 days in one call with, "far more than is required to serve any immediate user need."
[20:20:29] JohnBergqvist: I disagree...
[20:20:36] stuartm: and "Use what you need, and no more. Atlas serves end-users, not servers. Request the data your users need, direct from their client, and when they need it."
[20:21:31] JohnBergqvist: the problem is, the further ahead you go, they often upload placeholder or generic programme entries, which don't get replaced with the correct ones nearer their airdate, because the grabber sees an entry for it & so doesn't pull in the latest one
[20:21:40] JohnBergqvist: that's why I do --refresh 0 --refresh 1 etc.
[20:21:52] stuartm: basically Metabroadcast are no longer willing to support heavy data users on their free tier
[20:22:05] JohnBergqvist: cos I don't like things suddenly being updated a day before the recording is scheduled..
[20:22:22] stuartm: they finish with
[20:22:25] stuartm: "We understand these arrangements will not suit everyone, especially those users who are running software for personal use, who will want to maintain access permanently without paying for using Atlas. If you fall into this category, we recommend you consider some of the other options to obtain data. For example, we are aware of a US-based non-profit organization called Schedules Direct that offers schedule data for personal use, charging a small
[20:22:27] stuartm: annual fee. We have not been in contact with this organisation, so cannot specifically recommend them, however they do appear to offer the service that some current Atlas users require."
[20:22:52] stuartm: or in other words – "MythTV users should get lost"
[20:23:06] JohnBergqvist: if someone could check whether SD in the UK is using Press Association data, then i'd move over to it ASAP
[20:23:08] gary_buhrmaster: I suspect that MB (just like zap2it before them) got abused to the breaking point, and the results are not going to go well for the average (low volume) end user.
[20:23:49] JohnBergqvist: there are other grabbers, like bleb & tvguide too actually, for the UK
[20:23:54] JohnBergqvist: *XMLTV grabbers
[20:23:58] gary_buhrmaster: You can get a trail subscription from SD (14 days, I think) for free.
[20:24:23] JohnBergqvist: I can't get xmltv's SD grabber to compile right now, becuase my perl's fucked up yet again...
[20:24:33] dekarl: JohnBergqvist: is _uk_bleb still a thing? last time I looked it carried maybe a dozen channels and wasn't updated in ages
[20:24:38] JohnBergqvist: probably
[20:24:47] JohnBergqvist: someone in XMLTV should cull all the inactive grabbers
[20:26:41] JohnBergqvist: "perl: symbol lookup error: /usr/lib/perl5/vendor_perl/auto/Unicode/String/String.so: undefined symbol: Perl_xs_apiversion_bootcheck"... FML
[20:28:18] rkulagow (rkulagow!cc4fac04@gateway/web/freenode/ip.204.79.172.4) has joined #mythtv
[20:28:26] ** stuartm is going to watch some TV before crashing **
[20:29:28] rkulagow: @JohnBergqvist: if you let me know what channel you're interested in I can send you a sample of the raw data and you can check to see if it meets your requirements. i can't help with the JSON->XML piece.
[20:29:56] JohnBergqvist: BBC One HD, today's listing?
[20:29:58] rkulagow: and we have a 7-day trial which can be extended if there are issues.
[20:30:13] rkulagow: sure. hold on. probably too big for chat.
[20:31:11] JohnBergqvist: wait
[20:31:19] JohnBergqvist: if you can just get me a single program?
[20:31:22] JohnBergqvist: that'll be easier
[20:31:50] rkulagow: is it 19:00Z there now?
[20:31:51] JohnBergqvist: Channel 5 HD (or just Channel 5 if the HD version isn't here), Today, 10PM-11PM UK time
[20:32:09] JohnBergqvist: it's a program called "Your child in their hands"
[20:32:28] dekarl: 20:32Z
[20:32:51] rkulagow: { "startTime": "2016-05–17T21:00Z", "endTime": "2016-05–17T22:00Z", "duration": 60, "qualifiers": ["Cable in the classroom", "New", "Series Premiere"], "program": { "tmsId": "EP024252670001", "rootId": "12863746", "seriesId": "12863742", "subType": "Series", "title": "Kids' Hospital: Your Child in Their Hands", "releaseYear": 2016, "releaseDate": "2016-05–17"
[20:32:59] rkulagow: yeah, truncated.
[20:33:00] rkulagow: hold on
[20:33:28] rkulagow: http://pastebin.com/WRQKc0Qf
[20:33:42] rkulagow: that's raw JSON. the grabber would translate it as necessary.
[20:33:55] JohnBergqvist: Hmm, I think that's just the EIT data then
[20:34:00] JohnBergqvist: it's certainly not the press association data
[20:34:44] JohnBergqvist: shame.
[20:36:10] JohnBergqvist: What is 'Cable in the classroom' when it's at home?
[20:36:12] JohnBergqvist: weird
[20:36:53] rkulagow: here's a program from BBC.
[20:36:55] rkulagow: http://pastebin.com/XaCWBVRp
[20:36:58] rmeden (rmeden!~Robert@107-131-102-250.lightspeed.rcsntx.sbcglobal.net) has joined #mythtv
[20:38:31] dmfrey (dmfrey!~dmfrey@68.170.18.123) has quit (Ping timeout: 252 seconds)
[20:40:13] JohnBergqvist: OK i've signed up to SD, how do I add a UK line-up?
[20:40:15] Roklobster (Roklobster!~Dirkka@ppp118-209-54-50.lns20.mel4.internode.on.net) has joined #mythtv
[20:40:22] JohnBergqvist: it won't let me proceed without one
[20:40:38] rkulagow: the JSON service is API driven.
[20:40:47] rkulagow: once you've created an account
[20:40:56] rkulagow: the grabber should be doing all the management
[20:41:11] rkulagow: the website is only for management of the existing XML service for the US (legacy)
[20:41:27] rkulagow: since it's driven by an API, if you don't want a channel, it's up to the grabber to just not download that data.
[20:41:37] JohnBergqvist: OK
[20:41:55] rkulagow: all i know about the new grabber in the XMLTV service is that it exists. :)
[20:42:53] JohnBergqvist: dont worry ive got it now
[20:43:05] JohnBergqvist: if i run the --configure command, where does it save the config file to?
[20:43:10] JohnBergqvist: if you don't give it an output
[20:43:36] JohnBergqvist: wait, found it
[20:43:51] rkulagow: sorry, no idea. i didn't have anything to do with the XMLTV converter. if you have questions about the JSON service (which i did create), those i can answer.
[20:45:12] JohnBergqvist: OK
[20:45:27] rkulagow: @rmeden would be the man to ask regarding XMLTV since he's dual-hatted XMLTV.org / schedulesdirect.org
[20:48:43] JohnBergqvist (JohnBergqvist!~JohnBergq@host217-42-112-23.range217-42.btcentralplus.com) has quit (Quit: Leaving)
[20:53:00] rkulagow: we also provide a mapping of our lineups based on the transmitter name, like "Crystal Palace".
[20:53:09] rkulagow: https://json.schedulesdirect.org/20141201/transmitters/GBR
[20:56:57] rkulagow: as to the earlier question about where Gracenote gets its data from: they have their own resources. they don't use press association.
[20:57:07] davic: Like I do then
[20:57:16] davic: The channels themselves
[20:58:16] rkulagow: gracenote has a business-to-business relationship with the content creators and the content providers (freeview, sky, virgin, etc)
[20:58:31] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Quit: Do your hobbies)
[21:04:29] rkulagow (rkulagow!cc4fac04@gateway/web/freenode/ip.204.79.172.4) has quit (Quit: Page closed)
[21:10:45] dekarl: tgm4883: can you update the xmltv daily ppa packaging? That might getting the new SD grabber tested and release easier. https://launchpad.net/~mythbuntu/+archive/ubuntu/xmltv
[21:11:18] tgm4883: yea I need to do that
[21:12:30] davic: dekarl: btw, do you have issue with VIVA CH?
[21:13:24] dekarl: davic: I don't carry it at all, so no
[21:13:48] davic: No data after 18th of May
[21:14:44] davic: looking into it tomorrow meh
[21:17:48] knightr: Only devs have accounts on Trac, right?
[21:18:30] knightr: There is a user on the user mailing list which want to reset his password...
[21:19:14] knightr: (which AFAIK is not possible since he doesn't actually have an account...)
[21:19:32] knightr: gotta go...
[21:24:19] Tobbe5178 (Tobbe5178!~asdf@h184n1-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[21:30:09] gary_buhrmaster: knightr: correct (well, correct AFAIK). But the interface provides the buttons to suggest that you can login, and I have to admit more than once I wanted to go correct (the language/syntax/wording of a) ticket, but could not (no login).
[21:32:29] gary_buhrmaster: I think on the ((un?)countably infinite) TODO list of one of the devs there was a thought to integrate logins across the forum/wiki/trac/? Perhaps when someone finds that copious free time I have heard exists in the universe it could happen.
[21:33:55] gary_buhrmaster: btw, on the -users list, the questions/concerns regarding the atlas data changes have started.
[21:51:40] knightr_ (knightr_!~knightr@mythtv/developer/knightr) has joined #mythtv
[21:54:28] knightr_ (knightr_!~knightr@mythtv/developer/knightr) has quit (Client Quit)
[22:02:13] Chutt (Chutt!~ijr@2605:a000:1225:7e:c457:ef1d:60fd:2177) has quit (Read error: Connection reset by peer)
[22:02:36] rmeden: I'm here, and I can answer some XMLTV/SD questions if needed. (but I think it's pretty obvious... the tv_grab_sd_json grabber is just another XMLTV grabber)
[22:02:36] Chutt (Chutt!~ijr@2605:a000:1225:7e:c457:ef1d:60fd:2177) has joined #mythtv
[22:06:14] amessina (amessina!~amessina@unaffiliated/amessina) has quit (Remote host closed the connection)
[22:51:45] Roklobster (Roklobster!~Dirkka@ppp118-209-54-50.lns20.mel4.internode.on.net) has quit (Remote host closed the connection)
[22:53:54] dmfrey (dmfrey!~dmfrey@65-78-126-51.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv
[22:56:25] letifosi_ (letifosi_!~letifosif@216.207.42.134) has joined #mythtv
[22:59:52] letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has quit (Ping timeout: 252 seconds)
[23:00:39] letifosi_ (letifosi_!~letifosif@216.207.42.134) has quit (Ping timeout: 246 seconds)
[23:29:56] jpabq: rmeden: I just tried tv_grab_sd_json. Nice that it automatically sets up the channel icons. I did notice, however, that the parttotal is incorrect in some cases. For example I see an "Antiques Roadshow" that says it is "part 3 of 2".
[23:30:59] jpabq: rmeden: Using the old scheduledirect, it gets it right: "part 3 of 3"
[23:38:38] rkulagow (rkulagow!4c108fd5@gateway/web/freenode/ip.76.16.143.213) has joined #mythtv
[23:38:48] rkulagow: @jpabq: what's the programID?
[23:39:24] jpabq: EP002036520498
[23:39:50] jpabq: That is what Myth shows. Is that okay?
[23:40:39] rkulagow: what's the stationID?
[23:41:36] jpabq: xmltvid is 29021
[23:42:50] rkulagow: 5/25, 25 or 29?
[23:42:59] rkulagow: sorry, fiurst one is 5/24
[23:43:02] jpabq: 5/29 is where I noticed it.
[23:44:19] jpabq: I see the same @ 2am on 5/25
[23:44:51] rkulagow: it's something in the grabber or mythtv i think
[23:45:16] rkulagow: http://pastebin.com/CfmzpZCa
[23:45:24] rkulagow: 3 of 3 in the raw JSON
[23:47:41] jpabq: It looks like tv_grab_sd_json subtracts 1, but it does it for both partNumber and totalParts, so there must be a reason for that...
[23:49:15] jpabq: ... actually, if I am reading this right, tv_grab_sd_json ONLY /supplies/ partNumber, and not totalParts — so the totalParts is gettings lost?
[23:52:50] jpabq: No, I was reading it wrong, it appends totalParts on the end "part/total"
[23:56:55] arescorpio (arescorpio!~arescorpi@78-26-245-190.fibertel.com.ar) has joined #mythtv

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.