MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (66):

aloril, amessina, Anssi, brfransen, caelor_, cesman, Chutt, clever, coling, Cougar, dblain, dekarl, eee-blt_, ElmerFudd, enyc, fetzerch, Gibby, gigem, gregL, GreyFoxx, J-e-f-f-A, jams, jheizer, joki, jpharvey, jst, jwhite, jya, knightr_, kormoc, kurre2, moparisthebest, MythBuild, MythLogBot, nephyrin, og01_, peper03, poptix, purserj_, rhpot1991, rich0__, rmeden, robink, rsiebert, Seeker`, seld, Sharky112065, sheedy-away, skd5aner, sl1ce, sphery, sraue, stuartm, supaplex, superm1, taylorr, tgm4883, tonsofpcs, tris, unforgiven512, wagnerrp, Warped, XDS2010, xris, zentec, _charly_
Friday, October 3rd, 2014, 00:19 UTC
[00:19:12] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 250 seconds)
[00:20:40] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[00:27:27] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 272 seconds)
[00:34:23] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[02:22:52] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[02:23:26] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:34:35] rmeden1 (rmeden1!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has quit (Quit: Leaving.)
[02:35:04] rmeden (rmeden!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has joined #mythtv
[03:01:35] 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 (Quit: Oh No!!!! ;-))
[03:04:04] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@24.177.48.184) has joined #mythtv
[03:06:14] Squall571 (Squall571!4c124c2c@gateway/web/freenode/ip.76.18.76.44) has joined #mythtv
[03:20:40] arescorpio (arescorpio!~arescorpi@190.190.244.100) has joined #mythtv
[03:54:34] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds)
[03:54:55] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv
[03:55:41] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:11:46] bill6502 (bill6502!~bill@205.178.26.43) has left #mythtv ()
[04:48:43] Squall571 (Squall571!4c124c2c@gateway/web/freenode/ip.76.18.76.44) has quit (Ping timeout: 246 seconds)
[04:59:45] arescorpio (arescorpio!~arescorpi@190.190.244.100) has quit (Excess Flood)
[06:05:33] jst (jst!~quassel@198.199.94.175) has quit (Remote host closed the connection)
[06:05:41] jst (jst!~quassel@198.199.94.175) has joined #mythtv
[06:13:44] FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[06:44:41] jluttine (jluttine!~jluttine@dsl-hkibrasgw1-58c39e-156.dhcp.inet.fi) has left #mythtv ()
[06:57:41] enyc (enyc!~enyc@muddle.enyc.org.uk) has joined #mythtv
[06:58:39] esperegu: anyone a clue how to fix this mythfrontend crash? http://dpaste.com/0SXE6F7
[08:07:19] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:13:48] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 246 seconds)
[08:50:01] joki (joki!~joki@p54860214.dip0.t-ipconnect.de) has quit (Ping timeout: 260 seconds)
[08:55:15] joki (joki!~joki@p54862E8F.dip0.t-ipconnect.de) has joined #mythtv
[09:04:11] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has joined #mythtv
[09:04:11] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has quit (Changing host)
[09:04:11] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[09:14:06] dekarl1 (dekarl1!~dekarl@p4FE8510C.dip0.t-ipconnect.de) has joined #mythtv
[09:16:48] dekarl (dekarl!~dekarl@p4FE84EDB.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[09:34:44] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 260 seconds)
[09:47:57] kc (kc!~Casper@pool-108-52-47-183.phlapa.fios.verizon.net) has joined #mythtv
[09:47:57] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[09:47:57] kc (kc!~Casper@pool-108-52-47-183.phlapa.fios.verizon.net) has quit (Changing host)
[10:41:22] dekarl1 is now known as dekarl
[11:14:48] sphery_ (sphery_!~mdean@mythtv/developer/sphery) has quit (Quit: leaving)
[11:15:09] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[12:14:36] rsiebert (rsiebert!~quassel@g225187103.adsl.alicedsl.de) has joined #mythtv
[12:17:24] rsiebert_ (rsiebert_!~quassel@g225114027.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[12:22:44] moparisthebest (moparisthebest!~quassel@gateway/tor-sasl/moparisthebest) has quit (Remote host closed the connection)
[12:23:00] moparisthebest (moparisthebest!~quassel@gateway/tor-sasl/moparisthebest) has joined #mythtv
[12:28:17] skd5aner (skd5aner!~skd5aner@90.sub-70-198-71.myvzw.com) has quit (Read error: Connection reset by peer)
[12:28:40] skd5aner (skd5aner!~skd5aner@90.sub-70-198-71.myvzw.com) has joined #mythtv
[13:09:56] Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv
[13:15:05] Cougar (Cougar!~cougar@2a03:5880:104:10:d8e1:93a6:a0c2:d970) has quit (Ping timeout: 260 seconds)
[13:26:54] Cougar (Cougar!~cougar@2a03:5880:104:10:5579:413:8f11:91cd) has joined #mythtv
[13:50:58] gigem: rmeden: As I said then, that's unfortunate. I thought xmltv had picked up some DDism over the years and had moved in that direction some. FWIW, some did say xmltv could do differential updates too. They didn't distinguish, though, between "the framework allows it" and "somebody actually already does it".
[13:57:08] rmeden: gigem: The XMLTV schema hasn't changed much from before DD. It's certainly not normalized like the DD format. (DD=Data Direct.. Tribune's data format). Remember the term, XMLTV is multiple tings, including a File format (schema) and a Sourceforge Project (collection of tools)
[14:13:22] supaplex (supaplex!~supaplex@216-21-163-249.slc.googlefiber.net) has quit (Ping timeout: 240 seconds)
[14:15:27] supaplex (supaplex!~supaplex@216-21-163-249.slc.googlefiber.net) has joined #mythtv
[14:24:53] FabriceMG (FabriceMG!~Thunderbi@LCaen-656-01-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[14:32:21] stuartm: rmeden: the json php scripts we've seen for mythtv are not really an acceptable solution for most of us, for one, acting directly on the mythtv database (and altering the mythtv schema!!) is just plain wrong
[14:33:11] stuartm: every schema change we make would break the SD grabber, it bypasses all our code which applies fixups to data, extracts additional info etc
[14:33:55] rmeden: stuartm: I don't disagree.. wrong Robert :)
[14:34:36] rmeden: I did the SD-DD service, not JSON... my push for a TMS-DD replacement has always been "change as little as possible"
[14:35:12] stuartm: so migrating North American users to xmltv (as used by every one else) is really our preferred solution, so far as I'm aware, there's no new data in the json feed that is actually used by MythTV so users aren't going to miss out on anything and xmltv can be extended with time
[14:35:19] rmeden: alas, RobertK and others on the SD board wanted to start over with a better designed service
[14:35:59] rmeden: in RobertK's defense, he really is only interested in the backend.. he never meant to develop a MythTV grabber, but he needed a client to test his new server.
[14:37:29] rmeden: XMLTV is lots of different things.. what do you mean when you say "migrating North American Users to xmltv"? Do you mean XMLTV file format with an external grabber?
[14:37:51] stuartm: rmeden: could SD not track the changes stuff server-side? I had thought that's what the json feed was doing anyway – e.g. server only supplies what has changed since the last time the user downloaded ?
[14:38:43] stuartm: rmeden: I'm just trying to explain why we're not pursuing the php grabber solution
[14:38:56] rmeden: If you are going XMLTV file format, not much is different from using the SD-DD service.. I think, but using SD-DD directly is probably safer than using SD-DD through XMLTV file format.
[14:39:40] stuartm: rmeden: external grabber, xmltv format – which is what we support
[14:40:09] stuartm: we'd want to ditch the DD parsing code entirely, have just one to maintain
[14:40:22] rmeden: stuartm: SD could not reasonably track changes server side.. that's a lot of data to keep for lots of people.. plus what if a user has two devices?
[14:41:04] stuartm: our xmltv code is much better than our DD code, it supposed among other things merging only changes into the database instead of wiping our tables and importing all new data
[14:41:05] rmeden: startm: if the XMLTV output generated by tv_grab_na_dd comes out the same, I don't see a problem with it... but that's a MythTV decision.
[14:41:25] stuartm: s/supposed/supports/
[14:42:15] rmeden: it's not a bad plan... again, *IF* the data loaded into the DB from tv_grab_na_dd provides the same result (or good enough)
[14:42:41] rmeden: when I wrote tv_grab_na_dd, I tried to put all the TMS_DD data *somewhere* (it didn't always fit in the XMLTV schema)
[14:42:59] stuartm: our xmltv parser also imports more data than the DD parser e.g. season and episode info, tvdb/tmdb ids and some other stuff that I'm forgetting just now
[14:43:24] rmeden: tv_grab_na_dd doesn't do season/episode info.. it's not in the data.
[14:43:41] stuartm: rmeden: generally MythTV only displays/uses data that is provided by xmltv, so any DD specific data is just ignored anyhow
[14:43:57] rmeden: but MythTV going XMLTV only is really a separate issue from Nov 1. (the primary focus)
[14:44:26] stuartm: rmeden: I'm told it's available in the json data though, so if someone were to write a json>xmltv grabber it would be available?
[14:44:36] rmeden: yup
[14:45:02] rmeden: stuartm: so far no one has stood up to write a SD-JSON->xmltv grabber, but it's certainly possible
[14:45:27] rmeden: xmltv schema could also be extended to include additional fields
[14:45:40] stuartm: hoping that someone will make that effort, even if I have to twist a few arms ;)
[14:45:55] rmeden: I doubt it will be ready by Nov 1
[14:46:40] stuartm: no, which is why to start with we'll migrate at least our stable versions to use your intermediate json<>dd feed, for continuity
[14:48:54] rmeden: json<>DD?
[14:49:05] rmeden: there's JSON and SD-DD (Schedules Direct hosted data direct)
[14:49:12] stuartm: longer term though we'd prefer to have just one method for importing data, it will make code much easier to maintain, improve consistency for users and hopefully increase interest in improving xmltv and our xmltv support
[14:49:35] rmeden: I don't see a problem there
[14:49:43] stuartm: rmeden: the SD-DD feed (the new one) isn't just a translation of the json feed?
[14:50:33] stuartm: I assumed that it was, my bad
[14:50:38] rmeden: stuartm: nope, totally independant. It uses Tribune's decades old flat file feed
[14:51:46] stuartm: ok, so not that I'm suggesting that you'll actually do it, but you could then technically also supply a direct xmltv feed?
[14:52:02] rmeden: I think most of Tribune/Gracenote's customers use that... DataDirect, "On" (a JSON service source for SD-JSON) are "fads" in my opinion.. Gracenote's hope to get more into the data hosting business.
[14:53:38] rmeden: There's no reason SD couldn't create a direct XMLTV output service from either flat files or "On" .. I just don't think there's much of a need for it, when there's already a DD -> XMLTV converter
[14:54:26] rmeden: JSON hosted to an XMLTV grabber is much more efficient (as the JSON client would determine what to download from the server)
[14:55:33] rmeden: to do that and be included in the XMLTV SF project, XMLTV SF project needed to support a close to recent release of Perl, which it does now. (as of a couple of months ago)
[14:56:19] rmeden: so that's a good soultion, create a XMLTV project tv_grab_sd_json to output XMLTV (and extend XMLTV for more info)
[14:57:06] rmeden: but it's a lot of work
[14:57:40] Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Ping timeout: 260 seconds)
[15:06:11] Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has quit (Read error: Connection reset by peer)
[15:07:44] Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has joined #mythtv
[15:07:59] stuartm: rmeden: sorry got called away
[15:09:28] stuartm: in the distant past one of the reasons given for not switching over to xmltv for DD/SD users was that it was 'redundant' and a waste of cycles on users machines to convert from one format to another, hence my question
[15:10:21] stuartm: we're already discussing having certain non-US grabber sources migrate to Atlas (I presume you're familiar?) serving xmltv directly
[15:11:11] stuartm: dekarl is much more familiar with that proposal than I am
[15:18:24] rmeden: stuartm: not converting is more computationally efficient, but supporting multiple file formats isn't efficent use of human time... at least that could have been a counter argument at the time
[15:19:13] rmeden: if folks were interested in efficency, the only language would be C. (it does a btter job now that humans, so assembly is out)
[15:31:28] stuartm: preaching to the converted there, MythTV is after all a C/C++ application
[15:32:04] rmeden: if it's worth doing, it's worth doing in Perl. I'm converted... human effiicency is often more important :)
[15:33:10] stuartm: I've a soft spot for perl, and even php has it's place (just not as a command line grabber)
[15:34:48] rmeden: I've actually done some non-web php stuff.. it does a much better job than perl tools for SOAP.
[15:35:15] rmeden: but it did bother me :)... I just didn't want to take the time to get Perl working when I had a working 5 line script in php :)
[15:35:46] stuartm: perl's soap libs are awful
[15:36:03] rmeden: SD-DD is written in Perl, but the lineup fetch (from TMS) is in PHP (via a system call)
[15:36:07] stuartm: but then as many people would say, SOAP is awful
[15:36:23] rmeden: yup!
[15:36:56] rmeden: of course when TMS goes away, the TMS fetch will go away too
[15:38:02] stuartm: I gave up one doing one soap project in perl and instead used python, a language which I barely know at all, which IMHO says everything about soap with perl
[15:39:58] rmeden: I tried python once, but the whitespace nesting bothers me... didn't we get rid of column requirements with Fortran?
[15:45:18] stuartm: it's an annoyance, but in all other respects python isn't so bad, if perl is akin to C, then python is C++ – it does OO better than perl, although not perfectly
[15:46:09] stuartm: I'm still more comfortable with perl because I know it so much better
[15:46:56] ** jheizer hides being a .Net monkey **
[15:57:27] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[16:05:08] SteveGoodey (SteveGoodey!~steve@host109-158-49-145.range109-158.btcentralplus.com) has joined #mythtv
[16:29:48] Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has quit (Read error: Connection reset by peer)
[16:32:56] Chutt (Chutt!~ijr@cpe-174-100-158-24.neo.res.rr.com) has joined #mythtv
[16:35:01] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection)
[16:35:18] rmeden: I just fixed the category problem with sd_dd can someone test it?
[17:11:05] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[17:14:20] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Client Quit)
[17:33:32] Warped (Warped!~Warped@108.85.160.119) has joined #mythtv
[17:34:01] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 260 seconds)
[17:35:00] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[18:38:50] gigem: rmeden: Hold on, I'll try it shortly.
[18:39:45] rmeden: gigem: thanks.. BTW, I'm '87
[18:40:22] rmeden (rmeden!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has left #mythtv ()
[18:51:58] Warped (Warped!~Warped@108.85.160.119) has quit (Ping timeout: 244 seconds)
[18:52:19] rmeden (rmeden!~Robert@107-131-101-38.lightspeed.rcsntx.sbcglobal.net) has joined #mythtv
[18:52:41] rmeden: gigem: lost the window... how did the test go?
[18:56:08] dekarl: stuartm, ahh I suggested that as a way to get richer data out there, using an established API and hosting concept. The idea would have to be adjusted to include oztivo style authentication, now that the feed without authentication is going away
[18:57:28] dekarl: Maybe I'll look into doing it myself next year, looks like not many people are interested in contributing to the atlas eco system :(
[19:37:31] SteveGoodey (SteveGoodey!~steve@host109-158-49-145.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[19:50:58] gigem: rmeden: '84 here. I didn't realize you were in the DFW area. We should get together for lunch some time. I live in Garland and work in Richardson. The first run didn't work so well. I lost all data for cablecard source, and for my clear qam source, most programs don't have a category set. I'm rerunning now. When I tried the SD-DD service yesterday, I had strange results the first time, too.
[20:06:45] stuartm: rmeden: someone was mentioning in here last night that they only got data for 6 days when they tried the SD-DD service
[20:07:59] rmeden: stuartm: yea, saw that.. doesn't make sense I see more data, but if it happens again, I'm willing to trace it.
[20:08:21] jheizer: That was me. Have been absolutely swamped with work today so have not been able to give it another try. There was some data past the day 6, but not all as 3/4 of my recordings were not in the upcoming list anymore
[20:08:21] rmeden: but he also said some stations had full data, others didn't, without details
[20:08:58] gigem: rmeden: Yes, I'm getting category, aka most-relevant genre. There's some other weirdness, but it could be a local configuration issue. Assume it is unless I tell you otherwise.
[20:09:19] jheizer: I never pulled up the listings themselves so that was others. I can try another pull now.
[20:09:22] rmeden: jheizer: just let me know a bad channel and your SD username and I can take it from there
[20:10:01] rmeden: gigem: awsome... so until someone complains about only having one genre we're good :)
[20:10:43] jheizer: rmeden, doing a grab all now, will let you know in 5 min or so
[20:11:49] stuartm: rmeden: could it be an incomplete download? Connection is being dropped or similar?
[20:12:53] gigem: rmeden: I'd probably be the only one to complain. I like the multi-genre capability on the category search screen. :)
[20:12:57] rmeden: could be, but once I get the details, I can check the downlaoded results. I'm storing it for all downloads at the moment. (until the disk gets full, then I delete it)
[20:13:32] rmeden: gigem: better be careful, or I'll turn it back on random and you'll get so many pretty colors on your screen you'll really get confused!
[20:14:55] gigem: What did you say? I was distracted by the pretty mosaic on the EPG. :)
[20:19:06] jheizer: Everything looks good on this pull, new data feed has 1 more sporting item that my existing did not. Rest looks identical.
[20:19:21] rmeden: excellent
[20:20:12] rmeden: I load data around 9–10am EDT, no tsure if that could cause misssed days, don't think so, but who knows.
[20:20:47] rmeden: I'm really baffeled by the folks who are getting NOPOSTDATA errors
[20:21:14] jheizer: new feed had a day more than my existing. The one new item for tomorrow was a MLB game so it could have changed more data as I use a power rule on it.
[20:21:44] gigem: I must be extra dense today, because I can't figure this out. Does anyone know why channels from a videosource won't show up in the EPG or other program search screens? channel.visible = 1, so that's not it.
[20:30:31] dekarl: is channum + callsign unique?
[20:30:55] rmeden: should be, but I think it's really channum+station_id
[20:31:04] rmeden: (at least in the data)
[20:31:42] dekarl: gigem: is the source connected to an input?
[20:32:09] rmeden: are you talking within a lineup? oh wait, you're talking about eh display issues.. never mind :)
[20:32:19] dekarl: :)
[20:49:47] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Remote host closed the connection)
[20:52:07] stuartm: gigem: is the videosource associated with an input?
[20:53:41] gigem: dekarl, stuartm: That was it. This was with on my dev system and I guess I didn't re-add my cablecard tuners the last time reconfigured for whatever I was testing. Thanks.
[20:54:21] Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit ()
[20:57:17] stuartm: dekarl: sorry, didn't notice you suggesting the exact same thing 20 minutes before I did
[21:06:04] Warped (Warped!~Warped@108.85.160.119) has joined #mythtv
[21:53:46] Tobbe5178 (Tobbe5178!~asdf@h29n12-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[22:36:48] rich0__ (rich0__!~quassel@gentoo/developer/rich0) has joined #mythtv
[22:39:57] Tobbe5178 (Tobbe5178!~asdf@h29n12-sv-a13.ias.bredband.telia.com) has joined #mythtv
[22:40:12] rich0 (rich0!~quassel@gentoo/developer/rich0) has quit (Ping timeout: 245 seconds)
[22:41:31] Tobbe5178 (Tobbe5178!~asdf@h29n12-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)

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