MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (83):

aloril, andreax1, Anduin_, Andy50, Anssi, anykey_, beata, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, dagar, danielk22, Dave123, Dave123-road, dlblain, dlblog, eharris, Elv13, f33dMB, FinnTux, ghoti, gigem, gregL, GreyFoxx, Guest40970, highzeth, hobiga, iamlindoro, ikonia, ivanl, j-rod|afk, jams, jannau, jarle, jcarlos, JEDIDIAH__, joe_, jpabq, jpabq-, jpharvey, jstenback, justinh, jwhite, kc, knightr, kormoc, kurre, kwmonroe, laga, len, mag0o, MaverickTech, MythBuild, MythLogBot, okolsi, pheld, PointyPumper, poptix, purserj, reynaldo, sailerboy, Seeker`, simonckenyon, Snow-Man, sphery, sunkan, sutula, taylorr, tgm4883, ThisNewGuy, tomimo, tris, Unhelpful, wahrhaft, weta, xris, xxtjaxx, ybot, zombor, _charly_
Wednesday, May 11th, 2011, 00:11 UTC
[00:11:19] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 260 seconds)
[00:12:39] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[00:16:05] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[00:19:29] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Read error: Operation timed out)
[00:24:33] taylorr: markk: in a last act of desperation I increased the max vdpau surfaces to 10 and the vdp_presentation_queue_block_until_surface_idle stalls are gone completely
[00:24:59] taylorr: do you want me to find the minimum number we need for the blocking to go away?
[00:38:02] Cougar (Cougar!~cougar@kkk.version6.net) has quit (Ping timeout: 248 seconds)
[00:38:53] gigem (gigem!~gigem@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:40:20] gigem (gigem!~gigem@cpe-76-187-29-95.tx.res.rr.com) has joined #mythtv
[00:40:20] gigem (gigem!~gigem@mythtv/developer/gigem) has joined #mythtv
[00:40:20] gigem (gigem!~gigem@cpe-76-187-29-95.tx.res.rr.com) has quit (Changing host)
[00:42:13] Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv
[00:46:05] Cougar (Cougar!~cougar@kkk.version6.net) has quit (Read error: Operation timed out)
[00:46:30] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[00:49:45] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:50:07] Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv
[00:50:14] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[00:52:01] markk: taylorr: so the powermizer change didn't actually help by itself?
[00:56:25] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:59:31] thread (thread!~thread@174.103.76.117) has joined #mythtv
[00:59:36] thread (thread!~thread@174.103.76.117) has left #mythtv ()
[01:11:45] markk: taylorr: if I'm reading http://us.download.nvidia.com/XFree86/Linux-x . . . support.html correctly, then 8 is the max
[01:29:49] danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.)
[01:42:20] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[01:45:07] jpabq: markk, taylorr increasing the value also helped me as well. And, I did not switch the powermizer setting – it is still at adaptive.
[01:46:35] markk: jpabq: helped or fixed?
[01:47:06] jpabq: markk, I have only watched a couple of hours, but so far I would have to say fixed.
[01:47:51] jpabq: It is possible that with taylorr's ion, changing the power setting is necessary, while on a dedicated GT220 it is not?
[01:57:09] taylorr: markk: ok, got the kids to bed finally ;)
[01:57:51] taylorr: I thought the powermizer made the difference but forgot that I had also changed the video output surfaces to 10
[01:58:20] taylorr: I'll reenable powermizer and see how it goes
[02:00:05] markk: taylorr: I'm just slightly wary of adding another 4 output surfaces at the cost of potentially 30meg of video memory – and I haven't thought through av sync yet
[02:01:04] taylorr: markk: maybe there is something with our vdpau handling that is at fault
[02:02:41] taylorr: when I set it to 10 I don't see any VDPAU messages about too many surfaces
[02:04:03] markk: "A VdpPresentationQueue allows a maximum of 8 surfaces to be QUEUED or VISIBLE at any one time. This limit is per presentation queue. If this limit is exceeded, VdpPresentationQueueDisplay blocks until an entry in the presentation queue becomes free."
[02:07:15] taylorr: markk: ok, we aren't abiding by their recommendation though
[02:07:39] markk: taylorr: ??
[02:07:40] taylorr: "(num_ref) + 5 for interlaced content using advanced de-interlacing."
[02:08:43] markk: yes – we use more video buffers. but that's video buffers – we're talking about presentation surfaces
[02:12:00] taylorr: ah, sorry
[02:23:00] jpabq: markk, taylorr, change that to "helped". However, I have not tried changing the powermizer yet.
[02:23:28] taylorr: jpabq: be aware that there is more than one issue in play
[02:24:44] taylorr: you need to put VERBOSE calls around vdp_presentation_queue_block_until_surface_idle and see if there is any significant delay at some point before the frame drops
[02:25:10] jpabq: Also, the first couple of hours I was watching, the backend was not doing anything. Now it is, so there could be some interaction there. I definitely still get a pause when a new recording starts up. Maybe something else is happening on the backend that seizes attention.
[02:25:14] taylorr: also your HD-PVRs seem to reset the stream frequently
[02:26:16] taylorr: jpabq: right, the backend definitely seems to have an issue providing data to the frontend while under load
[02:26:34] jpabq: taylorr, actually, my HD-PVRs have gone back to being obedient. I have not had a recording glitch in several weeks now. I believe the glitches were being caused by a marginal hard drive, that I replaced a few weeks ago.
[02:28:47] jpabq: However, I also add the irqpoll to the kernel params about the same time, so it could be that.
[02:29:05] markk: taylorr: something I never really checked, when you get the pause – it does appear in the logs? i.e. av sync goes out etc
[02:30:27] taylorr: markk: yes, a prior vdp_presentation_queue_block_until_surface_idle call blocks video playback for a significant amount of time and then soon afterwards the AV-sync code starts dropping frames to catch back up
[02:31:56] taylorr: markk: after increasing the max num of output surfaces I haven't seen a single vdp_presentation_queue_block_until_surface_idle call take more than 1 msec
[02:32:57] jpabq: taylorr, actually your HD-PVR comment is relevant — the show I was just watching was recorded back when I was having such issues.
[02:33:07] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-57-109.hr.hr.cox.net) has quit (Read error: Operation timed out)
[02:33:19] mag0o_ is now known as mag0o
[02:34:25] taylorr: markk: I believe there are two fundamental issues in play – one is specific to VDPAU and the number of output surfaces the other issue I believe is do to the backend not sending data fast enough to the frontend's ringbuffer when under load
[02:35:13] taylorr: jpabq: run mythffmpeg -i against the recording and see if it gives a weird duration
[02:35:36] taylorr: if the duration is wrong with ffmpeg then it's definitely got one or more discontinuities
[02:36:15] markk: taylorr: thanks. re-reading the vdpau docs, I think it's perfectly reasonable to increase the number of presentation surfaces given the threading changes have pushed more code into the main thread. it will increase memory consumption though and I need to look at av sync – 8 surfaces represents up to a third of a second disparity between sending a frame for display and it appearing on screen
[02:36:45] taylorr: markk: I'm not noticing much issue with AV-sync
[02:37:19] markk: though the videosync code will limit the rate at which frames are sent for presentation – so it's hard to see how increasing the queue size will help:)
[02:39:40] taylorr: markk: if the videosync code is behind it will send frames faster
[02:39:45] markk: on a slightly different note – just been stress testing some live tv with 3 pips. small blip at program boundary – otherwise the only jitter was caused by position map updates – may need to look at how those calls are handled.
[02:40:26] taylorr: 3 pips! what type of system are you using for playback?
[02:41:12] markk: taylorr: it's only sd stuff – pretty straightforward:)
[02:42:17] markk: taylorr: yes – the frame rate may be temporarily increased but by that point you've already had your blip, surely?
[02:42:58] markk: or maybe it just allow it to recover much more quickly
[02:44:26] taylorr: markk: one thing that is interesting is the fact that some of the blocking lasts 300–500msec which is more than a performance problem
[02:44:46] taylorr: it seems if you don't have enough output surfaces to keep up then something very bad happens occasionally
[02:46:26] taylorr: markk: fyi, I've changed from 4 to 10 to 4 to 10 and ran for significant amounts of time and it's very clear that with just 4 output surfaces we have issues and with 10 I never see any blocking, not once
[02:48:29] taylorr: jpabq: did you notice any audio sync delays with using 10 output surfaces?
[02:49:16] jpabq: taylorr, no, I didn't
[02:50:57] markk: taylorr: ok – let me put to together a quick debugging patch. I'd like to see what the status of all of those output surfaces is during normal playback versus the glitch – and to make sure we don't get into a state where all of those surfaces are being used all of the time. I'm also wondering if we can monitor the time taken for that call and dynamically up the size of the presentation queue as needed
[02:55:21] sphery: taylorr: FWIW, I completely agree that there are 2 issues. I was using Xv and had been seeing the pauses on recording stop/start, but I've just enabled vdpau, and now I'm seeing pauses even when no recordings are occurring--and they seem to be more frequent in some recordings than others
[02:56:03] taylorr: sphery: you should try increasing the max output surfaces and report back if it helps
[02:56:49] sphery: the when-not-recording (or when-not-at-recording-boundary) pauses are vdpau ones, and never occurred with xv, but the recording boundary pauses occur with xv or vdpau... I'll try the max surfaces change--maybe tomorrow
[02:59:33] kormoc is now known as kormoc_afk
[03:19:52] taylorr: markk: so far it looks like PowerMizer has nothing to do with these issues
[03:46:58] markk: taylorr: http://pastebin.ca/2056559 – unfortunately, I'm not sure it really helps us as it seems to have quite an impact on performance :(
[03:50:41] skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Ping timeout: 264 seconds)
[04:01:11] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 276 seconds)
[04:01:17] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:02:25] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[04:12:29] taylorr: markk: running now – doesn't seem to slow anything down
[04:12:43] taylorr: usually happens 5–15 minutes
[04:19:44] taylorr: jpabq: what is this irgpoll kernel parameter you are talking about?
[04:24:36] taylorr: markk: 2011-05–11 00:23:08.354 VDPAU: Queue: current 0 some 0 (QQQV)
[04:24:36] taylorr: 2011-05–11 00:23:08.354 VDPAU: vdp_presentation_queue_block_until_surface_idle() — start
[04:24:36] taylorr: 2011-05–11 00:23:08.641 VDPAU: vdp_presentation_queue_block_until_surface_idle() — end
[04:25:22] taylorr: so the out surfaces were all in use when the blocking occured – you'll notice that it blocked fro ~290msec
[04:27:30] taylorr: it seems to happen all the time but typically just causes 13–14 msec delay
[04:27:51] taylorr: with 10 output surfaces it never blocks
[05:04:26] ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv
[05:26:57] markk: taylorr: gotta pick up my son from school but I think we probably need to bump the queue size to 8 and try and backport the vdpau buffer fixes to 0.24. I'd then be comfortable that 0.24.1 was in as good a state as we can get it. (and hence any remaining problems are 'genuine')
[05:50:40] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has quit (Ping timeout: 260 seconds)
[05:50:54] weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has quit (Read error: Operation timed out)
[05:59:17] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has joined #mythtv
[06:03:14] Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 250 seconds)
[06:05:18] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[06:07:19] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has quit (Ping timeout: 240 seconds)
[06:08:35] andreax1 (andreax1!~andreaz@p57B955F6.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[06:13:40] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has joined #mythtv
[06:24:07] martin____ (martin____!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv
[06:24:12] Andy5O (Andy5O!andy50@173-23-19-191.client.mchsi.com) has joined #mythtv
[06:26:52] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has quit (Ping timeout: 246 seconds)
[06:28:37] Andy5O (Andy5O!andy50@173-23-19-191.client.mchsi.com) has quit (Ping timeout: 246 seconds)
[06:32:14] Elv13 (Elv13!~lepagee@208.92.19.31) has quit (Ping timeout: 260 seconds)
[06:38:41] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[06:44:50] weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has joined #mythtv
[07:00:35] Andy50 (Andy50!andy50@173-23-19-191.client.mchsi.com) has joined #mythtv
[07:37:55] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[08:09:28] stuartm (stuartm!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has joined #mythtv
[08:09:29] stuartm (stuartm!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has quit (Changing host)
[08:09:29] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[08:11:21] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[08:13:23] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[08:40:12] Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Read error: Connection reset by peer)
[08:40:29] Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv
[09:09:23] len (len!~quassel@184-97-168-55.mpls.qwest.net) has quit (Remote host closed the connection)
[09:21:20] weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has quit (Ping timeout: 246 seconds)
[09:49:14] jya: markk: I got my hand on a new mac mini, with a nvidia 320M ; nvidia-settings report 256MB of RAM if that info matter. I'm yet to get VDPAU working .. Is this related to the 256MB of video RAM? (it's running ubuntu 11.04 64 bits)
[09:49:33] jya: http://pastebin.com/m1cLJ2uq
[09:54:35] jya: (it plays fine with vdpau and mplayer)
[10:05:02] mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[10:05:49] mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[10:06:15] mike is now known as Guest40970
[10:19:02] Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Read error: Connection reset by peer)
[10:39:23] markk: jya: is that 0.24-fixes?
[10:39:29] jya: yes.
[10:40:12] jya: do you want me to try with master?
[10:50:44] markk: jya: can you get some -v playback logs? might be a better hint
[10:50:54] jya: ok
[10:57:12] jya: http://pastebin.com/Rt9UAtD3
[11:01:36] jya: markk: I've changed the GUI size to 1280x720 ; and it works... Looks like it doesn't like the 27" resolution (according to the log) : it's a 2560x1440 screen
[11:04:13] markk: jya: strange – no obvious reason why 2560x1440 should be a problem; it's within vdpau specs
[11:04:32] markk: (and it's not saying it is running out of memory)
[11:05:23] jya: 1280x720 works nicely. I set the GUI to 1920x1080 ; just got a complete freeze
[11:12:58] jya: http://pastebin.com/DJp1PT76
[11:14:43] weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has joined #mythtv
[11:28:57] stuartm: 512MB is no longer the minimum requirement for vdpau?
[11:35:17] simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has joined #mythtv
[11:37:02] simonckenyon|3 (simonckenyon|3!~simoncken@195.7.61.12) has joined #mythtv
[11:37:16] simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Ping timeout: 240 seconds)
[11:37:19] jya: stuartm: it used to work fine with 256MB back in the 0.22 days
[11:38:22] stuartm: hmm, I thought the limit was always 512MB, but maybe I'm misremembering
[11:39:41] simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has quit (Ping timeout: 240 seconds)
[11:41:14] jya: the issue here is more so the error it yield; I can't see anything related to insufficient memory
[11:49:34] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[11:50:05] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[12:11:17] markk (markk!~mark@cm180.omega173.maxonline.com.sg) has quit (Ping timeout: 252 seconds)
[12:14:03] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[12:14:47] stuartm: jya: yeah, my question wasn't directly related to your problem, I just could have sworn that the min.req. was 512MB and I was wondering when that had changed
[12:15:22] jya: nah, it used to be 256MB... I had it working with early 128MB on board 8200 ...
[12:15:46] stuartm: right, just my memory then
[12:17:02] stuartm: I use 512MB for my 8200s, 128MB was definately not enough for BBC HD back then and I probably just bumped it to the max the bios allowed to be certain I wouldn't have problems
[12:17:30] stuartm: that's probably why 512MB stuck in my mind
[12:18:00] jya: I had written this in my vdpau faq ; minimum was 256MB with 180.25 nvidia drivers
[12:18:21] jya: nearly 3 years.. gosh time flies
[12:22:39] jya: I think I remember the minimum was around 0.23 ; with all the new fancy GUI
[12:33:23] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has joined #mythtv
[12:33:23] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has quit (Changing host)
[12:33:24] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[12:34:23] ** stuarta wonders what is leaking in the latest backend **
[12:34:41] stuarta: not huge ~2Mb RSS in 24hrs
[12:35:47] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv
[13:09:26] taylorr: stuartm: please hold off on 0.24.1 until I can back-port the video buffer fixes
[13:11:33] taylorr: anyone, did I just somehow screw up git?
[13:12:10] taylorr: Beirdo: what is up with that commit message by me?
[13:13:22] MythBuild: build #170 of 0.24-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . t/builds/170 blamelist: Mark Kendall <mkendall@mythtv.org >
[13:17:20] MythBuild: build #148 of 0.24-linux-32bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . t/builds/148 blamelist: Mark Kendall <mkendall@mythtv.org >
[13:21:58] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[13:22:39] MythBuild: build #171 of 0.24-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . t/builds/171
[13:26:51] MythBuild: build #9 of 0.24-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/0.24-linux-ppc/builds/9 blamelist: Mark Kendall <mkendall@mythtv.org >
[13:26:59] taylorr: markk: looks like the dynamic vdpau buffer creation code was after the removal of XVMC which resulted in some videobuffer clean-up
[13:27:39] MythBuild: build #149 of 0.24-linux-32bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . t/builds/149
[13:35:19] martin____ (martin____!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection)
[13:40:49] MythBuild: build #10 of 0.24-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . pc/builds/10
[14:03:08] j-rod|afk is now known as j-rod
[14:04:07] danielk22: umm, OpenGL makeCurrent() is failing on my main dev machine and ThemePainter appears to be gone. What is the current means to revert to the Qt painter when OpenGL goes out to lunch?
[14:06:10] danielk22: Most of the makeCurrent() error messages follow a "QGLTempContext: Unable to create GL context" so I'm guessing we should be auto-reverting to Qt drawing anyway... but that's a totally separate issue.
[14:09:59] taylorr: danielk22: mythfrontend -O ThemePainter=qt
[14:11:04] danielk22: taylorr: That didn't work. I also didn't find it in a grep of the code.
[14:13:24] taylorr: danielk22: try UIPainter instead of ThemePainter
[14:13:53] danielk22: thx, worked
[14:14:17] taylorr: https://github.com/MythTV/mythtv/commit/fb45eb9fe
[14:15:27] danielk22: sphery: ^^^ It looks like the auto-detection doesn't do so well in at least one case for OpenGL..
[14:16:46] danielk22: sphery: I'm planning to update the drivers soon. But let me know if you'd like me to collect some logs first..
[14:33:10] sphery: danielk22: Can you give a complete log of startup without setting UIPainter? Also some details of the graphics config would be useful. We might be able to detect broken drivers (when use of OpenGL fails) and fall back, but I'll need some help from markk to figure out how.
[14:35:01] danielk22: sphery: sure. will do
[14:59:37] stuartm: danielk22: any particular logging that would be useful to debug the backend hanging when it's supposed to be starting a recording? -v record + ?
[15:00:06] stuartm: I'm still intending to grab a backtrace, but I hadn't set it up when it occurred again last night
[15:01:48] danielk22: -v record,channel. But the backtrace is the best thing...
[15:01:55] danielk22: which recorder?
[15:02:49] stuartm: DTV
[15:03:02] danielk22: you mean DVB?
[15:03:59] stuartm: err yeah, it used to be dtvrecorder.cpp/h, I guess that's changed
[15:04:46] stuartm: the -v general, important log I have shows it never reaching the recording state – http://pastebin.com/gGtAk7Kb
[15:04:50] danielk22: stuartm: DTVRecorder is an abstract class, which has specific implementations HDHR,DVB,Firewire, etc.
[15:05:17] stuartm: danielk22: heh ok, my memory really is full of holes then
[15:05:54] stuartm: danielk22: yes dvb-t or dvb-s in that backend
[15:05:56] danielk22: stuartm: this could also be the scheduler so add that to the -v line :)
[15:06:13] stuartm: ok
[15:08:41] stuartm: I should really setup log rotation with those three enabled
[15:10:45] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[15:12:20] danielk22: http://pastebin.com/EbMmuvDB
[15:12:57] stuartm: thanks
[15:15:33] stuartm: especially with it logging "2011-05–11 16:15:11.700 DTVSM(/dev/dvb/adapter0/frontend0): Time Offset: 0.299905" once a second
[15:16:20] danielk22: heh, that should probably only be in VB_EXTRA..
[15:21:16] stuartm: danielk22: I'll move it
[15:23:26] stuartm: taylorr: thanks, it won't be until tonight at the earliest, I still have family here and I need some time to update the old release scripts
[15:28:15] abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has joined #mythtv
[15:51:05] danielk22: sphery: This is not the error message set I was seeing earlier, but I'm seeing the same symptom. http://pastebin.com/YztnNHJA
[15:52:32] martin_ (martin_!~quassel@h-165-113.A155.priv.bahnhof.se) has joined #mythtv
[15:53:24] danielk22: sphery: and with "-v gui" http://pastebin.ca/2056874
[15:54:33] danielk22: ah, i.c. the QGLContext::makeCurrent() is sent to stderr, that's why it looks different..
[15:56:21] danielk22: http://pastebin.ca/2056876 <- with stderr mixed in.
[16:05:30] Elv13 (Elv13!~lepagee@208.92.19.31) has joined #mythtv
[16:10:44] sphery: danielk22: thanks
[16:10:54] simonckenyon|3 (simonckenyon|3!~simoncken@195.7.61.12) has quit (Remote host closed the connection)
[16:13:07] Goga777 (Goga777!~Goga777@shpd-92-101-130-43.vologda.ru) has joined #mythtv
[16:13:15] simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv
[16:13:21] sphery: danielk22: It's strange that it shows no info for GL vender/renderer/version. What GPU and drivers are on there?
[16:17:22] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[16:20:42] Goga777 (Goga777!~Goga777@shpd-92-101-130-43.vologda.ru) has quit (Remote host closed the connection)
[16:38:12] abqjp: I also get those "Failed to create OpenGL texture" messages. They flood my frontend log as soon as I start up mythfrontend. I have been meaning to ask Mark about them for a few weeks and keep forgetting. mythfrontend seems to be working okay, so it has just been a minor annoyance. sphery, in my case that system has a GT220, running Fedora 14 with the latest rpmfusion nvidia drivers. That computer is off right now, so I am not positive, but
[16:38:13] abqjp: believe it is currently using nVidia 260.19.36 drivers.
[16:45:17] andreax (andreax!~andreaz@p57B955F6.dip.t-dialin.net) has joined #mythtv
[16:48:16] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[16:48:43] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[16:48:43] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[16:48:43] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[16:48:47] danielk22: sphery: 8300 GS, 260.19.21
[16:50:34] martin_ (martin_!~quassel@h-165-113.A155.priv.bahnhof.se) has quit (Ping timeout: 260 seconds)
[16:51:02] sphery: Strange... Both of you guys should be seeing something like: http://pastebin.com/ts7PAJa2 . I wonder if the packages aren't installing the drivers properly. (Not saying we shouldn't try to detect it and fall back to Qt painter, too, but just that the drivers seem to have some problems.)
[17:10:39] Beirdo: taylorr: seems you had some work done in parallel with others and merged the two when you pulled their changes. All seems good from here
[17:13:54] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[17:44:55] andreax1 (andreax1!~andreaz@p57B94E39.dip.t-dialin.net) has joined #mythtv
[17:45:10] andreax (andreax!~andreaz@p57B955F6.dip.t-dialin.net) has quit (Ping timeout: 263 seconds)
[18:01:54] taylorr: Beirdo: I did a git pull before git commit so that's weird
[18:02:02] taylorr: I'll be sure to --rebase next time
[18:07:22] taylorr: Captain_Murdoch: did you ever decide if the fanart timeouts (ie. kArtworkFanTimeout) for PBB should be reinstated?
[18:07:49] taylorr: I think it does help speedup going through recordings with fanart associated
[18:23:56] Captain_Murdoch: taylorr, yes, I talked with daniel and we think that was just an oversight. they should be re-instated. I have a patch but haven't committed yet.
[18:25:57] stuarta: what's the default web setup password we've set?
[18:28:13] Captain_Murdoch: mythtv
[18:28:20] stuarta: of course
[18:28:24] Captain_Murdoch: username admin
[18:28:50] stuarta: ta. hunting the commits list wasn't going so well... :)
[18:46:05] SteveGoodey (SteveGoodey!~steve@host86-184-205-239.range86-184.btcentralplus.com) has joined #mythtv
[18:49:51] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[18:53:38] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 276 seconds)
[18:58:13] SteveGoodey (SteveGoodey!~steve@host86-184-205-239.range86-184.btcentralplus.com) has quit (Read error: Connection reset by peer)
[19:07:31] kormoc_afk is now known as kormoc
[19:13:14] SteveGoodey (SteveGoodey!~steve@host86-184-205-239.range86-184.btcentralplus.com) has joined #mythtv
[19:18:33] ivanl (ivanl!4e56a3aa@gateway/web/freenode/ip.78.86.163.170) has joined #mythtv
[19:19:08] ivanl: hi, anybody here to answer a hardware decoding question?
[19:20:10] sphery: ivanl: are you sure you don't want #mythtv-users?
[19:23:01] ivanl: Hi sphery, thanks for replying. I suppose the question is more appropriate for mythtv-users, but I am actually a developer... Anyway, the question is how to tell myth to use specific hardware decoder. I have crystalHD but it seems software decoder is used
[19:27:49] ivanl: sphery: I'll ask that on mythtv-users. On another note, I've got a bunch of fixes for libmythtranscode and mythmusic that remove dependency on libqt3support. This means both mythtv 0.24 and mythplugins can be built in a purely Qt 4 environment. Any interest in this patch?
[19:29:39] sphery: ivanl: Yeah, those would probably be very useful. Please post them to a new ticket at http://code.mythtv.org/trac/ . Thanks.
[19:30:30] sphery: Actually, 2 tickets is proabably better. MythMusic is undergoing a major rewrite, now, so that patch may not be used/useful with the new code.
[19:31:05] ivanl: Fantastic, good to know. Thanks very much.
[19:39:53] noahric (noahric!~noahric@nat/google/x-kdfqvhdmwnsfncco) has joined #mythtv
[19:39:58] noahric (noahric!~noahric@nat/google/x-kdfqvhdmwnsfncco) has left #mythtv ()
[20:14:32] stuartm: Beirdo, danielk22: I'm seeing a QThread segfault in trunk with MHEG
[20:15:24] Beirdo: got a backtrace? I think that's in danielk22's redo (if current master), but I can give you a hand
[20:17:58] stuartm: http://mythtv.pastebin.ca/2057005
[20:18:19] stuartm: Beirdo: obtaining a full bt once I figure out where gdb is writing the log ...
[20:18:31] Beirdo: K :)
[20:20:13] stuartm: ah, ok, gdb ignores everything after the first . when specifying the log
[20:21:07] stuartm: nope, it's just ignoring what I specify ... bah
[20:22:22] Beirdo: it crashed on the wait?
[20:23:57] stuartm: http://mythtv.pastebin.ca/2057007
[20:25:05] stuartm: I'm getting the where
[20:25:35] stuartm: 0x00007ffff43a2b7b in QThread::wait(unsigned long) () from /usr/lib64/libQtCore.so.4
[20:25:43] stuartm: so yeah, the wait()
[20:26:00] stuartm: it's pretty consistent
[20:26:21] Beirdo: argh
[20:26:25] Beirdo: we fixed this already
[20:26:36] Beirdo: then the unfixed code got merged over top, it seems
[20:26:57] Beirdo: the m_engineThread needs to be initialized to NULL in the ctor
[20:27:09] Beirdo: ctor for MHIContext
[20:27:38] Beirdo: you want me to commit a fix?
[20:28:13] stuartm: Beirdo: you'll probably get it done faster than me, this machine is crawling atm :(
[20:28:52] martin___ (martin___!~quassel@h-165-113.A155.priv.bahnhof.se) has joined #mythtv
[20:29:43] Beirdo: OK
[20:29:46] Beirdo: one sec
[20:30:44] Beirdo: done
[20:32:12] stuartm: ta
[20:32:39] Beirdo: no problemo. I don't remember if it was that specific one or a similar one that got fixed earlier
[20:32:41] stuartm: of course whether I'll be able to compile it ...
[20:32:57] Beirdo: I should find a moment to do a code review...
[20:33:05] len (len!~quassel@184-97-168-55.mpls.qwest.net) has joined #mythtv
[20:33:16] stuartm: Beirdo: seems like a very recent regression, had no problems until I updated today
[20:33:53] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Read error: Connection reset by peer)
[20:33:56] Beirdo: yeah, daniel put in a pile of changes from the -rec2 branch. It's easy enough to miss an initializer, especially in code you can't personally test :)
[20:34:57] Beirdo: there's a check for NULL, but on startup, it was uninitialized, so if no thread got started, we wait on a thread whose pointer is random stack/heap garbage
[20:35:01] Beirdo: kaboom
[20:35:24] Beirdo: so, put in the initializer to NULL
[20:35:28] stuartm: I need more memory, simultaneously running three apps under gdb is murder
[20:35:34] Beirdo: hehe, yes it is
[20:36:51] stuartm: Beirdo: common error, it's one that's normally picked up easily by static analysis tools but either this one went under the radar or no-one is running regular checks anymore
[20:36:58] MythBuild: build #1164 of master-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1164 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org >
[20:37:05] stuartm: oop
[20:37:06] Beirdo: yeah, that reminds me...
[20:37:07] stuartm: s
[20:37:10] Beirdo: ah shite.
[20:37:23] stuartm: m_engieThread’
[20:37:29] stuartm: type
[20:37:30] Beirdo: hgahahah
[20:37:32] stuartm: typo
[20:37:49] stuartm: see, we're all capable of them ;)
[20:38:03] Beirdo: we sure are :)
[20:38:31] MythBuild: build #920 of master-linux-32bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/920 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org >
[20:38:34] Beirdo: we should work on the static analysis from buildbot sometime
[20:38:44] Beirdo: yeah yeah, fail away, now rebuild
[20:39:09] Beirdo: I chipped away at our warnings some
[20:39:18] stuartm: I noticed, nice
[20:39:40] Beirdo: I have a fix for the off the end of the array in tspacket.h, but danielk22 didn't like my first pass, so it's not in yet
[20:40:07] Beirdo: that one left in the plugins... I'll try again, but it was painful last time I tried.
[20:42:17] stuartm: it's been a while since I ran cppcheck, I'll see what the output from the latest version is like against trunk/head/master/whatever
[20:43:04] iamlindoro: "pointy bit at the end"
[20:43:08] Beirdo: yeah, if you can come up with a script to run with all your fave options, we could have the buildbot make a slave run it
[20:43:30] Beirdo: my 64-bit one (my backend) could do it if nobody else wants to
[20:44:33] MythBuild: build #1165 of master-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1165
[20:44:53] stuartm: if they've implemented the feature I lobbied hard for – ignoring directories by name, then scripting it should be much easier
[20:45:38] MythBuild: build #31 of master-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . pc/builds/31 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org >
[20:45:41] stuartm: we want to ignore the libav* stuff as it takes forever to check and we're not really concerned with the output, but up to now cppcheck has lacked a credible method of ignoring certain files and directories
[20:51:30] MythBuild: build #921 of master-linux-32bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/921
[20:53:05] Beirdo: ah, for sure
[20:53:29] Beirdo: no point in checking that code unless we want to make a third fork with our fixes (PLEASE no!)
[20:54:20] iamlindoro: libmythavffmpeg
[20:54:34] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit (Quit: http://www.youtube.com/watch?v=nGeKSiCQkPw)
[20:54:38] SteveGoodey (SteveGoodey!~steve@host86-184-205-239.range86-184.btcentralplus.com) has quit (Remote host closed the connection)
[20:54:53] Beirdo: we kinda are half-way there, but I don't see anyone volunteering to maintain it :)
[20:55:06] Beirdo: ok, part-way there
[20:55:55] iamlindoro: I still think that acceptance of/openness to our needed changes in the MPEG-TS demuxer is a valid way of choosing which fork to go with
[20:57:40] Beirdo: it's certainly gonna be one of the selling points, for sure
[20:57:57] iamlindoro: Not that anyone has approached either side to see who would work with us
[20:58:00] Beirdo: the less work we have to do in future syncs, the better
[20:58:03] iamlindoro: (tthough we should)
[20:58:13] martin___ (martin___!~quassel@h-165-113.A155.priv.bahnhof.se) has quit (Remote host closed the connection)
[20:58:15] Beirdo: true, we haven't gotten to that point yet
[20:58:33] iamlindoro: It probably needs doing well in advance of the next sync
[20:58:41] iamlindoro: so that we're not deciding on promises, but rather on real action
[20:58:46] Beirdo: for sure.
[20:59:06] Beirdo: I guess we could start doing something about it relatively soon
[21:11:09] MythBuild: build #32 of master-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . pc/builds/32
[21:21:16] Beirdo: there, all fixed
[21:22:06] danielk22: Beirdo: thank's for re-fixing that MHEG thing.. I was aware of that bug, I re-read over every line of the fixup patch but still missed it.
[21:22:30] Beirdo: heh, no problem. It's an easy one to miss
[21:22:31] danielk22: I think maybe I read that changeset backward... it's happened before.
[21:23:07] Beirdo: I hope we don't have others that need it as well, but that's something for a new code review, I guess
[21:23:29] danielk22: Beirdo: I thought you already committed a fix for the tspacket compiler complaint using pointer arithmetic to fool gcc..
[21:23:39] Beirdo: didn't work, and I reverted it
[21:23:50] Beirdo: it only fooled it until you turn on release build
[21:24:01] Beirdo: let me dig out the latest
[21:24:21] Beirdo: http://www.beirdo.ca/git/mythtv/commit/?h=fix . . . 8aeb782a9508
[21:24:39] danielk22: Beirdo: Heh, a code-review on the changes from the code-review.
[21:25:04] Beirdo: basically, read/write from the _tspayload[] instead of _data[] as that data's actually in _tspayload[]
[21:25:20] Beirdo: I didn't want to mess with the AFCOffset() itself as it's used in several places
[21:25:22] danielk22: Beirdo: Does the compiler optimize away the -4 ? If so I could live with it :)
[21:25:30] Beirdo: I would hope so
[21:25:53] danielk22: I know with ia86 it doesn't matter (one addition is free)
[21:26:22] Beirdo: of course, in debug builds it won't, but in the release builds, it inlines AFCOffset()
[21:26:34] Beirdo: so it should optimize it out
[21:26:41] danielk22: ah, right. AFCOffset is in the header?
[21:27:01] danielk22: (implemented in the header ? )
[21:27:28] Beirdo: yes
[21:29:16] danielk22: K, just looked your right, no reason this can't be applied. I was just worried about inefficiency in this low level class (it's handled millions of times per second per recorder in some cases).
[21:30:11] Beirdo: yeah, for sure
[21:30:21] Beirdo: OK, other than a fire drill, I'd get it in right now :)
[21:30:36] danielk22: heh, lets hope it's just a drill.
[21:31:46] Beirdo: it is, preannounced... 18 floors of stairs, here we come
[21:33:35] iamlindoro: Down is easy, and they'll probably even let you use the elevator on the way back up :)
[21:44:29] stuartm: ok, latest cppcheck has an ignore facility
[21:45:47] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[21:46:16] kth (kth!~kth@unaffiliated/kth) has quit (Client Quit)
[22:01:23] Beirdo: they did
[22:01:31] Beirdo: OK, let's do this. :)
[22:12:10] stuartm: example cppcheck output (there is an xml mode) – http://mythtv.pastebin.ca/2057073
[22:18:06] stuartm: there can and will be false positives, but we can add those to the suppression list
[22:20:48] Beirdo: yay, 8 more lovely warnings... gone
[22:22:12] Beirdo: yeah, I think cppcheck is definitely something we want to run at least daily
[22:23:35] Beirdo: I'm sure it will find a few more oopses that will catch up to us eventually
[22:25:01] j-rod is now known as j-rod|afk
[22:26:23] Beirdo: I can't figure out (yet) where the qHash warnings are being triggered
[22:26:52] Beirdo: I guess I could go through the stdout and figure out which file(s) make it hit
[22:28:42] stuartm: http://mythtv.pastebin.ca/2057080 << Full output with default checks, it skipped a lot of files because checking them would have taken too long (lots of ifdefs) but again we can force it to check those too
[22:28:46] Beirdo: looks like mythfrontend/exitprompt.cpp
[22:28:49] stuartm: we can also enable additional checks
[22:29:19] Beirdo: nice
[22:29:20] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds)
[22:29:28] Beirdo: ooh, potential memory leaks.
[22:29:37] stuartm: fwiw I know several of those are false positives, most of the real errors I fixed months ago
[22:29:56] Beirdo: yeah
[22:30:50] stuartm: I'll leave a complete, forced check running overnight and see what it produces
[22:31:14] Beirdo: OK, sounds good. How long does it take, and on what system?
[22:31:30] stuartm: it's going to take a lot longer because it checks every possible configuration which is where those ifdefs come in
[22:33:08] Beirdo: ahhh, nasty, but potentially helpful
[22:33:43] stuartm: Beirdo: it's slow, 30+ minutes at the defaults and ignoring external/, slower still if we force a check of all configs, but this is only a dual core 2.5Ghz and I was doing other things while it was running
[22:34:35] stuartm: I think we can ignore some other third party stuff like livemedia, hdhr etc
[22:34:40] stuartm: that should help
[22:34:43] Beirdo: K. So definitely a once-a-day or once-a-week sorta thing, not every commit ;)
[22:34:55] stuartm: definitately
[22:35:26] stuartm: I'd reckon once a week would be fine, new issues aren't going to be introduced that often
[22:35:45] Beirdo: I'd hope not
[22:36:06] kormoc: stuartm, if it'd help, I have a 24 core box I could do complete runs on (as long as it doesn't need to actually run the gfx)
[22:36:25] Beirdo: 24?! wow
[22:36:31] stuartm: I'll play with the options, weigh the balance of cost vs benefit of each
[22:36:36] stuartm: kormoc: wow
[22:36:42] kormoc: Beirdo, dual 6 core with ht
[22:36:49] Beirdo: nice
[22:37:03] ** kormoc pets his databases lovingly **
[22:37:32] Beirdo: hehe
[22:37:36] stuartm: e.g. we can specify include paths so that it can check our use of external code, but that exponentially slows things down
[22:38:34] Beirdo: booo. I google for "warning: redundant redeclaration of qHash"
[22:38:47] Beirdo: top 3 results are warnings from our buildbot
[22:38:51] Beirdo: dammit
[22:40:13] stuartm: truthfully I suspect Coverity kicks cppcheck's arse but there really isn't any choice when it comes to free (or open source) static analysis tools, cppcheck and a couple of less general tools like krazy2 are all that's available
[22:40:25] Beirdo: yeah
[22:40:35] Beirdo: every bit can help though
[22:41:41] stuartm: it has caught a number of problems in the past, which makes the output I pasted earlier seem less useful – all the juicy stuff got fixed already
[22:41:56] Beirdo: :)
[22:42:12] Beirdo: which has likely saved us numerous headscratching sessions
[22:44:17] Beirdo: so those two qHash warnings... dunno how to fix. It may just be the version of Qt. It's triggered by including QtDBus in the exit prompt part of the frontend
[22:44:32] stuartm: I like krazy2 personally for it's identification of common QT performance pitfalls but most of that stuff falls in the 'minor' category, I've annoyed a lot of people by committing fixes for that stuff and the benefits weren't really tangible
[22:44:55] stuartm: Beirdo: I'd ignore them, blame QT
[22:45:09] Beirdo: yeah, I think those are QT-isms
[22:45:33] Beirdo: the dispatchNow() ones we should deal with, and the avcodec_thread_init
[22:45:45] Beirdo: we'll get there
[22:46:27] stuartm: you're welcome to tackle the dispatchNow() stuff, it's not a quick fix :)
[22:47:05] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:47:26] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Remote host closed the connection)
[22:47:31] stuartm: I think most of us have already passed the buck on that one, I guess Paul might have looked at it again in his mythmusic re-write, maybe someone should ask him
[22:47:57] Beirdo: heh
[22:48:15] jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv
[22:48:15] jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host)
[22:48:15] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:52:36] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 252 seconds)
[23:02:04] Beirdo: I guess I'll take a look,see if I can understand what needs to go in to replace it
[23:11:26] Beirdo: well, first off, it has a memory leak, if I'm reading it right
[23:11:35] Beirdo: sendEvent doesn't autodelete events
[23:16:35] danielk22: Beirdo: I think there are only two places we use sendEvent()/dispatchNow(), a memory leak of the event wouldn't be my first worry. ;] deadlocks, segfaults, and UI freezes would be my first worries.
[23:17:50] Beirdo: yeah, agreed
[23:18:06] Beirdo: the tiny memory leak will be insignificant
[23:18:31] Beirdo: sendPlaybackStart and sendPlaybackEnd are the two spots
[23:19:07] Beirdo: easy to fix the pinhole leak in the process while thinking about how to do this though :)
[23:19:45] Beirdo: what I'm unsure of is *why* we are still using dispatchNow() instead of dispatch() on those two
[23:20:00] Beirdo: but code reading will likely show that out in tim
[23:20:04] Beirdo: time rather
[23:21:21] danielk22: Beirdo: Likely because we do something immediately after the dispatchNow() which relies on the event being processed.
[23:22:10] Beirdo: yeah. I'm kinda pondering the concept of using a signal instead, but just starting the brainstorming as it were.
[23:22:22] danielk22: Beirdo: The usual way to handle that is to break it into two events one that that initiates whatever we want do in the receiver and another event to do whatever needs to be done in the sender.
[23:23:21] Beirdo: ahh.
[23:23:23] danielk22: Beirdo: This can still be a problem if for some reason the event processing needs to happen in the thread doing the dispatchNow().
[23:26:20] Beirdo: seems that the only place that actually is decoding that event is mythmusic?
[23:28:02] Beirdo: oooh. to stop/restart background music playing.
[23:28:06] Beirdo: interesting
[23:36:57] stuartm: Beirdo: those two are used to stop/start mythmusic playing music when the user starts/ends playback of a video, they are time sensitive – mythmusic has to release the audio device before we try to open it for video playback
[23:37:13] Beirdo: yeah, that much I've determined
[23:37:28] Beirdo: I guess we can leave it for now pending the redone mythmusic
[23:37:29] stuartm: so you have, sorry I was catching up
[23:37:48] Beirdo: no problem, it's good to get confirmation
[23:37:48] ** stuartm goes back to idling **
[23:43:58] abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has quit (Quit: abqjp)
[23:46:37] jya (jya!~jyavenard@gw2.hydrix.com) has joined #mythtv
[23:46:37] jya (jya!~jyavenard@gw2.hydrix.com) has quit (Changing host)
[23:46:37] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv

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