MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (82):

aloril, analogue, Anssi, anykey_, brfransen, CaCtus491, cesman, Chutt, clever, coling, Cougar, damaltor, danielk22, David_Miller, dblain, dekarl1, dinamic|screen, dlblog, eharris_, ElmerFudd, Eruphus, f33dMB, foobum, foxbuntu, ghoti, GreyFoxx, Guest48629, highzeth, idl0r, J-e-f-f-A, jams, jarle, jcarlos, joe____, joki, jpabq, jstenback, jwh, jwhite, knightr, knightr_, kormoc, kurre2, kwmonroe, laga, mag0o, markcerv, MaverickTech, mrand, MythBuild, MythLogBot, NightMonkey, peitolm, Peps, pheld, pjd_, ponyofdeath, poptix, purserj, rsiebert_, seld, Sharky112065, skd5aner, Slasher`, SmallR2002, sphery, stichnot_, sunkan, sutula, toeb, tomimo, tris, Unhelpful, vallor, Vernon_at_work, wahrhaft, whoDat, xavierh, XDS2010, yb0t, _charly_, _Techie_-_AFK_
Thursday, July 5th, 2012, 00:09 UTC
[00:09:10] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[00:22:56] stichnot (stichnot!chatzilla@nat/intel/x-czzkiwinrrmcssdz) has joined #mythtv
[00:22:56] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[00:22:56] stichnot (stichnot!chatzilla@nat/intel/x-czzkiwinrrmcssdz) has quit (Changing host)
[00:24:09] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 265 seconds)
[00:34:01] Sharky112065: sturatm: further testing was successful :) thanks again
[00:53:10] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[01:08:00] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out)
[02:03:51] gigem: stuartm: GetNextLiveTVDir() definitely needs to grab schedLock when it's traversing recList. It also looks like Captain_Murdoch is using schedLock to protect access to fsInfoCache and possibly more, so it's not as easy a fix as just reducing the locking to just the recList access.
[02:09:50] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[03:09:15] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:31:26] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (Ping timeout: 246 seconds)
[03:37:18] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[04:41:13] Beirdo: yummy coffee
[04:41:43] Beirdo: boom, flash... boom, flash... I guess I should work on tickets, won't be any sleep for a while :)
[04:56:26] brfransen (brfransen!~brfransen@64.179.142.146) has quit ()
[05:02:07] brfransen (brfransen!~brfransen@64.179.142.146) has joined #mythtv
[05:05:59] dekarl (dekarl!~dekarl@p4FCEF751.dip.t-dialin.net) has joined #mythtv
[05:39:53] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has quit (Read error: Operation timed out)
[05:40:57] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has joined #mythtv
[06:03:53] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 245 seconds)
[06:05:41] SteveGoodey (SteveGoodey!~steve@host86-129-35-147.range86-129.btcentralplus.com) has joined #mythtv
[06:06:28] Goga777 (Goga777!~Goga777@2.95.79.158) has joined #mythtv
[06:16:23] Goga777 (Goga777!~Goga777@2.95.79.158) has quit (Ping timeout: 245 seconds)
[06:17:24] toeb: do you take small feature patches against the fixes/0.25 branch? I've made a small change i'd like to get into mythtv but i don't want to run master for testing it...
[06:24:36] SteveGoodey: toeb: Not sure if anyone is about. You could try your request at the dev mailing list mythtv-dev@mythtv.org
[06:32:52] SteveGoodey (SteveGoodey!~steve@host86-129-35-147.range86-129.btcentralplus.com) has quit (Remote host closed the connection)
[06:36:59] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv
[06:36:59] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host)
[06:36:59] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:57:07] Beirdo: yeah, best to ask on the mailing list. We are in major feature freeze at this point for 0.26 release, but bring it up anyways, and we'll see where it falls.
[06:57:33] Beirdo: if it's a bugfix, your chances of getting it soon go up, BTW
[07:12:05] petefunk (petefunk!~pfunk@pud5.7ac0.org) has quit (Ping timeout: 265 seconds)
[07:16:27] toeb: feature freeze for 0.26? already! Feels like 0.25 was released last week...
[07:27:11] Beirdo: well, we're TRYING to have a faster release cycle
[07:27:24] Beirdo: especially faster than the 15+ months for 0.25 :)
[07:31:08] toeb: has their been any anouncement for the feature freeze i missed?
[07:31:21] Beirdo: not yet :)
[07:31:45] toeb: so their actually is no feature freeze then ;-)
[07:32:01] Beirdo: it's been proposed, and as of yet, I haven't seen any objections of note, so we haven't finalized the dates, but we are in feature freeze
[07:32:19] Beirdo: at least for major features
[07:32:37] jya: it's started already?
[07:32:37] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[07:32:48] jya: I only have bug fixes anyway :)
[07:32:52] Beirdo: yes, did you not read the email? :)
[07:33:00] Beirdo: yeah, bug fixes are good :)
[07:33:00] jya: I did… but I can't recall the date
[07:33:21] Beirdo: it was proposed for immediate feature freeze for major features
[07:33:26] jya: did danielk22 merged is IPTV branch?
[07:33:36] Beirdo: don't think so, not sure
[07:35:45] jya: hum…. cause still lots of issues with IP based recording/playback. like can't change channels in liveTV
[07:35:50] Beirdo: ahh, it's so nice to be in a war zone... or so it seems
[07:35:58] Beirdo: fireworks rule.
[07:36:04] jya: ?
[07:36:29] Beirdo: it's July 4 (well, just became the 5th), and I'm in the USA.. you can do the math :)
[07:36:57] jya: of course..
[07:36:58] Beirdo: I expect explosions for at least another couple hours
[07:37:35] Beirdo: yeah, the IPTV stuff is still a bit of an issue, it seems
[07:37:45] Beirdo: not sure if that would be considered a blocker though
[07:38:24] Beirdo: we have not many IPTV users last I heard... it might slip into 0.27 to fix it for the few
[07:38:31] ** Beirdo shrugs **
[07:40:09] jya: this was introduced in 0.25.. I've fixed most of the problem, at least you can now watch it..
[07:40:36] jya: I was hoping with the new HLS recorder that it would open a whole lot set of new features.. Finally being able to watch all those channels out there
[07:40:46] jya: but if you can't use liveTV with those, it sucks big time
[07:41:08] jya: I've already made a list of about 100 HLS channels, most major news channels etc...
[07:41:41] jya: previously IPTV was really limited to those with an ISP providing IPTV… there aren't that many.
[07:41:50] jya: the HLS recorder frees us from this limitation
[07:47:24] Beirdo: yeah, to a certain extent :)
[07:54:18] jya: Beirdo: do you know how you can easily emit a signal in one thread that would be received in another ? I'm yet to find an easy tutorial on how to use Qt signals
[08:00:02] Beirdo: signal/slot is fairly simple
[08:00:40] Beirdo: you use connect() to connect the signal to the slot in the target thread (which needs to do a Qt event loop run or processEvents())
[08:00:50] Beirdo: and then emit the signal
[08:01:18] Beirdo: there's also QEvents (and derived classes) which can get posted too
[08:01:41] Beirdo: pretty sure Qt has a decent page on the signal/slot mechanism
[08:01:54] jya: signal is probably the wrong term… It was more like a notifications, similar for example to what the player uses to capture a keypress etc
[08:02:08] jya: i didn't want to use the slot mechanism...
[08:02:11] Beirdo: I think the keypresses use events
[08:02:18] jya: events.. that's the word
[08:02:29] jya: (i think :) )
[08:02:33] Beirdo: hehe, I hear ya, it's confusing
[08:02:55] Beirdo: look for uses of MythEvent (I think it is)
[08:03:01] jya: yeah… too much pthread… there it's a signal
[08:03:06] Beirdo: which is subclassed off QEvent
[08:03:18] Beirdo: if I recall correctly
[08:04:15] jya: my aim is to have RAOP or AirPlay daemon emit a "signal" whenever a new client arrives…. In which case the previous client will be dropped, and audio port closed
[08:05:16] jya: as RAOP and AirPlay are currently unrelated and work at the same time.. it will fix the issue of when an iPad sends a Video with iOS 5.1, it first opens an RAOP connection, then open a AirVideo one and then close RAOP.
[08:05:33] jya: right now, as the audio port is open by raop, the airplay has no audio
[08:05:43] Beirdo: heheh
[08:05:46] Beirdo: fair enough
[08:06:22] jya: plus the behaviour will be more in line with Apple's guidelines as to whomever ask something, the last one to ask has priority...
[08:06:45] Beirdo: I'm not much on following Apple's rules, personally :)
[08:06:48] Beirdo: heh
[08:06:57] jya: for example, client 1 plays audio , client 2 comes in plays audio… client 1 is supposed to be closed .. audio of client 2 is played. and when client 2 is over, it resumes client 1
[08:06:59] Beirdo: I guess this is a valid exception to that rule though :)
[08:07:31] jya: me I had implemented as: client 1 is playing, client 2 arrives, well.. too bad, it's already in use
[08:09:08] dekarl: jya, any idea yet on how to add guide data to the 100 HLS channels? If 0.26 came with a preloaded list of channels it would be very nice to have guide on them, too
[08:09:50] jya: apple has said it has fixed the VDA interlaced playback issue… At first, they just returned an error … Pretty crappy "fix" … got a new email yesterday that it should now be fixed "properly"
[08:10:25] jya: dekarl: you intend to write the xmltv grabber ?
[08:10:27] dekarl: Beirdo: can you tag #10880 with Dynamic PMT or add it to the title?
[08:10:27] ** MythLogBot http://code.mythtv.org/trac/ticket/10880 **
[08:11:01] jya: pfff… rubbish they fixed it...
[08:11:09] jya: VDADec: Error at privatedecoder_vda.cpp:488 (#-12473, Decoder failed)
[08:11:24] jya: they just exit with an error… how is that a fix to a kernel panic ????
[08:13:42] dekarl: jya, no one said it must be XMLTV, might as well add them to schedules direct as a "Stream URL + Guide" database (or setup a third project). But Nick Morrot has the interface for tv channel <-> guide channel matching prototyped in XMLTV... just need to agree on a procedure to tell the iptv recorder to use that grabber.
[08:13:42] dekarl: or to say it the other way around. The grabber is already written and supporting data for the channels :) But how do you update the channel list itself?
[08:14:18] jya: dekarl: for the channel, it will have to be done like with any other recorder type.
[08:14:32] jya: add a tv grabber and use channel id
[08:15:09] jya: the m3u8 can contain an extra field with the channel id, that would be something unique to myth… it's already handled for the .m3u
[08:15:40] dekarl: hmm, we could host a hls-for-mythtv.m3u at services.mythtv.org and set it up as default url for new iptv recorders and hint that there is a grabber that matches this list
[08:16:03] jya: so right now, the user would have to add the capture card as an IPTV, enter the URL to the m3u file… each containing a list of xmltv id and m3u8 URL...
[08:16:29] dekarl: or the playlist could be part of supplement.xmltv.org
[08:16:30] jya: then you go enter the tv grabber, and map it to the "capture card"
[08:16:55] jya: how the info is going to be implemented, IMHO is beyond the scope of my involvment
[08:17:06] jya: all the bricks are there to do it right now
[08:18:48] dekarl: Ahh, I need to find a student who wants to run a guide service. All the bricks are ready on the guide side, too. (actually its 2 complete sets of bricks by now) I'm short on time, too
[08:19:41] Beirdo: dekarl: #10880?
[08:19:44] jya: my time is seriously limited too… I'm stuck living in a small room at my inlaws for the next 5 months…
[08:20:29] dekarl: Beirdo, aye. the keyword is "transcode does not work with dynamic pmt" from the description. Thats something that is not common in ATSC/SCTE land if I understoof correclty
[08:20:34] jya: and I've started a new business that doesn't leave me much time for myth .. I hope to fix all the outstanding issues assigned to me or that I care about… but can't do much more
[08:21:00] dekarl: I've seen you triaging and that ticket with germany specific stuff passed by
[08:21:19] Beirdo: I haven't got to it yet, but sure
[08:21:57] dekarl: might be a nice hint for gpu-commflag, too (audio streams appearing and going away)
[08:22:59] Beirdo: yeah, that might be tough to do, but it's something to consider :)
[08:23:26] jya: testing for audio blanks certainly sounds like an option...
[08:23:42] Beirdo: jya: wow, big changes. For sure, if I toss a ticket at you that you can't handle in your schedule, feel free to shed them :)
[08:23:54] jya: though I would probably means all the high quality TV series like days of our lives would be flagged as ads every time they change scene
[08:24:01] Beirdo: yeah, I have audio level checks in there
[08:24:11] dekarl: hmm, maybe simple use "the PMT has been updated" as potential cut points, no need to make it super specific for any use case. It might be the video PES being switched out, too. <- for regional news... shared video stream all day, but split out into multiple copies for the regional news
[08:24:29] jya: dinner time...
[08:26:44] Beirdo: the issue is getting that information :)
[08:31:15] dekarl: oh, I see. There is no event "the version number of the PMT has changed, check for actual changes" that you could hook into, yet
[08:31:42] Beirdo: yeah, pretty much :)
[08:33:59] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[08:33:59] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[08:33:59] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[08:35:45] Beirdo: morning, stuartm :)
[08:37:54] stuartm: g'morning
[08:39:22] stuartm: fwiw, I've been trying to figure out what I want to do for 0.26 and how long it might take before commenting on the feature freeze timeline
[08:40:29] Beirdo: I think we should just settle on a date and put in what we have (feature-wise)
[08:40:30] stuartm: but so far nothing I can think of is particularly major, it just depends I guess on how we're classifying 'major'
[08:40:37] Beirdo: bug fixes aside, of course
[08:40:47] Beirdo: but sure
[08:41:57] stuartm: I did want to get mouse support during video playback done to support tablets, especially if 0.27 is going to be a longer cycle (which has yet to be discussed)
[08:43:05] Beirdo: that would be cool
[08:43:42] Beirdo: anyways, I've been trying to triage our massive pile of tickets... if I handed you some that really aren't yours, punt em as needed :)
[08:44:06] Beirdo: we have a few MHEG-related ones that I didn't know where to send that are still unassigned
[08:45:09] ** stuarta wishes he had time to even start mythtv to watch programs **
[08:45:23] Beirdo: hehe, I hear ya
[08:45:30] stuartm: might as well be me who deals with those, no-one else is able to test so ...
[08:45:31] Beirdo: I've had weeks on end like that before
[08:45:48] stuarta: months :-/
[08:45:57] Beirdo: yeah, I figured it would end up being you or the other UK-based Stuart :)
[08:46:34] dekarl: stuartm, would be nice to get #10784 and #10794 in. one is with the other stuart and one with daniel (not sure about MHEG stuff with him)
[08:46:34] ** MythLogBot http://code.mythtv.org/trac/ticket/10784 **
[08:46:34] ** MythLogBot http://code.mythtv.org/trac/ticket/10794 **
[08:46:40] Beirdo: stuarta: any news on the OSX slave?
[08:46:55] stuarta: short version: it's fucked
[08:47:14] Seeker`: jya: as far as I can recall, the code style changes in the RAOP HTTP Digest patch were a result of running astyle with the config file from the mythtv extra repo
[08:47:31] stuarta: longer version: with pulling partial changesets from ffmpeg i can get both to build to the same point where they ICE the compiler
[08:47:45] Beirdo: hehe. aye carumba
[08:48:16] stuarta: now given i've got XCode 4.1 which is the last one that'll run on 32bit OSX, and XCode 4.3 is out, it's kinda QED
[08:48:42] stuarta: by both i mean head and 0.25
[08:49:33] stuarta: i need to junk my server and get a new one, or try and make it virt
[08:49:38] stuarta: which is what i'm trying now
[08:49:55] stuarta: so far it's only given me rude error messages
[08:50:50] Beirdo: yeah, virtualizing OSX ain't easy
[08:52:00] stuarta: i've expecting it to give me lots of grief
[08:53:13] Beirdo: 2am... wonder if the explosions can be considered over yet
[09:05:51] jya: Seeker`: that may well be… but a patch should only touch one thing: here adding a new feature… If he wants to change the style, he's free to submit another patch (which I will likely not accept :) )
[09:07:07] Beirdo: we will have to run another sweep of astyle at some point on the entire set of code...
[09:07:15] Beirdo: but that's never high priority :)
[09:09:41] jya: not sure who wrote the astyle file in the extra repo, but if it produced the RAOP patch, it's more suitable for C than C++
[09:09:55] jya: create a bastardised version of C++ IMHO
[09:11:46] Beirdo: I think it was stuartm, and I don't know how close it gets to our mythtv style
[09:12:37] stuartm: it was as close as it was possible to get
[09:13:03] stuartm: but that said, it matches our coding standards pretty closely
[09:13:29] Beirdo: yeah. A lot of us don't really follow our coding standards terribly closely
[09:13:39] Beirdo: we all have our own little vices :)
[09:14:14] jya: many of our coding "standard" makes no sense to me… especially the naming convention
[09:14:50] stuartm: they don't have to, they just are
[09:15:07] jya: and in that patch, I'm pretty sure he changed spaces for tabs...
[09:16:17] jya: and for C++, I use Stroustrup's declaration
[09:16:22] jya: e.g. (const unsigned char*) vs (const unsigned char *)
[09:16:44] jya: char* is far more clear to me than char *
[09:17:44] jya: again with the RAOP patch, the 2nd line of a wrapping line for function's argument, aren't aligned with the top.. looks ugly
[09:18:09] stuartm: I think we can probably comment that one out of the astyle config, that was more my personal preference and shouldn't have been in the copy I put in extras
[09:19:00] jya: I'm not sure the point of having digest protection either… this isn't supported by Apple's RAOP… which for the time being are the only clients that would ever connect to myth raop server
[09:20:50] Beirdo: well, that's beyond me :)
[09:21:24] stuartm: maybe's he's written his own client, I guess you'd have to ask him
[09:21:38] stuartm: s/maybe's/maybe/
[09:23:00] Beirdo: oh wonderful. Up to 20 tickets in my queue now.
[09:23:17] Beirdo: and I'm done with triage for now. Enough for one day
[09:23:29] stuartm: heh, that's more like the average for me
[09:24:26] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[09:24:29] jya: Beirdo, for AirPlay not suspending the screensaver, this has nothing with AirPlay … it starts a standard player…
[09:38:52] Beirdo: oh? OK, feel free to punt it :)
[09:39:35] Beirdo: I figured you're likely best set to look at what the issue might be. Feel free to disagree :)
[09:44:00] Beirdo: better to have a pair of eyes on it than none at all
[09:48:27] Beirdo: wonder if wagnerrp's having power issues like so many others in that area of the midwest
[09:52:48] ** stuarta suggests solar power **
[09:55:37] Beirdo: heh. Tornado/wind power...
[09:55:55] Beirdo: anyways, I'm gonna head for bed. I think the fireworks are finally mostly over
[09:56:10] Beirdo: 3am. pffft. Lightweights.
[09:59:35] Seeker`: jya: it was me that wrote the patch. i used the astyle to try to make the code fit the coding guidelines, so that it wouldnt be rejected and i wouldnt have to screw with it any more -_-
[10:00:19] Seeker`: and the patch worked with my iphone, so while it might not be explocitly documented it does support it atm
[10:00:20] ** stuarta peers out the window of the office at all the nice planes that have arrived for the airshow **
[10:00:35] Seeker`: stuartm: farnborough?
[10:00:49] stuarta: yes
[10:01:09] Seeker`: wrong stuart :(
[10:01:09] stuarta: http://farnborough.com/trade-aircraft/trade-f . . . lay-aircraft
[10:01:51] stuarta: they've been doing test flights this week, it's been awesome.
[10:02:09] Seeker`: :)
[10:02:27] stuartm: not so much work getting done in those offices this week then? :)
[10:02:35] stuarta: productivity--
[10:02:44] stuarta: we've been like meerkats all week
[10:03:07] stuarta: these military spec planes make a *lot* more noise than the normal planes
[10:03:30] stuarta: so we all go, what's that, ooooo!!!
[10:03:34] stuartm: aye they do, designed for power not noise reduction
[10:03:37] stuarta: omg! planes!
[10:05:19] Seeker`: have been dragged round most of the air museums as a kid, not to any live displays though
[10:05:20] stuartm: that's the reason for the size difference in the external appearance of engines on commercial craft versus say a tornado or harrier, underneath they are the same but the commercial craft have huge blades up front so that they can run the engine at lower speeds (more fuel efficient, less noise)
[10:05:37] ** stuartm was an RAF cadet **
[10:06:23] Seeker`: me too. not for long though.
[10:07:06] stuartm: for a while I did think I'd be joining up, but I'm slightly short-sighted and that would mean no chance of flying fast jets plus I really hated all the parading crap
[10:08:00] stuartm: but I did enjoy getting to play with the aircraft though, doing maintenence on Pegasus engines, playing with the computers and thermal cameras on Jaguars and that sort of thing
[10:15:04] stuartm: and the flying of course
[10:16:45] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has joined #mythtv
[10:25:36] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has quit (Quit: leaving)
[10:27:23] joki (joki!~joki@p54861FEE.dip.t-dialin.net) has quit (Read error: Operation timed out)
[10:28:27] joki (joki!~joki@p548627FA.dip.t-dialin.net) has joined #mythtv
[10:30:04] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[10:31:12] jya: Seeker`: I don't mind a patch adding a new feature. but not a patch that change the code style *and* add a new feature. it makes it very hard to review what actually matters: the feature change… Just like we try to avoid doing a commit making more than one change at once
[10:55:40] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[11:07:14] jya: Looking at MythEvent, I see some classes send the event using qCoreContext->dispatch(MythEvent), and some other via qApp->postEvent(GetMythMainWindow(), MythEvent)...
[11:07:29] jya: is there a reason for the difference, or one way better than another ?
[11:16:29] stuartm: jya: dispatch sends to all objects which have registered as a listener, postEvent() sends to one target only, in that case the main window object
[11:17:20] jya: stuartm: I see thanks… so in my case, I guess I need to use dispatch
[11:17:46] jya: is there an easy way to wait until an event as been received and processed by a particular listener ?
[11:19:01] stuartm: sendEvent() is the only way to do that, it blocks until the receiver has handled the event, but like postEvent() it's a one-to-one system
[11:19:21] stuartm: http://doc.trolltech.com/4.6/qcoreapplication.html#sendEvent
[11:20:15] jya: great.. that doc should get me going...
[11:21:13] stuartm: dispatch is our own wrapper about the QT events, allowing us to post events to any registered receiver, it just maintains a list of receivers and then calls postEvent() on each in turn
[11:21:21] stuartm: s/about/around/
[11:22:20] jya: stuartm: you did make the notification stuff didn't you ?
[11:22:38] jya: my memory is a bit fuzzy these days.
[11:22:43] stuartm: we used to have a dispatchNow() which would wait for the event to be handled by each listener, but it's deprecated because it caused some problems, thread safety and locking up threads etc
[11:23:18] stuartm: no I didn't :/
[11:23:52] jya: ah, I thought you had given me a sample code to use...
[11:24:23] jya: oh well.. must have dreamt it
[11:24:26] stuartm: if I did I've no memory of it, which actually might be possible :)
[11:25:02] jya: i'm fairly convinced you had posted a pastebin code snippet on how it would be done
[11:25:16] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[11:25:39] stuartm: I'll definitely, positively look at this weekend, promise
[11:25:56] stuartm: now I have to go out for a bit
[11:26:24] jya: that's too bad…. i put all the bricks to show nice metadata of files played via iTunes… the XBMC folks took that part of the code, barely mentioned it came from mythtv and have added that feature to xbmc…
[11:29:21] knightr_: Beirdo, MythArchive has it own set of themes and the current set of font size/weigt it uses does look like ..... since it is almost unreadable...
[11:29:46] stuartm: yeah, that happens, it can be a bit demoralising when some other project takes your feature plugs it into their app and then gains new users off the back of your work
[11:30:02] stuartm: but that's open source, it's great and it sucks in equal measure
[11:31:40] stuartm: it makes it difficult for any app to set itself apart with a distinctive new feature if a day later their rivals can copy/paste the code and you're right back to square one
[11:32:00] jya: indeed...
[11:32:04] ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 248 seconds)
[11:38:18] stuartm: we do need to get much better at publicity, when we add stuff like that it should be announced as a news item, so that even if other projects take the code we got the press first and everyone knows where it came from
[11:38:46] stuartm: I've said before that we are losing the PR war
[11:39:05] jya: did we ever fight that "war" ? :)
[11:40:11] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[11:42:32] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[11:54:21] jya: stuartm: does creating a member customEvent(QEvent*) enough to receive the events?
[12:00:39] jya: yep… that works … cool !
[12:19:53] Goga777 (Goga777!~Goga777@2.95.79.158) has joined #mythtv
[12:27:32] XDS2010 (XDS2010!users.1218@id-1218.hampstead.irccloud.com) has quit (Write error: Broken pipe)
[12:28:20] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[12:30:52] XDS2010 (XDS2010!users.1218@id-1218.hampstead.irccloud.com) has joined #mythtv
[13:06:14] stoffel (stoffel!~quassel@pD9E43A4A.dip.t-dialin.net) has joined #mythtv
[13:08:36] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[13:20:01] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:27:21] danielk22: stuartm: gigem: #10702 seems to be a scheduler deadlock. Any chance it's the same one you guys have been looking at?
[13:27:21] ** MythLogBot http://code.mythtv.org/trac/ticket/10702 **
[13:29:10] knightr_: danielk22, I am sure if you got that message from dblain:
[13:29:11] knightr_: <dblain> If there is a problem with QDateTime handling in the services API where we need to override default Qt behavior, the code located at libmythservicecontracts\service.cpp can be changed to handle the time zone when parsing the date/time string. I won't be around for a while so if someone could please forward this to daniel when he's back online it would be appriciated.
[13:31:27] danielk22: knightr_: Thanks. I'll take a look there.
[13:31:55] knightr_: np....
[13:33:55] danielk22: Hmmm, that just confuses me more. The date should have already had a UTC time spec so no changes should be needed elsewhere and QDateTime::toUTC() should have been a no-op.
[13:39:09] danielk22: dblain: Content::GetRecordingArtworkList() seems to be getting a QDateTime containing a UTC data&time but with the timespec set to Qt::LocalTime. But Service::ConvertToParameterPtr() explicitly sets the timespec to Qt:UTC. Is Service::ConvertToParameterPtr() supposed to marshal QDateTime parms for all services?
[13:40:13] danielk22: stuartm: I'm wondering if the diagnosis is wrong. You are testing the services with the Android client? Can you post a URL so I can grab it and test?
[13:41:04] rsiebert_ (rsiebert_!~quassel@g229054069.adsl.alicedsl.de) has joined #mythtv
[13:41:15] danielk22: stuartm: FYI The change you made shouldn't have done anything. If the date already had it's timespec set to UTC, as it should have, then QDateTime::toUTC() would be a no-op.
[13:41:50] rsiebert (rsiebert!~quassel@g229052128.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[13:43:32] stoffel (stoffel!~quassel@pD9E43A4A.dip.t-dialin.net) has quit (Remote host closed the connection)
[13:48:04] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 246 seconds)
[13:53:18] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:53:21] danielk22: Beirdo: For #10548 I have an alternate version of the delete code in the rec2 branch, but didn't commit since you beat me to it. I could dig that up, but have you looked into the issue yet? Is it a design issue or just an implementation issue?
[13:53:21] ** MythLogBot http://code.mythtv.org/trac/ticket/10548 **
[13:55:08] danielk22: If we have a large number of delete threads running at the same time that may be a design issue, but it's also possible we just need to hand back the DB connection after pulling some initial values from the DB.
[14:04:10] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has joined #mythtv
[14:11:01] knightr_: What the best way to log SQLqueries/inserts/updates?I found I have found a setting page which seems to have trouble inserting a value in a field but seems has no problem updating it. It looks like I could easily log the query by adding some logging to SimpleDBStorage (that's what it uses) but is there a way to get the "query" with its binded variables filled in?
[14:17:13] jams: i would suggest turning on mysql logging
[14:26:15] stuartm: danielk22: no it was definitely causing at least half the problem, are we sure the timespec was set for that particular call? Is the timespec global, per instance or thread?
[14:28:17] stuartm: danielk22: I wouldn't swear that your patch is needed since I didn't test with my fix and without that one, but toUTC() only accounts for the times being an hour out and they were two hours adrift so that suggests both were needed
[14:30:32] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has quit (Quit: leaving)
[14:31:07] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has joined #mythtv
[14:31:21] stuartm: danielk22: the two clients I were testing were MediaSee (think that's a manufacturer bundled app only) and more recently I've been playing with BubbleUpnp – https://play.google.com/store/apps/details?id . . . d.bubbleupnp
[14:32:06] stuartm: it was MediaSee I was having issues with but since the urls were being generated by Myth it should have affected any upnp app
[14:32:32] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[14:33:06] Goga777 (Goga777!~Goga777@2.95.79.158) has quit (Quit: Leaving)
[14:36:50] dblain: danielk22: I wasn't part of the UTC changes to the services API so I don't know if there are redundant calls made. The ConvertToParameterPtr method is used to take the raw string parameters in the call to all service methods (query string, SOAP params, form post data, etc...) and convert them to the expected parameter types for the called function. It can be overriden to add new data types
[14:36:50] dblain: but the class mentioned is the base class used by all.
[14:39:42] stuartm: danielk22: are we talking about the same toUTC()? the one I removed was in upnpcdtv.cpp on the recording start-time retrived from the db
[14:40:03] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[14:40:03] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host)
[14:40:03] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:45:06] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[14:45:49] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:48:38] stuartm: danielk22: http://svn.mythtv.org/trac/ticket/10702 was a duplicate of the deadlock I already fixed. Anything that deadlocks on schedLock in Scheduler::Reschedule() would be the same issue, that lock is no longer used in Reschedule()
[14:49:28] pjd_ (pjd_!~phil@93.89.91.89) has joined #mythtv
[14:49:35] stuartm: danielk22: anything setting the timespec in libmythservicecontracts isn't going to affect calls in backend/upnp*.cpp
[14:50:29] danielk22: stuartm: Yeah upnpcdstv.cpp, the problem is with "dtStartTime = query.value( 1).toDateTime();" and the same function for dtEndTime, the rvalue should be wrapped in as_utc(). I'll make the fix.
[14:52:34] danielk22: stuartm: Right, but libmythservicecontracts would affect the things in programs/mythbackend/services/ (at least I'd think so.)
[14:53:12] knightr_: jams, thanks, I'll loioked into it...
[14:54:12] danielk22: stuartm: I'm surprised I missed those calls in upnpcdstv.cpp, I grepped for all toDateTime() calls in the source during the conversion.
[14:55:28] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:55:35] danielk22: grep tells me there are 15 in the source without as_utc...
[14:57:12] stuartm: danielk22: yeah, I believe services/ should be ok ...
[14:58:27] jmusits (jmusits!~jmusits@66-109-48-242.tvc-ip.com) has joined #mythtv
[14:58:57] danielk22: Looking at the history there is really no reason the ones in upnp should have been missed.
[14:59:33] stuartm: the problem here is that the upnp/services/etc stuff is spread around the place, the upnp request urls are generated in backend/upnp/ and libs/libmythupnp/, the urls themselves are against the services API and requests to those are handled in backend/services/ and libs/libmythservicecontracts/
[15:00:48] stuartm: it's bound to start getting a little confusing :)
[15:01:26] stuartm: has the old xml api stuff been removed now? Or do we have to worry about that too?
[15:01:39] stuartm: dblain: ^?
[15:08:54] amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv
[15:11:54] pjd_: Hi folks, the company I work for has been developing a new DVB capture card, we're looking for testers and feedback etc, is it appropriate for me to post this sort of request to the devel mailing list?
[15:22:01] gigem: stuartm: I think we're probably okay with GetNextLiveTVDir() with my change. schedLock is dropped before calling the recorder, so that should let GetNextLiveTVDir() grab it. I'm going to make one minor tweak to my patch and commit it shortly. Do you have a list of the currently open tickets for these deadlocks? I know about #10647, #10770 and #10771.
[15:22:01] ** MythLogBot http://code.mythtv.org/trac/ticket/10647 **
[15:22:01] ** MythLogBot http://code.mythtv.org/trac/ticket/10770 **
[15:22:01] ** MythLogBot http://code.mythtv.org/trac/ticket/10771 **
[15:24:23] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[15:32:07] dblain: stuartm: yes, the old xml api has be removed/replaced by the services API.
[15:36:46] danielk22: pjd_: Sure
[15:36:50] jmusits: 1
[15:36:57] jmusits (jmusits!~jmusits@66-109-48-242.tvc-ip.com) has quit (Quit: leaving)
[15:37:43] pjd_: danielk22: cheers, I've just this moment sent it actually
[15:40:02] dblain: stuartm: Currently the upnp stack is not based on the services framework. It would need a custom serializer to handle the didl-lite that upnp requires as the payload. But it references uri's for the content from the services API so there is an interdependancy, but that is what the services API is for :)
[15:44:17] dblain: As for the seperation of the Service Contracts and the implementation... I just consider that good design and allows for projects to reference the interfaces/data classes without needing to reference an specific implementation.
[15:47:51] knightr_: pjd_, another way to contact MythTV developers (and only MythTV developers) would have been to use http://www.mythtv.org/contact/ ...
[15:50:40] brfransen (brfransen!~brfransen@64.179.142.146) has quit ()
[15:58:33] pjd_: knightr_: oh, ok thanks
[15:59:16] jmusits (jmusits!~jmusits@66-109-48-242.tvc-ip.com) has joined #mythtv
[16:04:39] knightr_: pjd_, we don't have many devs which could possibly test this kind of equipement though (a lot of us are in NA) so the number of requests you get should be relatively low (if it's not you might want to check if they are really MythTV devs... :) :)
[16:05:44] pjd_: knightr_: ok, cheers, I had already anticipated a bit of background checking :)
[16:06:57] knightr_: that's why I mentionned the URL (for the next time maybe :) ), only MythTV devs actually get mails sent there...
[16:22:56] Captain_Murdoch: stuartm, I wouldn't be bothered if Scheduler::GetNextLiveTVDir() went away and we just fell back to using the dir with the most free space. The dynamics are a bit different now than when I wrote that code originally, so we could easily just say LiveTV always goes to the dir with the most free space. The other use of FillRecordingDir() is in the main schedule code, so that already has the schedLock lock.
[16:23:38] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[16:24:54] brfransen (brfransen!~brfransen@64.179.142.146) has joined #mythtv
[16:25:34] Captain_Murdoch: gigem, wasn't using schedLock to protect fsInfoCache explicitly, but since FillRecordingDir() was only called with schedLock locked, then that implicitly protected them. If we get rid of GetNextLiveTVDir and just use max free space for the next LiveTV program then the only user of FillRecordingDir will be the Scheduler::HandleRecording() which already has schedLock locked when it is called.
[16:26:43] cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has joined #mythtv
[16:27:17] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[16:30:28] Defense|Twin (Defense|Twin!~jepz@e177226188.adsl.alicedsl.de) has joined #mythtv
[16:34:59] stuartm: would the simpler logic speed up channels changes a few ms? It seems we spend enough time in GetN...TVDir() to trigger that deadlock on a semi-regular basis which seems to suggest that it has at least some impact on speed
[16:39:00] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving)
[16:40:45] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[16:41:27] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[16:42:07] stuartm: Beirdo: I don't know if there are other instances, but to be valid html we should ensure all html includes both a doctype and a language descriptor
[16:47:03] stuartm: does Steven not realise that he's now talking to himself?
[17:01:18] stichnot (stichnot!~chatzilla@192.55.55.39) has joined #mythtv
[17:01:18] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[17:01:18] stichnot (stichnot!~chatzilla@192.55.55.39) has quit (Changing host)
[17:02:45] ponyofdeath (ponyofdeath!~vladi@cpe-75-80-169-76.san.res.rr.com) has joined #mythtv
[17:03:33] ponyofdeath: hi, trying to get .25 working but cannot seem to get it to tune to a channel. here are hte logs from mythbackend. http://bpaste.net/show/33575/
[17:13:41] stuartm: MainServer::HandleVersion – Client speaks protocol version 8 but we speak 72! Heh – what client are you using?
[17:14:15] stuartm: Not mythfrontend I'd guess
[17:14:42] Captain_Murdoch: stuartm, probably would speed up channel changes since we wouldn't have to go back to the MBE to decide where to put the file. the decision would be a local one based on free space.
[17:16:07] stuartm: Captain_Murdoch: sounds like a win-win solution then, simplifies the code, speeds up channel changes and removes one possible source of deadlocks
[17:16:27] stuartm: or win-win-win I guess ;)
[17:17:24] stuartm: ponyofdeath: whatever client you are using, it apparently doesn't support MythTV 0.25, I don't even think it would support MythTV 0.1 based on that protocol version
[17:18:23] ponyofdeath: stuartm: xbmc git
[17:18:52] ponyofdeath: stuartm: it worked with .24 upgraded to .25 and seems like only xbmc git even connects to it
[17:19:52] stuartm: ok, you need to take that up with the xbmc guys then – #xbmc – it's not a mythtv issue, the official MythTV frontend should work
[17:20:16] ponyofdeath: so why the error cannot tune to channel 11
[17:20:54] stuartm: ponyofdeath: because it's not compatible, if it's not compatible it's sending all the wrong commands to the backend
[17:21:39] stuartm: if you can reproduce the problem with mythfrontend then we'll look into it, but we don't support xbmc
[17:21:46] stuartm: fwiw #mythtv-users is the support channel
[17:25:55] stuartm: of course even if it said it supported the correct protocol version, that doesn't mean it actually does, which unfortunately it true of too many third party clients which is why we require bugs to be demonstrated with the official frontend
[17:27:46] Captain_Murdoch: stuartm, http://pastebin.ca/2167428 should do the trick on the recording side if you want to test something. untested here, but compiles fine.
[17:32:47] ponyofdeath: stuartm: ok thanks!
[17:33:24] stichnot (stichnot!~chatzilla@192.55.55.39) has joined #mythtv
[17:33:24] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[17:33:24] stichnot (stichnot!~chatzilla@192.55.55.39) has quit (Changing host)
[18:07:47] Goga777 (Goga777!~Goga777@2.95.188.8) has joined #mythtv
[18:26:24] danielk22: heh, protocol version 8!
[18:35:54] sphery: that's the "throw out the minimum version this lib supports, then increment until the backend accepts" mythtv protocol library doing that--i.e. the reason we added the tokens
[18:37:27] Goga777 (Goga777!~Goga777@2.95.188.8) has quit (Read error: Operation timed out)
[18:37:31] sphery: (or really, that one parses the error message to get the supported version, then just tries again with that version)
[18:51:52] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[18:52:33] andreax (andreax!~andreaz@p54BF2746.dip.t-dialin.net) has joined #mythtv
[19:09:14] jmusits (jmusits!~jmusits@66-109-48-242.tvc-ip.com) has quit (Quit: leaving)
[19:16:27] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[19:26:58] amejia (amejia!~andres@xbmc/staff/amejia) has quit (Quit: Konversation terminated!)
[19:33:27] cecil is now known as cesman
[19:33:38] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[19:33:38] cesman (cesman!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has quit (Changing host)
[19:47:35] stuartm: the sooner we get third party clients transitioned to the services API instead the better
[19:50:01] danielk22: stuartm: I'm not sure it will solve much unless we're planning to support multiple versions of the services API at the same time..
[19:50:27] amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv
[19:52:58] stuartm: danielk22: services API is supposedly static or at least backwards compatible, that was IIRC one of the original design goals
[19:54:24] danielk22: stuartm: dblain can correct me, but I don't see how it is by nature any more backwards compatible. To me it looks like backward compatibility is more difficult to achieve with it.
[19:54:34] stuartm: due to the way it's implemented you can extend it, add new commands and return additional data without breaking older apps
[19:55:51] stuartm: well that's the nature of xml/json at least ... I'm extrapolating
[19:56:18] danielk22: But if you fix a bug in some API call you've broken backwards compatibility. There is no easy way I can see to export multiple versions of a call at the moment at least.
[19:57:08] Beirdo: stuartm: thanks for the confirmation :) I guess that user will need to do the bisect to find out what we didn't change...
[19:57:09] dblain: danielk22, stuartm: my personal goal was to create a fairly stable, standards based interface to MythTV functionality that is extensible. Backwards compatibility will ultimately be up to the developer making changes to the implementation, but I would hope it would be attempted whenever possible.
[19:57:28] danielk22: The only advantage I see is that each service is versioned. So if you change a service a client doesn't use then they don't need updating.
[19:58:30] dblain: danielk22: like any other bug, it depends on what is changed. If a new parameter is added or the meaning an existing one is changed, than I can see it potentially breaking a client, but these risks can be mitigated.
[19:59:40] Goga777 (Goga777!~Goga777@2.95.188.8) has joined #mythtv
[20:00:30] dblain: The other aspect of the Service API (once all features are implemented), is it should eliminate the need to have a client connect to our database directly... to me that is a big plus in the stability column.
[20:00:32] stuartm: danielk22: currently you can't remove a value from a response and add a new one without breaking a client, if the client expects value 12 to be the title and it becomes the recording group instead that's bad – with the services API I'm assuming that all values are labelled so that wouldn't happen, you could add/remove and change the order of things and it won't break a well written client
[20:00:36] Beirdo: the best way to mitigate such risks would be to document the API, and get the various developers to confirm that they are good with the current parameters, etc.
[20:00:43] danielk22: dblain: for example.. DTV::GetConflictList() currently returns a local date in AsOf, this was always intended to be a UTC date... How does one fix this?
[20:01:05] Beirdo: otherwise, we run into the "ooops, but we need.... " situations
[20:01:21] stuartm: but I'm making assumptions here, I've not read the code or looked at the output
[20:01:43] Beirdo: if we effectively are locking down the API, it needs wide review first. just my opinion, of course :)
[20:02:10] Beirdo: we certainly don't wanna be like ffmpeg, changing it on a whim over and over
[20:02:27] dblain: danielk22: definitely a bug that will impact some clients, but it won't break them completely and more importantly it won't cause invalid calls / damage to our data.
[20:02:57] danielk22: stuartm: I think that's at least true with the current marshalling.. XML and json.
[20:03:32] danielk22: dblain: true
[20:04:51] Goga777 (Goga777!~Goga777@2.95.188.8) has quit (Quit: Leaving)
[20:09:56] dblain: Beirdo: have you seen the WSDL html pages generated by the backend? I wanted to pull descriptions from the code / metadata to have auto documentation but wasn't sure the best approach to get access to it. Also, I wasn't sure if this is better / worse than the doxygen documents and didn't want to duplicate efforts.
[20:10:27] Beirdo: not yet, but I could take a look at them later on
[20:10:29] stuartm: Beirdo: happy coincidence that the user's setup and hardware was identical in some respects to my own
[20:11:07] Beirdo: so far, I've been happy that we have a working API (thank you muchly) and have ignored the maintenence aspects :)
[20:12:16] Beirdo: if we could get the documentation to also build for doxygen maybe, that could be cool, but dunno. That would have to take some thinking for sure
[20:12:21] dblain: I just built the framework... many other did the heavy lifting to make it useful :)
[20:12:25] stuartm: actually, in one respect I can reproduce the issue, but with apps other that mythfrontend – if I fullscreen an application on the smaller monitor the top disappears offscreen
[20:12:53] stuartm: so that would be my hunch, it's an X/window manager limitation
[20:13:02] dblain: Beirdo: Not sure how we'd be able to do that since the WSDL html pages are generated at runtime with a xslt template.
[20:13:16] Beirdo: hmmm.
[20:13:21] Beirdo: good point :)
[20:13:32] stuartm: Beirdo: the issue would disappear if we got that bit of mythgallery converted to mythui
[20:13:34] dblain: I'm fine with using doxygen. it's our standard.
[20:14:05] Beirdo: I guess we could make an app that could run and create a documentation .cpp file from the xslt?
[20:14:33] Beirdo: be kinda messy, but that's the best my brain comes up with on short notice
[20:14:34] Beirdo: heh
[20:14:54] dblain: Not worth it. The WSDL xslt template was an extra I did to make the display of the WSDL xml look somewhat nice in a browser.
[20:15:58] Beirdo: yeah. The only problem is... for 3rd-party app developers, they basically need to start up the backend to get API documentation rather than having (say) a PDF output to read
[20:16:19] Beirdo: something to think about, I guess
[20:16:26] dblain: exactly. hence my "Not worth it" comment :)
[20:18:51] Beirdo: haha, helps to hit BUILD before RUN
[20:18:57] ** Beirdo slaps eclipse **
[20:19:58] danielk22: We could just create a mirror of these everytime we do a doxygen build..
[20:20:42] Beirdo: yeah, if there was a way to extract for the doxygen build programatically, I'd be all for it
[20:21:06] Beirdo: as long as it isn't wasted effort, of course
[20:40:06] andreax1 (andreax1!~andreaz@p5089E3D0.dip.t-dialin.net) has joined #mythtv
[20:42:24] andreax (andreax!~andreaz@p54BF2746.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[20:44:44] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[20:56:32] cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has quit (Ping timeout: 252 seconds)
[21:06:26] Defense|Twin (Defense|Twin!~jepz@e177226188.adsl.alicedsl.de) has quit (Remote host closed the connection)
[21:33:21] stichnot_ (stichnot_!chatzilla@nat/intel/x-kquphsfnllkxgmjp) has joined #mythtv
[21:33:21] stichnot_ (stichnot_!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[21:33:21] stichnot_ (stichnot_!chatzilla@nat/intel/x-kquphsfnllkxgmjp) has quit (Changing host)
[22:01:59] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Remote host closed the connection)
[22:09:15] Lomion0815 (Lomion0815!~markus@178-191-186-207.adsl.highway.telekom.at) has quit (Remote host closed the connection)
[22:13:24] andreax1 (andreax1!~andreaz@p5089E3D0.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[22:19:28] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[22:21:14] dekarl1 (dekarl1!~dekarl@p4FCEF8DB.dip.t-dialin.net) has joined #mythtv
[22:22:41] dekarl (dekarl!~dekarl@p4FCEF751.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[22:22:43] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has quit (Read error: Connection reset by peer)
[22:24:21] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has joined #mythtv
[22:24:48] amejia (amejia!~andres@xbmc/staff/amejia) has quit (Quit: Konversation terminated!)
[22:53:39] Mousey (Mousey!~r0dent_@ross154.net) has quit (Remote host closed the connection)
[23:29:18] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 245 seconds)
[23:29:20] zombor_ (zombor_!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[23:29:20] zombor_ (zombor_!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host)
[23:29:21] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:30:19] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:33:50] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 252 seconds)
[23:40:31] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:41:35] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer)
[23:41:47] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:43:33] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: No route to host)
[23:45:49] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 265 seconds)
[23:48:36] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[23:52:20] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 248 seconds)

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