MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (66):

coling, ElmerFudd, MythLogBot, Steve_Goodey, tonsofpcs, aberrios_, aloril, Anssi, caelor_, Captain_Murdoch, clever, Cougar, dblain, dekarl, eee-blt, fetzerch, Gibby_, gigem, gregL, jams, jarryd, jheizer_, jnylen, jst, jwhite, jya, kormoc, moparsthbest, nephyrin, peper03, purserj, rhpot1991, rsiebert, Sharky112065, sheedy-away, sphery, stuarta, tris, unforgiven512, wagnerrp, Warped, wseltzer1, jarle__, Chutt_, MythBuild_, zentec, stuartm, _charly_, amessina, GreyFoxx_, xris-, XDS2010___, jpharvey, sraue, kurre2, robink, adamw, jpabq, arescorpio, joki, Seeker, cecil_, knightr, emm386, enyc, poptix-
Sunday, August 31st, 2014, 01:35 UTC
[01:35:55] andreaz (andreaz!~andre_000@p579223AB.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)
[01:55:35] jpabq_: adamw: if you are still around, Ihave a few minutes...
[01:55:43] jpabq_ is now known as jpabq
[01:55:53] jpabq (jpabq!~quassel@97-123-212-176.albq.qwest.net) has quit (Changing host)
[01:55:53] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[01:56:26] adamw: jpabq: hi!
[01:56:46] jpabq: Hi
[01:57:20] adamw: jpabq: well, it might not be quite as straightforward as I thought, but anyway...what we kinda want to do is have firewirerecorder.cpp process MPEG-TS packets using the stuff dtvrecorder.cpp uses, not its own custom ProcessTSPacket function
[01:57:46] adamw: unfortunately the codepaths diverge quite substantially before that point, which makes the 'simple' change...not that simple...
[01:57:57] adamw: though one of the shortcuts i tried might be close to working and I just missed it, i guess.
[01:59:03] jpabq: adamw: Does the firewire stream produce a TS or a PS?
[01:59:56] adamw: y'know...i didn't even think of that
[02:00:07] adamw: i was kinda going off the recommendation in the bug report to use the DTV stuff...
[02:00:52] adamw: jpabq: FirewireRecorder::InitStreamData calls AddMPEGSPListener(this); , does that mean PS?
[02:01:13] jpabq: I believe so.
[02:02:59] adamw: hah. yeah, the almighty googles seem to suggest it's a PS also.
[02:03:16] adamw: so...that's a pretty good reason not to reuse the code for handling transport streams, i guess =)
[02:04:18] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds)
[02:04:57] adamw: or, hm. maybe not. sigh, now i'm just not sure :)
[02:06:06] jpabq: FirewireRecorder::ProcessTSPacket() that would imply that it is processing a TS. Maybe some firewire has TS and other PS?
[02:07:18] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[02:07:45] jpabq: Must be TS. I am not seeing anything which is indicating that it is PS.
[02:09:35] jpabq: firewiredevice.cpp really needs to be rewritten as a "firewirestreamhandler.cpp", with parts of it going into "firewirechannel.cpp"
[02:11:09] jpabq: I am gessing it is a "single program transport stream".
[02:11:45] adamw: yeah, that seems to be what the handler is for
[02:12:32] adamw: so the cheap shortcut i tried that didn't work was just to dump FirewireRecorder::ProcessTSPacket entirely and turn the calls to it from FirewireRecorder::AddData into calls to GetStreamData()->ProcessTSPacket
[02:12:54] adamw: it builds, but doesn't work (zero length stream)
[02:13:53] adamw: so now i'm trying one which keeps FirewireRecorder::ProcessTSPacket but just does the basic checks then identifies the PID type and calls ProcessVideoTSPacket or ProcessAudioTSPacket appropriately (which i think should wind up coming in from DTVRecorder)
[02:13:59] adamw: if that doesn't work i plan on pouting :P
[02:14:24] jpabq: adamw: I would be willing to spend a couple of hours tomorrow hacking the current code into the more 'standard' StreamHandler / SignalMonitor / Channel / Recorder architecture that we use for most other 'recorders'. I would be willing to get it to the point where it compiles, but after that I would not be much help, since I don't know much about firewire and it is not available where I live.
[02:14:46] adamw: jpabq: i can certainly test and try dumb monkey fixes and throw debug statements around
[02:15:04] adamw: i have the hardware and the MPEG-4 streams right here
[02:15:55] jpabq: I see that there are two different files to handle the hardware: firewiredevice and darwinfirewiredevice
[02:16:07] adamw: three
[02:16:08] jpabq: oh, and linuxfirewiredevice
[02:16:10] adamw: there's a linux one
[02:16:14] adamw: i've gotta go fora bit tho, brb
[02:16:52] jpabq: I am off for tongight myself. If I have time tomorrow, I will see what I can come up with.
[02:18:40] shattingduck (shattingduck!~quassel@cable-86-56-16-249.cust.telecolumbus.net) has quit (Remote host closed the connection)
[02:41:47] adamw: jpabq: thanks a lot, i'll be around
[02:45:47] adamw: jpabq: hey, my new version worked!
[03:02:23] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[03:02:56] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:07:08] arescorpio (arescorpio!~arescorpi@92-202-17-190.fibertel.com.ar) has joined #mythtv
[03:40:49] jnylen: Hmm
[03:41:34] jnylen: What would the best way to add a "next transmission" to a xmltv file
[03:51:45] wagnerrp: next in the series? or a second showing of the same exact show?
[03:55:28] jnylen: Same episode
[03:55:30] jnylen: later on
[03:56:35] wagnerrp: internally, we're expecting each unique show to have a unique program id
[03:56:49] jnylen: We don't have that in our system (nonametv)
[03:56:57] wagnerrp: i don't know if that's proper procedure for xmltv though, or what field that would be
[03:57:22] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[03:58:20] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:50:17] arescorpio (arescorpio!~arescorpi@92-202-17-190.fibertel.com.ar) has quit (Excess Flood)
[05:59:42] dekarl: adamw: are you also trying to do #7205? (Support Firewire with missing PAT/PMT, just guessing as you mention "checks then identifies the PID type")
[06:11:08] dekarl: jnylen: if the xmltv source provides a) title, b) sets catgory=series, c) has season/episode in xmltv_ns then mythtv will generate a fake TMS program ID https://github.com/MythTV/mythtv/blob/master/ . . . ser.cpp#L541
[06:13:27] dekarl: if the source doesn't then we search for the program title to collect candidates and use the duplicate matching method specified in the recording rule (there is a locale speficic default) to figure out which showing are the same by comparing the subtitle (a funny name for episode title) and/or the description
[06:14:07] dekarl: there are new developments to also use the seriesid/programid to search for candidates with varying title texts, but I've not looked into that yet
[06:15:54] dekarl: in case you have some proper dd_prodids you can also put them in the xmltv https://github.com/MythTV/mythtv/blob/master/ . . . ser.cpp#L437
[06:20:37] dekarl: what we still miss is a way to signal a generic episode. (where we know which series it belongs to, but not the exact episode, due to missing data upstream)
[06:21:39] dekarl: and a way to turn the series id from thetvdb/themoviedb/tvrage into a seriesid for serieslink that could work. its all designed to work well with the TMS system and then some hacked on additions
[06:22:12] dekarl: currently everything is just a hash of the series title (with all the collisions you get that way)
[06:23:46] dekarl: what we need is something more like a tv-anytime content resolver, but that's a project for another day ;)
[06:36:57] jnylen: dekarl: Couldn't we generate a own unique program id
[06:57:04] dekarl: yes we could generated our own CRID style IDs and use these (basically crid://xmltv.se/content/abcdefgh)
[06:59:21] dekarl: But how do we manage these ids, so that the same content gets the same id? We'd need a mapping engine that takes manual hints. Oh and with tv-anytime style crids we could use a tv-anytime content resolver ;)
[06:59:55] dekarl: So tell it "record $james-bond-crid" and it would resolve that into the content locators of all james bond movies
[07:02:38] dekarl: It would work best if we create a database of programme descriptions, so we can detect repeats and emit the same programid again.
[07:03:16] dekarl: at which point we have replaced tmdb/tvdb with our own content database (<cough>tvbrainz</cough> ;)
[07:13:54] adamw: dekarl: nope, wasn't doing that – it's just about telling video from audio from control packets
[07:15:03] adamw: dekarl: the patch i came up with is attached to https://code.mythtv.org/trac/ticket/10080 , review welcome :)
[07:47:05] aloril (aloril!~aloril@dsl-tkubrasgw2-54faa3-2.dhcp.inet.fi) has quit (Ping timeout: 255 seconds)
[07:53:54] SteveGoodey (SteveGoodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has joined #mythtv
[07:54:21] aloril (aloril!~aloril@dsl-tkubrasgw2-54faa3-2.dhcp.inet.fi) has joined #mythtv
[08:20:45] Macer (Macer!macer@unaffiliated/macer) has joined #mythtv
[08:20:53] Macer: hello. just having a problem...
[08:20:55] Macer: 2014-08–31 03:20:00.292008 E [7862/101032] CoreContext mainserver.cpp:6268 (reconnectTimeout) – MainServer: Failed to open master server socket, timeout
[08:20:58] Macer: Handling Segmentation fault: 11
[08:21:05] Macer: and mythbackend dies
[08:21:10] Macer: did i mess something up here?
[08:30:15] dekarl: Macer: see /topic and "Failed to open master server socket" appears to hint at a slave backend. If it isn't I'd check the IP/MasterServerIP settings
[08:31:15] Macer: oh. my mistake. sorry about that.
[08:33:28] adamw: so if anyone's interested in helping figure out what the hell's coming out of the two channels i still can't tune with my MPEG-4 patch, https://www.happyassassin.net/temp/bad_216.mpg is a tiny snippet from one
[08:33:42] adamw: dvbsnoop output for it looks a lot like garbage, don't really know how else to go about analyzing it
[08:34:25] adamw: er, that's what i get from test_mpeg2
[08:43:18] joki- (joki-!~joki@p54861835.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds)
[08:46:19] Macer (Macer!macer@unaffiliated/macer) has left #mythtv ()
[08:48:16] joki (joki!~joki@p548613A1.dip0.t-ipconnect.de) has joined #mythtv
[09:03:27] jnylen: dekarl: this should be easy to do actually. I'll look into it.
[09:14:11] Seeker`_: are there problems with building master atm? Or am I failing in some special way
[09:14:15] Seeker`_ is now known as Seeker`
[09:14:45] Seeker` is now known as Guest97941
[09:15:17] dekarl: seeker, https://code.mythtv.org/buildbot/waterfall ?
[09:15:23] Guest97941 is now known as Seeker
[09:15:29] Seeker (Seeker!~cjo20@host86-164-181-3.range86-164.btcentralplus.com) has quit (Changing host)
[09:15:29] Seeker (Seeker!~cjo20@unaffiliated/seeker) has joined #mythtv
[09:17:07] Seeker: make[2]: *** No rule to make target `libavcodec/dsputil_template.c', needed by `libavcodec/dsputil.o'. Stop.
[09:17:10] Seeker: is what I'm getting
[09:21:24] dekarl: Seeker: make distclean && configure && make ? I'm not having that file and not finding a reference to it either in master
[09:40:35] dekarl1 (dekarl1!~dekarl@p4FE852CD.dip0.t-ipconnect.de) has joined #mythtv
[09:43:06] dekarl (dekarl!~dekarl@p4FE84172.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds)
[09:43:11] cecil_ (cecil_!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has joined #mythtv
[09:43:37] cecil (cecil!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has quit (Ping timeout: 245 seconds)
[09:47:49] dekarl1 is now known as dekarl
[09:54:48] Steve-Goodey (Steve-Goodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has joined #mythtv
[09:57:24] SteveGoodey (SteveGoodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has quit (Ping timeout: 250 seconds)
[10:27:48] paul-h (paul-h!~Paul@94.12.155.185) has joined #mythtv
[10:33:25] paul-h: stuartm: http://pastebin.com/3Kmrv2P3 – No idea if what he says is true but this one actually seems to work this time :)
[11:44:23] Steve_Goodey (Steve_Goodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has joined #mythtv
[11:44:44] Steve-Goodey (Steve-Goodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has quit (Ping timeout: 260 seconds)
[11:59:17] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 260 seconds)
[12:12:21] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[12:13:30] rsiebert_ (rsiebert_!~quassel@f052011080.adsl.alicedsl.de) has joined #mythtv
[12:16:30] rsiebert (rsiebert!~quassel@f052008205.adsl.alicedsl.de) has quit (Ping timeout: 250 seconds)
[12:49:23] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[12:50:20] GreyFoxx_ (GreyFoxx_!~greg@out.of.phaze.org) has joined #mythtv
[12:57:03] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (*.net *.split)
[12:57:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (*.net *.split)
[12:57:07] jya_ is now known as jya
[14:12:23] shattingduck (shattingduck!~quassel@cable-86-56-16-249.cust.telecolumbus.net) has joined #mythtv
[14:38:20] dekarl: adamw: mythutil --pidcounter says its garbage, too. Even though a peek at the hexdump shows some ts packet start codes (0x47 expected to be 188 bytes apart)
[14:55:17] esperegu_ (esperegu_!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Ping timeout: 245 seconds)
[14:56:26] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv
[14:56:45] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Remote host closed the connection)
[14:57:55] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv
[16:25:07] adamw: dekarl: welp, my boxes certainly make something of it. odd.
[16:25:35] adamw: it's not like i actually care about either BC News 1 HD or APTN, but just the principle of the thing :P
[16:33:44] stuartm: if there are ts packet start codes but it's otherwise unreadable that would suggest some level of encryption, though it's generally done at the vid stream level AFAIK and not at the ts level
[16:34:24] adamw: the box diagnostics claim that *every* channel is encrypted (even the ones that work fine), so that doesn't tell me much
[16:35:39] stuartm: if it was 'standard' encryption you'd expect to see it flagged in the PMT (iirc, since this isn't really my area), but if the PMT is scrambled ...
[16:36:06] stuartm: it's probably safe to say this wouldn't be the standard form of encryption used everywhere else
[16:37:12] stuartm: more surprising is that the box even outputs anything for those channels – why bother? So it's definitely curious
[16:38:08] stuartm: they could be using non-standard packets, or simply a form of standard TS packet that we've never ever seen before (unlikely but ...)
[16:40:23] stuartm: there has to be another utility for dumping from firewire, something that would confirm that it's a problem with the raw data and not MythTV or test_mpeg2's handling of that data
[16:40:47] dekarl: stuartm, PAT/PMT must be in the clear IIRC
[16:41:26] dekarl: maybe it was just coincidence and all it takes is some priming (whatever that means) http://www.mythtv.org/wiki/Firewire_primer.pl
[16:41:34] adamw: stuartm: yeah, that's the kind of thing i was looking for pointers with
[16:41:58] adamw: dekarl: priming is mostly user cargo cult bullshit and/or just a complicated way of restarting the backend/bus when stuff doesn't work, afaics
[16:43:33] dekarl: adamw: so its repeatable the same result with the same channels? then its something else.
[16:44:06] adamw: dekarl: yeah, it's not the usual firewire 'weirdness' like stopping streams, quasi-random 0-byte streams, none of that
[16:44:18] dekarl: IIRC there was something about some devices (need to google) spewing out random bytes before starting with proper content
[16:44:33] adamw: dekarl: other channels (including mpeg-4 channels) work 99.9% reliably (i seem to have an unusually reliable setup), these two produce this garbage data all the time
[16:45:07] dekarl: hmm, maybe they have the "no firewire for you" bit set ;)
[16:45:11] adamw: (there might be others, these are just the two i've found – i only care about HD channels, and I don't have a lot of premium ones, so I don't have that much choice)
[16:45:35] stuartm: dekarl: that would be my guess, but if that's the case why output any data at all
[16:45:37] adamw: i checked the flags i could find, they all looked good (and the same as on channels that worked)
[16:46:45] adamw: hmm, that's interesting
[16:46:55] adamw: firewire_tester reports failure on the channels that don't work
[16:46:59] dekarl: stuartm, hmm I bet no one tested that, maybe its just an electrically open connection that it gets switched to emitting random bytes (I'm making that up)
[16:47:09] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[16:47:10] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[16:47:10] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[16:47:32] adamw: oh, now it's reporting failure on everything. i don't even know what that thing does.
[16:50:04] shattingduck (shattingduck!~quassel@cable-86-56-16-249.cust.telecolumbus.net) has quit (Remote host closed the connection)
[16:52:50] adamw: meh, i'm going for brunch soon, i'll poke it more later
[18:22:53] rsiebert_ (rsiebert_!~quassel@f052011080.adsl.alicedsl.de) has quit (Read error: Connection reset by peer)
[18:23:58] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has joined #mythtv
[18:33:07] emm386 (emm386!~user@pdpc/supporter/active/emm386) has joined #mythtv
[18:33:22] emm386 (emm386!~user@pdpc/supporter/active/emm386) has left #mythtv ()
[18:35:00] emm386 (emm386!~user@pdpc/supporter/active/emm386) has joined #mythtv
[18:36:11] emm386 (emm386!~user@pdpc/supporter/active/emm386) has quit (Client Quit)
[18:37:16] emm386 (emm386!~user@pdpc/supporter/active/emm386) has joined #mythtv
[18:39:54] emm386: is there a current guide to build mythfrontend on os x? i see there are two branches in the packager on git, osx-fixes and osx-buildbot, but they seem out of date. is fixes/0.27 correct for a mavericks or yosemitie build? no mention of these in the readme.
[18:42:56] arescorpio (arescorpio!~arescorpi@92-202-17-190.fibertel.com.ar) has joined #mythtv
[18:45:20] dekarl: emm386: fixes/0.27 is the stable branch, see e.g. http://www.avenard.org/files/mythtv/mac/
[18:46:47] dekarl: I think they are built with https://github.com/MythTV/packaging/tree/master/OSX/build
[18:48:55] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:50:35] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has joined #mythtv
[18:54:50] emm386: thanks. i'd like to try to make an ipad build of the frontend. i see there is qt for ios available. any idea if this has been attempted and what the ultimate hangup was?
[18:55:08] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:55:42] wagnerrp: you'll have to rewrite the graphics, video, and decoding engines to use iOS specific interfaces
[18:56:49] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has joined #mythtv
[18:58:49] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has quit (Remote host closed the connection)
[19:00:30] rsiebert (rsiebert!~quassel@f052011080.adsl.alicedsl.de) has joined #mythtv
[19:08:15] stuartm: MythTV uses QT, but it is not a pure QT app, we render video and graphics directly through APIs such as OpenGL which are themselves platform independent but not used by all platforms (e.g. the iPad)
[19:09:54] stuartm: and as wagnerrp notes, video decoding is something else that isn't provided by QT, for a mobile device which isn't very powerful you need to use it's built-in hardware decoding and the API for that is usually specific to the platform
[19:13:33] stuartm: beyond that, 'apps' are a far cry from 'applications', they are quite deliberately different in structure and heavily tied to proprietary APIs because Apple et al don't want you to be able to port them from one manufacturers device to another, they want to dissuade you from that by making it as difficult as possible because 'Apps' and not hardware are what sell phones and tablets
[19:19:04] dekarl: emm386: quoting from apple "Important: iPhone and iPad apps that send large amounts of audio or video data over cellular networks are required to use HTTP Live Streaming. See “Requirements for Apps.”"
[19:21:21] emm386: stuartm: yeah, i imagine i'll be foregoeing app store approval / offical apis. my hope is that the underlying opengl support is close enough to os x to make the decoding rewrite something less than impossible.
[19:22:08] emm386: if it works as a PoC that can run with a developer cert maybe others would be interested in joining such an effort. i imagine it has been discussed before by myth devs
[19:24:06] wagnerrp: doesn't a developer cert cost about a grand?
[19:25:36] emm386: nah, it's $99/year
[19:40:12] stuarta_ is now known as stuarta
[19:40:48] tgm4883 (tgm4883!uid23806@ubuntu/member/tgm4883) has quit (Quit: Connection closed for inactivity)
[19:45:48] stuarta: stuartm: i think the occasional failed git's happen when I have too many vm's running on the host
[19:46:11] stuarta: either that or it's the hosting company, but then other builds would fail too
[19:47:42] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Ping timeout: 250 seconds)
[19:54:01] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv
[20:01:46] stuartm: ahh the contradictions of DLNA, it requires that protocolInfo strings be less than 128 bytes for backwards compatibility, but wastes a lot of that by requiring a 32 byte string (bit flags) containing 24 unused fields (zeros)
[20:02:59] stuartm: in testing that 128byte limit isn't hard to hit as a result if you include all the DLNA info e.g. "http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_TS_HD_EU_ISO;DLNA.ORG_FLAGS=0150000 0000000000000000000000000;DLNA.ORG_CI=0;DLNA.ORG_OP=01"
[20:07:35] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Remote host closed the connection)
[20:09:26] stuartm: of course if that were all true it would be a major gaffe by the DLNA group ... but it's not, just went back to re-read the guideline and the limit is actually 256 B, not sure how that because 128 in my mind :/
[20:13:39] ** stuarta tweaks memory allocation to VM's **
[20:14:21] sheedy-away is now known as sheedy
[20:30:53] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv
[20:33:45] paul-h (paul-h!~Paul@94.12.155.185) has quit (Quit: Konversation terminated!)
[20:43:03] enyc (enyc!~enyc@muddle.enyc.org.uk) has joined #mythtv
[20:47:17] jpharvey (jpharvey!~jpharvey@host109-148-236-223.range109-148.btcentralplus.com) has quit (Remote host closed the connection)
[20:49:12] jpharvey (jpharvey!~jpharvey@host109-148-236-223.range109-148.btcentralplus.com) has joined #mythtv
[20:55:46] esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Remote host closed the connection)
[20:58:42] Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446])
[21:12:26] stuarta: jya: so part of the problem with the qt5 builds at the moment is the include paths aren't getting setup right. what should be -I<SRC_ROOT>/external/qjson/include becomes -I/external/qjson/include
[21:12:38] stuarta: haven't managed to unpick why yet
[21:15:00] Steve_Goodey (Steve_Goodey!~steve@host109-155-184-37.range109-155.btcentralplus.com) has quit (Quit: Konversation terminated!)
[21:16:02] stuarta: that is at least the case in libs/libmythbase
[21:19:16] ** stuarta goes to bed **
[21:20:32] sheedy is now known as sheedy-away
[21:47:42] andreaz (andreaz!~andre_000@p579223AB.dip0.t-ipconnect.de) has joined #mythtv
[22:43:54] Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv
[23:00:07] poptix- (poptix-!poptix@poptix.net) has joined #mythtv
[23:00:09] poptix (poptix!poptix@poptix.net) has quit (Read error: Connection reset by peer)
[23:14:39] andreaz (andreaz!~andre_000@p579223AB.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)

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