MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (73):

joki, jya, MythLogBot, skd5aner, SteveGoodey, tonsofpcs, aloril, amessina_, Anssi, caelor_, Captain_Murdoch, Chutt, clever, coling, Cougar, dekarl, eee-blt, ElmerFudd, enyc, fetzerch, GreyFoxx, J-e-f-f-A, jafa2, jams, jarle, jheizer, jnylen, jpabq, jpharvey_, jwhite, kc, kormoc, kurre2, MythBuild, nephyrin, peper03, poptix, purserj, rhpot1991, robink, seld, Sharky112065, sl1ce, sphery, stuarta, stuartm, superm1, tgm4883, Tobbe5178, tris, unforgiven512, wagnerrp, xris, _charly_, aberrios_, jarryd, taylorr, og01, zentec, moparsthbest, dblain_, wahrhaft_, Gibby, gregL, Guest64002, jst_, sheedy, knightr, cecil, Seeker`, XDS2010, Ben64, 77CAAAV32
Thursday, September 18th, 2014, 00:33 UTC
[00:33:26] andreaz (andreaz!~andre_000@p5792344E.dip0.t-ipconnect.de) has joined #mythtv
[00:34:16] andreaz (andreaz!~andre_000@p5792344E.dip0.t-ipconnect.de) has quit (Client Quit)
[00:58:45] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 1.0)
[00:59:55] gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has joined #mythtv
[00:59:56] gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has quit (Changing host)
[00:59:56] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[01:43:22] sheedy is now known as sheedy-away
[02:40:22] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[02:41:05] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:48:17] databus (databus!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has joined #mythtv
[03:03:42] databus (databus!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has left #mythtv ()
[03:17:18] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[03:18:37] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:41:35] arescorpio (arescorpio!~arescorpi@178-31-245-190.fibertel.com.ar) has joined #mythtv
[03:58:42] skd5aner (skd5aner!~skd5aner@181.sub-70-198-70.myvzw.com) has quit (Read error: Connection reset by peer)
[03:59:03] skd5aner (skd5aner!~skd5aner@181.sub-70-198-70.myvzw.com) has joined #mythtv
[04:05:59] arescorpio (arescorpio!~arescorpi@178-31-245-190.fibertel.com.ar) has quit (Excess Flood)
[04:53:43] dekarl1 (dekarl1!~dekarl@p4FE84DB1.dip0.t-ipconnect.de) has joined #mythtv
[04:55:06] dekarl (dekarl!~dekarl@p4FE857FB.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[05:32:28] dekarl1 is now known as dekarl
[05:56:29] SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has joined #mythtv
[06:03:46] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds)
[06:07:05] SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!)
[06:08:07] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:16:46] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds)
[06:21:07] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:39:23] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[07:25:49] dekarl (dekarl!~dekarl@p4FE84DB1.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)
[07:28:08] dekarl (dekarl!~dekarl@p4FE84DB1.dip0.t-ipconnect.de) has joined #mythtv
[07:43:40] skd5aner (skd5aner!~skd5aner@181.sub-70-198-70.myvzw.com) has quit (Ping timeout: 258 seconds)
[07:44:21] skd5aner (skd5aner!~skd5aner@181.sub-70-198-70.myvzw.com) has joined #mythtv
[07:55:46] stuarta: stuartm: when looking at not pushing out the link local address i was reading though the serverpool code. it seems to take care of a lot of different edge cases. is there any mileage in leveraging that?
[07:56:26] stuarta: stuartm: i'm also going to try a different fix, which is to strip the link local of the scope in the SSDP announcement
[07:56:47] stuarta: since the scope is only relevant to the box which is sending the announcement
[07:57:15] stuarta: it may just turn out that it won't work properly
[08:02:01] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:15:44] jafa2 (jafa2!~jafa@2001:470:80ca:2000:6c30:202c:b0ad:7a62) has quit (Ping timeout: 260 seconds)
[08:17:44] jafa2 (jafa2!~jafa@2001:470:80ca:2000:d443:9d7b:7bb1:f7e3) has joined #mythtv
[08:46:18] joki (joki!~joki@p54860058.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[08:49:54] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[08:52:35] joki (joki!~joki@p548628B8.dip0.t-ipconnect.de) has joined #mythtv
[08:58:54] dekarl1 (dekarl1!~dekarl@p4FCEEBC1.dip0.t-ipconnect.de) has joined #mythtv
[08:59:35] dekarl (dekarl!~dekarl@p4FE84DB1.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[09:15:45] skd5aner (skd5aner!~skd5aner@181.sub-70-198-70.myvzw.com) has quit (Ping timeout: 255 seconds)
[09:16:00] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has joined #mythtv
[09:30:06] dekarl1 is now known as dekarl
[09:54:17] FabriceMG1 (FabriceMG1!~Thunderbi@217.112.59.207) has joined #mythtv
[09:58:20] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Ping timeout: 272 seconds)
[09:58:37] FabriceMG1 (FabriceMG1!~Thunderbi@217.112.59.207) has quit (Ping timeout: 245 seconds)
[09:58:39] FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[10:00:10] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has quit (Read error: Connection reset by peer)
[10:00:29] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has joined #mythtv
[10:46:47] stuartm: stuarta: we get the address list from ServerPool, the only difference is that it's cached in the UPnP code and it probably shouldn't be – we still want the server to listen on localhost, just not announce that address since you want to be able to access the WebFrontend and Services API via that address
[10:47:23] stuarta: ok
[10:54:26] GreyFoxx_ is now known as GreyFoxx
[10:54:49] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (Changing host)
[10:54:49] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has joined #mythtv
[11:24:12] stuartm: so changing the SSDP code to use a filtered listed direct from ServerPool makes sense and keeps the code duplication down
[11:53:30] stuarta: that's what i was wondering
[12:04:29] stuarta: also as that's used for the main backend sockets, it means if one works the other should too
[12:10:24] stuartm: it's used for the upnp server itself
[12:10:43] stuartm: HttpServer is derived from ServerPool
[12:18:38] andreaz (andreaz!~Andreaz@tmo-106-42.customers.d1-online.com) has joined #mythtv
[12:20:16] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has quit (Ping timeout: 260 seconds)
[12:24:20] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has joined #mythtv
[12:25:00] sheedy-away is now known as sheedy
[12:31:32] stuarta: stuartm: re #12087 there was a commit a while back which stopped removing the "also in HD" in the eitfixups. that's the cause of this issue
[12:31:32] ** MythLogBot http://code.mythtv.org/trac/ticket/12087 **
[12:31:33] sheedy is now known as sheedy-away
[12:34:18] stuartm: stuarta: well an indirect cause, primary cause is that the default_authorities weren't populated for those channels, the fact that the descriptions don't match just compounds the original issue as it can't fallback to Subtitle then Description matching
[12:35:38] stuarta: indeed
[12:35:55] stuarta: i did think when that commit went in it would break things
[12:36:15] stuartm: any idea when that fixup was removed?
[12:36:41] stuarta: crap, it's a long time back at least 6 months
[12:37:18] stuartm: de karl?
[12:37:30] stuarta: prob
[12:37:51] stuartm: k, will go hunting later
[13:04:04] jheizer__ (jheizer__!~jheizer@73.51.93.177) has quit (Ping timeout: 272 seconds)
[13:05:52] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has quit (Ping timeout: 240 seconds)
[13:06:26] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has joined #mythtv
[13:14:18] jheizer (jheizer!~jheizer@73.51.93.177) has joined #mythtv
[14:04:47] andreaz1 (andreaz1!~Andreaz@tmo-106-42.customers.d1-online.com) has joined #mythtv
[14:08:40] andreaz (andreaz!~Andreaz@tmo-106-42.customers.d1-online.com) has quit (Ping timeout: 250 seconds)
[15:11:54] FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[15:26:49] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-72.range109-148.btcentralplus.com) has joined #mythtv
[15:30:17] jpharvey (jpharvey!~jpharvey@host86-181-25-182.range86-181.btcentralplus.com) has quit (Ping timeout: 260 seconds)
[15:47:59] dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv
[15:49:01] dekarl-work: stuarta, re https://forum.mythtv.org/viewtopic.php?f=2&t=353 how does an ITV description look like? is there some text like [S,HD,W] or how do people know if they are going to get a HD programme? https://github.com/MythTV/mythtv/blob/master/ . . . xup.cpp#L738
[15:57:02] dekarl-work: Just wondering how FixUK should set VID_HDTV (I can't find any code that would set it)
[15:57:17] stuarta: dekarl-work: HD = hd broadcast
[15:58:13] dekarl-work: stuarta: and where does that HD appear in the description?
[15:58:21] stuarta: generally at the end
[15:58:28] dekarl-work: at the end of what?
[15:58:36] stuarta: description
[15:58:52] ** dekarl-work sounds stupid, but I can't just peek at it, due to being in a different country :) **
[15:59:13] dekarl-work: so its just "this is the best episode ever.\nHD"?
[15:59:31] stuarta: ever. [HD]
[15:59:48] dekarl-work: ahhh
[15:59:51] stuarta: [S,AD,HD] are common
[16:00:42] dekarl-work: so we could just add HD to the m_ukCC handler?
[16:00:54] stuarta: yep, surprised it isn't already there
[16:01:06] dekarl-work: its only m_ukCC("\\[(?:(AD|SL|S|W),?)+\\]"),
[16:01:37] dekarl-work: well, that explains why you wondered if FixUK is getting applied :) Makes lots more sense when that would actually do something to the HD flag
[16:02:19] stuarta: heh, yes that would work
[16:02:21] dekarl-work: maybe its because UK broadcasters set sane component tags on their events?
[16:02:53] stuarta: yes they often do
[16:03:14] dekarl-work: some channels appear to differentiate between "upscaled" and "native" HD. even though that doesn't really make sense for the component tag
[16:03:42] dekarl-work: because the actual video component will be proper HD (its just blurry)
[16:06:42] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has quit (Write error: Connection reset by peer)
[16:06:59] skd5aner (skd5aner!~skd5aner@229.sub-70-198-68.myvzw.com) has joined #mythtv
[16:08:53] dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: lets add HD and see how it goes)
[16:32:28] sheedy-away is now known as sheedy
[16:35:03] sheedy is now known as sheedy-away
[16:36:16] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv
[16:48:37] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 245 seconds)
[16:49:15] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[17:02:27] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:14:27] SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has joined #mythtv
[17:24:11] sheedy-away is now known as sheedy
[17:40:42] stuartm: I thought there was a an HD component descriptor, or did I just imagine that?
[17:50:05] andreaz1 (andreaz1!~Andreaz@tmo-106-42.customers.d1-online.com) has quit (Read error: Connection reset by peer)
[17:56:35] andreaz (andreaz!~Andreaz@tmo-106-42.customers.d1-online.com) has joined #mythtv
[18:03:46] andreaz (andreaz!~Andreaz@tmo-106-42.customers.d1-online.com) has quit (Read error: Connection reset by peer)
[18:07:51] stuartm: dekarl: VID_HDTV is handled by parse_dvb_component_descriptors
[18:14:51] Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 32.0.1/20140911151253])
[18:19:11] dekarl: stuartm: according to the user the component descriptor signals SD...
[18:19:40] stuartm: doh
[18:20:12] dekarl: may be on purpose, maybe not... but it sounds like it is a surpise / misconfiguration
[18:20:13] stuartm: still, the codec gives us a good clue, AVC in the UK means HD
[18:21:00] dekarl: signalling is mpeg-2 :)
[18:21:19] dekarl: the descriptor is on thw forum
[18:21:50] dekarl: maybe someone can file a ticket to the dvb-t operator?
[18:22:44] stuartm: double doh
[18:23:55] dekarl: could be a SD feed configured for the HD service or something like that
[19:16:42] dekarl: meh, why do I see season/episode data in recorded that's not coming from the metadata grabber :(
[19:25:04] dekarl: does setting season/episode to 0 here work? https://code.mythtv.org/doxygen/tv__rec_8cpp_source.html#l00409
[19:26:01] dekarl: the intent is to avoid polluting the recording database with season/episode data that doesn't come from thetvdb (or whatever tv grabber the user uses) due to the common disagreements on the episode order
[19:34:46] stuartm: dekarl: given the effort I put in to deriving and storing that info in recorded I'd have to fight you ;)
[19:35:19] stuartm: if you really want to stop it being copied over, that's not the place to do it
[19:35:41] dekarl: to the forks!
[19:35:43] dekarl: ;)
[19:36:34] dekarl: stuartm, should we switch to "guide-season/guide-episode" and "metadata-season/metadata-episode"?
[19:36:40] stuartm: IMHO the information from the broadcaster trumps tvdb, that's the order you'll watch it in anyway
[19:37:32] dekarl: I agree with that. But the answer doesn't not match to the question. (its a good answer though)
[19:37:36] dekarl: thetvdb gets to say what the correct episode and season number are *on thetvdb itself*
[19:37:36] stuartm: having it appear to record 1,3,2,5 would be confusing, "why didn't it record episode 4!"
[19:38:18] dekarl: showing the metadata from a different episode will lead to unhappy W
[19:38:46] dekarl: e.g. a guide provides title/season/episode, then we just look it up and fill in the missing episode title
[19:38:55] sheedy is now known as sheedy-away
[19:39:00] dekarl: so the episode title on screen will not match the title on file
[19:39:29] stuartm: dekarl: right, but not everyone is using tvdb, why should they lose out? I'm fine with overwriting the guide info with tvdb season/episode if users chose that, but not discarding guide info whether or not users actually have tvdb data
[19:39:34] dekarl: you can have your "episode/season" for "human consumption" and I can have a separate "episode/season" for the grabber
[19:39:38] stuartm: especially since tvdb doesn't carry all series
[19:40:08] dekarl: s/thetvdb/whatever the user uses as tv grabber, I don't know of any other legal grabber out there!/
[19:40:28] dekarl: :(
[19:40:41] stuartm: splitting them into two different columns might be the only solution that makes everyone happy, but which one gets displayed in the UI etc?
[19:41:08] stuartm: dekarl: not everyone uses a tv grabber for their recordings
[19:41:12] dekarl: guide data if its present, based on the asumption that the local guide will more likely match the users expectation?
[19:41:39] stuartm: fair enough
[19:41:43] dekarl: stuartm, yes, I read somewhere that others pull in data directly into our database from sources that shall not be named
[19:42:32] dekarl: progress! now it just needs to be put into code :)
[19:42:39] stuartm: dekarl: I don't mean guide data, I mean they don't run a post-recording mythmetadatalookup or whatever
[19:43:25] stuartm: if you're merging in tvdb data into guide data then the values will already be 'correct', no?
[19:43:39] dekarl: stuartm, if they don't run any post-recording "data and pictures available making program" then they should not care about season/episode data
[19:43:52] stuartm: dekarl: why not?
[19:44:14] dekarl: stuartm the data comes from the guide and doesn't break any metadata lookup data
[19:44:16] stuartm: it's useful for sorting recording, as an indication of where in a series you are etc
[19:44:40] stuartm: in upnp we sort recordings by season, and by episode
[19:45:00] stuartm: and I intend on offering the same in the WebFrontend
[19:45:49] stuartm: season/episode info isn't just a means to get artwork and nothing else, it serves it's own purpose
[19:51:57] dekarl: I think we agree with eachother, but its hard to be sure when we use one word for four concepts :/
[19:53:28] dekarl: season/episode the concept of the guide data, season/episode the field in the program table/property ProgInfo/ProgramInfo, season/episode the field in the recorded table, season/episode part of the primary key of the metadata grabber
[19:54:42] dekarl: I'm trying to say that the guide data does not make good metadata lookup data. The former being stored in season/episode in the program table, the latter being store in the recorded table in fields with the same name.
[19:56:12] dekarl: So my first intend was to cut the pipe that copies season/episode from program into season/episode of recorded (as they are called right now).
[19:56:32] dekarl: Now I think we should just give the recording two sets of fields, one for each usage
[20:32:19] sepeck (sepeck!~sepeck@drupal.org/user/5195/view) has joined #mythtv
[20:32:21] sepeck (sepeck!~sepeck@drupal.org/user/5195/view) has left #mythtv ()
[21:02:42] SteveGoodey (SteveGoodey!~steve@host86-164-55-181.range86-164.btcentralplus.com) has quit (Ping timeout: 245 seconds)
[21:27:48] wseltzer1 (wseltzer1!~wseltzer@peppercorn.seltzer.org) has quit (Ping timeout: 245 seconds)
[21:27:55] 77CAAAV32 (77CAAAV32!~wseltzer@peppercorn.seltzer.org) has joined #mythtv
[21:28:13] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 245 seconds)
[21:28:29] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[21:28:38] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@24-177-48-184.dhcp.oxfr.ma.charter.com) has quit (Ping timeout: 245 seconds)
[21:28:45] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@24-177-48-184.dhcp.oxfr.ma.charter.com) has joined #mythtv
[21:28:53] unforgiven512 (unforgiven512!~unforgive@oxymorphone.unforgivendevelopment.com) has quit (Ping timeout: 240 seconds)
[21:29:49] unforgiven512 (unforgiven512!~unforgive@oxymorphone.unforgivendevelopment.com) has joined #mythtv
[21:42:08] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-72.range109-148.btcentralplus.com) has quit (Ping timeout: 260 seconds)
[21:46:46] jpabq: stuartm: I have been away, and probably will not bother reading all of the history here over the last week+, but I did notice your comment about coverty. That should now be fixed.
[21:48:05] jpabq: dekarl: I just tried the new json downloader for schedules direct. It populates season/episode directing into the program table (it looks like). In Steppes, I was showing the syndicated episode number, if season/epsiode data was not available, and now nothing is showing — in the guide or upcomming recordings.
[21:51:33] dekarl: jpabq: oh, good reminder, need to talk to robert about populating the inetref on master
[21:53:29] jpabq: Looks like I am also missing 'people' information for upcomming episodes. I wonder if I need to just dump the appropriate tables and let it reload them...
[21:54:39] jpharvey_ (jpharvey_!~jpharvey@host86-179-38-240.range86-179.btcentralplus.com) has joined #mythtv
[21:57:45] jpabq: Ah. So, there are new SD tables in mythconverg. For example SDcredits. Does that mean someone needs to add SD specific support to myth to deal with this data?
[21:58:52] dekarl: jpabq: no, just that it is easier for mfdb-json to just add some tables to mythconverg then to come up with its own database
[21:59:32] jpabq: OK. I am just trying to figure out why when I press 'I' on an upcomming episode there is no 'cast' information.
[21:59:45] dekarl: is it in the source data?
[22:01:12] dekarl: why? https://github.com/SchedulesDirect/mfdb-json/ . . . ty.php#L1273
[22:01:15] jpabq: That data was there before running the json downloader. Now, no cast, producers, etc are listed.
[22:01:39] dekarl: ok, is the cast data present in the source data?
[22:01:59] dekarl: it is my understanding that the old XML and the new JSON data source have absolutely nothing in common
[22:03:16] jpabq: Do you know how to check? The SDcredits table has a bunch of stuff in it — I can track it that way, unless you know of an easier way?
[22:04:29] dekarl: I don't use schedulesdirect, so I have no idea. I just look at the code/samples
[22:06:17] jpabq: SDcredits has data for this episode I am looking at. Derefing it back to SDpeople has the actors I would expect.
[22:06:47] stuartm: wtf, new tables?
[22:06:59] stuartm: no
[22:07:14] jams: stuartm yes they have a new grabber
[22:07:34] stuartm: jams: right, but it shouldn't be inserting into it's own custom tables
[22:07:37] stuartm: that's just wrong
[22:07:50] jams: but it does...or at least the forum post mentioned it
[22:08:11] jams: assumed that was already discussed..but i guess not
[22:08:42] dekarl: stuartm, I don't care about the additional tables that just happen to live in the same schema with a prefix. Looks like its some kind of cache in SD format to be used by the script and converted to MythTV format *in our tables*
[22:08:52] dekarl: I do care about messing with our tables, though :/
[22:08:54] stuartm: I'm about to throw a hissy fit
[22:09:09] dekarl: ALTER TABLE credits CHANGE role
[22:10:45] jams: i haven't even looked at it yet but probably will by Nov 1st which is when support for the currect service stops
[22:10:47] stuartm: this situation is just so fucked up
[22:10:58] jheizer: ALTER TABLE videosource ADD COLUMN
[22:11:29] dekarl: jheizer: just seen that :(
[22:13:43] jpabq: After using the json downloader from SchedulesDirect, the credits table is empty :(
[22:15:55] stuartm: I was annoyed enough when my pleas to use xmltv were just ignored, I was even more upset that they were inserting direct into the database, but actually altering tables in database ... what a pile of crap
[22:16:41] jpharvey_ (jpharvey_!~jpharvey@host86-179-38-240.range86-179.btcentralplus.com) has quit (Ping timeout: 260 seconds)
[22:17:18] jheizer: huh, I had always assumed there was communication between you guys and them. Just not on here/publicly.
[22:17:31] stuartm: none at all
[22:17:36] jams: jheizer, same here
[22:19:04] stuartm: well except when Robert first mentioned he was working on something to support the new data format, and I laid out the benefits of standardising on xmltv
[22:19:36] dekarl: jpabq: jams: try https://github.com/SchedulesDirect/mfdb-json/issues ?
[22:19:55] stuartm: apparently sp hery repeatedly aired that preference on the SD forums, but I guess no-one was listening
[22:20:24] stuartm: jams: first we learnt of this Nov 1st deadline is when you guys did
[22:20:55] stuartm: if we'd known when SD knew we might have a decent solution already in place
[22:21:07] jams: oh so like a week or two ago
[22:21:21] stuartm: instead of a php! script ffs
[22:21:32] jams: yeah i thought that was odd. Seemed like a good time for a point-release with the grabber already in the system
[22:22:03] jheizer: Lol yeah @ php. And people give me crap over .Net on linux.
[22:22:32] jheizer: So I guess I should shut up. haha
[22:22:53] stuartm: just as we're about to release a version of MythTV that eliminates the php dependency (for mythweb), we're back requiring it for a CLI grabber
[22:23:51] stuartm: well hopefully we won't, with luck someone will step up to write a proper solution in the next six weeks
[22:25:53] dekarl: Would be a good time to switch xmltv to git, collect some of the forks and do a release with a new tv_grab_na_dd grabber...
[22:28:07] stuartm: dekarl: well I'd probably not change up the revision control system on people just before a release, but that's just me – I still remember how steep a learning curve git has and how disruptive the transition was
[22:28:35] jpharvey_ (jpharvey_!~jpharvey@host86-179-38-241.range86-179.btcentralplus.com) has joined #mythtv
[22:29:33] stuartm: dekarl: even an unofficial ns_sd grabber would be ok, and I don't think it's much of a stretch to write one from scratch in the time available if you've got a little experience and the time
[22:31:35] jheizer: I wonder if this means before the cut off date or not "Which isn't to say
[22:31:35] jheizer: that lineup management can't be on the Schedules Direct website at
[22:31:35] jheizer: some point, just that during the beta process it isn't."
[22:31:46] stuartm: even if it doesn't showcase all the new stuff(?) that the json feed offers, it's still going to be at least as good as the current SD grabber and probably better (xmltv supports season/episode etc)
[22:31:54] jheizer: or if all those items have to be duplicated as well
[22:35:22] jheizer: I have to run, but maybe this .Net dope can help out. Nice self contained hunk of code.
[22:37:44] jpharvey_ (jpharvey_!~jpharvey@host86-179-38-241.range86-179.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[22:49:30] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-225.range109-148.btcentralplus.com) has joined #mythtv
[23:09:35] jpharvey__ (jpharvey__!~jpharvey@host109-148-114-165.range109-148.btcentralplus.com) has joined #mythtv
[23:10:20] aberrios_ (aberrios_!~aberrios@195.130.201.200) has quit (Ping timeout: 250 seconds)
[23:11:17] aberrios_ (aberrios_!~aberrios@195.130.201.200) has joined #mythtv
[23:13:20] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-225.range109-148.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[23:19:04] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-100.range109-148.btcentralplus.com) has joined #mythtv
[23:23:13] jpharvey__ (jpharvey__!~jpharvey@host109-148-114-165.range109-148.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[23:42:22] jpharvey_ (jpharvey_!~jpharvey@host109-148-114-100.range109-148.btcentralplus.com) has quit (Ping timeout: 240 seconds)
[23:47:14] sheedy-away is now known as sheedy
[23:54:42] jpharvey_ (jpharvey_!~jpharvey@host86-179-38-196.range86-179.btcentralplus.com) has joined #mythtv

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