MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (89):

Anduin, Anssi, anykey_, beata, Beirdo, brfransen, brtb, cattelan, cesman, clever, coling, Cougar, damaltor, danielk22, davide_, dblain, dekarl, dlblog, eharris, ElmerFudd, foobum, foxbuntu, ghoti, gregL, GreyFoxx, highzeth, iamlindoro, IMSanchMac, J-e-f-f-A, jafa2, jams, jarle, jcarlos, JoeJulian, joe____, joki, jpabq, jpabq-, jstenback, justinh, jwhite, jya, knightr, kurre2, kwmonroe, laga, mag0o, markk, MaverickTech, mike|2, mirage335, mrand, MythBuild, MythLogBot, mzanetti, netw1z, Peitolm, pheld, poptix, purserj, rhpot1991, rsiebert__, rsiebert___, sailerboy, Seeker`, skd5aner, Slasher`, sphery, sraue, stichnot, stuarta, stuartm, superm1, sutula, taylorr, TazzNZ, tgm4883, ThisNewGuy1, tomimo, tris, Unhelpful, vallor, wagnerrp, wahrhaft_, xris, ybot_, zCougar, zombor, _charly_
Sunday, January 29th, 2012, 00:38 UTC
[00:38:49] dekarl-too (dekarl-too!~dekarl@p5DE5632A.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[01:04:32] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[01:15:02] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:28:18] gast (gast!bcc294ec@gateway/web/freenode/ip.188.194.148.236) has left #mythtv ()
[01:36:43] Guest74019 (Guest74019!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Ping timeout: 252 seconds)
[01:46:23] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[01:48:13] Beirdo: stuartm: you have time to retest #10221?
[01:53:06] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[02:06:10] davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection)
[02:06:34] davide (davide!~david@host70.16.intrusion.com) has joined #mythtv
[02:22:37] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out)
[02:37:49] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 240 seconds)
[02:37:53] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has quit (Ping timeout: 252 seconds)
[02:38:15] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has joined #mythtv
[02:42:10] foxbuntu (foxbuntu!~foxbuntu@67-3-88-14.desm.qwest.net) has joined #mythtv
[02:42:20] foxbuntu (foxbuntu!~foxbuntu@67-3-88-14.desm.qwest.net) has quit (Changing host)
[02:42:20] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv
[03:02:11] poptix (poptix!poptix@poptix.net) has quit (Ping timeout: 260 seconds)
[03:02:34] poptix (poptix!poptix@poptix.net) has joined #mythtv
[03:02:50] highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 248 seconds)
[03:05:26] highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv
[03:22:55] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[03:26:06] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:30:28] Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Remote host closed the connection)
[04:13:34] PointyPumper (PointyPumper!~pintlezz@190.244.65.185) has joined #mythtv
[04:46:44] jafa2 (jafa2!~jafa@c-98-234-217-27.hsd1.ca.comcast.net) has quit (Ping timeout: 255 seconds)
[04:48:06] jafa2 (jafa2!~jafa@c-98-234-217-27.hsd1.ca.comcast.net) has joined #mythtv
[04:51:03] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[04:52:53] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:58:46] fluvvell (fluvvell!~barryc@port166-72.ubs.maxnet.net.nz) has quit (Remote host closed the connection)
[05:05:54] PointyPumper (PointyPumper!~pintlezz@190.244.65.185) has quit ()
[05:52:46] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[05:55:15] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[06:37:41] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[08:14:29] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has joined #mythtv
[08:44:42] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[09:16:02] EagleIJoe (EagleIJoe!~rockhound@d033020.adsl.hansenet.de) has joined #mythtv
[10:25:20] rsiebert_ (rsiebert_!~quassel@g231187086.adsl.alicedsl.de) has quit (Remote host closed the connection)
[10:27:48] rsiebert_ (rsiebert_!~quassel@g231187086.adsl.alicedsl.de) has joined #mythtv
[10:56:38] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Operation timed out)
[11:05:54] mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv
[11:14:18] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[11:35:56] EagleIJoe (EagleIJoe!~rockhound@d033020.adsl.hansenet.de) has quit (Quit: EagleIJoe)
[11:37:49] ocrateb (ocrateb!~ocrateb@s83-177-186-55.cust.tele2.se) has joined #mythtv
[11:42:06] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:48:28] ocrateb (ocrateb!~ocrateb@s83-177-186-55.cust.tele2.se) has quit (Quit: Leaving)
[12:15:37] EagleIJoe (EagleIJoe!~rockhound@d033020.adsl.hansenet.de) has joined #mythtv
[12:19:59] stuartm: Beirdo: absolutely
[12:21:57] Seeker`: stuartm: thats some bad lag :P
[12:22:28] ** stuartm wasn't around until now :) **
[12:23:01] ** Seeker` was joking :) **
[12:25:59] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 244 seconds)
[13:05:12] davide_ (davide_!~david@host70.16.intrusion.com) has joined #mythtv
[13:05:12] davide_ (davide_!~david@host70.16.intrusion.com) has quit (Changing host)
[13:05:13] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[13:05:55] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has quit (Ping timeout: 260 seconds)
[13:06:48] davide (davide!~david@host70.16.intrusion.com) has quit (Ping timeout: 252 seconds)
[13:16:44] GreyFoxx (GreyFoxx!~greg@2607:ae00:fff9::1) has quit (Ping timeout: 276 seconds)
[13:57:34] stuartm: there was something I said I'd look into relating to statetypes in buttonlists, but I can't remember what it was and I didn't write it down, can anyone remember what the issue was?
[13:58:35] stuartm: at least I think it was statetypes it definitely related to buttonlists in some way
[14:00:50] dekarl-too (dekarl-too!~dekarl@p4FC721D9.dip.t-dialin.net) has joined #mythtv
[14:04:17] dekarl-too: stuartm: do you prefer a new ticket with a patch to enhance channels.conf importing or unlocking #7701? (asking you as you locked it) sadly I could not successfully test it yet, seems like something is borked independently of the onid/tid/sistandard issue :(
[14:06:57] stuartm: dekarl-too: I've unlocked it
[14:08:04] stuartm: I'm still not keen on the whole channels.conf import but sadly no-one is working to fix our scanner bugs any more :(
[14:11:59] stuartm: dekarl-too: str == "T" doesn't account for T2?
[14:12:32] dekarl-too: is there a T2? I thought its just C, T and S<xx.xE/W>
[14:13:10] dekarl-too: at least according to the format description at linuxtv and samples scans on vdr wiki
[14:14:45] stuartm: ah, yeah, I jumped to conclusions when I saw the str[0] == 'S' check
[14:15:00] stuartm: sorry :)
[14:18:31] dekarl-too: it appears to be bailing out somewhere in the PARSE_XXX macros very early in my tests though. according to google its been doing that for others, too. (I tried to debug but had to stop before I got gdb working right on mythbuntu with patched sources :(
[14:21:46] Goga777 (Goga777!~Goga777@128-71-150-153.broadband.corbina.ru) has joined #mythtv
[14:37:26] EagleIJoe (EagleIJoe!~rockhound@d033020.adsl.hansenet.de) has quit (Quit: EagleIJoe)
[14:50:22] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has joined #mythtv
[14:55:50] Seeker`: wrt to scanning, are there any sources that require an accuracy of > 1000 khz?
[14:57:00] dekarl-too: yes, all of them. I don't think there are any cards that will find the center frequency from a 1MHz offset
[14:57:04] Seeker`: sorry, < 1000 khz
[14:57:49] dekarl-too: just read the but reports, some cards can't handle 60kHz offsets and really depend on the channel scanner trying all offset frequencies manualy
[14:57:55] dekarl-too: s/but/bug/
[14:58:05] Seeker`: I was asking because a lot of sites give info about DVB-S frequencies as, e.g. 10847 MHz
[14:59:17] dekarl-too: The bug reports are mostly related to DVB-T and the scanner storing the intended frequency instead of the actual tuned to one
[15:01:22] dekarl-too: all these corner cases (like some countries using positve and negative offset) lead me to consider using an external scanner for the time being and importing the scan as a viable workaround (it being unrealistic to fix the DVB scanner bugs in time for 0.25)
[15:07:47] dekarl-too: e.g. http://code.mythtv.org/trac/ticket/9777#comment:6
[15:11:01] gast (gast!bcc294ec@gateway/web/freenode/ip.188.194.148.236) has joined #mythtv
[15:12:11] GreyFoxx (GreyFoxx!~greg@2607:ae00:fff9::1) has joined #mythtv
[15:13:03] allesmueller (allesmueller!~allesmuel@46.206.195.229) has joined #mythtv
[15:13:03] allesmueller (allesmueller!~allesmuel@unixboard/users/allesmueller) has joined #mythtv
[15:13:03] allesmueller (allesmueller!~allesmuel@46.206.195.229) has quit (Changing host)
[15:17:20] rsiebert__ (rsiebert__!~quassel@g231186039.adsl.alicedsl.de) has joined #mythtv
[15:17:28] rsiebert___ (rsiebert___!~quassel@g231186039.adsl.alicedsl.de) has joined #mythtv
[15:20:52] rsiebert_ (rsiebert_!~quassel@g231187086.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds)
[15:20:52] rsiebert (rsiebert!~quassel@g231187086.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds)
[15:51:38] stuartm: fwiw, if someone was really interested in working on it then it should be possible to fix some of the scanning bugs, the feature freeze might be in two weeks but the release isn't for another two months
[16:01:21] gast (gast!bcc294ec@gateway/web/freenode/ip.188.194.148.236) has quit ()
[16:03:33] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 248 seconds)
[16:03:56] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[16:06:13] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[17:57:41] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has quit (Ping timeout: 244 seconds)
[18:01:02] dekarl-too (dekarl-too!~dekarl@p4FC721D9.dip.t-dialin.net) has quit (Quit: Get out of that boring IRC client! It's no good for you. Bersirc 2.2 is your answer! [ http://www.bersirc.org/ - Open Source IRC ])
[18:05:51] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[18:06:15] davide_ (davide_!~david@host70.16.intrusion.com) has joined #mythtv
[18:06:15] davide_ (davide_!~david@host70.16.intrusion.com) has quit (Changing host)
[18:06:16] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[18:17:22] bobobobob (bobobobob!4830d958@gateway/web/freenode/ip.72.48.217.88) has joined #mythtv
[18:28:34] bobobobob (bobobobob!4830d958@gateway/web/freenode/ip.72.48.217.88) has left #mythtv ()
[18:28:38] joki (joki!~joki@p54865768.dip.t-dialin.net) has quit (Ping timeout: 240 seconds)
[18:29:14] joki (joki!~joki@p54864CC5.dip.t-dialin.net) has joined #mythtv
[18:31:31] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[18:34:05] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has joined #mythtv
[18:38:38] Captain_Murdoch: stuartm, thanks for the MDM changes. sorry it's been such a hassle for you and sorry I didn't respond sooner, I was laid up in bed yesterday with the flu.
[18:39:09] Captain_Murdoch: and the animated image loading changes. :) look nice a nice improvement.
[18:43:34] pri0n (pri0n!~aturpin@107.58.106.161) has joined #mythtv
[18:43:50] pri0n (pri0n!~aturpin@107.58.106.161) has left #mythtv ("Ex-Chat")
[18:52:53] stuartm: it was only a hassle because of the 0.25 deadline :) One or two of the changes are a little hacky, I wouldn't mind finding a way to do them better but I figure they are safe to revisit during the feature freeze
[18:53:41] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Read error: Operation timed out)
[18:55:02] stuartm: Captain_Murdoch: I hope you're feeling better btw :)
[18:59:48] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[19:02:12] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[19:05:38] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[19:14:13] stuarta: stuartm: scanning bugs shouldn't be too difficult to nail
[19:14:44] ** stuarta looks at the diary and tries to find time between starting new job and painting to even switch on pc **
[19:14:56] danielk22: wagnerrp: stuartm: We're down to just 8 cppcheck warnings. 4 of them have to do with m_weight in FileSystemInfo. I'm not sure what this is used for, but it isn't initialized in the ctor, it isn't set on assignment and it isn't serialized in networking comms.
[19:15:15] stuarta: sounds like "nothing" to me
[19:15:29] danielk22: wagnerrp: stuartm: You guys seem to be the only ones in the blamelist..
[19:17:08] wagnerrp: danielk22: i believe that is something that gets used later by the storage scheduler
[19:17:25] wagnerrp: ill take a look at it later today
[19:18:09] danielk22: jpabq: 'H264Parser::au_contains_keyframe_message' is something else I didn't want to quiet since I don't know the correct behavior there.
[19:18:43] danielk22: wagnerrp: Thx
[19:18:43] wagnerrp: Captain_Murdoch: im about to push a new protocol query to request a list of all currently-connected backends
[19:19:04] wagnerrp: all it does is scan the PBSlist for unique hostnames that are listed as backends
[19:19:09] wagnerrp: if youve got any input on that
[19:20:11] wagnerrp: iamlindoro: sphery said he talked to you, and might be interested in reworking the Videos storage groups to have more consistent behavior with the others
[19:20:30] wagnerrp: (i.e. all defined on the master, rather than each slave with its own definition)
[19:20:34] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[19:21:15] wagnerrp: if there were the ability to enumerate available backends, rather than having to try to connect to each individually and wait for a timeout
[19:21:24] stuarta: i've also now got myself a dvb-s2 card
[19:23:05] stuarta: danielk22: why don't we just rewrite the vbi code that cppcheck hates?
[19:23:17] stuarta: everytime i read it i hate it too
[19:23:23] stuarta: it just reads wrong
[19:24:09] stuartm: danielk22: hmm, I think I'm in the blamelist because I moved it from libmyth to libmythbase, I don't remember having any other reason to touch it
[19:24:54] danielk22: stuarta: I wouldn't mind if someone did that, but the code works.. there is a lot of code that doesn't work that would get my attention first..
[19:26:22] danielk22: stuartm: ok.. wagnerrp is going to look at it.. Captain_Murdoch may need to ultimately look at it, I just looked at the blamelist and figure someone on it would know who to pass the buck too ;)
[19:27:41] wagnerrp: danielk22: i dont believe i added any additional members besides what the struct it replaced had
[19:28:10] wagnerrp: i just moved the serialization and summation methods into it
[19:28:25] danielk22: BTW Where do I check in suppressions? #10 is just an idiom cppcheck doesn't recognize.
[19:28:59] danielk22: wagnerrp: If you can point me to the original struct & functions I can check the blamelist on those to find out where m_weight came from...
[19:29:48] wagnerrp: dont worry about it, im just trying to get an SBE booted up so i can test the aforementioned commit
[19:29:52] wagnerrp: and then ill get to that
[19:29:59] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[19:30:44] stuartm: danielk22: it's in the 'extras' repo – https://github.com/MythTV/extras
[19:30:58] stuartm: danielk22: https://github.com/MythTV/extras/blob/master/ . . . ressions.txt
[19:42:03] wagnerrp: danielk22: perhaps a bit longer... cycling images around to a new copy to boot my SBE off of, i seem to have deadlocked something on my fileserver
[19:42:19] wagnerrp: brb... (irc client is running on the file server too)
[19:42:28] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Quit: Leaving)
[19:42:56] jpabq: danielk22, Do I just run cppcheck on H264Parser to see the report? I will take a look.
[19:43:48] jpabq: stuartm, statetypes (such as watched) do no work in trees. Maybe that is what your were thinking of?
[19:43:48] stuartm: danielk22: did you find what you wanted wrt to running cppcheck locally?
[19:43:59] stuartm: jpabq: bah, right, trees not buttonlists
[19:44:20] stuartm: jpabq: thanks, I'm making a note and I will start on a fix tomorrow
[19:46:20] stuartm: btw, if anyone wants to remind me of some of the things I've promised to do but haven't, now is the time
[19:48:26] danielk22: stuartm: yeah, looks like it's all in that extras repo..
[19:48:40] jpabq: Did you ever figure out why state updates in PBB don't happen when you are done watching a show? Shows that were recording when you started watching something, still say they are recording when you stop watching it, even if they have actually finished recording.
[19:48:43] stuartm: yep
[19:51:08] stuartm: jpabq: I know roughly which commit broke it, I can work from there, I do actually have that written down but rather cryptically as 'de-duplicate pbb' since at least part of the problem is that we're setting the same flags in at least two different places
[19:53:13] danielk22: There was a commit that blocked PBB ProgramInfo updates while a video was playing. That broke things, but ideally we can fix without reintroducing the issue that was addressing (short pauses during video playback on some systems.)
[19:54:40] stuartm: danielk22: yeah, that commit blocked re-loading of the list, it didn't block the actual update events that I recall, but it's connected somehow
[19:55:01] jpabq: Don't really need PBB updates while a video is playing, but probably need one, when the playback has stopped.
[19:56:54] stuartm: it allowed the cached PI objects to be updated, but prevented full list reloads (which shouldn't be required anyway), I think that's where the flags being set in two different places bit comes in – when we perform an updated without reload we're not setting all the statetypes that would be set when a list reload occurs
[19:57:14] stuartm: s/an updated/an update/
[19:58:01] stuartm: I've written an expanded note on that, it's currently issue #2 on this new list :)
[19:58:12] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Read error: Operation timed out)
[19:59:51] wagnerrp (wagnerrp!~wagnerrp_@2001:470:1f11:12f::a27) has joined #mythtv
[19:59:51] wagnerrp (wagnerrp!~wagnerrp_@2001:470:1f11:12f::a27) has quit (Changing host)
[19:59:52] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[20:00:02] jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 252 seconds)
[20:03:44] danielk22: We were processing the updates while the video was playing to avoid needing to do a full reload after the video finished playing. I think maybe we blocked the updates, forgot to reintroduce the full reload..
[20:04:42] danielk22: stuartm: maybe what we need is a "partial full reload" i.e. only process the events so far as noting the PI that needs updating, and then update all the changed PI's once the video finishes playing.
[20:12:37] stuartm: danielk22: so far as I'm aware we are still updating the PIs and we should be updating the UI too, the disruptive bit was doing a full list update which was only supposed to happen if the recording group of a recording changed
[20:13:28] stuartm: even then, it's not necessary to reload the entire list because a recording has been added or removed, we can insert/remove any item in the UI list without rebuilding it
[20:13:59] stuartm: I'll figure out what's happening, I can reproduce so it's not going to take long
[20:19:15] stuartm: danielk22: can I take it from that last commit that we're embracing c++ style casting? In the past changes to use C++ casting have been unpopular and so I tended to avoid changing existing instances
[20:19:43] danielk22: stuartm: The entire list wasn't being reloaded to add or remove a recording.. but honestly I haven't looked at the commit, I just recall it breaking updates.. These days I just exit and reenter the Watch Recordings screen to force a full update after video playback.
[20:21:48] danielk22: stuartm: Well casts should be avoided whenever necessary. But C++ style casts do have advantages over C style casts; in that at least they are easier to find via grep.. Which is important since casts are often the cause of bugs..
[20:22:01] danielk22: s/necessary/possible/
[20:22:36] stuartm: HandleProgramInfoUpdateEvent calls ScheduleUpdateUIList() which schedules a full list reload, as does HandleRecordingAddEvent() – we're supposed postpone these reloads until after playback has finished, as far as I can tell this bit works because new recordings are displayed after exiting playback but state updates are not
[20:25:50] danielk22: stuartm: List updates are not happening here after video playback... I don't if it's just a drawing thing or if the PI's are really out of date. Most noticeable is anything that was recording when we entered playback will still show as recording after video playback even if it stopped recording an hour back.
[20:26:57] danielk22: But that's what you said state updates are what appears to be missing.
[20:29:19] iamlindoro: wagnerrp: yes, it sounds good to me
[20:29:32] danielk22: stuartm: I don't know if preview images are getting updated or not either. I believe these were part of what was taking too long to process..
[20:30:29] wagnerrp: iamlindoro: just committed, basically just a 'QUERY_ACTIVE_BACKENDS', returning a list of hostnames prepended by a counter
[20:30:32] stuartm: danielk22: I'll look at the whole lot, there are some other issues in PBB which I'll tackle at the same time
[20:31:29] dekarl: stuartm, shall i make a nice list of that? http://irc.mythtv.org/ircLog/channel/4/2012-01-11:22:10
[20:32:35] stuartm: no need ;)
[20:34:28] stuartm: dekarl: oh sorry, you're referring to the scanning issues? I think you want stuarta for those
[20:34:45] stuartm: since he know thinks he might have time
[20:35:02] MythBuild: build #2896 of master-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2896 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:35:11] stuartm: but even so, a list of outstanding problems would be useful to whoever ends up fixing them
[20:36:44] MythBuild: build #1682 of master-freebsd-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1682 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:37:10] wagnerrp: what?
[20:37:21] wagnerrp: i built that one just fine on both freebsd and gentoo
[20:37:33] iamlindoro: et tu, freebsd
[20:39:30] MythBuild: build #2645 of master-linux-32bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2645 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:39:44] MythBuild: build #1667 of master-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1667 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:40:08] wagnerrp: must have fat-fingered 'q!' in vim
[20:40:14] stuartm: seems they are all out to get you
[20:43:38] MythBuild: build #108 of master-osx-snow-leopard is complete: Failure [failed compile] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/108 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:43:45] stuarta: only a couple more to fail
[20:46:25] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[20:46:42] MythBuild: build #2897 of master-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2897
[20:49:13] MythBuild: build #1422 of master-debian-stable-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1422 blamelist: Raymond Wagner <rwagner@mythtv.org >
[20:49:25] MythBuild: build #1683 of master-freebsd-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1683
[20:53:39] MythBuild: build #1668 of master-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1668
[20:54:24] MythBuild: build #2646 of master-linux-32bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2646
[20:56:41] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has joined #mythtv
[20:56:41] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has quit (Changing host)
[20:56:41] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[20:58:24] stoffel (stoffel!~quassel@pD9E42ECA.dip.t-dialin.net) has quit (Remote host closed the connection)
[20:58:39] wagnerrp: Captain_Murdoch: are you actually around, or just reconnecting while away?
[21:00:48] MythBuild: build #109 of master-osx-snow-leopard is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/109
[21:04:00] highzeth (highzeth!~hz@hoiseth.no) has quit (Read error: Connection reset by peer)
[21:04:28] highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv
[21:04:31] wagnerrp: danielk22: re cppcheck stuff... i could pull in SGweightLocalStarting, SGweightRemoteStarting, and SGweigthPerDir:<host>:<path>
[21:05:08] wagnerrp: but all that would accomplish would be to shift code around, since the scheduler already applies all that stuff as an initial value before ever pulling it
[21:05:24] wagnerrp: i dont really see any need to do anything but initialize it to zero
[21:06:59] wagnerrp: unless we want to start using the same weighting algorithms for other writes, such as video or music data
[21:07:17] MythBuild: build #1423 of master-debian-stable-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1423
[21:09:17] Beirdo: natanojl: you got a moment?
[21:13:56] ** stuarta wonders if wagnerrp is having a bad day **
[21:14:07] wagnerrp: heh
[21:14:21] wagnerrp: im going to get my ohloh commit count up one character at a time!
[21:14:39] stuarta: it's the only way i'm going to catch up to the rest of you
[21:16:04] stuarta: the buildslaves are getting a good workout tonight
[21:16:12] MythBuild: build #2900 of master-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2900 blamelist: Raymond Wagner <rwagner@mythtv.org >
[21:17:14] Beirdo: you're keeping my apartment warm :)
[21:17:33] stuarta: and my study
[21:17:34] MythBuild: build #111 of master-osx-snow-leopard is complete: Failure [failed compile] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/111 blamelist: David Engel <dengel@mythtv.org >, Raymond Wagner <rwagner@mythtv.org >
[21:19:22] wagnerrp: Beirdo: is it possible to limit the buildbot to only certain directories?
[21:19:35] Beirdo: umm, such as?
[21:19:54] wagnerrp: i.e. a commit to one of the bindings, or html, themes, translations, etc... does not trigger a rebuild
[21:19:55] MythBuild: build #2901 of master-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2901
[21:20:14] natanojl: Beirdo: Sure
[21:20:16] stuarta: should be possible
[21:20:20] Beirdo: natanojl: just looking for two things: to confirm the email address and to get an htpasswd line from you for trac :)
[21:20:37] Beirdo: wagnerrp: could possibly be done, but I don't think it's a wise plan
[21:20:47] map7_ (map7_!~map7@ppp118-209-93-114.lns20.mel4.internode.on.net) has quit (Ping timeout: 252 seconds)
[21:20:57] stuarta: burn cpu burn
[21:21:04] Beirdo: I'd rather see it try every time to be absolutely sure we have it right
[21:21:08] Beirdo: but we can look into it
[21:21:09] wagnerrp: i suppose other than the windows buildbot, everything else is running ccache, and isnt really hurt by a couple minutes of disk IO
[21:21:20] Beirdo: yeah, I need to ccache that one :)
[21:21:31] Beirdo: natanojl: so hit me up in PM if you wish :)
[21:21:44] stuarta: btw. i poked mark about the ppc buildbot and mentioned our findings on tuning ccache
[21:22:01] Beirdo: marc provitt as in?
[21:22:05] stuarta: aye
[21:22:15] stuarta: said he'd look at it
[21:22:35] Beirdo: cool. He just moved to a new job as of the end of the week last week so I can't throw things over the cubicle wall at him anymore
[21:23:11] wagnerrp: in regards to giving it more than the default 1GB cache?
[21:23:21] stuarta: sounds like me, got 2 days left at the old job, start new one monday week
[21:23:23] stuarta: wagnerrp: yes
[21:24:17] Beirdo: he's a cool guy... a debian-lover, but that works for me
[21:24:31] stuarta: i've used debian for years
[21:24:41] stuarta: until i got the shits with them not shipping firefox
[21:24:52] Beirdo: I'm close to switching from Ubuntu to Debian
[21:25:01] stuarta: i went the other way
[21:25:15] stuarta: ffs. my ccache on the osx slave is 6.7Gb
[21:25:29] Beirdo: well, upstart and such... they are the reasons I am starting to wanna switch
[21:25:50] stuarta: everyone is moving towards dependency based booting
[21:26:05] Beirdo: that's fine, but indeterminate is not
[21:26:17] stuarta: now if you'd said their stupid new window manager....
[21:26:22] Beirdo: and upstart is not predictable for booting.
[21:26:25] wagnerrp: moving towards?
[21:26:39] Beirdo: and my boxes are more servers than desktop, really
[21:26:41] wagnerrp: freebsd has been set up that way since i started using it, like 10 years ago
[21:27:14] wagnerrp: same with gentoo
[21:27:46] stuarta: i have a lot of time for ubuntu server edition
[21:27:55] Goga777 (Goga777!~Goga777@128-71-150-153.broadband.corbina.ru) has quit (Remote host closed the connection)
[21:28:21] ** stuarta remembers he needs to become redhat fanboy **
[21:29:46] stuarta: Beirdo: maybe you need to put an alwaysUseLatest=true on the mingw build since it's so slow
[21:30:14] stuarta: or ccache :)
[21:31:28] Beirdo: hmmm
[21:31:44] Beirdo: I think the alwaysUseLatest would be a good start :)
[21:32:03] Beirdo: ccache once I find a working version again
[21:32:12] stuarta: at least that way it'll combine wagnerrp's typo fixes with his main commit in one build :)
[21:32:23] ** stuarta hides **
[21:33:07] MythBuild: build #112 of master-osx-snow-leopard is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/112
[21:33:31] Beirdo: hehe
[21:33:32] wagnerrp: only two of the bots caught that bad version
[21:34:01] stuarta: btw. ended up fixing alwaysUseLatest with the buildbot guys
[21:34:09] natanojl: Thanks everyone for letting me join the team :)
[21:34:28] wagnerrp: congratulations and welcome
[21:34:39] Beirdo: Oh, I already have alwaysUseLatest
[21:34:46] wagnerrp: now, don't do what that Raymond character over there did, and keep committing typos
[21:34:49] stuarta: discovered that setting branch="whatever" in the slave config did bugger all, it built whatever branch was being triggered anyway
[21:35:26] Beirdo: hehe, if we all remembered to to test builds before pushing, then this would be a lot simpler in many cases :)
[21:35:46] ** stuarta tries to work out wtf the qmake from the osx framework is trying todo **
[21:35:55] Beirdo: gooood luck
[21:36:09] stuarta: so far the only thing that builds is the ffmpeg stuff
[21:36:14] stuarta: that's cause it isn't qt
[21:36:19] Beirdo: hehe
[21:36:28] Beirdo: qmake is my nemesis
[21:36:32] stuarta: natanojl: congrats
[21:37:09] stuarta: i've given myself the intriguing task of getting myth to build on osx using Qt installed as a framework from official packages
[21:37:39] stuarta: on the basis that you can't actually compile Qt on osx lion atm
[21:38:07] natanojl: wagnerrp, stuarta: Thank you
[21:39:41] cattelan_away is now known as cattelan
[21:40:18] Beirdo: natanojl: I guess if you wanted to do wiki admin stuff, wagnerrp or iamlindoro are likely good people to talk with. I don't think I have (or really want) keys to that part of the kingdom.
[21:40:36] wagnerrp: you dont?
[21:40:52] stuarta: i thought all the devs did
[21:40:53] Beirdo: not at a login level, I don't think
[21:41:02] Beirdo: unless it got added, and I forgot
[21:41:04] wagnerrp: stuarta: nope, only a handful
[21:41:38] Beirdo: heh, I can always mess with the db if I really wanted to, but I'm happy with our current wiki admins... if ya need more help, I could help of course
[21:42:01] stuarta: speaking of help, if you need any on the server migration lemme know
[21:42:26] wagnerrp: stuarta: not that theres any reason they couldnt have it if they asked... they just never asked
[21:42:33] Beirdo: Cool. I think right now, the worst part is getting a) an itemized plan and b) getting going.
[21:42:49] ** stuarta gives Beirdo a "round tuit" **
[21:42:59] Beirdo: hehe :)
[21:43:13] Beirdo: I think I'll get postfix setup soon though as a start
[21:43:21] Beirdo: easy enough to transplant all that
[21:43:51] stuarta: have we got the base build done then?
[21:43:51] Beirdo: managing the DNS changes are the trickiest part (as OSUOSL staff do that)
[21:43:52] wagnerrp: looks like both chris's, all three roberts, other stuart, and isaac
[21:44:10] wagnerrp: along with a couple other non-devs and former-devs
[21:44:25] Beirdo: I believe the box has been paved, and we have it up and running and waiting
[21:44:39] stuarta: k
[21:44:42] Beirdo: xris has rsynced over the majority of the data
[21:44:50] Beirdo: the most fun will be yon bot
[21:44:59] Beirdo: it's DB is pushing 1G
[21:45:08] stuartm: right, wiki admin privs weren't given to everyone, partly because they didn't ask and partly because they didn't need them
[21:45:18] Beirdo: although, I guess I could go get it compile and ready
[21:46:33] wagnerrp: the logbot is pushing 1GB?
[21:46:53] Beirdo: in DB size, yeah
[21:47:00] Beirdo: it has from 2005, remember
[21:47:02] wagnerrp: i guess its been running largely non-stop for what... six? seven years?
[21:47:16] stuartm: just like not everyone has root on the server(s), not everyone needs them and not to say we don't trust everyone but it's safer not to give people keys to things they don't need access to (it only takes one dev to have their machine breached to compromise the project, as was so recently demonstrated by kernel.org)
[21:47:37] natanojl: Beirdo: I don't think I need wiki admin rights at this point :)
[21:47:42] Beirdo: 873MB
[21:48:11] stuartm: Beirdo: archive everything older than the last couple of years?
[21:48:15] Beirdo: plus about the same for the lucene db (which needs a rebuild again)
[21:48:34] Beirdo: meh, we could, but it does no harm to sit there
[21:48:46] Beirdo: it's just when transferring it that it's any issue
[21:49:19] wagnerrp: write in some code that will backfill the logs onto a new live instance?
[21:49:30] Beirdo: heh
[21:49:40] wagnerrp: rather than require the whole thing be transferred at once
[21:49:54] Beirdo: I guess I could
[21:50:06] Beirdo: but it moves seldom enough...
[21:50:27] Beirdo: I need to fix the locking around the lucene stuff though
[21:50:30] stuartm: Beirdo: still, if it was smaller backups would be easier
[21:50:31] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[21:50:33] wagnerrp: its not like its much code, or really even needs to be written into the bot
[21:50:47] Beirdo: so I can reindex/rebuild while the bot is running
[21:50:53] wagnerrp: its just shuffling from one mysql database to another, right?
[21:51:01] Beirdo: yes
[21:51:08] Beirdo: other than the lucene
[21:51:18] Beirdo: which is currently borked anyways :)
[21:51:29] Beirdo: dangit, now you are inspiring me to fix it
[21:51:30] Beirdo: hehe
[21:52:27] wagnerrp: well thats simple enough... i could throw something in python that would just pump lines over ssh into another python instance and into the new dataabse
[21:52:29] stuarta: ah yes, your mingw builder does alwaysUseLatest.
[21:55:04] Beirdo: well, let me get on at least compiling the bot and getting mysql ready
[21:55:05] Beirdo: heh
[21:55:20] stuartm: stuarta: any chance you'd be able to test the seriesid patches? Since you use EIT exclusively the results are going to be more useful than any test I might run
[21:55:58] stuartm: markk: or since you were interested in this feature, maybe you'd be happy to test?
[21:56:10] stuarta: not right now, i have a few bits of stuff todo to make my dev rig actually work on that
[21:56:14] Beirdo: hahah, xris actually rsynced the home dirs too. nice
[21:56:28] xris: Beirdo: still need to sync /etc by hand nice that we put most of the stuff in /opt so rsync is easy
[21:56:40] xris: homedirs are a little out of date. I only sync'd them once
[21:56:47] xris: but yeah, users and such got sync'd early on
[21:56:52] Beirdo: cool
[21:56:56] xris: I did /opt last week
[21:57:05] Beirdo: I'm gonna try to get teh bot recompiled and ready
[21:57:43] stuarta: is it back as alcor?
[21:57:59] Beirdo: yes
[21:58:01] xris: yeah, the alcor name never left
[21:58:20] xris: and in the move to the "new" server, we got osu to fix all of the DNS names to be CNAMES, so it'll be really easy to move things back
[21:59:04] Beirdo: and the TTLs are 5min
[21:59:12] Beirdo: so it should be not too bad
[21:59:26] stuarta: cool
[22:00:48] Beirdo: I think the most important thing is to make sure the mail service works on the new one, so we can swing over trac and buildbot stuff
[22:01:09] Beirdo: then once they (and other web services) are moved, then we can move the mailing lists too
[22:01:41] xris: yeah.
[22:02:18] xris: not sure what to move first. web would be easy but it briefly puts the mailing list manager out of sync
[22:02:23] xris: maybe easiest to just move everything
[22:02:40] xris: I planned to set up a proxy autoconf file to test things before we actually move dns
[22:05:32] stuartm: xris: I doubt anyone would mind a period of downtime to allow a full migration
[22:05:45] xris: yeah
[22:05:58] xris: just confuse users who think they've signed up or removed from the mailing list
[22:06:31] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[22:08:13] stuartm: xris: we can close the lists before migration, no? Or do you mean email subscription/removals ending up in limbo?
[22:08:49] xris: limbo
[22:09:11] xris: though mostly not an issue if we shut things down on the old box as we migrate
[22:11:35] stuarta: if you have the osuosl guys on hand to make dns changes it can be pretty seamless
[22:12:34] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[22:25:02] xris: yeah. they're around most of the time, though it's usually better to schedule after-hours stuff
[22:25:49] Beirdo: so, the IRC bot is a' compiling
[22:25:55] stuarta: depends where you are in the world :)
[22:26:05] stuarta: pretty fast no doubt
[22:28:04] stuarta: xris: since you are around, Beirdo and I both agree nginx is the webserver of choice
[22:29:16] stuarta: now why doesn't centos package php-fpm
[22:29:20] stuarta: pile of poo
[22:30:09] Beirdo: oh nice
[22:30:33] Beirdo: and they put libc-client headers in /usr/include/imap instead of /usr/include/c-client
[22:30:36] Beirdo: ok then
[22:31:53] xris: stuarta: nginx works better as an intermediary.
[22:32:06] xris: but I also prefer it over apache. just never used it with php
[22:32:18] stuarta: i've mythweb running nicely under it
[22:32:28] stuarta: nginx + php-fpm
[22:32:29] xris: WAY better for python. we should definitely look at getting uwsgi installed for trac (for nginx or apache)
[22:32:39] stuarta: it's just way better
[22:32:47] jya (jya!~jyavenard@120.148.99.54) has joined #mythtv
[22:32:48] jya (jya!~jyavenard@120.148.99.54) has quit (Changing host)
[22:32:48] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:32:52] stuarta: definitely
[22:33:57] stuarta: oh joy, i have to build it myself
[22:36:08] xris: huh?
[22:36:22] xris: nginx?
[22:36:48] stuarta: nah php-fpm
[22:36:57] stuarta: they don't enable it by default
[22:37:29] stuarta: either that or <insert_random_repository_here>
[22:37:57] xris: nginx has its own repository for a lot of distro types
[22:38:10] stuarta: nginx is all good to go
[22:40:03] Seeker`: so if 0.25 is almost frozen, what will be the targets for 0.26?
[22:40:23] stuartm: MythSocket(1c3eda0:62): Protocol error: 'GET / HT' is not a valid size prefix. 360 bytes pending.
[22:40:46] stuartm: wagnerrp: I'm seeing that after upgrading to protocol version 72
[22:40:57] Beirdo: Seeker`: TBD... AFTER 0.25 is out :)
[22:41:15] stuarta: i was looking for flying pigs
[22:41:31] Beirdo: yeah, that's probably close
[22:41:32] wagnerrp: stuartm: i have no idea what that means
[22:42:08] stuarta: stuartm: that looks like it's received a partial request (assuming it printed the whole thing out)
[22:42:13] wagnerrp: oh, size prefix being the 8-byte size string for the next packet
[22:42:40] Beirdo: the fun of custom protocols :)
[22:43:11] wagnerrp: is that frontend or backend logs?
[22:43:19] stuartm: wagnerrp: ok, could just be that I accessed the http server just after starting the backend
[22:43:22] stuartm: wagnerrp: backend
[22:43:28] stuartm: GET / HTTP maybe?
[22:44:04] stuartm: we'll ignore it unless it repeats
[22:44:11] wagnerrp: sounds like the HTTP and proto servers are getting mixed up
[22:44:20] wagnerrp: youre sending HTTP packets at the proto server
[22:44:47] wagnerrp: although nothing i changed should have any affect on that
[22:44:53] stuartm: heh, could be I typo'd the port
[22:45:30] stuarta: PEBKAC!
[22:45:31] stuartm: wagnerrp: yep, I've never seen protocol errors like that before hence I assumed it was connected
[22:46:21] stuartm: fwiw, if I try "GET 192.168.159.2:6543" it's clearly the cause of the error, sorry for the noise
[22:47:08] Beirdo: hehe
[22:54:32] stuartm: davide_: after 65b63e1f5 reschedules are taking over two minutes (vs 9 seconds) and mysql is using 100% cpu during the reschedule
[22:56:12] stuartm: there's no index on generic, but I'm not sure if that's the reason
[23:03:34] Beirdo: wow, that's quite a slowdown
[23:22:28] stuartm: it's actually a little worse – with that commit "Scheduled 796 items in 119.5 = 0.40 match + 119.06 place" and after reverting "Scheduled 796 items in 5.5 = 0.35 match + 5.19 place"
[23:22:43] stuartm: so 2 minutes verses 5.5 seconds
[23:25:24] stuartm: gigem: ^
[23:31:03] gigem: stuartm: that's not good. can you try adding an index for program.generic? also, if you can, please mail me the output from running "mythbackend -v schedule --testsched" on your master backend.
[23:32:10] gigem: oh, and please also send the same output with that commit reverted.
[23:38:38] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[23:57:39] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Read error: Operation timed out)

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