:: #mythtv

Daily chat history

Current users (86):

aloril, Anssi, anykey__, autopatch, brfransen, CaCtus491, Captain_Murdoch, cattelan, Chutt, clever, coling, Cougar, damaltor, danielk22, David_Mi1ler, dblain, dekarl1, dinamic|screen, dlblog, eharris_, ElmerFudd, foobum, foxbuntu, ghoti, gregL_, GreyFoxx, highzeth, idl0r, J-e-f-f-A, jams, jarle, jcarlos, joe____, joki, jpabq, jstenback, jwh, jwhite, kc, knightr__, kormoc, kurre2, kwmonroe, laga, mag0o, markcerv, MaverickTech, mrand, mrec, MythBuild, MythLogBot, mzanetti, NightMonkey, peitolm, Peps, petefunk, pheld, poptix, purserj, rsiebert_, seld, Sharky112065, skd5aner, Slasher`, SmallR2002, sphery, sraue, stichnot_, sutula, tgm4883, ThisNewGuy, toeb, tomimo, tris, Unhelpful, vallor, Vernon_at_work, VManiac16, wagnerrp, wahrhaft, whoDat, xavierh, XDS2010, yb0t, _charly_, _Techie_-_AFK_
Tuesday, June 19th, 2012, 00:22 UTC
[00:22:22] amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv
[00:22:30] amejia_ (amejia_!~andres@xbmc/staff/amejia) has quit (Read error: Connection reset by peer)
[00:23:04] amejia (amejia!~andres@xbmc/staff/amejia) has quit (Client Quit)
[00:30:32] dmfrey (dmfrey! has joined #mythtv
[00:48:19] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[00:50:29] dmfrey (dmfrey! has joined #mythtv
[01:02:43] Sharky112065 (Sharky112065!~Sharky112@ has quit (Ping timeout: 246 seconds)
[01:03:10] Sharky112065 (Sharky112065! has joined #mythtv
[01:06:20] VManiac16 (VManiac16!~Unknown@ has joined #mythtv
[01:06:35] jwh_ (jwh_! has joined #mythtv
[01:06:44] Chutt_ (Chutt_! has joined #mythtv
[01:09:53] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:12:24] jwh (jwh! has quit (Ping timeout: 264 seconds)
[01:12:24] Computer_Czar (Computer_Czar!~Unknown@ has quit (Ping timeout: 264 seconds)
[01:12:25] Chutt (Chutt! has quit (Ping timeout: 264 seconds)
[01:12:25] idl0r (idl0r!~idl0r@gentoo/developer/idl0r) has joined #mythtv
[01:12:25] idl0r (idl0r!~idl0r@gentoo/developer/idl0r) has quit (Ping timeout: 264 seconds)
[01:12:58] pheld (pheld! has quit (Quit: Leaving.)
[01:32:25] Beirdo: well, so far so good... the animations in the menu worked, playback is working
[01:34:02] Beirdo: I think I'll be pushing pretty soon.
[02:07:19] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[02:09:29] Chutt_ is now known as Chutt
[02:33:36] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[02:38:26] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[03:13:10] gregL_ (gregL_! has joined #mythtv
[05:38:21] aloril (aloril! has quit (Ping timeout: 260 seconds)
[05:51:20] aloril (aloril! has joined #mythtv
[05:56:32] jwh_ is now known as jwh
[06:08:30] cattelan_away is now known as cattelan_away_aw
[06:10:06] cattelan_away_aw is now known as cattelan_away
[06:11:36] cattelan_away is now known as cattelan_away_aw
[07:25:07] rsiebert_ (rsiebert_! has joined #mythtv
[07:25:47] rsiebert (rsiebert! has quit (Ping timeout: 246 seconds)
[07:32:09] pheld (pheld! has joined #mythtv
[07:33:35] techie (techie! has joined #mythtv
[07:34:30] techie: mythweb seems to be applying its reqrite rule to any requests, not just requests for the /mythweb/ directory, does anybody know how to remedy this?
[08:00:47] stuartm: hmm, new leak/growth in the backend, heading towards 1GB after being up for just 12 hours
[08:00:47] Slasher` (Slasher`!~Slasher@ has quit (Ping timeout: 246 seconds)
[08:06:42] stuartm: danielk22: I'm seeing that "Real-time signal 0" issue, unable to start the frontend at all
[08:07:17] stuartm: always seems to occur immediately or shortly after "Added logging to mythlogserver at TCP:35327"
[08:10:07] stuartm: Beirdo: I had to manually remove the Makefile for zeromq to build after the 'don't build docs' commit otherwise it would fail with something like "No target 'all' in doc"
[08:10:15] stuartm: a distclean didn't help
[08:16:58] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:24:23] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 244 seconds)
[08:36:13] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[08:47:46] stuartm: Beirdo: any idea what's going on here, is this 'normal' for the backend?
[08:59:46] Goga777 (Goga777! has joined #mythtv
[09:01:33] stuartm: trying to explain the 900MB res that my backend gets up to after a very short period of time, but valgrind isn't being very helpful
[09:11:33] Slasher` (Slasher`!~Slasher@ has joined #mythtv
[09:50:08] jcarlos (jcarlos! has quit (Ping timeout: 240 seconds)
[10:22:05] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[10:22:42] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[10:27:28] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Client Quit)
[10:35:09] aloril (aloril! has quit (Ping timeout: 260 seconds)
[10:48:26] aloril (aloril! has joined #mythtv
[11:41:46] stuartm: xris: lyngsat have changed the url of the hi-res icons so that the path no longer matches the normal icons, I'm not sure how best to fix it – e.g. (they've dropped the /logo at the start there
[11:41:49] stuartm: )
[11:42:56] stuartm: but that only applies to the high res, the low res are at
[11:49:54] stuartm: ^C2012-06–19 12:49:36.570557 C Received SIGINT
[11:49:55] stuartm: *** glibc detected *** mythtv-setup: corrupted double-linked list: 0x00000000025e3250 ***
[11:51:32] stuartm: umm these signal handlers are really screwed up, it's a complete crap shoot as to whether I can start the frontend/mythtv-setup etc, it keeps dying with stuff like  – Handling SIGABRT \n Aborted
[11:51:44] stuartm: or "Real-time signal 0"
[11:51:55] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[11:52:27] stuartm: and lots of "*** glibc detected *** mythtv-setup: munmap_chunk(): invalid pointer: 0x0000000001b47920 ***"
[11:56:20] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[11:56:30] dblain (dblain! has joined #mythtv
[11:56:30] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[11:56:30] dblain (dblain! has quit (Changing host)
[11:59:12] jcarlos (jcarlos! has joined #mythtv
[12:02:19] techie is now known as _Techie_-_AFK_
[12:17:45] danielk22: "Real-time signal 0" That's the one I've been seeing when startup just doesn't happen.
[12:21:31] Jordack (Jordack! has joined #mythtv
[12:22:37] stuartm: for me startup begins but it then bails before completing, same for the SIGBART
[12:23:07] danielk22: Beirdo:
[12:26:59] danielk22: Beirdo: ignore that, it doesn't seem to apply.
[12:38:17] danielk22: Beirdo: stuartm: This should be useful . . . ally-653952/
[12:57:42] danielk22: I don't see anything in signalhandling.cpp that pops out at me for this. But I do see some oddities: we don't check the return of sigaction, so we wouldn't know if it is reporting and error.
[12:58:01] danielk22: We use signal() in ~SignalHandler() rather than sigaction.
[12:59:06] danielk22: We define m_usr{1,2}Handler but these to not get a sigaction() init in the SignalHandler ctor.
[13:05:51] Goga777 (Goga777! has quit (Remote host closed the connection)
[13:07:15] danielk22: And reading up on signal() it should be avoided for portability. If you compile with -std=xxx or -ansi with gcc you get the broken System V implementation (signal handled once and rapid deliveries could result in recursive invocations of the handler); and presumably you could also get this with clang.
[13:09:58] dmfrey (dmfrey! has joined #mythtv
[13:10:39] danielk22: Although it sounds almost safe to use it to set SIG_DFL, since that is what the System V semantics reset it to, you would still have the signal not blocked during delivery issue; so you are depending on the OS handling that properly (probably true of true unixes, but who knows with other OSs).
[13:21:22] danielk22: Beirdo: We should probably roll the SIGHUP handling into the signalmonitor.cpp too. That way as we fix issues there it will be fixed for all the signal handling.
[13:27:03] danielk22: I don't think you should be disabling m_sighupNotifier while handling it. It's unnecessary to block notifications since they are dispatched from the same thread that handleSigHup() is run in.
[13:44:26] cattelan_away_aw is now known as cattelan_away
[13:53:02] dmfrey: does the myth services api honor the http expires headers to verify the freshness of the data returned?
[13:53:39] dmfrey: or the cache-control headers?
[14:05:17] dmfrey: what about etag?
[14:11:24] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:15:49] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[14:31:30] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer)
[14:31:34] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:32:51] zombor_ is now known as zombor
[14:43:52] Captain_Murdoch: danielk22, not sure what the QHttp vs QNAMngr comment was about, don't think i've ever used QHttp. If we are using QHttp anywhere, we should be able to convet those to use our MythDownloadManager or, if necessary, their own QNetworkAccessManager instead of MDM's.
[14:46:56] danielk22: Captain_Murdoch: Ah, I assumed those were your because you wrote MythDownloadManager. But they are actually in use in the two earlier myth download managers (mythhttppool and httpcomms).
[14:47:17] danielk22: & in some random other locations like the cetonstreamhandler.
[14:48:53] danielk22: I guess we should just convert the users or HttpComms and MythHttpPool to MythDownloadManager then eliminate those..
[14:50:28] Captain_Murdoch: we've slowly been converting I think, but nothing has been done in the past 6 months that I know of.
[14:53:05] danielk22: Sure, it looks like there is only one use of MythHttpPool, and six uses of httpcomms left.
[15:22:39] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[15:32:32] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[15:48:37] dmfrey (dmfrey! has quit (Remote host closed the connection)
[15:49:20] dmfrey (dmfrey! has joined #mythtv
[16:11:32] msg (msg!~John@unaffiliated/john) has joined #mythtv
[16:11:40] msg (msg!~John@unaffiliated/john) has left #mythtv ()
[16:16:58] dblain: dmfrey: the services API implements etag support.
[16:17:13] dmfrey: dblain, thanks, i will look into it
[16:25:40] joki (joki! has quit (Ping timeout: 272 seconds)
[16:27:22] joki (joki! has joined #mythtv
[16:29:20] SteveGoodey (SteveGoodey! has joined #mythtv
[16:30:31] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer)
[16:32:10] Goga777 (Goga777! has joined #mythtv
[16:32:14] danielk22: ==1643== in use at exit: 3,585,918 bytes in 13,449 blocks
[16:32:14] danielk22: ==1643== total heap usage: 525,975 allocs, 512,526 frees, 130,606,125 bytes allocated
[16:32:45] danielk22: ^^^ Pretty sure the memory use is not due to unfreed memory but due to memory fragmentation.
[16:35:38] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[16:35:41] danielk22: Could also be a memory mapped file in zeromq
[16:35:59] zombor (zombor! has joined #mythtv
[16:35:59] zombor (zombor! has quit (Changing host)
[16:35:59] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[16:37:45] Goga777 (Goga777! has quit (Quit: Leaving)
[16:39:15] stichnot (stichnot!~chatzilla@ has joined #mythtv
[16:39:20] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[16:39:20] stichnot (stichnot!~chatzilla@ has quit (Changing host)
[16:48:10] stuartm: danielk22: yeah, I'm not seeing a smoking gun with valgrind either, but the growth isn't confined to mythlogserver either, in my case resident memory jumps to ~900MB during recording and stays like that even a few hours later
[16:48:21] stuartm: sorry, that's with the backend
[16:50:26] stuartm: prior to that it's using just ~65MB and is pretty stable at that level even after a couple of hours of uptime, so it's hard to see just how my issue relates to the logging
[16:51:09] stuartm: there is some additional logging at recording start/end but nothing to explain the increases
[17:01:37] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[17:02:00] stichnot: fwiw, my backend is also running at ~50% of one i7 core during remote frontend playback, for no apparent good reason, similar to the recent "Mythbackend high cpu?" thread on mythtv-users list
[17:02:57] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[17:03:08] danielk22: stichnot: try running strace.. I'm seeing many recvfrom and poll calls...
[17:03:43] danielk22: But I'm seeting this on the frontend not the backend.
[17:03:44] stichnot: danielk22: it's a long time since I've run strace. What args are you using?
[17:04:02] danielk22: just running it straight "strace mythfrontend"
[17:04:40] stichnot: also my poor mythcommflag process is desperately trying to segfault but is being held in limbo :)
[17:04:54] stichnot: I assume that's due to the signal handling problems already mentioned
[17:05:31] danielk22: stichnot: Yeah, I committed a fix for the segfault problem yesterday though.
[17:05:52] stichnot: lastly, I just noticed my mythbackend process consuming ~2GB of RAM. Nothing new here, just echoing other reports.
[17:06:06] stichnot: danielk22: ok, I'm currently a few days behind
[17:10:28] stichnot: danielk22: strace -p`pidof mythbackend` shows practically nothing while consuming ~50% CPU during remote frontend playback of a recording
[17:16:38] J-e-f-f-A_ (J-e-f-f-A_! has joined #mythtv
[17:16:57] J-e-f-f-A (J-e-f-f-A! has quit (Read error: No route to host)
[17:16:57] J-e-f-f-A_ is now known as J-e-f-f-A
[17:17:55] andreax (andreax! has joined #mythtv
[17:21:07] stuartm: stichnot: additional reports are useful since they confirm this isn't a unique issue
[17:22:07] xris: stuartm: on top of all of that, for awhile at least, they were blocking referrals that didn't come from their domain. makes the editor useless
[17:22:34] xris: we really just need to come up with something of our own to replace them
[17:22:36] stuartm: xris: the latter is fixed, it's just the url change causing problems atm
[17:22:47] xris: ah, that's good to know
[17:24:19] stuartm: xris: aye that would be great, but I really don't hold out a lot of hope for that, we can't even give the existing icon stuff the time it requires, the moderation backlog is just crazy and problems like this url change go unnoticed for long periods
[17:24:50] xris: yup
[17:25:15] xris: I've wanted to write something like that for years (crowdsource it) but obviously haven't been able to get anything done
[17:25:23] xris: "life" takes up too much time these days
[17:25:25] stuartm: danielk22, stichnot: could the high CPU and maybe even memory be related to logging because of the way it's filtering out the LOG stuff that the user doesn't want to see? I mentioned before that I'm seeing the growth rocket during recording, but the visible logging is minimal during that period – the filtered logging however is significant during recording (record, channel, file, dvb etc)
[17:26:43] stuartm: xris: the icon downloader works well enough in the UK at least, especially since the last lot of changes I made, but we need to change the way icon submissions are confirmed so that it's done automatically
[17:27:17] xris: yup
[17:27:19] stuartm: we should update the database a little more often
[17:27:27] xris: that, too
[17:27:37] stuartm: I did it earlier today fwiw
[17:27:50] stuartm: well for lyngsat at least
[17:27:57] danielk22: stuartm: You mean verboseMask isn't set to what is on the -v line? Yeah that could cause a whole lot of CPU usage. Converting all the recorded tables to XML, etc.
[17:28:26] danielk22: It would cause a lot of mallocs too.
[17:28:43] stuartm: danielk22: that's what I was thinking, just seems to explain some of the symptoms
[17:28:53] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[17:29:05] stuartm: but I've no idea if it's actually the case
[17:29:20] dekarl1 (dekarl1! has joined #mythtv
[17:31:12] stuartm: hmm, manually started a mfdb run which ended over an hour ago according to the log but I just noticed that the process is still running
[17:31:14] dekarl (dekarl! has quit (Ping timeout: 265 seconds)
[17:32:27] danielk22: stuartm: We shouldn't forget the reference counting changes either. Could be my changes for some of this.
[17:33:23] Sharky112065 (Sharky112065! has quit (Ping timeout: 246 seconds)
[17:34:09] stuartm: danielk22: could be yeah, between the issues related to signal handling, the reference counter changes and the logging changes plus stuff I'm sure to have forgotten it's all become a little confused :)
[17:34:37] dmfrey: dblain, I am calling, for instance, GetRecordedList and inspecting the headers with firebug, chrome inspector, Simple Rest Client in chrome and curl but am not seeing any ETags being returned. Am I missing something?
[17:34:58] stuartm: oh, the UTC stuff too what with the mysql timezone problems
[17:35:38] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[17:37:55] stichnot: regarding the CPU usage, my money is on [f84028861c163520c9da11d5787126ee0cfb497e]
[17:38:28] stichnot: I bet MythDate::current() is vastly more expensive than QDateTime::currentDateTime()
[17:39:16] stichnot: and if so, it doesn't seem necessary to be so fussy about log timestamps, right?
[17:40:02] stichnot: . . . 26ee0cfb497e
[17:41:15] danielk22: stichnot: The result will be exactly the same since we're just using the toTime_t(), but I doubt there will be any difference in CPU use.
[17:42:23] danielk22: ah, we are using QDateTime::time() to. So the difference is we'll log in UTC rather than local time..
[17:43:04] danielk22: Oh and we only use this when a system doesn't have gettimeofday().. so unless you are on windows..
[17:45:01] XDS2010 (XDS2010!~users.121@gateway/web/ has quit (Read error: Connection reset by peer)
[17:45:15] danielk22: stuartm: I completely disabled LOG() and mythfrontend still uses over 2 GB.
[17:45:58] stuartm: danielk22: ok, that narrows it down
[17:46:06] stichnot: danielk22: I believe we create the QDateTime for every log message of the current loglevel, and later filter it based on "-v". I expect that QDateTime::currentDateTime() is lazy about any sort of conversion until it's actually used. But MythDate::current() calls toUTC() which would likely be much more expensive
[17:47:26] stuartm: danielk22: is the backend usage out of the ordinary? If we assume there's just the one cause at the moment for both my backend and your frontend to be using excessive memory then what areas were changed in the reference counting which are common to both?
[17:48:06] stuartm: I'm still only seeing the issue with the backend
[17:48:10] danielk22: stichnot: We don't run that code on Linux systems, and we don't call that unless we call LogPrintLine() which is only called if we pass the VERBOSE_LEVEL_CHECK() macro.
[17:48:44] danielk22: stuartm: backend, frontend and mythlogserver are all using a lot of memory.
[17:49:50] danielk22: I'm pretty sure the memory use has nothing to do with the reference counting; but I can imagine it causing the glibc complaint. (If a already deleted object has DecrRef() called on it.
[17:50:03] stuartm: so not libmythui, libmythtv ot libupnp then
[17:50:33] danielk22: I checked the reference counting stuff for leaks.. there are very few, and none in libmythui.
[17:50:53] stichnot: d'oh! you're right, I didn't read VERBOSE_LEVEL_CHECK carefully enough
[17:51:00] stuartm: danielk22: yeah, as I said, too many different issues cropping up which may or may not be related
[17:54:13] Beirdo: danielk: using signal to set it back to the default during shutdown is perfectly acceptable.
[17:54:50] Beirdo: danielk22: the SIGHUP is only used in mythlogserver now.
[17:55:15] stuartm: heh, can't seem to stop running into bugs, just discovered a new one in LiveTV when it switches to an in-progress recording, if you then exit livetv it stops the recording ... but it's still marked as being in-progress and doesn't appear in Watch Recordings anywhere
[17:55:29] Beirdo: and yeah, I was planning on handling it via the signalhandler code now too.
[17:56:50] Beirdo: stichnot: the segfault stuff should work now
[17:57:46] stichnot: Beirdo: ok. I'll update to the latest soon.
[17:57:59] Beirdo: stuartm: AFAIK, the logging doesn't allocate the item if filtered, but that may have gotten tweaked
[17:59:14] sphery: stuartm: does that mean you're going to pick up ?  :)
[17:59:18] dblain: dmfrey: ETag support was commited 3 months ago: therefore it's only in master.
[17:59:48] dmfrey: ah, gotcha
[17:59:50] Beirdo: and now I'm caught up :)
[18:00:26] XDS2010 (XDS2010!~users.121@gateway/web/ has joined #mythtv
[18:00:29] stuartm: sphery: heh, no since I only use LiveTV to test stuff, as I was doing this time ... really needs to fixed though, that's one nasty bug
[18:00:31] danielk22: Beirdo: FYI The CPU usage of the log server when not logging has fallen to 1% here...
[18:01:17] aloril (aloril! has quit (Ping timeout: 260 seconds)
[18:02:58] Beirdo: OK, so it might have been the QTimer after all
[18:03:01] Beirdo: good to know
[18:03:09] ** Beirdo gives QTimer the finger **
[18:04:02] Beirdo: and the frontend seemed to be happy with the change too, so hopefully all is good on that part
[18:04:57] Beirdo: it should also reduce the bogus attempts to repeatedly start the logserver (as it would wait 5min for the ::stop() to finish with MythSignalingTimer when I first converted it)
[18:05:04] stuartm: danielk22: maybe related, maybe not, but I'm seeing discontinuities in recordings and a far amount of Ringbuffer WaitForAvail warnings in the backend log
[18:06:22] danielk22: stuartm: There haven't been any recent changes in the recording stuff so it's probably related to the global problems we're seeing.
[18:06:28] sphery: fwiw, users have mentioned seeing a lot of issue that have come down to backend being unable to keep up with writing data
[18:07:22] sphery: ... maybe it's kernel/system/distro changes that necessitate giving mythbackend extra priority
[18:07:23] danielk22: sphery: recently? I followed up on two of those earlier and it turned out their hard drives were failing.
[18:07:24] Beirdo: all it takes is for one lock to be held longer than needed and we knock ourselves off kilter
[18:07:29] stuartm: sphery: this is new, for me a least
[18:07:56] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:08:10] sphery: i.e. akin to when the cgroup support was added for scheduler priority (the distros may have picked up some completely-fair i/o kind of analog?)
[18:08:11] stuartm: although maybe it's being brought on by the higher cpu usage and/or memory usage pushing things into swap
[18:08:16] Beirdo: I wish we had a way to graph out activity in each thread and mark the mutex lock/unlock activity on the graph
[18:08:49] Beirdo: I had a debugging tool like that on VxWorks many years back
[18:09:12] stuartm: Beirdo: possibly something that gdb can do, but I'm just not familiar enough with it
[18:09:13] sphery: stuartm: anyway, probably wouldn't hurt to try the ionice on that comment, at least to see if it helps the recordigns
[18:09:36] Beirdo: seems like an extension to oprofile + gdb, yeah
[18:11:13] Beirdo: wonder if dtrace does it... although not sure how stable dtrace is in Linux
[18:11:26] Beirdo: let's port to Solaris 10, yeah, that's it!
[18:13:32] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[18:14:16] aloril (aloril! has joined #mythtv
[18:14:57] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Quit: ChatZilla [Firefox 12.0/20120420145725])
[18:18:04] XDS2010 (XDS2010!~users.121@gateway/web/ has quit (Read error: Connection reset by peer)
[18:23:09] stichnot (stichnot!~chatzilla@ has joined #mythtv
[18:23:09] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[18:23:09] stichnot (stichnot!~chatzilla@ has quit (Changing host)
[18:28:49] XDS2010 (XDS2010!~users.121@gateway/web/ has joined #mythtv
[18:34:06] stichnot: hmm... tried to run VTune on the backend machine, and I think it crashed the machine
[18:34:32] Beirdo: well, don't do that :)
[18:37:09] Beirdo: MythBuild: force build doxygen-master now
[18:37:10] MythBuild: build forced [ETA 2m39s]
[18:37:10] MythBuild: I'll give a shout when the build finishes
[18:37:16] Beirdo: there we go
[18:39:33] natanojl (natanojl! has joined #mythtv
[18:40:09] MythBuild: Hey! build doxygen-master #1308 is complete: Success [3build successful]
[18:40:09] ** MythLogBot **
[18:40:09] MythBuild: Build details are at . . . /builds/1308
[18:41:32] Beirdo: OK that's better
[18:41:49] Beirdo: I had //< instead of ///< in mythsystem.h for the longest time
[19:10:56] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[19:12:11] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 252 seconds)
[19:20:26] zombor (zombor! has joined #mythtv
[19:20:27] zombor (zombor! has quit (Changing host)
[19:20:27] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[19:24:27] Sharky112065 (Sharky112065! has joined #mythtv
[19:30:10] XDS2010 (XDS2010!~users.121@gateway/web/ has quit (Remote host closed the connection)
[19:32:07] XDS2010 (XDS2010!users.1218@gateway/web/ has joined #mythtv
[19:40:42] dmfrey (dmfrey! has quit (Remote host closed the connection)
[19:41:22] dmfrey (dmfrey! has joined #mythtv
[19:46:41] cattelan_away is now known as cattelan
[19:53:37] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[19:55:03] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[20:25:44] stuartm: 1956m 536m 9232 S 77 15.5 38:49.12 mythbackend
[20:26:49] stuartm: that's 77% cpu, 536 MB resident and it's not actually doing anything, no recordings, no scheduling
[20:29:13] stuartm: actually not nothing, the frontend was playing back an old recording
[20:30:13] Beirdo: there's gotta be some good explanation as to WTF it's doing
[20:30:27] Beirdo: the memory could well be the ring buffer
[20:30:32] Beirdo: but 77% CPU?
[20:32:25] stuartm: the memory usage is unusual and the longer I leave it the worse it gets, it was 895MB or thereabouts after being left overnight
[20:32:38] stuartm: stichnot was saying his hit 2GB
[20:32:47] Beirdo: interesting
[20:33:05] Beirdo: something is a bit wonky... wonder what?
[20:33:59] Beirdo: how the hell do I have 5 commflags running when I set the max to 4?
[20:34:35] Beirdo: at least they are going fast. nearly 1000fps
[20:34:58] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:35:20] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[20:36:40] stuartm: stichnot: you aren't running with my scheduler patch in place are you?
[20:36:50] stichnot: not yet
[20:37:16] stuartm: stichnot: great, for a moment there I was worried ;)
[20:38:08] stuartm: Not that it conceivably could result in memory growth and such high cpu usage, but still
[20:38:34] stuartm: s/conceivably could/could conceivably/
[20:40:32] danielk22: Beirdo: I tried running with electric fence this morning, but it got caught in an infinite loop trying to allocate space for an exception.
[20:40:44] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[20:41:01] danielk22: Beirdo: AFAIK We don't even throw exceptions outside of libmythupnp.
[20:41:44] Beirdo: zeromq does
[20:41:54] Beirdo: unfortunately
[20:41:55] stuartm: danielk22: some of Anduin's code does, possibly his contributions to mythui and certainly some of mythvideo
[20:42:09] Beirdo: I did tighten down the try/catch blocks a few minutes ago
[20:42:32] Beirdo: it seems I have a shutdown issue to solve after the timer change
[20:42:41] Beirdo: will have that checked in shortly too
[20:42:51] danielk22: ah.. hmm. but you would have to not only throw exceptions but also have an explicit/implicit malloc inside the throw block; that should show up in cppcheck...
[20:43:06] danielk22: (It does for libmythupnp).
[20:43:43] Beirdo: the thread deregister in the mythsignalingtimer thread is blocked waiting for the log thread... and the log thread is waiting for the timer thread.
[20:43:46] Beirdo: bugger.
[20:43:47] Beirdo: easy to fix
[20:44:26] stuartm: danielk22: ah ok
[20:47:08] danielk22: AFAIK Only two things cause malloc itself to throw an exception. Bad params (say size 0) or not enough memory to satisfy the request (say size 2,000,000,000,000,000,000). We could easily check for both in our own malloc..
[20:48:00] Beirdo: size 0 is supposed to be handled IIRC.
[20:48:04] danielk22: (Err new itself.)
[20:48:26] Beirdo: supposed to either return NULL or a valid pointer to be freed later
[20:49:00] Beirdo: but yeah, not many cases where malloc should raise exceptions
[20:49:26] Beirdo: zeromq uses exceptions for error reporting (blast them)
[20:49:27] danielk22: Well malloc itself doesn't. new does.
[20:49:40] Beirdo: right
[20:49:51] danielk22: Written by a former Java dev ? :)
[20:50:15] Beirdo: probably :)
[20:50:31] Beirdo: so we gotta handle em in a few places, but it's not too bad
[20:50:39] Beirdo: only on connect, really
[20:51:00] Beirdo: I guess I could move that down into nzmqt and push up another patch to nzmqt
[20:51:32] Beirdo: OK, commit about to be pushed.
[20:51:39] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[20:52:41] Beirdo: I see my commflags and metadatalookups actually exiting now. That deadlock is gone.
[20:53:15] stuartm: cool, that was another issue I was seeing – preview and mfdb processes not exiting
[20:53:45] danielk22: stuartm: For the glibc malloc thing.. try manually deleting all your plugins and doing a full distclean in both mythtv and mythplugins. I think a lib version update may have been missed. Then try running with MALLOC_CHECK_=3 that will abort as close to the error as possible.
[20:53:48] Beirdo: they should now. It was a stupidity on my part, forgot to check that the exit condition was correct after the change
[20:54:10] stuartm: danielk22: sure
[20:55:00] stuartm: did I remember to bump the lib version for those mythui changes I made the other day?
[20:55:11] MythBuild: build #1222 of master-vista-mingw-32bit is complete: Failure [4failed compile] Build details are at . . . /builds/1222 blamelist: Gavin Hurlbut < >
[20:55:16] danielk22: glibc is actually using a pretty good malloc as of 5–6 years ago.
[20:55:24] Beirdo: OK, what did I miss for 'blows?
[20:55:49] stuartm: ah, one commit but not the other
[20:56:39] Beirdo: fatal error when writing output?!
[20:57:02] stuartm: and it's been bumped since
[20:58:10] Beirdo: ah, I see the issue
[20:59:44] ** Beirdo should be known as ID10t today **
[21:00:15] Beirdo: stuartm: do you have the instructions on how to do a coverity build?
[21:03:18] stuartm: not complete instructions, just what Eric posted to the -dev list
[21:05:02] Beirdo: K. I'll have to take another look. I was hoping that sometime we could setup a weekly job (or something like that) on buildbot to update it
[21:05:03] stuartm:
[21:05:03] ** MythLogBot **
[21:05:56] Beirdo: "yourDownloadLocation"
[21:06:01] Beirdo: download of what?
[21:06:48] stuartm: Beirdo: the 'build', which I think means a copy of the source including compiled objects/binaries
[21:06:57] Beirdo: heh, I guess there's still questions to be answered on that
[21:07:08] Beirdo: hmm. interesting
[21:07:15] Beirdo: tarballed or something?
[21:07:54] Beirdo: oh
[21:08:06] Beirdo: danielk22: what is the command-line to get version info from icc?
[21:08:16] stuartm: Beirdo: found this earlier in the thread –
[21:08:42] stuartm: so yes, tarballed
[21:08:53] Beirdo: ahhh, OK, that's useful
[21:09:12] Beirdo: I'll probalby start tinkering with getting that available soon
[21:09:25] Beirdo: but not pushing to them quite yet
[21:09:36] danielk22: icc --version
[21:09:54] Beirdo: danielk22: too obvious. Cool. I'll add it to the version output
[21:10:20] danielk22: It outputs three lines, the first says "icc (ICC) 12.1.3 20120212" for icc and "icpc (ICC) 12.1.3 20120212" for "icpc --version"
[21:10:20] danielk22: "
[21:10:38] danielk22: icc is the C compiler icpc is the C++ compiler.
[21:11:19] danielk22: Note: I wouldn't really recommend running an icc/icpc compiled mythtv right now ;]
[21:12:06] Beirdo: hehe
[21:12:23] Beirdo: OK, added the version check to the script we run at the end
[21:12:33] Beirdo: that way if we change versions, etc...
[21:13:39] Beirdo: and on non-icc boxes, I'm sure it will just give a lame error in the logs
[21:13:48] Beirdo: we'll see soon enough
[21:17:00] stuarta_ (stuarta_! has quit (Ping timeout: 272 seconds)
[21:18:00] Beirdo: poor frog
[21:20:03] stuartm: oh, do we need to build the zeromq tests, doesn't take long but if it's a simple configure change ...
[21:20:06] stuartm: ?
[21:20:20] Beirdo: I don't think we need them
[21:20:31] Beirdo: another configure change?
[21:20:49] stuartm: maybe, maybe not, getting ahead of myself, haven't checked yet
[21:21:01] Beirdo: I know they had one to skip the docs
[21:21:31] stuartm: and I'm sorry, but where does the frog come into it?
[21:22:08] Beirdo: stuarta's domain :)
[21:22:15] Beirdo: 17:17 -!- stuarta_ [ ] has quit [Ping timeout: 272 seconds]
[21:25:05] stuartm: ah heh, I should have guessed
[21:26:29] stuartm: ok, no configure arg that I can see, disabling them would mean removing references to the tests directory from the Makefile and ac configs, so not really worth the hassle that would cause when re-syncing
[21:26:46] Beirdo: yeah, that would be a bit messier
[21:26:52] Beirdo: well, thanks for checking
[21:27:11] stuartm: even the docs fix doesn't work here since the Makefile gets regenerated
[21:27:28] Beirdo: I need to check into DESTDIR type install issues with zeromq soon
[21:27:44] Beirdo: the docs one just tells configure to skip it, I thought
[21:29:27] stuartm: it modifies the Makefile which is a generated file, I had to wipe the existing Makefile and let it be regenerated just to get the compilation working after some recent change
[21:29:52] Beirdo: yeah, it would modify the Makefile
[21:29:53] stuartm: ah no sorry, mis-read, modifies the external Makefile
[21:30:10] stuartm: not the zeromq Makefile
[21:30:29] Beirdo: yes, that's where the change was made, although I bet it regenerated zeromq's Makefile in the process
[21:40:18] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[21:41:07] Beirdo: time for a break ;)
[21:41:19] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:41:19] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[21:44:22] stuartm: it's not good that I was expecting someone to mention Kit Kats ... no matter how much I try to avoid advertising it still manages make an unwelcome impact
[21:47:23] Beirdo: hehe
[21:53:06] stuartm: danielk22: you were right about the distclean, of course I had the exact same issue a month ago and you suggested the distclean that time as well, I should have remembered :/
[21:53:30] stuartm: next time feel free to clip me round the ear
[21:54:51] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[21:54:57] Beirdo: I think that's caught most of us repeatedly
[22:01:24] SmallR2002 (SmallR2002! has quit (Ping timeout: 245 seconds)
[22:08:42] Beirdo: frigging smolt is still borked
[22:12:13] Beirdo: now to clean out my old recordings that are 0 byte
[22:13:32] Beirdo: 2012-06–19 15:13:15.977435 E MythSocket(2771b00:111): writeStringList: Error, No data written on writeBlock (921 errors) starts with: 89 BACKEND_MESSAGE[]:[]SYSTEM_EVENT CLIENT_CONNECTED HO...
[22:13:36] Beirdo: nice
[22:14:41] Beirdo: spewwwwww
[22:18:30] MythBuild: build #1224 of master-vista-mingw-32bit is complete: Success [3build successful] Build details are at . . . /builds/1224
[22:19:19] natanojl (natanojl! has quit (Ping timeout: 244 seconds)
[22:27:41] dinamic|screen (dinamic|screen! has quit (Ping timeout: 248 seconds)
[22:30:53] Jordack (Jordack! has quit (Quit:
[22:32:10] SmallR2002 (SmallR2002! has joined #mythtv
[22:32:23] Beirdo: I think I shall shoot my HD receiver
[22:32:46] Beirdo: seems every file recorded from it for quite some time... was a DirecTV bouncing screen saver
[22:34:28] Beirdo: I think I'll be checking them for "unsubscribed" messages, and raising holy hell with DirecTV
[22:37:02] Beirdo: they think I'm not subscribed to HBO, it seems. What am I paying them the big bucks for then?
[22:37:49] dinamic|screen (dinamic|screen! has joined #mythtv
[22:40:56] Beirdo: There, maybe that will help. Told all three receivers to reboot
[22:47:20] SmallR2002 (SmallR2002! has quit (Ping timeout: 246 seconds)
[22:49:59] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:01:18] SmallR2002 (SmallR2002! has joined #mythtv
[23:01:55] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:05:32] SmallR2002 (SmallR2002! has quit (Ping timeout: 246 seconds)
[23:08:01] SmallR2002 (SmallR2002! has joined #mythtv
[23:09:44] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 272 seconds)
[23:11:12] Beirdo: OK, is it just me, or is all recording via HDPVR hopelessly borked right now?
[23:16:11] andreax (andreax! has quit (Read error: Connection reset by peer)
[23:26:03] stichnot: Beirdo: My HDPVR recordings have been just fine all along, though I'm a few days behind Master
[23:33:52] Beirdo: OK
[23:33:57] Beirdo: I think I found the issue
[23:34:13] Beirdo: 1) DirecTV is being a supreme bitch
[23:34:35] Beirdo: 2) the UTC changes slightly buggered things up for my script
[23:35:02] Beirdo: as for DirecTV, they are insisting your HDMI device accept the encryption now for some channels (like HBO)
[23:35:16] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[23:35:20] Beirdo: and my TV should be able to, but that input isn't active... and the TV's off
[23:35:39] Beirdo: so I'll be yanking the HDMI cable tonight and that should help
[23:41:05] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[23:42:43] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)

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