MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aarcane_, allesmueller_, aloril_, amessina, Anssi, Beirdo, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, eharris, ElmerFudd, fetzerch, ghoti, Gibby, gregL, GreyFoxx_, Guest72035, jams_, jarle, jarryd, jheizer, joe____, johanbr, joki, jpharvey, jst, jwhite, kc, knightr_, kurre2, kwmonroe, laga_, MaverickTech, moparisthebest_, mrand, MythLogBot, natanojl, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert, Seeker`, seld_, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, tafypz, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010, xris, _charly_
Friday, October 11th, 2013, 00:25 UTC
[00:25:48] jya: jpabq: no you can't... because it's used for AirPlay video.. Most videos sent by AirPlay will be HLS stream
[00:27:41] clever: i was looking at how my cable co pushes youtube videos to the cable box, for some reason, the cable box is hitting up an https server while streaming it
[00:27:47] clever: and the app name is in the domain name
[00:28:14] clever: its using upnp, and ignoring all of the standards
[00:29:11] jya: stuartm: I much prefer to use my table over my computer for casual web browsing, facebook or even small videos. I can be comfy wherever I am.. not even a laptop is that comfortable (and I have a very light 11' Macbook air)
[00:52:15] rsiebert_ (rsiebert_!~quassel@g225052165.adsl.alicedsl.de) has joined #mythtv
[00:55:23] rsiebert (rsiebert!~quassel@g225053096.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[01:37:56] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[01:55:10] dgeary2 (dgeary2!~debian@d110-33-96-225.mas800.nsw.optusnet.com.au) has joined #mythtv
[01:55:18] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[02:17:12] nyloc (nyloc!~quassel@p57B4F017.dip0.t-ipconnect.de) has joined #mythtv
[02:18:14] _nyloc_ (_nyloc_!~quassel@p3EE2CAB8.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[02:37:52] dgeary2 (dgeary2!~debian@d110-33-96-225.mas800.nsw.optusnet.com.au) has quit (Ping timeout: 248 seconds)
[02:44:16] rsiebert_ (rsiebert_!~quassel@g225052165.adsl.alicedsl.de) has quit (*.net *.split)
[02:44:16] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (*.net *.split)
[02:44:16] tonsofpcs (tonsofpcs!~tonsofpcs@rivendell/member/tonsofpcs) has quit (*.net *.split)
[02:44:17] jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has quit (*.net *.split)
[02:44:34] Seeker` (Seeker`!~cjo20@host86-164-181-164.range86-164.btcentralplus.com) has joined #mythtv
[02:44:39] jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has joined #mythtv
[02:45:04] Seeker` (Seeker`!~cjo20@host86-164-181-164.range86-164.btcentralplus.com) has quit (Changing host)
[02:45:05] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[02:45:23] rsiebert (rsiebert!~quassel@g225052165.adsl.alicedsl.de) has joined #mythtv
[02:46:51] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[02:47:38] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:49:32] tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has joined #mythtv
[02:59:08] joki (joki!~joki@p54862279.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)
[03:05:03] joki (joki!~joki@p54860F7E.dip0.t-ipconnect.de) has joined #mythtv
[03:30:11] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:34:23] danielk221 (danielk221!~danielk@exchange.wgen.net) has quit (*.net *.split)
[03:34:23] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (*.net *.split)
[03:34:23] kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has quit (*.net *.split)
[03:34:23] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (*.net *.split)
[03:34:39] kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has joined #mythtv
[03:34:49] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv
[03:35:39] jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has joined #mythtv
[03:35:46] jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has quit (Changing host)
[03:35:47] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[03:44:52] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[03:46:02] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:28:33] kc (kc!~Casper@unaffiliated/kc) has quit (Remote host closed the connection)
[04:30:15] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[04:42:55] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[05:34:58] clever (clever!~clever@nwcsnbsc00w-142167021018.dhcp-dynamic.FibreOp.nb.bellaliant.net) has quit (Quit: leaving)
[05:35:40] clever (clever!~clever@nwcsnbsc00w-142167021018.dhcp-dynamic.FibreOp.nb.bellaliant.net) has joined #mythtv
[05:52:54] Darkchaos (Darkchaos!~mephisto@i59F7A33C.versanet.de) has joined #mythtv
[06:03:08] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv
[06:12:59] nyloc (nyloc!~quassel@p57B4F017.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[06:13:11] nyloc (nyloc!~quassel@p5B26FF1F.dip0.t-ipconnect.de) has joined #mythtv
[06:34:13] _nyloc_ (_nyloc_!~quassel@p57B4F9E8.dip0.t-ipconnect.de) has joined #mythtv
[06:35:52] nyloc (nyloc!~quassel@p5B26FF1F.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[06:46:51] danielk22 (danielk22!~danielk22@96.57.9.142) has quit (Ping timeout: 248 seconds)
[06:54:51] danielk22 (danielk22!~danielk22@96.57.9.142) has joined #mythtv
[06:57:37] danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv
[07:12:29] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[07:13:41] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Client Quit)
[07:20:55] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 240 seconds)
[07:26:21] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[07:39:48] Darkchaos (Darkchaos!~mephisto@i59F7A33C.versanet.de) has quit (Ping timeout: 240 seconds)
[07:57:12] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 265 seconds)
[08:02:40] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[08:32:45] dgeary2 (dgeary2!~debian@pa49-187-89-24.pa.nsw.optusnet.com.au) has joined #mythtv
[08:43:38] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection)
[08:44:02] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[08:55:04] SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv
[08:58:10] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[09:38:01] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection)
[09:38:28] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[09:39:18] dgeary2 (dgeary2!~debian@pa49-187-89-24.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat)
[09:53:29] dekarl1 (dekarl1!~dekarl@p4FCEEA6F.dip0.t-ipconnect.de) has joined #mythtv
[09:55:07] dekarl (dekarl!~dekarl@p4FE84265.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds)
[10:18:05] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[10:34:28] nyloc (nyloc!~quassel@p3EE2CA55.dip0.t-ipconnect.de) has joined #mythtv
[10:35:10] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[10:36:02] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[10:37:30] _nyloc_ (_nyloc_!~quassel@p57B4F9E8.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[10:53:09] Steve-Goodey (Steve-Goodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv
[11:47:03] danielk22 (danielk22!~danielk22@96.57.9.142) has quit (Ping timeout: 272 seconds)
[12:00:22] danielk22 (danielk22!~danielk22@exchange.wgen.net) has joined #mythtv
[12:29:03] Steve-Goodey (Steve-Goodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!)
[12:41:57] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:20:26] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[13:31:52] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[13:31:52] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[13:31:52] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[13:33:06] danielk22 (danielk22!~danielk22@exchange.wgen.net) has quit (Ping timeout: 245 seconds)
[13:39:13] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:40:52] knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[13:43:31] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[13:55:07] _nyloc_ (_nyloc_!~quassel@p57B4F3D9.dip0.t-ipconnect.de) has joined #mythtv
[13:56:30] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:58:40] nyloc (nyloc!~quassel@p3EE2CA55.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[14:02:18] allesmueller_ (allesmueller_!~N@188-23-56-121.adsl.highway.telekom.at) has joined #mythtv
[14:03:25] Darkchaos (Darkchaos!~mephisto@i59F7A930.versanet.de) has joined #mythtv
[14:05:47] allesmueller__ (allesmueller__!~N@188-22-221-190.adsl.highway.telekom.at) has quit (Ping timeout: 248 seconds)
[15:00:57] Darkchaos (Darkchaos!~mephisto@i59F7A930.versanet.de) has quit (Ping timeout: 252 seconds)
[15:05:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[15:23:01] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[15:24:40] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Client Quit)
[15:38:28] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[15:48:19] stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv
[15:48:25] stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host)
[15:48:26] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:49:05] dblain (dblain!dblain@mythtv/developer/dblain) has joined #mythtv
[15:59:43] nyloc (nyloc!~quassel@p3EE2C43F.dip0.t-ipconnect.de) has joined #mythtv
[16:02:36] _nyloc__ (_nyloc__!~quassel@p57B4F2C7.dip0.t-ipconnect.de) has joined #mythtv
[16:02:52] _nyloc_ (_nyloc_!~quassel@p57B4F3D9.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[16:05:11] nyloc (nyloc!~quassel@p3EE2C43F.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[16:07:48] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[16:09:15] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[16:16:36] skd5aner: Hey folks, anyone around that might be able to help take a look at a gdb output and see if it yields any useful info? I don't really know how to interpret one...
[16:17:02] skd5aner: every few days, my frotnend tries to load the recoridngs list and it takes about a minute and then eventually says nothing is there...
[16:17:34] skd5aner: the notificaiton system will then periodically flop between the backend not being availalbe and then being available. When I go on to the server, mythbackend is running close to 100% on several of my cores
[16:17:50] skd5aner: the only thing that solves it is killing off the backend and restarting it
[16:18:24] skd5aner: so I attached gdb to it and got a backtrace – not sure if it provides useful info or not
[16:19:31] skd5aner: Here's the gdb output: http://pastebin.com/CMQBMV1a
[16:19:48] skd5aner: fyi – 0.27-fixes that is a few weeks old
[16:20:39] stuarta: so it sounds like it's deadlocking, from a quick look at the pastebin, that should have what we need to find it
[16:20:59] stuarta: but i'm have to run off home now, so i can't do any detailed analysis
[16:39:33] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[16:51:15] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[16:53:56] stichnot (stichnot!~stichnot@216.239.45.88) has joined #mythtv
[16:53:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:53:56] stichnot (stichnot!~stichnot@216.239.45.88) has quit (Changing host)
[17:07:30] stichnot: skd5aner: any chance your backend does a suspend/resume before one of these storms?
[17:16:11] doev (doev!~doev@p4FD423CA.dip0.t-ipconnect.de) has joined #mythtv
[17:17:51] stichnot: skd5aner: If this is the case, be sure you have this commit: http://code.mythtv.org/cgit/mythtv/commit/?id . . . 642a2c55c095
[17:18:49] skd5aner: stichnot: I do not have suspend turned on on my masterbackend – it's always-on
[17:23:26] stichnot: skd5aner: ok. I'm not sure this is limited to suspend/resume, so it's probably good to have that commit before going further.
[17:24:05] skd5aner: is there an easy way to see if that commit is part of the version I pulled from git?
[17:24:24] doev (doev!~doev@p4FD423CA.dip0.t-ipconnect.de) has quit (Quit: Verlassend)
[17:24:27] stichnot: In my case, often when my laptop would resume, the running mythbackend would get into that 100% CPU state (draining the battery, which was the first indication) and causing Watch Recordings etc. to fail.
[17:25:39] stichnot: mythfrontend --version should show something like v0.27-RC1-102-gcac6a3b for that commit, or later (the 102 or later is the key)
[17:28:20] skd5aner: ah, Well, I'm older than that
[17:28:27] skd5aner: I'll update and see
[17:31:12] rsiebert (rsiebert!~quassel@g225052165.adsl.alicedsl.de) has quit (Read error: Connection reset by peer)
[17:32:01] rsiebert (rsiebert!~quassel@g225052165.adsl.alicedsl.de) has joined #mythtv
[17:36:08] earthworm (earthworm!~biggaz@host-78-144-62-218.as13285.net) has joined #mythtv
[17:51:56] stuartm: well 102 is relative to the tag, in this case RC1 – 102 commits after RC1 was tagged, currently it should read v0.27–39
[17:52:18] stuartm: or 39 commits after the 0.27 (release) tag
[18:05:52] Darkchaos (Darkchaos!~mephisto@i59F7A930.versanet.de) has joined #mythtv
[18:07:02] SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!)
[18:07:29] skd5aner: v0.27-RC1-47-g783944e
[18:08:52] skd5aner: stuartm: anything obvious to your in that backtrace?
[18:08:57] skd5aner: s/your/you
[18:14:49] nyloc (nyloc!~quassel@p3EE2CD60.dip0.t-ipconnect.de) has joined #mythtv
[18:15:34] _nyloc__ (_nyloc__!~quassel@p57B4F2C7.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[18:18:05] _nyloc_ (_nyloc_!~quassel@p5B26F455.dip0.t-ipconnect.de) has joined #mythtv
[18:18:17] nyloc (nyloc!~quassel@p3EE2CD60.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[18:27:18] stuartm: there's a lock being held in thread 81, Scheduler::GetRecording() which looks suspicious
[18:27:51] stuartm: and again in the exact same place, but thread 77
[18:28:35] stuartm: and thread 74
[18:31:33] stuartm: and thread 24
[18:32:27] stuartm: thread 21 (Scheduler::Reschedule())
[18:34:12] natanojl: Those are all waiting on the scheduler lock held by thread 40
[18:34:21] stuartm: thread 18, thread 16, thread 14, thread 12, thread 10, thread 8, thread 6, thread 4
[18:35:06] stuartm: yup, there's no cap on the number of threads being started/queued to make the exact same query on the scheduler :/
[18:35:36] stuartm: which isn't directly the problem, but it's not pretty either
[18:36:35] stuartm: 11 threads (if I've counted correctly) all doing the same thing, 12 threads in total deadlocked by thread 40
[18:36:46] _nyloc_ (_nyloc_!~quassel@p5B26F455.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[18:37:36] nyloc (nyloc!~quassel@p5B26F377.dip0.t-ipconnect.de) has joined #mythtv
[18:38:15] stuartm: natanojl: sure about thread 40? not seeing it myself
[18:39:12] stuartm: 1ffe048 is the mutex lock, and it's only referenced from the threads I mentioned
[18:39:39] stuartm: although it doesn't appear that any of those threads are actually holding the lock, they are just waiting for it
[18:40:27] stuartm: ah ok, Scheduler::HandleIdleShutdown()
[18:40:43] natanojl: stuartm: scheduler.cpp:1823
[18:43:03] stuartm: natanojl: yeah I see it thanks
[18:43:26] stuartm: just need to figure out why thread 40 is stuck :)
[18:43:29] natanojl: stuartm: np
[18:44:03] stuartm: could it ironically be because we've run out of thread pool threads to handle the request?
[18:53:12] stuartm: one thing is definitely clear from that backtrace – if we're already handling a request from a frontend or slave then we should just ignore duplicates, utterly pointless to queue them up or spawn endless threads to handle them all
[18:53:31] stuartm: skd5aner: can you describe your setup, any slaves?
[18:54:32] stuartm: is there a backend log to go with the backtrace?
[18:56:08] natanojl: It could perhaps have been interesting to see if thread 40 was actually stuck in MythSocket::ReadStringList or not because I don't see a corresponding thread with MythSocket::ReadStringListReal being called
[19:02:09] Darkchaos (Darkchaos!~mephisto@i59F7A930.versanet.de) has quit (Ping timeout: 272 seconds)
[19:03:37] _nyloc_ (_nyloc_!~quassel@p3EE2DDEF.dip0.t-ipconnect.de) has joined #mythtv
[19:05:03] stuartm: there isn't one, and that's the problem, ReadStringList() is calling InvokeMethod with BlockingQueuedConnection but the thread it's trying to use is 'this'
[19:05:25] stuartm: which is a straightforward deadlock
[19:05:44] stuartm: it's asking to send an event to 'this' thread and block until it happens
[19:06:04] stuartm: QT docs even warn about that – "If type is Qt::BlockingQueuedConnection, the method will be invoked in the same way as for Qt::QueuedConnection, except that the current thread will block until the event is delivered. Using this connection type to communicate between objects in the same thread will lead to deadlocks."
[19:06:09] stuartm: so it's programmer error
[19:06:48] nyloc (nyloc!~quassel@p5B26F377.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[19:07:15] stuartm: jya added that code, and we even discussed it at length several weeks ago after it caused other bugs, but I never noticed the logical flaw until now
[19:08:51] stuartm: hmm, maybe not the same code after all, looks like that was last modified exactly one year ago today by Daniel
[19:10:25] stuartm: natanojl, care to sanity check that for me? that construct is so widely used that I'm wondering if I've misunderstood it
[19:10:45] stuartm: danielk221: ^^
[19:12:02] stuartm: guess the issue is that QThread::currentThread() != m_thread->qthread() somehow returns false, which should be impossible
[19:19:30] natanojl: stuartm: I don't see why that should be impossible
[19:20:13] stuartm: err, yeah ignore that last part
[19:24:43] stuartm: point being that ReadStringList() isn't called from m_thread for ReadWriteStringList(), so it should be the same thread and use a DirectConnection, but instead it's using a BlockingConnection
[19:25:31] natanojl: my guess was that the event hadn't reach the socket's thread yet and therefore didn't show up in the backtrace
[19:25:51] stuartm: or the other way around
[19:28:33] stuartm: natanojl: nah, it's deadlocked there I'm sure of it and there seems to be something fishy in that usage of InvokeMethod but perhaps because it's a Friday night I'm not able to put all the pieces of the puzzle together :)
[19:29:42] natanojl: neither am I :)
[19:30:30] ** natanojl blames the cold he's recovering from **
[19:30:41] skd5aner: stuartm: dedicated mbe, and a combined sbe/mfe
[19:31:17] skd5aner: stuartm: there maybe a log that was running without any verbosity, but this is so so random, sometimes it happens once a day, sometimes once every 3–5 weeks
[19:32:05] stuartm: we'd only want to use a BlockingQueuedConnection if ReadStringList() is called from a different thread ... but it seems to do the exact opposite, use a DirectConnection if we're calling it from another thread ... but if that's the case why isn't the backend deadlocking constantly?
[19:32:11] skd5aner: the gdb was from the mbe
[19:33:24] stuartm: again, ignore everything I just said – getting myself tied up in knots
[19:33:55] natanojl: stuartm: ok :)
[19:34:27] stuartm: the first part is true, " we'd only want to use a BlockingQueuedConnection if ReadStringList() is called from a different thread"
[19:34:37] skd5aner: stuartm: want my backend log?
[19:35:06] stuartm: skd5aner: no, that's ok, know where it's going wrong now, just not the why
[19:35:40] skd5aner: stuartm: :)
[19:35:54] skd5aner: stuartm: doesn't appear to be much in the logs anyway...
[19:36:48] skd5aner: lots of stuff like this though:
[19:36:48] skd5aner: 2013-10–11 10:54:29.379753 I [2157/2228] MythSocketThread(90) mainserver.cpp:434 (readyRead) – readyRead ignoring, expecting reply
[19:37:00] natanojl: wagnerrp: Thanks for the credit :)
[19:38:32] stuartm: skd5aner: ok thanks, that may be relevant after all :)
[19:40:01] stuartm: the reason I asked about a slave in the first place was because I know there is an outsstanding issue with slaves using the wrong sockets – sending control stuff on the event socket which causes real problems
[19:42:05] stuartm: I actually committed some fixes for the symptoms to master, but seems I may not have backported them
[19:42:18] stuartm: skd5aner: this is with 0.27 correct?
[19:46:03] skd5aner: yes... althought they are on slightly different revisions of 0.27-fixes
[19:46:31] stuartm: skd5aner: I've just backported my fixes from master, they may help
[19:46:58] skd5aner: mbe = v0.27-RC1-47-g783944e sbe/fe = v0.27-RC1-87-g5dfd171
[19:47:23] skd5aner: stuartm: I'll go update now... unfortunately, I can't replicate this on demand :(
[19:47:26] stuartm: those are pretty old, both well before the 0.27 release
[19:47:55] skd5aner: well before? I thought I updated a few days after release at least on the frontend machine
[19:49:17] stuartm: well the mbe at least is 'well before', the sbe/fe is still RC1
[19:49:40] skd5aner: np, I'll update now
[19:49:49] skd5aner: I guess I'll keep you posted if it happens again
[19:50:11] skd5aner: would you prefer that I launch mbe with any --verbose logging options?
[19:50:15] stuartm: looks like 12th Sept – release was on 17th/18th
[19:50:43] stuartm: skd5aner: no need, one of the fixes includes the logging we'd need at the default verbosity
[19:50:51] skd5aner: cool
[19:51:09] stuartm: "Programmer Error! SendReceiveStringList(%1) used on socket with callbacks enabled."
[19:51:25] stuartm: if you see that, then we know there's a problem :)
[19:52:03] stuartm: and I expect that you will see it (assuming the deadlocks continue to occur)
[19:52:58] skd5aner: Hey – random newb question here...
[19:53:41] skd5aner: I typically take the "safe" route and do a make clean && make distclean before doing a git pull and recompiling/installing
[19:53:44] skd5aner: is that necessary?
[19:59:45] stuartm: generally no, it's not necessary but if it's been a while since you last compiled then a make clean is sometimes recommended
[20:00:27] stuartm: and a distclean if it's been a really long time, or there has been an API change (rare on the stable branch)
[20:00:49] skd5aner: cool – thought so... thanks
[20:00:49] stuartm: skd5aner: if you haven't already got it installed, then get ccache
[20:00:56] skd5aner: yup, it's installed :)
[20:02:46] stuartm: if you really want to save time, then it's almost never necessary to clean/distclean ffmpeg – so you can specify targets to be 'cleaned' with -C e.g. make -C libs/ clean
[20:03:27] stuartm: unfortunately you can't stack arguments so "make -C libs/ -C programs/ clean" produces an error
[20:03:57] stuartm: by not rebuilding ffmpeg, even with ccache, you'll cut the compile time by at least half, propbably more
[20:03:58] stoffel (stoffel!~quassel@pD9E41480.dip0.t-ipconnect.de) has joined #mythtv
[20:04:02] skd5aner: nah, my time isn't /that/ valuable – although if I was actually developing and making frequent changes, I could see where that'd be valuable :)
[20:08:16] skd5aner: stuartm: ok, updated... I'll keep you posted and let you know if it continues to happen
[20:13:07] skd5aner: thanks again for taking a look ;)
[20:18:18] stuartm: believe it or not all I succeeded in doing was confusing myself, coming to a bunch of ultimately wrong conclusions, all the time forgetting that I'd already looked at and fixed this issue just 3 weeks ago :)
[20:20:18] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection)
[20:20:49] peper03: Just a random question seeing the various recommendations to use ccache – What build times are people experiencing in general for a completely clean build? A complete build after distclean takes abour 4 minutes here.
[20:21:18] stuartm: peper03: with or without ccache?
[20:21:28] peper03: stuartm: Without
[20:22:16] stuartm: wow, that's impressive, at least for someone like me who is stuck on an older AMD 2.5Ghz dual core
[20:22:42] peper03: Hardly seems worth adding another layer of something that could possibly go awry.
[20:23:37] stuartm: cache vary rarely goes awry, although it has been known to happen
[20:24:08] stuartm: it would probably knock your compile times down to 30 seconds though
[20:25:38] peper03: My old Core II Duo motherboard/processor went into my production box and I upgraded to an i7–2600 running at 3.4 GHz. Quad-core with hyper-threading certainly doesn't hurt, but adding more RAM really helped.
[20:26:41] peper03: Hardly seems worth it (ccache). Usually I just rebuild libs or even libs/libmythtv. Takes something like four seconds.
[20:28:25] peper03: I originally had 4GB RAM but added another 8GB, which mostly gets used as disk cache/buffer, but you really notice it when the HDD LED barely flickers (once everything has been read at least once, obviously). No SSD here yet.
[20:41:09] stichnot: peper03: A clean build (after ccache -C, using make -j8) takes me just under 5 minutes. I probably have the same processor as you. I have an SSD, but with 4GB RAM there is no difference between build times using an SSD and not.
[20:43:29] stichnot: 54s when repeating the build with a warmed-up ccache
[20:44:13] peper03: stichnot: Yeah, I would expect an SSD to negate any disk cache held in RAM to large extent. I use -j14 (someone, somewhere mentioned that and I just went with it and even then there's a bit of wiggle in the CPU load).
[20:46:08] dekarl1: wrt lost audio after transode, I see writing video frames and collecting the timecode in three places, should the offset be only applied in two or in all three places? http://code.mythtv.org/trac/ticket/11639#comment:21
[20:46:12] dekarl1 is now known as dekarl
[20:46:21] jams_ (jams_!~jams@CPE-72-131-4-141.wi.res.rr.com) has joined #mythtv
[20:50:03] jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has quit (Ping timeout: 248 seconds)
[20:51:36] nyloc (nyloc!~quassel@p3EE2DC12.dip0.t-ipconnect.de) has joined #mythtv
[20:53:56] _nyloc_ (_nyloc_!~quassel@p3EE2DDEF.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[20:55:15] stoffel (stoffel!~quassel@pD9E41480.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[20:57:49] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[21:04:48] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:08:53] tafypz (tafypz!~quassel@pool-71-125-44-123.nycmny.fios.verizon.net) has joined #mythtv
[21:10:14] tstorm (tstorm!~tstorm@50-76-62-217-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[21:11:04] tafypz: Hi, I created a ticket (http://code.mythtv.org/trac/ticket/11905) and provided a patch along with it
[21:11:49] tafypz: while using the services api on 0.27 and trying to get artwork for a recording with a '&' in the name
[21:12:54] tafypz: the current httprequest would attempt to decode the entire set of parameters in one shot before passing it to the GetParameters which handles parameters one by one
[21:13:24] tafypz: by doing so an extra parameter is created because of the '&' in the title
[21:13:42] tafypz: and therefore the services api fails to return the artwork
[21:15:13] tafypz: the patch removes the fromPercentEncoding on the entire parameter substring and let GetParameters do its work (which calls fromPercentEncoding on the name / value pair)
[22:19:28] jpabq: skd5aner: Well, it finally happened to me. I just noticed that last nights recording the the football game wont play with mythfrontend/mythavtest. When I play it with mplayer, I notice that there are a couple of seconds of "silence" at the beggining, and the video shows that it was still in the procdess of locking on the new channel.
[22:21:18] jpabq: I am wondering if myth has a problem because it trying to use the audio as the 'master' for a/v sync, and there is no audio encoded into the beginning of that file?
[22:24:50] tstorm (tstorm!~tstorm@50-76-62-217-ip-static.hfc.comcastbusiness.net) has quit (Ping timeout: 264 seconds)
[22:49:46] tonsofpcs: tafypz: & ?
[22:55:31] tafypz: tonsofpcs
[22:55:51] tafypz: it takes this and makes an extra parameter
[22:57:04] tafypz: tonsofpcs: if you send this /Content/GetImageFile?StorageGroup=Coverart&FileName=Eastbound%26+Down+Seaso n+4_coverart.jpg
[22:57:25] tonsofpcs: tafypz: even if you escape it as & or %26 ?
[22:57:54] tafypz: yes
[22:58:07] tafypz: here is what happens:
[22:58:30] tafypz: the query I pasted is received by the backend
[22:58:58] tafypz: then it takes the parameter part (after "?")
[22:59:07] tafypz: and does a decoding of the entire string
[22:59:14] tafypz: so you get StorageGroup=Coverart&FileName=Eastbound&+Down+Season+4_coverart.jpg
[22:59:43] tafypz: then it passes that to the GetParameters method
[22:59:59] tafypz: which takes the + and replace them by " "
[23:00:12] tafypz: then it splits it by &
[23:00:41] tafypz: so you get the parameters value pairs StorageGroup=Coverart
[23:00:50] tafypz: FileName=Eastbound
[23:01:28] tafypz: instead of FileName=Eastbound& Down Season 4_coverart.jpg
[23:02:06] tafypz: GetParameters does the also the decoding on the name value pairs
[23:02:27] tonsofpcs: sounds like the decoding shouldn't happen until after the split... I'm not sure what the exact standard is on 'how' to do this but I'm sure there's at least one RFC about it.
[23:04:24] tafypz: tonsofpcs: indeed the problem is because of that initial decoding just removing it make everything work properly
[23:05:07] tafypz: also parameter names and values get decoded too (in the original code)
[23:06:18] tafypz: so the patch was literally just removing the call to QUrl fromPercentEncoding
[23:07:08] tafypz: I have been running the patch on my system for the past few days without issues...
[23:07:22] tafypz: I use mainly the services api....
[23:12:38] tafypz: I provided the patch based off the 0.27 codebase, hopefully this would be accepted as I am sure that I am not the only one with the issue...
[23:13:20] tonsofpcs: tafypz: seems reasonable.
[23:13:29] ** tonsofpcs isn't really a dev, just sits here to make the devs sound smarter :) **
[23:14:02] tafypz: :D
[23:17:05] tafypz (tafypz!~quassel@pool-71-125-44-123.nycmny.fios.verizon.net) has quit (Remote host closed the connection)
[23:17:23] tafypz (tafypz!~quassel@pool-71-125-44-123.nycmny.fios.verizon.net) has joined #mythtv
[23:17:46] tafypz (tafypz!~quassel@pool-71-125-44-123.nycmny.fios.verizon.net) has quit (Client Quit)
[23:18:04] tafypz (tafypz!~quassel@pool-71-125-44-123.nycmny.fios.verizon.net) has joined #mythtv
[23:25:08] stichnot: gigem_: just read your mythtv-users post. I do wish we would capture a user-unfriendly recorder ID as a column in the recorded table as an aid in tracking down a possibly flaky recorder.
[23:32:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[23:36:05] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Quit: warped_)
[23:38:39] stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv
[23:38:40] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:38:40] stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host)
[23:44:21] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[23:57:41] earthworm (earthworm!~biggaz@host-78-144-62-218.as13285.net) has quit (Ping timeout: 245 seconds)

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