:: #mythtv

Daily chat history

Current users (87):

aca_, aloril, amessina, Anssi, Beirdo_, bobweaver, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk22, danielk222, dblain, dekarl1, ElmerFudd, ephemer0l, fetzerch, foobum, foxbuntu, gary_buhrmaster, ghoti, Gibby, gigem, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jhall_, jheizer, joe__, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, jya_, knightr_, kormoc, krumer, KungFuJesus, kurre2, kwmonroe, laga, MavT, Merlin83b, moparisthebest, mrand1, MythBuild, MythLogBot, neufeld, nutron, nyloc, poptix, purserj, rhpot1991, roxlu, rsiebert_, Seeker`, seld, Sharky112065, skd5aner, skidaddle, sl1ce, SmallR2002, sp00ge, sphery, sraue, stichnot, stuartm, superm1, tafy, taylorr, tgm4883, toeb, tonsofpcs, wagnerrp, wahrhaft, wolfgang2, XDS2010, xris, _charly_
Monday, June 3rd, 2013, 00:18 UTC
[00:18:45] gregL (gregL! has quit (Ping timeout: 248 seconds)
[00:25:56] ephemer0l (ephemer0l!~ephemer0l@unaffiliated/ephemer0l) has joined #mythtv
[00:35:16] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[00:36:18] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:42:44] jya_: the popup in mythfrontend telling you that it couldn't connect to the backend is a tad too insistent.. it keeps popping up over and over.. preventing you to fix whatever would be necessary to fix it
[01:58:27] wagnerrp: weee... unintended recursion
[02:06:39] jya_: i think the issue is also in 0.26
[02:22:39] nyloc (nyloc! has joined #mythtv
[02:26:39] _nyloc_ (_nyloc_! has quit (Ping timeout: 256 seconds)
[03:04:55] jya_: when you create a timer and then call killTimer() before the event got fired, it still calls the event ??
[03:06:09] cesman (cesman! has joined #mythtv
[03:06:09] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[03:06:09] cesman (cesman! has quit (Changing host)
[03:06:12] wagnerrp: QTimer.stop() should stop it from firing
[03:07:26] jya_: I don't use QTimer
[03:07:47] jya_: I thought I would do it the easy way and use the simpler timerEvent found in all QObject
[03:09:21] jya_: i call killTimer(time rid) and still a few seconds later the timerEvent is triggered..
[03:12:13] jya_: I guess I can simply check if the timer id I saved is now 0… still surprising it would trigger the event
[03:21:05] joki (joki! has quit (Ping timeout: 248 seconds)
[03:28:05] joki (joki! has joined #mythtv
[03:34:11] gregL (gregL! has joined #mythtv
[03:36:24] stichnot (stichnot! has joined #mythtv
[03:36:25] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:36:25] stichnot (stichnot! has quit (Changing host)
[03:43:26] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 256 seconds)
[03:44:31] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:58:58] jya_: danielk22: I get lots of crash in TVRec::FinishedRecording when exiting liveTV. Always related to the LiveTVChainEntry list crashing when trying to get the begin() iterator
[06:05:23] len (len! has quit (Remote host closed the connection)
[06:25:52] FabriceMG (FabriceMG! has joined #mythtv
[07:05:00] SteveGoodey (SteveGoodey! has joined #mythtv
[07:25:50] nutron (nutron!~nutron@unaffiliated/nutron) has joined #mythtv
[07:36:01] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7ce4:d94e:24d7:3e58) has joined #mythtv
[07:47:07] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Read error: Connection reset by peer)
[09:08:03] stuartm: jya_: getting it, or using it? Former would be very strange
[09:08:39] jya_: stuartm: sorry , I don't follow
[09:08:50] jya_: ah.. I see.
[09:08:52] jya_: getting it
[09:11:09] stuartm: interesting ...
[09:11:55] jya_: my guess is a racing condition somewhere, the default destructeur of the qt container it's linked to having been destroyed
[09:12:25] jya_: it crashes in the for (it = blah.begin(); …)
[09:14:16] stuartm: yeah, it'll be something like that, or more unlikely some consistent memory corruption/overwriting of that container
[09:14:19] jya_: stuartm: if you inclined: was playing with liveTV I got some fancy deadlock there:
[09:14:54] jya_: I ended up with like 12 threads out of 34 in a wait() condition
[09:14:59] stuartm: jya_: I'm not doing anything better atm, so I'll take a look :)
[09:15:34] stuartm: jya_: are you running latest master? I committed a fix yesterday which will probably make some of those threads disappear
[09:16:00] jya_: stuartm: I updated earlier yesterday
[09:16:19] jya_: all the threads seem valid
[09:16:54] jya_: the condition I have above is when changing channels fail. It tries to restore the previous channel which itself fail
[09:17:14] jya_: so mythfrontend goes back with a buffer error
[09:17:29] jya_: and mythbackend has a few IO thread, write thread all waiting for one another
[09:18:10] jya_: I guess most will never see this condition. But the HLS recorder taking such a long time changing channels clearly reveal that something is broken in that picture
[09:18:23] stuartm: yeah, bt doesn't look like the ones I was getting
[09:18:46] jya_: yeah.. no 700 threads :)
[09:22:20] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[09:26:05] stuartm: nice tangle you've got there
[09:37:45] stuartm: ok, so you've got three threads waiting on sockListLock in MainServer ... two read, one write ... and a fourth thread (40) which is holding that lock
[09:38:23] stuartm: thread 40 is waiting for the encoder to change state from kState_ChangingState
[09:39:02] stuartm: tbh, we probably shouldn't be holding sockListLock which we're waiting there, it completely locks up the backend
[09:40:25] stuartm: this isn't the root cause of the issue fwiw, it's just a problem in it's own right, we're holding a broad lock in loop with no timeout and a 500ms sleep
[09:41:26] stuartm: er 500µs
[09:53:13] stuartm: jya_: do you have the backend log from just before the deadlock?
[09:53:32] jya_: stuartm: I should yes…
[09:53:38] jya_: now finding it is another matter :)
[09:54:47] jya_: i have an idea on how to get around the problem though… trying to delete a HLS ring buffer can take a while because it has to wait for whatever segment is currently downloading to end… the maximum tuning timeout is 65s ; which is what I usually get over
[09:57:17] jya_: i could always commit my changes for you to try to reproduce it
[09:57:46] jya_: added the backend log
[09:58:02] jya_: thanks Xcode for keeping traces of every single session for the day!
[10:05:27] jya_: to make an object inherit from a QObject, isn't it simply a matter of adding the Q_OBJECT macro in the class definition? the moc_ of my file isn't created for some reason
[10:06:01] stuartm: ok ... that's the third thread stopped on a LOG macro in TVRec, which can't be a coincidence
[10:07:19] jya_: i thought so too… but the backtrace seems a tad screwy there too
[10:07:44] jya_: i run it with --nodblog if that makes a difference
[10:09:58] stuartm: well it could be screwy, but the logging thread could also be deadlocked (although it doesn't appear to be)
[10:12:39] jya_: i doubt the logging was off, because i could see the logging continuing in the console
[10:15:41] stuarta (stuarta! has joined #mythtv
[10:15:41] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[10:15:41] stuarta (stuarta! has quit (Changing host)
[10:23:34] stuartm: anyway to recap, four threads (the entire socket/protocol handling) are deadlocked waiting for the encoder to change state, the recorder is in the process of changing the state but the last few steps in thread 13 make no sense at all
[10:26:59] stuartm: TVRec::HandleStateChange() >> TVRec::run() >> TVRec::TuningOnSameMultiplex() >> TVRec::~TVRec() is just nonsense
[10:27:39] jya_: yes I saw that… the destructor calling the constructor
[10:29:01] jya_: ah… just happened to me again.
[10:29:02] stuartm: some of the line numbers given for TVRec don't seem to make sense against master, so I think gdb got very confused
[10:31:15] stuartm: we can prevent the entire backend from becoming non-responsive by not holding the socklistlock while waiting for the encoder state to change, but I cannot determine from that backtrace what's going wrong with the recorder, the root cause
[10:31:26] MythBuild (MythBuild! has quit (Remote host closed the connection)
[10:31:53] MythBuild (MythBuild! has joined #mythtv
[10:32:39] stuarta: killed off the ppc builder and the debian squeeze builder
[10:32:48] stuarta: ppc hasn't worked for months
[10:39:49] stuarta: squeeze is now old stable as wheezy has been released
[10:43:59] stuartm: stuarta: cool
[10:45:49] wagnerrp: jya: IIRC, there should be two running
[10:45:54] wagnerrp: one handles input, one handles output
[10:47:29] stuartm: danielk222: do you know if socklistlock in MainServer is supposed to be protecting sockets as well as the lists, or is it just the lists?
[10:48:14] wagnerrp: protecting sockets from multiple simultaneous uses?
[10:48:27] wagnerrp: the sockets should be doing that themselves
[10:49:34] wagnerrp: i believe SendReceiveStringList locks out access to the socket until it receives a response from the first query
[10:51:51] stuarta: stuartm: i promise i'll get around to adding coverity at some point
[11:03:47] stuartm: wagnerrp: in this case I meant the MythSocket objects rather than the underlying sockets
[11:05:11] stuartm: stuarta: np, I've got a couple of tips/script I can share now – I'll pastebin those later, I'm AFK for an hour or two
[11:09:00] SteveGoodey (SteveGoodey! has joined #mythtv
[11:09:08] wagnerrp: stuartm: the underlying socket is actually a PlaybackSocket, which encapsulates MythSocket
[11:11:09] SteveGoodey (SteveGoodey! has quit (Client Quit)
[11:17:00] stuarta: stuartm: no worries. i'm pretty busy here myself
[11:59:58] jya_: little Qt question… I have a class, I made it inherit from QObject… I call deleteLater() on it… but the object is never deleted… I'm certain event loopa are running (though maybe in a different thread)… So.. in short.. why is my object never deleted?
[12:00:08] jya_: destructor is never called
[12:00:54] IReboot (IReboot! has joined #mythtv
[12:02:10] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 245 seconds)
[12:26:26] jya_: looks like the qt event loop isn't running, which would explain
[12:26:40] danielk222: jya_: deleteLater() only works for objects created in a Qt event thread with a running event loop.
[12:27:17] jya_: isn't MThrea a Qt thread? isn't the event loop running then?
[12:30:38] jya_: I was hoping to use deleteLater() in place of delete in the iptvchannel ; so changing channel wouldn't have to wait for the full delete to complete...
[12:30:45] jya_: oh well….
[12:34:23] jya_: danielk222: do you have 5 minutes to review my change?
[12:36:07] jya_:
[12:43:25] jya_: i implemented option #2 i was referring earlier this morning
[12:43:25] ** MythLogBot **
[13:00:46] SteveGoodey (SteveGoodey! has joined #mythtv
[13:06:35] jya_: oh well, I'm pushing it now… can review it later.. works very well at present…
[13:09:31] Jordack (Jordack! has joined #mythtv
[13:37:38] FastZ (FastZ!~FastZ@ has joined #mythtv
[13:49:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[14:23:45] FastZ (FastZ!~FastZ@ has left #mythtv ()
[14:44:43] danielk222: jya_: A QThread only has the event loop running if you use the default run() or call exec(), MThread has the same API.
[14:45:44] jya_: well, something is dodgy then, cause my stream handler never got deleteLater() but then I saw that streambase calls quit(0) or exit(0)
[14:57:10] FabriceMG (FabriceMG! has quit (Ping timeout: 245 seconds)
[14:58:17] FabriceMG (FabriceMG! has joined #mythtv
[15:02:21] FabriceMG (FabriceMG! has quit (Client Quit)
[15:03:15] jya_: Captain_Murdoch: what's the --hlsstreamid option for ?
[15:09:08] jarle (jarle! has quit (Quit: Leaving)
[15:12:57] jarle (jarle! has joined #mythtv
[15:17:55] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection)
[15:49:00] Captain_Murdoch: jya_, currently we track HLS streams in the database. that will probably go away with the on-demand HLS encoding I've been working on for what seems like eons. haven't had much time at all lately unfortunately.
[15:49:27] jya_: yes, I figured that one in the end
[15:49:48] jya_: do you need libx264 to encode an hls stream?
[15:49:54] Captain_Murdoch: yes.
[15:50:19] jya_: i get a failure on avcodec_find_encoder_by_name with libx264 being the parameter… not sure why
[15:50:37] jya_: fairly certain my version of myth was compiled with it
[15:52:39] Captain_Murdoch: external/FFmpeg/libavcodec/libx264.c is where that name is defined, is libx264.c being compiled in?
[15:53:41] jya_: ah no it wasn't… CONFIG_LIBX264 is 0 in config.h
[15:54:13] stichnot (stichnot!~stichnot@ has joined #mythtv
[15:54:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:54:14] stichnot (stichnot!~stichnot@ has quit (Changing host)
[15:54:31] jya_: oh well, back to recompiling the whole thing
[15:57:23] jya_: the HLS encoder seems to be broken at present following ffmpeg resync. the move from S16 to float audio samples made the argument provided to the encoder incorrect… looking into it
[15:58:28] seld (seld! has quit (Ping timeout: 245 seconds)
[15:59:24] seld (seld! has joined #mythtv
[16:08:51] rsiebert_ (rsiebert_! has joined #mythtv
[16:12:00] rsiebert (rsiebert! has quit (Ping timeout: 256 seconds)
[16:13:05] jya_: Captain_Murdoch: what are the different possibilities for encoding audio?
[16:13:16] jya_: mp3lame and which other one ?
[16:19:52] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:19:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:19:53] stichnot (stichnot!~stichnot@ has quit (Changing host)
[16:32:05] dekarl: jya_: libfaac and the ffmpeg aac encoder?
[16:32:24] jya_: yep...
[16:44:36] dekarl: jya_, is #11497 (yet another instance of AC3 encoder now returns/expects planar audio – fltp instead of s16) something for you? (warpme asked on the dev list but was a bit vague in his mail)
[16:44:36] ** MythLogBot **
[16:45:08] dekarl: nvm, I'm just seeing your updates to the ticket
[16:46:25] dekarl: btw, now that git is local again, can we reenable the timeline? (maybe just turn off commits if its to much load, but I like it to take a quick look at updated tickets)
[16:47:02] dekarl: ^- thinking of the trac timeline
[16:47:57] Captain_Murdoch: dekarl, libfaac is preferred. The maintainer of the ffmpeg aac encoder asked that I not use that by default/recommendation since it is still marked experimental.
[16:48:41] Captain_Murdoch: we can fall back to using built-in aac encoder, but libfaac is preferred
[16:52:44] peper03 (peper03! has joined #mythtv
[16:54:00] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7ce4:d94e:24d7:3e58) has quit (Read error: Connection reset by peer)
[17:00:31] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[17:11:46] roxlu (roxlu! has joined #mythtv
[17:11:48] roxlu: hey!
[17:12:15] roxlu: great to see there is such an active community
[17:14:05] roxlu: I was looking into VDPAU and found some post which lead me to mythtv. It seems that mythtv uses this and I was wondering if someone in here knows a bit about it?
[17:43:08] stuartm: roxlu: can you be more specific?
[17:44:04] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:44:58] roxlu: Basically I'm at the point where I just found out about the existence of VDPAU
[17:45:14] roxlu: and I want to find out how I can use it to decode a h264 stream
[17:45:27] roxlu: and use the decoded buffer as a openGL texture
[18:12:10] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Operation timed out)
[18:29:02] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:29:28] moparisthebest_ is now known as moparisthebest
[18:35:43] Lomion0815 (Lomion0815! has joined #mythtv
[18:40:44] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 252 seconds)
[18:53:06] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:58:00] dekarl1 (dekarl1! has joined #mythtv
[18:58:32] stuartm: danielk222, or anyone else, do you mind signing off on this patch? It limits the scope of the locking in MainServer::connectionClosed() so that we shouldn't deadlock (or delay) sockets unnecessarily should it take some time for an encoder to change state or to tear down the livetv chain –
[18:59:27] stuartm: needs an extra pair of eyes given the potential to introduce series new bugs if the locking isn't right
[19:00:31] dekarl (dekarl! has quit (Ping timeout: 264 seconds)
[19:11:08] stuartm: jya_: it can't hurt to try that patch, although I can't say for sure that it will help with your issue, at worst it should leave the backend semi-working if you hit a deadlock when tearing down the livetv chain
[19:13:47] stuartm: at best it actually be the fix, it's entirely plausible that the recorder thread was waiting on yet another thread which was waiting on the socketlistlock
[19:14:00] stuartm: might
[19:18:44] Tobbe5178 (Tobbe5178! has quit (Read error: No route to host)
[19:20:58] Tobbe5178 (Tobbe5178! has joined #mythtv
[19:33:14] stichnot: stuartm: you're going to do another Coverity build this week, right?
[19:34:24] stuartm: stichnot: did one yesterday, but I'm willing to do another in a couple of days
[19:45:26] natanojl (natanojl! has joined #mythtv
[19:47:16] stichnot: stuartm: thanks, I didn't notice that had changed
[19:48:53] stuartm: the count remained relatively static (actually went up a bit) because two plugins were included that were previously missing
[19:50:21] stichnot: cool, I was wondering about that
[19:51:19] knightr_ (knightr_! has joined #mythtv
[19:51:23] jheizer_ (jheizer_! has joined #mythtv
[19:54:42] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 256 seconds)
[20:00:53] chronic1 (chronic1! has joined #mythtv
[20:01:04] chronic1 (chronic1! has left #mythtv ()
[20:06:47] stuartm: danielk222, jya_: ignore that patch, it's wrong and causes some serious problems
[20:09:15] jheizer_ (jheizer_! has quit (Ping timeout: 256 seconds)
[20:17:10] stuartm: used an iterator after erase() ... oops
[20:25:50] peper03 (peper03! has quit (Quit: Konversation terminated!)
[20:27:06] stuartm: fixed version –
[20:29:58] stuartm: nope, it just fails in a different way now :/
[20:33:01] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds)
[20:39:10] Tobbe5178 (Tobbe5178! has quit (Ping timeout: 252 seconds)
[20:44:35] Tobbe5178 (Tobbe5178! has joined #mythtv
[20:48:41] Tobbe5178 (Tobbe5178! has quit (Read error: No route to host)
[20:50:55] Tobbe5178 (Tobbe5178! has joined #mythtv
[20:51:19] Jordack (Jordack! has quit ()
[21:04:16] natanojl (natanojl! has quit (Ping timeout: 276 seconds)
[21:13:20] SteveGoodey (SteveGoodey! has joined #mythtv
[21:15:24] SteveGoodey (SteveGoodey! has quit (Client Quit)
[21:22:55] Lomion0815 (Lomion0815! has quit (Ping timeout: 256 seconds)
[21:39:09] stichnot (stichnot!stichnot@nat/google/x-gesehzutqtgmelsq) has joined #mythtv
[21:39:09] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:39:09] stichnot (stichnot!stichnot@nat/google/x-gesehzutqtgmelsq) has quit (Changing host)
[21:39:53] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[21:57:20] aloril (aloril! has quit (Read error: Operation timed out)
[22:02:53] gigem: stuartm: Is 788bc510 still necessary with the later changes to drop schedLock when calling the recorders? It created a race condition and I'd like to revert most of it. The race condition is caused by Reschedule() using a different lock than reschedWait.wait(). If a new request comes in between the check of HaveQueuedRequests() and the call to reschedWait.wait(), the scheduler would not see it until the
[22:02:55] gigem: wait times out or another request comes in.
[22:10:22] stuartm: gigem: I'm not sure ...
[22:11:22] aloril (aloril! has joined #mythtv
[22:14:00] Tobbe5178 (Tobbe5178! has quit (Read error: Connection reset by peer)
[22:22:08] skd5aner (skd5aner! has joined #mythtv
[22:22:55] stuartm: it didn't affect me, at least not regularly, I had to work out what was happening from various backtraces provided by users
[22:23:29] gigem: stuartm: Based on what I remember from the deadlocks, I don't think it's needed. Unless you or danielk222 think of a reason not to, I'll revert it tomorrow.
[22:29:03] stuartm: I wish I'd given more detail in the commit message so I could be certain one way or the other
[22:29:55] stuartm: it was a particularly nasty deadlock so I'd hate to see it reappear :/
[22:30:41] gigem: I don't think this will bring it back. If it does, we'll fine a better fix.
[22:55:54] jya: dekarl1: the issue isn't decoding.. it's encoding, the encoder expects planar data
[22:56:34] tafy (tafy! has joined #mythtv
[22:57:32] jya: Captain_Murdoch: currently it's the default mp3lame encoder that is broken
[22:59:16] tafy: Hi, I updated ticket #11491 with a new patch
[22:59:16] ** MythLogBot **
[23:00:04] tafy: it will return the recording markup data in this format :
[23:00:44] tafy: So a services-api user does not need to know about the mark type ids from the DB
[23:09:58] IReboot (IReboot! has quit (Quit: Ex-Chat)

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