:: #mythtv

Daily chat history

Current users (85):

aloril, amessina, Anssi, anykey__, autopatch, brfransen, CaCtus491, Captain_Murdoch, cattelan_away, Chutt, clever, coling, Computer_Czar, Cougar, damaltor, danielk22, David_Mi1ler, dblain, dekarl, dinamic|screen, dlblog, eharris_, ElmerFudd, foobum, foxbuntu, ghoti, GreyFoxx, highzeth, idl0r, J-e-f-f-A, jams, jarle, jcarlos, joe____, joki, jpabq, jstenback, jwh, jwhite, kc, knightr__, 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_, stuarta_, sutula, tgm4883, ThisNewGuy, toeb, tomimo, tris, Unhelpful, vallor, Vernon_at_work, wagnerrp, wahrhaft, whoDat, xavierh, XDS2010, yb0t, _charly_
Monday, June 18th, 2012, 00:05 UTC
[00:05:32] idl0r (idl0r!~idl0r@gentoo/developer/idl0r) has quit (Ping timeout: 264 seconds)
[00:05:32] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Ping timeout: 264 seconds)
[00:05:34] stuarta_ (stuarta_! has joined #mythtv
[00:07:25] idl0r (idl0r!~idl0r@gentoo/developer/idl0r) has joined #mythtv
[00:14:42] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:59:48] toeb (toeb! has quit (Read error: Operation timed out)
[01:02:07] toeb (toeb! has joined #mythtv
[01:37:16] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[02:01:32] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[02:08:05] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:13:48] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[02:20:18] jams_ (jams_! has quit (Ping timeout: 245 seconds)
[02:22:08] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[02:37:17] zombor (zombor!~zombor_@ has joined #mythtv
[02:37:17] zombor (zombor!~zombor_@ has quit (Changing host)
[02:37:17] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[02:52:37] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[02:59:15] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:04:03] Computer_Czar (Computer_Czar!~Unknown@ has joined #mythtv
[03:12:11] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Operation timed out)
[03:14:39] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[03:19:04] Goga777 (Goga777! has joined #mythtv
[03:52:18] jwh_ (jwh_! has joined #mythtv
[03:52:47] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:53:07] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[03:53:07] jya_ is now known as jya
[03:53:30] Slasher` (Slasher`!~Slasher@ has quit (Ping timeout: 260 seconds)
[03:53:37] jwh (jwh! has quit (Read error: Connection reset by peer)
[03:55:09] Slasher` (Slasher`!~Slasher@ has joined #mythtv
[04:13:34] cattelan is now known as cattelan_away
[04:14:40] jwh_ is now known as jwh
[04:15:41] Goga777 (Goga777! has quit (Remote host closed the connection)
[04:27:02] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[05:23:21] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[05:55:10] Sharky112065 is now known as Sharky-Sleep
[06:41:21] Goga777 (Goga777! has joined #mythtv
[06:46:37] Lomion0815 (Lomion0815! has joined #mythtv
[07:24:55] rsiebert (rsiebert! has joined #mythtv
[07:25:32] rsiebert_ (rsiebert_! has quit (Ping timeout: 246 seconds)
[07:40:45] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[07:40:56] natanojl (natanojl! has quit (Ping timeout: 246 seconds)
[07:46:13] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[07:50:02] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Client Quit)
[08:14:17] Cougar (Cougar! has quit (Read error: Operation timed out)
[08:17:34] Cougar (Cougar! has joined #mythtv
[08:27:10] Goga777 (Goga777! has quit (Remote host closed the connection)
[08:45:21] MavT (MavT! has quit (Ping timeout: 260 seconds)
[09:21:02] Lomion0815 (Lomion0815! has quit (Ping timeout: 246 seconds)
[09:23:05] Lomion0815 (Lomion0815! has joined #mythtv
[09:32:47] Lomion0815 (Lomion0815! has quit (Quit: Lost terminal)
[09:43:36] Goga777 (Goga777! has joined #mythtv
[09:51:14] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 265 seconds)
[10:03:51] Lomion0815 (Lomion0815! has joined #mythtv
[10:04:33] Lomion0815 (Lomion0815! has quit (Client Quit)
[10:05:56] Lomion0815 (Lomion0815! has joined #mythtv
[10:23:39] stuartm: gigem: is there any way we can split the scheduler lock into two or more locks? One protecting reschedQueue and the other whatever else needs protecting? Having one lock covering everything seems to be at least a contributory cause of the backend deadlock I'm seeing and I can't see why rescheduleQueue needs protecting by schedLock when it's only accessed in a couple of places
[10:35:06] stuartm: in fact I'm going to run with that and see how it performs
[10:40:20] stuartm: I've added a second QMutex, m_queueLock which is used to protect reschedQueue, if I'm right then that should fix the deadlock and also speed up some things since the backend event loop and mainserver will no longer be blocked during a reschedule
[10:51:09] zombor (zombor!~zombor_@ has joined #mythtv
[10:51:09] zombor (zombor!~zombor_@ has quit (Changing host)
[10:51:09] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[10:57:45] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[11:05:15] MaverickTech (MaverickTech! has joined #mythtv
[11:28:36] stuartm: is there any good reason why some protocol commands return "OK" while others return "ok" ... shouldn't those be consistent?
[11:40:03] superm1: Beirdo: how come zeromq was added in tree rather than as a new dependency?
[11:52:19] map7_ (map7_! has joined #mythtv
[12:10:09] map7_ (map7_! has quit (Read error: Connection reset by peer)
[12:11:16] Lomion0815 (Lomion0815! has quit (Quit: Lost terminal)
[12:34:18] Chutt (Chutt! has joined #mythtv
[12:37:58] dmfrey (dmfrey! has joined #mythtv
[12:45:05] stuartm: gigem: here's what I'm currently testing, am I missing anything?
[12:50:06] stuartm: err, obviously a version of that patch which compiles, that's the wrong one ...
[13:02:23] stuartm: this should be the correct one, git stash getting the better of me –
[13:10:08] jams (jams! has joined #mythtv
[13:11:13] stuartm: might be imagining it, but the backend is a lot more responsive to the frontend now during reschedules, before I was seeing periodic delays on entering screens such as Watch Recordings that seemed to coincide with a reschedule occurring (every 5 minutes with EIT)
[13:22:01] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:32:20] MythBuild: build #16 of master-linux-64bit-icc is complete: Failure [4failed compile plugins] Build details are at . . . cc/builds/16 blamelist: Stuart Morgan < >, Antonio Marcos Lopez Alonso < >, David Engel < >, Nicolas Riendeau < >, Jim Stichnoth
[13:32:20] MythBuild: < >, Gavin Hurlbut < >
[13:36:45] Sharky-Sleep is now known as Sharky112065
[13:53:14] Beirdo: superm1: for the same reasons ffmpeg was added to the tree.
[13:54:02] Beirdo: not all distros will have a compatible version... and this gives us a known version to us that's common no matter what stupid choices a user makes.
[13:58:55] stichnot: taylorr: seems to help #10829. However, one still has to seek about 8 frames before the aspect ratio change is actually detected and acted on. Any suggestions about how to improve this?
[13:58:55] ** MythLogBot **
[14:06:51] stuartm: stichnot: that sounds familiar, I might be wrong but I seem to recall a change to wait a certain number of frames to act on aspect ratio changes since some sources were sending frames with the incorrect aspect every nth frame or there were channels sending the odd incorrect frame at advert transitions which caused unsightly switches
[14:07:46] stuartm: if such a check was implemented, then it clearly needs bypassing for editing ... or I could just be talking complete rubbish as usual
[14:09:01] gregL_ (gregL_! has quit (Read error: Connection reset by peer)
[14:12:26] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[14:13:49] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:16:02] stichnot: stuartm: thanks, I'll see if I can chase down that clue
[14:17:41] stichnot: stuartm: I'll try out that patch for 10647, but it will take a day or two to get dedicated time on the production system
[14:21:00] stichnot: stuartm: btw, I don't have EIT enabled, do you think the patch is still relevant?
[14:21:11] stuartm: stichnot: ok thanks, I'm testing it myself but since I can't reproduce the problem on demand it might take a few days to know that it's working, the more people who can test the quicker we'll arrive at a definitive answer
[14:21:57] stuartm: stichnot: I do, in my case it's the EIT scanner initiating frequent reschedules which is highlighting the lock issue, but it could just as easily happen with non-eit reschedule
[14:21:58] stichnot: yeah, I first need to see if I can reproduce it on demand...
[14:23:06] stuartm: stichnot: that might be difficult, it's dependent on timing, but there may still be scenarios under which it becomes easier to reproduce
[14:23:44] stuartm: i.e. LiveTV will involve frequent recording starts
[14:24:05] gregL_ (gregL_! has joined #mythtv
[14:28:08] dblain_ (dblain_! has joined #mythtv
[14:30:14] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Ping timeout: 244 seconds)
[14:30:35] stuartm: there may be scope for more lock related fixes in the Scheduler, e.g. I'm not sure that we need to hold the scheduler lock in some places following that patch and in others we might be able to reduce the scope of the locking so it's not held so long
[14:32:07] dblain_ is now known as dblain
[14:32:10] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[14:32:10] dblain (dblain! has quit (Changing host)
[14:49:51] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[14:56:01] MythBuild: build #3918 of master-linux-64bit is complete: Failure [4failed compile core] Build details are at . . . /builds/3918 blamelist: Daniel Thor Kristjansson < >
[14:58:47] MythBuild: build #2426 of master-debian-stable-64bit is complete: Failure [4failed compile core] Build details are at . . . /builds/2426 blamelist: Daniel Thor Kristjansson < >
[15:00:18] MythBuild: build #3691 of master-linux-32bit is complete: Failure [4failed compile core] Build details are at . . . /builds/3691 blamelist: Daniel Thor Kristjansson < >
[15:10:05] MythBuild: build #3919 of master-linux-64bit is complete: Success [3build successful] Build details are at . . . /builds/3919
[15:10:31] gigem: stuartm: Good catch on the race condition. I have no problem with a separate lock for the reschedule queue. I don't care for moving the trivial wrappers out of the .h file though.
[15:12:05] stuartm: gigem: I only did that when they stretched to more than a single line, but I can move them back if that's not a concern
[15:12:30] gigem: I'd prefer it. Thanks.
[15:13:12] gigem: It's one less set of prototypes to keep in sync when/if I go back in to revise the schedule requests.
[15:13:13] stuartm: np, everyone has a different opinion on how big/small inlined methods should be
[15:13:15] SteveGoodey (SteveGoodey! has joined #mythtv
[15:15:36] MythBuild: build #2427 of master-debian-stable-64bit is complete: Success [3build successful] Build details are at . . . /builds/2427
[15:16:35] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 260 seconds)
[15:18:40] danielk22: stuartm: Do you want me to take a look at that backtrace? It looks like you have the matter in hand..
[15:19:46] stuartm: danielk22: I think I've got it sussed and a reasonable fix, so no but thanks for offering
[15:20:58] MythBuild: build #3692 of master-linux-32bit is complete: Success [3build successful] Build details are at . . . /builds/3692
[15:24:55] MythBuild: build #1214 of master-vista-mingw-32bit is complete: Failure [4failed compile] Build details are at . . . /builds/1214 blamelist: Daniel Thor Kristjansson < >
[15:25:50] stuartm: the problem lock in this instance was the scheduler one so best fixed there rather than something like trying to prevent the EIT scanner from triggering a reschedule immediately prior to a recording
[15:26:26] Goga777 (Goga777! has quit (Quit: Leaving)
[15:26:57] MythBuild: build #17 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at . . . cc/builds/17
[15:27:33] gregL_ (gregL_! has quit (Quit: Leaving)
[15:27:44] stuartm: besides which I think this deadlock is possible even if the reschedule is triggered in other ways, it's just much less likely than the EIT case because of the timing
[15:37:45] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[15:39:34] gregL_ (gregL_! has joined #mythtv
[15:40:21] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[15:48:05] andreax (andreax! has joined #mythtv
[16:07:16] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[16:11:15] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection)
[16:12:42] taylorr (taylorr! has joined #mythtv
[16:12:42] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[16:12:42] taylorr (taylorr! has quit (Changing host)
[16:20:36] dmfrey (dmfrey! has quit (Remote host closed the connection)
[16:21:21] dmfrey (dmfrey! has joined #mythtv
[16:25:22] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[16:26:29] joki (joki! has quit (Ping timeout: 244 seconds)
[16:26:38] joki- (joki-! has joined #mythtv
[16:26:56] joki- is now known as joki
[16:35:26] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[16:47:40] SteveGoodey (SteveGoodey! has joined #mythtv
[16:58:00] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 244 seconds)
[17:02:28] zombor (zombor! has joined #mythtv
[17:02:28] zombor (zombor! has quit (Changing host)
[17:02:28] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[17:09:13] stichnot (stichnot!chatzilla@nat/intel/x-bsevvixiqtqnckas) has joined #mythtv
[17:09:14] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[17:09:14] stichnot (stichnot!chatzilla@nat/intel/x-bsevvixiqtqnckas) has quit (Changing host)
[17:19:59] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[17:25:16] Jordack (Jordack! has joined #mythtv
[17:28:18] stuartm: stichnot: I've had a look at the backtrace you attached and I don't think the patch will fix your issue, it's similar in that it's a deadlock over schedLock with the main thread/event loop blocked but caused by a different coincidence of events
[17:28:56] dekarl (dekarl! has joined #mythtv
[17:29:31] stichnot: OK. Do you think it's fundamentally a scheduler deadlock issue, or is it something that should be fixed in the surrounding code?
[17:29:32] stuartm: in that case the frontend (I'm guessing) has requested the list of pending recordings just as we're switching programmes in the livetv chain, the latter obtains the lock blocking the former
[17:29:43] stuartm: stichnot: definitely a scheduler issue
[17:29:56] stuartm: the locks need re-working/re-thinking
[17:30:49] stuartm: maybe a switch to read/write locks on recList instead of a mutex
[17:30:54] dekarl1 (dekarl1! has quit (Ping timeout: 265 seconds)
[17:31:27] stuartm: most access to recList is read only and there's no good reason for those to clash with each other
[17:34:11] gregL_ (gregL_! has quit (Read error: Connection reset by peer)
[17:48:29] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[17:48:58] zombor (zombor! has joined #mythtv
[17:48:58] zombor (zombor! has quit (Changing host)
[17:48:58] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[17:50:40] stuartm: gigem: does switching the scheduler lock to a QReadWriteLock make sense to you? Only a couple of places actually modify recList for example, the rest are just reading and it seems like that change would greatly reduce the potential for deadlocks
[18:00:00] stuartm: as it stands a protocol call or internal backend event that accesses information through the scheduler e.g. GetRecording(), GetAllPending() can cause a deadlock if it occurs during a recording starting or livetv transition
[18:02:07] danielk22: Beirdo: mythlogserver is still eating up 1572 meg and a steady 14% of cpu when the backend is the only process and isn't doing anything..
[18:06:10] danielk22: Beirdo: There are no log messages being sent. And the fixed 14% reminds me an of the QTimer bug. Are you using QTimer in the logging code. That bug was never fixed upstream despite my sending them a sample fix.
[18:07:47] Beirdo: yes, I use QTimer
[18:08:01] Beirdo: strangely enough, it's not behaving that way at ALL for me.
[18:08:10] Beirdo: what version of Qt are you running?
[18:08:33] Beirdo: for me:
[18:08:41] Beirdo: 15904 gjhurlbu 20 0 425m 25m 2208 S 1 0.7 55:37.34 mythlogserver
[18:08:45] danielk22: Beirdo: I'm using 4.8.1
[18:08:53] Beirdo: so.. 25MB resident and 1% CPU
[18:08:57] Beirdo: hmm
[18:09:08] Beirdo: I'm on 4.6.2, I believe
[18:09:44] Beirdo: the QTimers are being used to send heartbeat messages to each client every second
[18:10:10] Beirdo: and also to shutdown when all clients (but itself) are disconnecte
[18:10:11] Beirdo: d
[18:10:21] MythBuild: build #1217 of master-vista-mingw-32bit is complete: Success [3build successful] Build details are at . . . /builds/1217
[18:10:46] danielk22: Pretty sure it's QTimer then. Basically, recent Qt degenerates to using a busy loop for exactly 14% of the available CPU time no matter how fast/slow the cpu is.
[18:10:58] Beirdo: WTF?
[18:11:16] danielk22: I don't recall the qt ticket number, but it affects a number of releases.
[18:11:31] Beirdo: and yet we still use Qt even though we have to work around its multiple limitations :)
[18:11:34] Beirdo: heh
[18:11:40] Beirdo: OK.
[18:11:55] danielk22: This bug is why we needed a special thread to send pulse events in libmythui..
[18:11:58] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 245 seconds)
[18:12:01] Beirdo: do we have a MythTimer replacement that gives the same sort of desired behavior?
[18:12:13] Beirdo: rather than the undesired behavior?
[18:13:23] danielk22: Yep, MythSignalingTimer...
[18:13:46] Beirdo: K. I'll take a look at retrofitting that then
[18:13:52] Beirdo: stupid QTimer :)
[18:14:02] Beirdo: as for the memory usage...
[18:14:26] Beirdo: not quite sure why it would be using so much memory still
[18:14:35] Beirdo: I need to do a valgrind run, clearly
[18:15:04] Beirdo: if you get around to it with your different environment, that can be useful
[18:16:02] Beirdo: should be able to just kill the logserver that's running and restart using valgrind. You may need to stop the backend, and restart it after the valgrind run is ready for connections though
[18:16:15] danielk22: It doesn't need any arguements?
[18:16:34] Beirdo: only if you want it to log itself...
[18:16:54] Beirdo: the backend sends the logging location in the messages
[18:17:12] Beirdo: so the commandline for logserver is just for logging its own activity
[18:17:18] danielk22: ok, installing valgrind on the production box now..
[18:17:59] Beirdo: I usually use (for valgrind options): --log-file=${VALLOG} --track-origins=yes -v --time-stamp=yes --read-var-info=yes
[18:18:15] Beirdo: substitute in your own valgrind log file name of course
[18:18:36] danielk22: More evidence that it is the stupid QTimer bug, it's still the same amount of CPU under valgrind..
[18:18:51] Beirdo: Heh. Frick.
[18:18:58] Beirdo: OK, that is unfortunate.
[18:20:18] stuartm: sphery: if I change 'startswith' to 'contains' in the rsyslog config then it starts working, it seems that the app name isn't the first thing in the message
[18:20:32] Beirdo: so the MythSignalingTimer is just another thread that does it for us. I see :)
[18:20:44] Beirdo: cool, that shouldn't be too hard to retrofit to
[18:20:53] danielk22: I can't believe they still haven't fixed it, the bug was introduced in a 4.5.2. It's basically an off-by-one bug!
[18:21:04] dmfrey (dmfrey! has quit (Remote host closed the connection)
[18:21:06] Beirdo: 7% for each QTimer, times 2 QTimers
[18:21:33] Beirdo: yeah, it seems to be fixed on my setup (symptom-wise) but that coulda been Ubuntu's doing
[18:21:44] dmfrey (dmfrey! has joined #mythtv
[18:21:51] Beirdo: either way, if it's not fixed, we'll continue to work around it
[18:22:38] danielk22: Beirdo: Probably just luck. There is also a race condition involved.
[18:22:44] Beirdo: ahhh
[18:23:58] danielk22: sphery: You don't remember the bug #, do you?
[18:24:11] stuartm: sphery: I suppose because 'mythlogserver' is the first thing, seems a tad redundant
[18:25:24] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[18:25:27] Beirdo: stuartm: if I could shut off the "mythlogserver" part of the syslog line, I woulda... I tried, and there seemed to be no way.
[18:27:36] stuartm: Beirdo: ah, shame
[18:28:17] Beirdo: no matter what, syslog seemed to want to add it back (bastard)
[18:31:40] Beirdo: aww, no "setSingleShot()" for MythSignalingTimer
[18:31:49] Beirdo: fine, I'll rework it to not need it
[18:33:03] Beirdo: hmm, no isActive either
[18:33:14] Beirdo: I think I'll implement that in the timer class
[18:39:19] Beirdo: doing a test compile (with logserver converted to MythSignalingTimer)
[18:39:35] Beirdo: I guess I need to change the one in the logging thread for clients too (oops)
[18:40:15] dmfrey (dmfrey! has quit (Remote host closed the connection)
[18:40:43] Beirdo: Ummm
[18:40:54] Beirdo: how the heck do we have 1131 warnings now?!
[18:40:59] dmfrey (dmfrey! has joined #mythtv
[18:41:16] Beirdo: oh jeez.
[18:41:34] Beirdo: the hidden method warnings were off all that time in gcc and now are on.
[18:41:49] Beirdo: well, I guess we have some cleanup to do
[18:42:58] andreax (andreax! has quit (Read error: Connection reset by peer)
[18:45:29] stuartm: I'm still searching for an explanation for some of those, something I expect to do with implicit conversions although not ones I really understand
[18:46:57] stuartm: e.g. does "void ClassB::Something(int i);" really hide "void ClassA::Something(void);"? I say no, gcc/icc/clang say yes
[18:52:49] danielk22: Beirdo: valgrind doesn't like "if (m_logFile) free((void*)m_logFile)" as uninitialised value.
[18:53:21] Beirdo: hmmm
[18:53:36] Beirdo: K, I'll take another look at taht one :)
[18:53:44] danielk22: Beirdo: I can't really get things to run properly with the logging under valgrind.. but strangely enough it uses half as much memory under valgrind (just over 700 megs).
[18:53:53] Beirdo: pretty sure it's supposed to be set
[18:53:55] danielk22: logging.cpp:174
[18:54:13] danielk22: Beirdo: to null if nothing else I assume.
[18:54:31] Beirdo: yeah, that was my intention, may have missed a spot
[18:56:29] Beirdo: crap, I did miss that one
[18:56:37] danielk22: It also doesn't like logging.cpp:171
[18:56:51] danielk22: and logging.cpp:168
[18:57:20] Beirdo: table and appName?
[18:57:33] danielk22: yep
[18:58:05] danielk22: It looks like all three are not initialized in the ctor.
[18:58:24] Beirdo: yup, fixing that with the QTimer replacement :)
[18:58:25] Beirdo: thanks
[18:58:41] danielk22: np
[18:58:46] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:58:58] Beirdo: looks like I half-fixed the issue before :) missed 3 of em
[18:59:19] Beirdo: test compile... should be able to commit soon
[19:00:37] Beirdo: ooh that was pretty
[19:00:43] Beirdo: kaBOOM
[19:00:44] sphery: danielk22: + #7953
[19:00:44] ** MythLogBot **
[19:03:21] Beirdo: ohh, I see.
[19:04:59] Beirdo: OK, this MySQL timezone crap needs more explanation in the logs
[19:05:09] Beirdo: MySQL time zone support is missing. Please install it and try again.
[19:05:13] Beirdo: that is not sufficient
[19:05:58] superm1: Beirdo: in this case though, is there a delta to upstream? If not, would you be open to a distro using the one in distro rather than in tree when applicable?
[19:06:25] superm1: also based on our build failures around it, it looked like it was installing to a conflicting path /usr/lib/ or so
[19:06:37] Beirdo: there are deltas, I believe, and no, I would not be open to having random versions
[19:06:59] Beirdo: yeah, I need to fix the install to use DESTDIR, I think it is
[19:07:04] Beirdo: and/or sysroot
[19:07:14] Beirdo: we'll get there :)
[19:07:34] Beirdo: if we use random system libs, we end up with random support requests
[19:07:42] sphery: danielk22: btw, I think the 7%/14% was due to the 70/sec for the pulse rate--it used a busy loop for the last 1ms for each of those 70/sec, meaning busy loop for 0.07s/s = 7% CPU
[19:08:26] Beirdo: what EXACT mysql time zone support am I supposed to magically add, and how?
[19:08:52] Beirdo: we are obviously looking for something specific which is non-standard
[19:08:55] Beirdo: so...
[19:08:55] sphery: Beirdo: (and feel free to add to message)
[19:09:38] Beirdo: why don't we do that automatically?
[19:09:45] superm1: well i've no idea how stable or available or regularly released that package is. i'd of course prefer not to cause you guys a lot of support requests, but in general build dep on >= some stable version of the package with a stable cadence should yield less work than in tree I would tend to think
[19:09:50] sphery: Beirdo: need mysql root to install it
[19:10:55] Beirdo: ah
[19:11:01] Beirdo: we should add that URL to the logs
[19:11:10] Beirdo: or you WILL be hearing a lot of users asking
[19:11:21] sphery: agreed
[19:12:09] gigem: stuartm: While I conceptually know what read-write locks do, I don't have any experience with them, not even back in my embedded days. Consequently, I can't say right now how much sense it makes or hom much work it would be. I can say that currently the lock protects both the list itself and all of the list items. That might or might not fit well with a read-write lock.
[19:12:21] gigem: stuartm: Your queue lock change needs to also update the reschedWait.wait()s in Scheduler::run(). Since you'll be using m_queueLock instead of schedLock at that point, you'll need to unlcok schedLock around the waits.
[19:12:48] superm1: sphery: is there an easy non root user test to do to see it's enabled? another idea can be to add in init script prestart jobs a test to see if it's enabled and block backend start if not
[19:13:13] superm1: or even better, on debian/ubuntu systems use the debian-mysql package account user to add it (should be able to I believe)
[19:13:13] sphery: superm1: any user can test if it's enabled with: SELECT CONVERT_TZ('2012-06–07 12:00:00', 'GMT', 'America/New_York');
[19:13:20] superm1: awesome
[19:13:23] sphery: a NULL reply means no data is installed
[19:13:38] gigem: Beirdo or sphery: If you got better verbiage for the time zone error, feel free to add it. Personally, I think most of the help for that should be in the release notes.
[19:13:50] sphery: would be nice if the mysql packages were able to install the data
[19:14:16] Beirdo: gigem: I think if we just add one more line with the wiki URL, we will considerably reduce support load :)
[19:14:54] superm1: sphery: i checked with the maintainer and they were on board with that idea, but just need to work out the packaging details
[19:14:57] Beirdo: I do like the way you have it setup though. Shame it requires another tweak like that, but what can we do?
[19:15:24] gigem: sphery: I don't think it will make much difference as the bitching and moaning will be load regardless.
[19:15:47] sphery: I still don't know why a MySQL build doesn't at least generate the SQL ( mysql_tzinfo_to_sql /usr/share/zoneinfo > tzinfo.sql ) and then a mysql_install_db load it
[19:15:52] stuartm: gigem: there's not much work involved in switching to a read/write lock, and very little will actually change code which, there are read/write versions of QMutexLocker() and that's about all that needs changing, in most cases a QReadLocker() will be used with any methods which modify things getting a QWriteLocker() instead
[19:16:11] sphery: yeah, there will be many complaints about the hours lost when users look everywhere (except the logs) to find out why "MythTV 0.26 doesn't work"
[19:16:46] sphery: at least a link to the wiki page would reward those users who actually do look in the log
[19:19:48] stuartm: gigem: the wait()s don't need changing since HaveQueuedRequests()/HandleReschedule() both release the queue lock when they are done
[19:22:22] stuartm: we're still using schedLock in run() but whether it still needs to be unlocked at those points I don't know
[19:23:42] stuartm: I've been running with the patch for a few hours now and a couple hundred reschedules, several recordings (setup to test) and some livetv tests, so far it's worked perfectly
[19:24:44] gigem: stuartm: Oops on the waits. I was thinking it was closely tied to the schedLock. It happens when I try to do 5 things at the same time.
[19:26:10] stuartm: np, it had me scratching my head for a few minutes when I was writing the patch, I couldn't decide what was needed
[19:27:09] Beirdo: OK, pushed. I'm seeing some odd race conditions on startup of mythlogserver now that I didn't before, but I'll chase it down.
[19:27:10] stuartm: it can get a little hard to keep the order and relationship of locks/events straight in your mind
[19:27:34] Beirdo: yeah, that's what I'm seeing in the logserver too, I think :)
[19:27:39] Beirdo: locking issues.
[19:29:58] stuartm: I suspect that some other places could do with more granular locking rather than one single shared lock, or might even benefit from some refactoring so that can be lockless
[19:31:59] danielk22: Beirdo: When it doesn't start up do you get some verbiage about real-time signal 0 or somesuch? I've been getting that and mythfrontend failing to start in the last few days. Very random though and message isn't coming from mythtv logging as it's not timestamped.
[19:32:20] stuartm: figuring these out can induce headaches so I understand why it doesn't get done too often
[19:32:24] taylorr: stichnot: the only way to detect the aspect ratio change earlier is to check the frame right after it's released from the decoder instead of getting queued up for display
[19:32:34] Beirdo: no, it just seems to hang like it's deadlocked
[19:33:27] stuartm: stichnot: ^^ see, I was wrong, it had nothing to do with waiting a fixed number of frames
[19:34:37] taylorr: stichnot: probably best to check for aspect changes when the ffmpeg decoder releases the frame and then add an aspect ratio member to the AVFrame struct for when the frame is displayed
[19:34:52] gigem: stuartm: I'm not yet convinced the read-lock change is that simple. There needs to be a read-lock held whenever the scheduler traverses the list to make sure the iterators don't get invalidated. Whenever the scheduler needs to update any of the list items though, it needs to have a write-lock. Does QReadWRiteLock() upgrading read-locks to write-locks and vice versa? Also, holding a read-lock while
[19:34:54] gigem: traversing the list, might still dead-lock if one of the asynchronous events like UpdateRecStatus or a slave connecting/disconnecting and needs to grab a write-lock.
[19:35:52] taylorr: stichnot: it's been a while since I played around with the video buffers so I'm not sure the best place to add the detector... if you have issues I can help when I get some time
[19:37:40] stuartm: gigem: in those cases you'd obtain a single write lock rather than first getting a read lock then switching to a write lock
[19:38:06] danielk22: Beirdo: That's different from what I'm seeing.
[19:38:39] stuartm: gigem: yeah, it's not a complete solution to the deadlock issues, it should fix some of them though and leave us fewer to figure out
[19:39:32] stichnot: taylorr: stuartm: thanks. I'll look in that direction. Isn't AVFrame defined by ffmpeg? How do we usually deal with local changes to ffmpeg, to minimize resynching nightmares?
[19:39:36] stuartm: gigem: there may be a better solution entirely, I'm open to other ideas, the lock change just seemed like an easy place to start
[19:39:36] danielk22: stuartm: gigem: In general, R/W locks are for performance not for solving deadlock issues.
[19:40:44] stuartm: danielk22: right, although in this case it should help with performance and solve at least a couple of the potential deadlocks such as the one stichnot reported
[19:42:20] taylorr: stichnot: sorry, meant VideoFrame struct
[19:42:22] stuartm: tbh anything more would require a better knowledge of the scheduler and more interest than I can claim, I'd like to see these issues sorted but not devote a huge amount of time to working on it
[19:42:44] Beirdo: OK, I definitely am having locking issues
[19:42:49] Beirdo: sigh
[19:42:49] taylorr: stichnot: no changes to ffmpeg are necessary
[19:43:16] stichnot: taylorr: thanks, that's a relief :)
[19:43:17] Beirdo: let me go get coffee, and come back to pound this into submission
[19:44:44] stuartm: danielk22: performance not least because a scheduler lock held in a recorder thread or similar can block the main thread entirely until it's released which is not good even if it doesn't result in a deadlock as it will in at least two scenarios (one of which I've fixed)
[19:46:46] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[19:49:49] taylorr: stichnot: in avformatdecoder::ProcessVideoFrame shouldn't we already be setting the aspect in VideoFrame properly?
[19:58:36] stichnot: taylorr: it would seem so, unless there is some race between the decoder thread and the UI thread. I don't know the code well enough to say whether that's possible.
[19:59:24] taylorr: stichnot: no race condition would be possible, AFAIK
[20:00:22] Beirdo: hmm
[20:00:28] Beirdo: maybe a misdiagnosis
[20:00:53] Beirdo: I'm stuck in a QThread::wait on MythSignalingTimer::stop()
[20:02:43] Beirdo: OH JEEZ
[20:03:04] Beirdo: OK, I'm going to recode part of MythSignalingTimer
[20:03:15] Beirdo: it does usleep(totalsleeptime)
[20:03:22] Beirdo: I want a 5min timer
[20:03:47] Beirdo: so if I tell it to stop... it doesn't abort that timer, it will not return from stop() until 5 min passes
[20:03:50] Beirdo: not good
[20:04:33] Beirdo: that should use a QWaitCondition, not a usleep
[20:06:45] stichnot: taylorr: Thanks, I'll play with this some more. It's particularly challenging because there is something very broken with the cutlist editor seeking when you import the samples into MythVideo and run "mythcommflag --rebuild" on them.
[20:08:39] cattelan_away (cattelan_away! has quit (Ping timeout: 244 seconds)
[20:08:52] omaha (omaha! has joined #mythtv
[20:09:02] danielk22: Beirdo: That class was designed for 14 ms waits..
[20:09:32] omaha: does mythtv use tvtime
[20:09:34] omaha: ?
[20:09:36] Beirdo: well, if it should be a replacement for QTimer :)
[20:09:38] Beirdo: ..
[20:09:56] Beirdo: I'll pastebin my diff before pushing if you want.
[20:10:10] danielk22: no need, just make sure the UI still works :)
[20:10:43] Beirdo: hehe, OK, I'll make sure not to push until I get a chance to try it on the frontend to make sure I don't make a nasty regression :)
[20:15:56] Beirdo: ahhh, there we go
[20:16:24] Beirdo: the net result is: 5min wait on startup of mythbackend before the mythbackend's logs are seen
[20:16:54] Beirdo: so, yeah, definitely needs this tweak if I'm gonna use that class, which I think is the best plan
[20:17:15] Beirdo: now I can turn the debug spew back off
[20:18:12] Beirdo: oooh nice.
[20:18:26] Beirdo: QMutex::lock: mutex lock failure
[20:18:30] Beirdo: on shutdown
[20:18:53] danielk22: Beirdo: I've added a sample program to the Qt bug, but since it's closed I'm not sure if it will get any attention.
[20:19:18] Beirdo: Cool
[20:19:21] danielk22: Beirdo: That usually happens when a lock is touched after it's been deleted.
[20:19:22] stuartm: omaha: no, mythtv is a complete application it doesn't rely on other apps to do recording/playback
[20:19:23] Beirdo: hopefully they fix it
[20:19:36] Beirdo: #8 0x00007f8c1d9a594f in JobQueue::DoMetadataLookupThread (this=0xcf1320, jobID=10521) at jobqueue.cpp:2176
[20:19:36] ** MythLogBot **
[20:19:46] Beirdo: that's where it came from
[20:19:49] stuartm: apparently the new welcome message still gets ignored :(
[20:32:13] danielk22: Beirdo: I don't think the QTimer bug could be causing the CPU issue with a 1 or 5 second timer. It's pra fixed 1ms CPU usage per firing, so a 1 second time would cause 0.1% CPU usage.
[20:32:47] Beirdo: hmm
[20:33:03] Beirdo: well, fixing that anyways, there might be other idiocies in their code
[20:36:33] natanojl (natanojl! has joined #mythtv
[20:38:50] Beirdo: OK, now it just needs testing with the frontend
[20:39:33] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 246 seconds)
[20:46:30] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[20:51:19] danielk22: Beirdo: I don't know if Nokia is actively fixing bugs. QTBUG-5990 — the don't use QProcess bug — has been open since 2009 and has a 11 month old patch from Qt-Support that hasn't made it into trunk..
[20:53:04] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[20:54:23] Beirdo: yeah, sad
[20:56:19] danielk22: I wish there were a logical buyer for the Qt part of Nokia. I'm sure they would sell for cheap right now..
[20:56:57] Beirdo: Yeah, it's a fairly useful framework too. As long as MS doesn't buy it
[20:57:18] Beirdo: or Oracle. They already have enough crap
[21:14:41] danielk22: If I were to choose a suitor, it would be IBM. If SUSE were really independent I could see it as part of an expansion for them; they could become the premier KDE distro. But I don't see either of those happening. Probably there will be a slow decline followed by a fork when the KDE devs just can't take it anymore.
[21:20:36] pheld (pheld! has quit (Ping timeout: 272 seconds)
[21:24:29] Beirdo: jeez, someone posting to -contractors instead of making a bug report.
[21:24:33] pheld (pheld! has joined #mythtv
[21:24:35] Beirdo: THWACK
[21:32:18] Jordack (Jordack! has quit ()
[21:51:22] stichnot: danielk22: regarding icc "warning #913: invalid multibyte character sequence" warnings. These really should be single-byte characters for our purposes. Is it possible that the literals are being compiled as UTF-8, in which case they would turn into multibyte character sequences?
[21:52:15] stichnot: btw, what version of icc is being used?
[21:55:28] stuartm: . . . s/logs/stdio << Well this doesn't help, it's reporting the gcc version instead ;)
[21:57:12] stichnot: LANG=en_US.UTF-8 seems like an interesting clue
[21:58:33] Beirdo: heh
[21:58:46] Beirdo: yeah, there's currently no check for icc version :)
[22:12:24] stichnot: danielk22: I'd be interested to see the icc results if you set LANG=en_US or LANG=en_US.ISO-8859–15
[22:17:05] stichnot: I assume the UTF-8 check in mythcorecontext.cpp is more about reading and writing files, as opposed to building internal cc608/VBI tables which the slew of icc warnings is all about
[22:20:14] stichnot: or perhaps LANG=C
[22:22:34] natanojl (natanojl! has quit (Ping timeout: 276 seconds)
[22:22:54] amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv
[22:23:54] danielk22: stichnot: I tried LANG=en_US and LANG=C
[22:24:16] stichnot: with no change to those warnings?
[22:24:39] danielk22: icpc (ICC) 12.1.3 20120212
[22:24:46] danielk22: no change with those.
[22:25:28] danielk22: stichnot: I don't think icc is generating the wrong code. I think it's just warning us that some other compiler might.
[22:25:53] stichnot: Another suggestion I saw was "export LC_ALL=C" (in addition to LANG)
[22:26:15] danielk22: C++03 doesn't specify a character set for the source, so anything above 127 is potentially a problem.
[22:26:31] stichnot: If that is the case, I think we should disable the warning.
[22:27:20] danielk22: ok, that is my thinking too.
[22:27:51] stichnot: I think it would be hard to tell whether the myth build had the right code, unless you went to the trouble of faking a cc608 stream
[22:28:14] stichnot: actually, that WGBH test file would probably help
[22:29:20] danielk22: Just tried that, doesn't work either.
[22:30:36] danielk22: stichnot: Not needed, I can just replace one of the '' with the 0xXX equiv.. if it generates the same .o file...
[22:31:18] stichnot: Good point.
[22:31:25] danielk22: I'll have to turn off -g first, but that's no biggie.
[22:37:19] danielk22: grumble they differ
[22:37:52] danielk22: Anyway I should just be able to print out the arrays and diff that output..
[22:38:00] omaha (omaha! has left #mythtv ("Leaving")
[22:52:07] Slasher` (Slasher`!~Slasher@ has quit (*.net *.split)
[22:52:08] J-e-f-f-A (J-e-f-f-A! has quit (*.net *.split)
[22:52:08] ghoti (ghoti! has quit (*.net *.split)
[22:52:08] markcerv (markcerv! has quit (*.net *.split)
[22:52:08] highzeth (highzeth! has quit (*.net *.split)
[22:52:08] xavierh (xavierh! has quit (*.net *.split)
[22:52:16] markcerv (markcerv! has joined #mythtv
[22:52:23] ghoti (ghoti! has joined #mythtv
[22:52:23] xavierh (xavierh! has joined #mythtv
[22:52:30] highzeth (highzeth! has joined #mythtv
[22:52:39] Slasher` (Slasher`!~Slasher@ has joined #mythtv
[22:52:46] J-e-f-f-A (J-e-f-f-A! has joined #mythtv
[22:56:01] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:15:02] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[23:15:49] zombor_ (zombor_!~zombor_@ has joined #mythtv
[23:15:50] zombor_ (zombor_!~zombor_@ has quit (Changing host)
[23:15:50] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:19:19] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 245 seconds)
[23:22:21] zombor_ is now known as zombor
[23:25:44] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[23:32:44] cattelan_away (cattelan_away! has joined #mythtv
[23:40:32] amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv
[23:40:42] amejia (amejia!~andres@xbmc/staff/amejia) has quit (Read error: Connection reset by peer)
[23:51:09] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:52:32] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 250 seconds)
[23:55:54] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[23:58:29] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)

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