MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (79):

aloril, Anssi, Beirdo, benklop_, brfransen, Captain_Murdoch, CeilingKitten, cesman, Chutt, clever, coling, Cougar, dblain, dekarl, ElmerFudd, fetzerch, foxbuntu, ghoti, Gibby, gigem, gregL, GreyFoxx, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer__, joe_____, joki, jpabq, jpabq_, jpharvey_, jst_, jwhite, jya, kc, kenni, kurre2, kwmonroe, laga, moparisthebest, mrand, MythBuild, MythLogBot, neufeld, NightMonkey, Nothing4You, nyloc, peper03, pkendall, poptix, purserj, quovodis, rhpot1991, robink, rsiebert, Seeker`, seld, skd5aner, sl1ce, SlappityJack, SmallR2002, sphery, sraue, stichnot, stuarta, stuartm, superm1, taylorr, tgm4883, toeb, tonsofpcs, tris, wagnerrp, wolfgang, XDS2010_, xris, _charly_
Wednesday, September 11th, 2013, 00:15 UTC
[00:15:31] jya: stichnot: that could be yes for the other screen (for the detail of a recording, the delay is clearly related to how long it takes for a frontend to respond to a status query)
[00:15:50] jya: i certainly do see the scheduler being kicked on whenever I modify something elsewhere
[00:16:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[00:23:30] SmallR2002 (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[00:25:53] MythBuild: build #2064 of doxygen-master is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/doxy . . . /builds/2064 blamelist: Stuart Morgan <smorgan@mythtv.org >, Mario Limonciello <superm1@ubuntu.com >, Jim Stichnoth <jstichnoth@mythtv.org >, Nicolas Riendeau <nriendeau@mythtv.org >
[00:44:48] knightr: not again (still one the blamelist... :-) )
[00:44:53] knightr: s/one/on
[01:08:23] jya: knightr: it's always your fault anyway :)
[01:09:34] wagnerrp_ (wagnerrp_!6b124e7a@gateway/web/freenode/ip.107.18.78.122) has joined #mythtv
[01:10:02] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Quit: Leaving)
[01:10:53] jya: peper03: i was checking that your changes didn't break the rewind issue (which the locking was supposed to fix)… So i looked for my beloved Barbie DVD, I notice now that I can't bring the menu to go immediately to the root menu when the DVD starts
[01:11:19] jya: so I'm stuck with minutes of copyright announcements….
[01:11:25] jya: a tad annoying
[01:12:13] wagnerrp_: MythBuild: force build 0.27-freebsd-64bit now
[01:12:14] MythBuild: build forced [ETA 11m44s]
[01:12:14] MythBuild: I'll give a shout when the build finishes
[01:12:14] MythBuild: build #40 of 0.27-freebsd-64bit is complete: Exception [6exception git] Build details are at http://code.mythtv.org/buildbot/builders/0.27 . . . it/builds/40
[01:12:28] wagnerrp_: i guess that's a real problem...
[01:14:11] robink (robink!~quassel@fatcat.creosotehill.org) has quit (Changing host)
[01:14:11] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[01:15:28] wagnerrp_: MythBuild: force build 0.27-freebsd-64bit now
[01:15:29] MythBuild: build forced [ETA 11m44s]
[01:15:29] MythBuild: I'll give a shout when the build finishes
[01:17:47] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[01:17:47] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[01:17:47] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[01:27:07] knightr: jya, I am beginning to think it is, I got that message quite a few times today... :)
[01:29:19] jya: what about we make --disable-mythlogserver the default ? that would fix a few issue (mythlogserver spawning 1000s of times, or segfault when quitting)
[01:35:30] MythBuild: Hey! build 0.27-freebsd-64bit #41 is complete: Failure [4failed git]
[01:35:30] ** MythLogBot http://code.mythtv.org/trac/ticket/41 **
[01:35:30] MythBuild: Build details are at http://code.mythtv.org/buildbot/builders/0.27 . . . it/builds/41
[01:37:28] wagnerrp_: MythBuild: force build 0.27-freebsd-64bit now
[01:37:29] MythBuild: build forced [ETA 11m44s]
[01:37:29] MythBuild: I'll give a shout when the build finishes
[01:47:55] jpharvey_ (jpharvey_!~jpharvey@host109-148-115-200.range109-148.btcentralplus.com) has quit (Ping timeout: 245 seconds)
[01:48:17] jpharvey_ (jpharvey_!~jpharvey@host109-148-115-200.range109-148.btcentralplus.com) has joined #mythtv
[01:57:29] MythBuild: Hey! build 0.27-freebsd-64bit #42 is complete: Failure [4failed git]
[01:57:29] ** MythLogBot http://code.mythtv.org/trac/ticket/42 **
[01:57:30] MythBuild: Build details are at http://code.mythtv.org/buildbot/builders/0.27 . . . it/builds/42
[01:59:18] wagnerrp_: MythBuild: force build 0.27-freebsd-64bit now
[01:59:18] MythBuild: build forced [ETA 11m44s]
[01:59:19] MythBuild: I'll give a shout when the build finishes
[02:21:20] MythBuild: build #43 of 0.27-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.27 . . . it/builds/43
[02:23:50] wagnerrp_: MythBuild: force build doxygen-master now
[02:23:51] MythBuild: build forced [ETA 6m51s]
[02:23:51] MythBuild: I'll give a shout when the build finishes
[02:26:30] dekarl (dekarl!~dekarl@p4FE853EE.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[02:26:53] dekarl (dekarl!~dekarl@p4FE85C86.dip0.t-ipconnect.de) has joined #mythtv
[02:30:30] MythBuild: build #2065 of doxygen-master is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/doxy . . . /builds/2065
[02:31:26] wagnerrp_ (wagnerrp_!6b124e7a@gateway/web/freenode/ip.107.18.78.122) has quit (Quit: Page closed)
[02:34:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[02:38:28] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 241 seconds)
[02:39:13] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:43:33] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:50:02] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[02:50:54] nyloc (nyloc!~quassel@p57B4F55E.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[02:52:55] nyloc (nyloc!~quassel@p5B26FFA9.dip0.t-ipconnect.de) has joined #mythtv
[03:14:37] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:15:26] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:16:50] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:19:57] dgeary2 (dgeary2!~debian@d110-33-217-107.mas801.nsw.optusnet.com.au) has joined #mythtv
[03:23:28] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:34:36] joki (joki!~joki@p548635C1.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[03:35:49] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Ping timeout: 240 seconds)
[03:36:51] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv
[03:40:35] joki (joki!~joki@p5486170D.dip0.t-ipconnect.de) has joined #mythtv
[03:43:22] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:44:46] stichnot: jya: yeah, your mythweb change regarding frontends definitely cleared up that one delay
[03:45:07] stichnot: I wouldn't have seen it except I happened to have one frontend offline
[03:45:31] jya: page takes still has much time to complete loading as before...
[03:45:42] jya: just doesn't wait until the end to show stuff
[03:46:14] jya: need to modify the php bindings so it only attempts to connect for say 5s
[03:46:26] jya: right now there's no timeout of any kind (at least none obvious)
[03:47:05] jya: it search the database to get the list of frontends which have network interface enabled… would have thought it would ask the backend for those
[03:48:12] stichnot: you're thinking of the backend returning the list of frontends that are currently actively connected?
[03:48:23] jya: well yes...
[03:48:34] jya: there's no such mechanism used by mythweb...
[03:48:53] stichnot: that should take a protocol change, so no go for 0.27... too bad
[03:49:29] jya: there's no such method currently?
[03:49:37] jya: how are the stuff using the service API doing ?
[03:49:56] stichnot: hmm, good question, maybe the mechanism is in fact there
[03:50:49] jya: i mean I start the iphone app that uses the service API
[03:50:55] jya: the list of frontend shows immediately
[03:58:25] dgeary2 (dgeary2!~debian@d110-33-217-107.mas801.nsw.optusnet.com.au) has quit (Quit: Ex-Chat)
[04:30:52] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[04:32:28] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[04:58:42] ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 264 seconds)
[05:30:42] bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv
[05:32:59] bill6502: FYI, MythTV Android Frontend uses Bonjour to discover the frontends & backends. Perhaps the iphone does the same.
[05:45:11] dekarl: I think providers who mess up dns should simply be liquidated. "we sell typos but break lots of stuff along the way" is a crap business model.
[05:46:30] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[05:54:40] bill6502 (bill6502!~bill@205.178.26.43) has left #mythtv ()
[06:04:10] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[06:04:21] ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 248 seconds)
[06:08:05] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[06:09:14] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 240 seconds)
[06:09:44] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[06:12:06] jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has quit (Ping timeout: 245 seconds)
[06:13:02] jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has joined #mythtv
[06:32:54] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[06:49:56] jpharvey_: fr
[07:07:11] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[07:21:22] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[07:26:51] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Read error: Connection reset by peer)
[07:27:16] cesman (cesman!~cesman@pool-108-23-186-248.lsanca.fios.verizon.net) has joined #mythtv
[07:39:46] SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has joined #mythtv
[07:59:42] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:19:12] peper03: jya: Do you mean you can't call up the OSD menu? It seems to work ok here. Does it work if you revert my commit?
[08:24:23] peper03: stichnot: I was looking at the patch from #11186. In principle it looks ok but then I noticed that the problem only seems to occur if VDPAU is used for playback. OpenGL works fine, which makes me think that the core problem lies elsewhere. Any thoughts/ideas?
[08:24:23] ** MythLogBot http://code.mythtv.org/trac/ticket/11186 **
[08:25:44] paul-h (paul-h!~Paul@2.216.195.232) has joined #mythtv
[08:41:17] jya: peper03: haven't tried… I doubt it had anything to do with your commit… must have happened before
[09:32:51] paul-h: jya: occasionally I still end up with both the music player and video player both playing at the same time. This time I was playing a radio stream and tried to test play a DVD from the Archive Utils menu
[09:33:46] paul-h: it's completely random though if I try to reproduce it again it works
[11:14:40] sphery: peper03: Re #11186, I'm pretty sure that when it comes to UI painters, the OpenGL painter supports negative coordinates and the Qt painter doesn't. This sounds like the same thing, but on the OSD side. (I'd bet with the Xv renderer, you'd also see problems?) Might want to talk with stuartm for his thoughts on it since I think negative coords aren't allowed, even though they work with OpenGL painter.
[11:14:40] ** MythLogBot http://code.mythtv.org/trac/ticket/11186 **
[11:16:59] stuartm: right, they aren't strictly allowed, although because they do happen to work with the GL painter (not by design) they are now used extensively and things like animations even depend on them
[11:20:12] stuarta: oh dear. sounds like something to fix soon.
[11:20:14] sphery: jya: Does the iphone app just query the DB for a list of host names in settings without actually checking to see if they're running? It seems the only problem with MythWeb is a) the fact that it actually tries to contact the hosts and b) broken/slow name resolution. So, perhaps we should either a) stop checking to see if the frontend is running on the host or b) put the name resolution for frontends in the DB (like we do with the ...
[11:20:20] sphery: ... backends--that's the reason we have users specify "this server" IP address for backends).
[11:20:50] stuarta: yeah, why does mythweb even try to contact the frontends?
[11:21:09] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv
[11:21:11] stuartm: stuarta: aye, but it's a bit of a chore and I've been putting off working on it for some time now
[11:21:37] stuarta: i've too many things on the "been putting this off" list
[11:22:20] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[11:22:46] stuartm: the only possible reason that mythweb has to query online frontends is for the 'remote control' stuff, and so it should only be doing it when accessing that particular page, not when displaying recording rules etc
[11:23:32] sphery: for the backends, we just have an BackendServerIP setting for the backends, we could add a similar setting for the frontends.
[11:23:51] sphery: stuartm: on any recording detail page, it allows you to "play on frontend" and such
[11:24:19] sphery: and it seems there's similar "do this on my frontend" stuff for other things, too
[11:26:13] stuartm: oops
[11:27:16] stuarta: ho hum
[11:27:18] stuartm: sphery: so we should just query the backend for connected frontends (and their addresses), we shouldn't need mythweb to ping all possible hostnames
[11:28:57] stuarta: exactly
[11:29:01] sphery: Yeah, seems like the best approach to me (but it does require storing IP addresses (IPv4 and/or IPv6) for frontends, too). As for the ping, MythWeb is using network control to "query location" (and checking that it's not "offline").
[11:29:05] stuarta: do we have this functionality already
[11:29:20] stuarta: sphery: why does it require storing the ip?
[11:29:23] stuartm: sphery: it doesn't, the backend knows the IP of all connected hosts
[11:29:36] sphery: storing IP addresses may or may not mean a new setting for users to have to fill out (likely will because of the whole "which address should we use" question)
[11:29:47] stuarta: i'm thinking of a registration list or similar, that the backend maintains, that can be queried.
[11:30:16] sphery: that would work if we can get that
[11:31:01] sphery: but it begs the question of why we force the user to specify backend IP address if it's something we can just figure out (well, at least before we tried to limit which addresses we were listening on)
[11:31:07] stuartm: stuarta: more or less already exists, only bit that is missing is the user-friendly 'frontend identifier' string, so we can display 'Play on BedroomTV' instead of 'Play on 10.0.0.34'
[11:31:48] sphery: and, really, I guess that means that our frontend is now binding to all addresses, so either way we have some lack of symmetry on the 2
[11:31:53] stuarta: sphery: also a good question. with all of upnp, bonjour etc, we should be able to make it "just work"
[11:32:14] stuartm: stuarta: we already do ...
[11:32:17] sphery: and myth protocol (FWIW, I will never have bonjour on my system)
[11:32:32] stuarta: me either
[11:32:32] stuartm: we use SSDP for auto-discovery of backends
[11:33:56] stuarta: i've lots of ideas currently popping into my head
[11:34:09] sphery: that said, the UPnP stuff requires long enough of a wait for replies that it's probably not something we should use on every page request for mythweb
[11:34:41] stuarta: imho mythweb should just query the backend, as it should already know
[11:35:10] sphery: having the backend (or database) maintain a list of frontends and their addresses seems the best way (how we get that list is the challenge)
[11:35:52] stuartm: right, frontends connect to the backend on startup and maintain that connection until they are shutdown, so the backend already has a list of connected clients – we even iterate over it when checking whether the backend is allowed to shutdown
[11:37:12] sphery: storing in the DB has the down side of showing old, no-longer-used frontends (which is what seems to have caused the problem here--there were still frontends with NetworkControlEnabled in the DB that no longer exist), and the name resolution would take forever to time out on each, but if we at least stored the IP address/didn't use "external" name resolution, we'd find out "immediately" that there's no frontend there
[11:39:47] sphery: Having the backend maintain a list of "recently active" frontends would be better (I'm assuming we'd want to allow playback on idle frontends, too)
[11:42:02] stuarta: sphery: i see no need to store it, it's a dynamic runtime thing
[11:42:21] stuarta: what is the state of my "mythtv system" *NOW*
[11:42:47] dekarl: Would anybody be willing to change the active EIT Scanner from having one list of transports each to sharing one list? (bonus points for involving the passive scanner and coming up with a way to update that list every now and then, too)
[11:42:49] dekarl: I'd like to order the channels to first scan the transport that carries everything, then switch to the transport with the least available guide data next and so on.
[11:43:10] dekarl: But I am not into multithreading and locking :/
[11:43:29] stuarta: dekarl: i've some good ideas in that area...
[11:44:03] stuarta: i've been thinking of a whole overall, which also ties in with dynamic automatic channel lineup handling.
[11:44:34] dekarl: Ohh, something like a background channel updater? (trying to avoid the word scan here)
[11:44:38] stuarta: yes
[11:45:02] dekarl: Now we are talking cool 1.0 stuff :)
[11:45:27] stuarta: it would need to walk the known muxes, to get the channel data
[11:45:28] stuarta: (and mux changes)
[11:45:56] stuarta: so it would be relatively trivial to do if (collect_eit) runEitScanner...
[11:46:27] dekarl: You could just look at the transport that carries the whole SI and pull all PAT/SDT in one go. (I think that Astra has that. Need to verify but the PAT on 19.2° announces it)
[11:47:05] dekarl: Thinking that the most visible stuff is on satelite with channels coming and going every other day
[11:47:19] stuarta: that was why i was thinking of it.
[11:47:35] stuarta: back in half hour or so, time for a walk
[12:12:56] stuartm: such an updater would have to avoid updating callsign, channum, xmltvid, visible and useonairguide if any of those were explicitly configured by the user – that means changes to the schema IMHO
[12:14:54] stuartm: we'd need to store 'userschanum', 'userscallsign' and turn 'useonairguide' into an enum (kNoEITPresent, kEITOn, kEITOff)
[12:17:28] dblain: stuartm, stuarta, sphery: re:frontend discovery – The backend already caches all SSDP announcements and makes it available with the "getDeviceList" method. It's not a service API implementation (only returns XML), but part of the upnp http extensions.
[12:21:02] JohnBergqvist (JohnBergqvist!~JohnBergq@79-67-250-255.dynamic.dsl.as9105.com) has joined #mythtv
[12:26:54] MythBuild: build #2066 of doxygen-master is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/doxy . . . /builds/2066 blamelist: Paul Harrison <pharrison@mythtv.org >, Marko Punnar <mythtv@aretaja.org >
[12:38:55] stuarta: stuartm: oh, yeah, there are plenty of schema changes required for the whole thing
[12:40:10] stuartm: stuarta: I might make those schema changes early in this cycle, it's a relatively simple step but it would also save me having to backup my channel table before every scan so I can copy back my preferences later
[12:40:13] stuarta: but hopefully we could also kill off those long standing, "the channel scanner overwrote my changes"
[12:40:17] stuarta: tickets
[12:40:47] stuartm: adding new channels should be optional
[12:41:05] stuartm: well add them, but if the users prefers mark them as !visible
[12:41:19] stuarta: i was thinking auto after a period of time
[12:41:54] stuartm: don't need the EPG cluttered with adult chat channels and shopping channels :)
[12:42:09] stuarta: but stuff like that we can make configurable
[12:42:11] stuartm: alternatively, we could filter based on default authority
[12:42:35] stuartm: bds.tv > /dev/null
[12:44:24] stuartm: crap.tv > /dev/null
[12:44:48] stuarta: that we should layer in a 2nd phase
[12:45:08] stuarta: i'd initially settle for not trashing user changes
[12:45:30] stuartm: when users complain they can't receive QVC we tell them MythTV is performing a public service and saving them from themselves
[12:49:01] stuarta: but things like also making the setup easier, by leveraging the dvbscan data for initial mux selection and stuff like that
[12:52:02] dekarl: hmm, the backend status could offer a list of "new channels" to look at and enable/disable (whatever the opposite of the users chosen default is)
[12:52:17] stuarta: there are *lots* of possible options we could use here
[12:53:27] dekarl: otoh, how would that work for the HLS Recorder? Or extend it to the Shoutcast recorder (not there yet). Needs a good concept that covers more cases then just satelite :)
[12:54:26] stuarta: indeed
[12:55:43] stuarta: dvb-* is fine, we know everything is signalled in a way we can find the info we want
[12:55:56] stuartm: a screen in the frontend listing new channels and giving the user the option to approve them would be great
[12:56:30] stuartm: and when I say new, I mean truly new – a channel moving or changing name shouldn't need user-intervention
[12:56:39] stuarta: tristate: auto-add, user-ask, never changr
[12:57:01] stuartm: yeah
[13:36:22] stichnot: peper03, sphery, stuartm: re #11186. SubtitleScreen::OptimiseDisplayedArea() shifts all the elements into the m_safeArea region, and calls MythUIType::SetArea() with the combined area of the elements, cropped to the m_safeArea limit. I vaguely recall MythUI possibly doing clipping based on SetArea(), but that the clipping is unreliable and works differently for different painters.
[13:36:22] ** MythLogBot http://code.mythtv.org/trac/ticket/11186 **
[13:37:15] stichnot: So my conclusion is that it's best to crop explicitly where possibly, like the patch does for top and left.
[13:37:50] stichnot: However, I would also add explicit cropping for right and bottom.
[13:39:16] stichnot: I've seen bad artifacts when attempting to draw outside m_safeArea due to lack of bottom/right clipping.
[13:40:08] stichnot: For example, you can see this on cc608/cc708 captions when you set the subtitle zoom to 200%.
[13:40:38] stichnot: I don't think it happens for srt subtitles because of the WrapLongLines() code
[14:02:54] JavaSucks (JavaSucks!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:03:08] JavaSucks is now known as Jordack
[14:13:21] JohnBergqvist (JohnBergqvist!~JohnBergq@79-67-250-255.dynamic.dsl.as9105.com) has quit (Quit: Leaving)
[14:15:11] Gibby (Gibby!~Gibby@184.170.249.223) has quit (Ping timeout: 260 seconds)
[14:16:47] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has joined #mythtv
[14:25:46] peper03: stichtnot,sphery,stuartm: Ok, thanks for that. I'll add the extra cropping then.
[14:27:49] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has quit (Ping timeout: 248 seconds)
[14:28:21] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has joined #mythtv
[14:30:03] Ankhwatcher (Ankhwatcher!~rory@80.111.79.219) has joined #mythtv
[14:30:12] Ankhwatcher (Ankhwatcher!~rory@80.111.79.219) has left #mythtv ()
[14:31:24] stichnot: peper03: thanks. Do you have a way to test the extra cropping? and btw, in that patch, I would use std::min() and std::max() instead of conditionals, for slightly better clarity.
[14:32:15] dekarl: oh my, even xkcd references are not good for seaching the chatlog... https://www.google.de/search?q=site:irc.mytht . . . com%2F927%2F
[14:34:04] stuarta: MythBuild: force build doxygen-master now
[14:34:04] MythBuild: build forced [ETA 6m44s]
[14:34:04] MythBuild: I'll give a shout when the build finishes
[14:40:51] MythBuild: build #2067 of doxygen-master is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/doxy . . . /builds/2067
[14:43:37] SlapJack (SlapJack!~Neo@c-71-192-243-243.hsd1.ma.comcast.net) has joined #mythtv
[14:48:53] gigem: stichnot: Re mythweb slowness, do you know what mythweb is sending/expecting and do you have a backend log? It's possible the sleep refactoring I did inadvertently delayed status updates.
[14:49:22] gigem: stichnot: Also, I like to see a backend log with -v schedule for your resume issue.
[14:55:58] stichnot: gigem: I'll gather that info within a couple hours.
[15:00:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 262 seconds)
[15:01:27] peper03: stichnot: I can certainly test it with DVD overlays. The code in the patch is added to SubtitleScreen::AddScaledImage, which as far as I can tell is only used for DVD highlights. I guess then that the cropping really needs to be done elsewhere if you say there are also issues with normal captions. I'll have to have a look at how that stuff works...
[15:08:58] rtjacob (rtjacob!~taylort3@user-0c8htht.cable.mindspring.com) has joined #mythtv
[15:12:16] gigem: stuarta: Okay.
[15:13:44] ** stuarta gets confused and runs away **
[15:14:29] rtjacob (rtjacob!~taylort3@user-0c8htht.cable.mindspring.com) has left #mythtv ("Leaving")
[15:25:07] jheizer__: LOL @ search via xkcd
[15:29:27] stuartm: great, deadlocked the frontend :)
[15:29:36] stuarta: \o/
[15:30:51] stuartm: MythPlayer::ChangeSpeed (this=0x3f80000004961000) at mythplayer.cpp:3605
[15:31:21] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[15:32:03] stuartm: and TVBrowseHelper::GetNextProgram (this=0x7ff36752a000, direction=32755, infoMap=...) at tvbrowsehelper.cpp:332
[15:34:37] stuartm: does anyone know how to stop gdb paging output? when you're logging the output having to hit return a hundred times to get through a full bt is a pain
[15:39:57] stuarta: pager none
[15:40:02] stuarta: or unset pager
[15:41:33] stuarta: iirc
[15:41:54] stuarta: a good thing is also to use `gcore` to capture a coredump which you can look at later
[15:43:21] stuarta: stuartm: ah also worth doing
[15:43:31] stuarta: set logging file <filename>
[15:43:34] stuarta: set logging on
[15:43:50] stuartm: yeah, I was using the logging, hence no need for the pager
[15:47:46] stuartm: thanks btw
[15:47:50] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:47:56] stuarta: np
[15:54:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[16:06:14] sphery: stuartm: per http://www.mythtv.org/wiki/Debugging#Create_a_gdb_script_file , set pagination off
[16:07:10] stuarta: ah yes, that's it :)
[16:09:58] stuartm: ah-hah, I should how known that – thanks for digging it up
[16:10:38] stuartm: I should create a new config for the times when you're attaching to a running process
[16:11:04] stuarta: so should i. things appear to be falling out of my brain again
[16:12:50] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Ping timeout: 264 seconds)
[16:13:07] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv
[16:16:48] stuartm: dblain: is there any way to dump the xml we're creating for debugging?
[16:22:54] SlappityJack (SlappityJack!~Neo@c-71-192-243-243.hsd1.ma.comcast.net) has joined #mythtv
[16:22:54] rsiebert (rsiebert!~quassel@g229052241.adsl.alicedsl.de) has joined #mythtv
[16:26:02] SlapJack (SlapJack!~Neo@c-71-192-243-243.hsd1.ma.comcast.net) has quit (Ping timeout: 264 seconds)
[16:26:16] rsiebert_ (rsiebert_!~quassel@e179168180.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds)
[16:34:57] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:42:30] stichnot: gigem: http://pastebin.com/qtuUZAVB is the mythbackend -v schedule excerpt. 9:37:25 is when I loaded the "Upcoming Recordings" mythweb page. 09:37:44 is when I clicked on the "Don't Record" button for some item. 09:38:14 is when the Upcoming Recordings page finally redisplayed.
[16:53:44] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:04:50] dblain: stuartm: which xml?
[17:07:21] ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 276 seconds)
[17:09:07] stuartm: cds object principally
[17:09:32] stuartm: although if I could print out the entire response that would be good
[17:10:16] stuartm: can do it via wireshark, but it's fiddly
[17:13:17] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[17:13:27] dblain: stuartm: I was just looking through the code and the debugging code I used to have isn't there any more. If you want to see all data mythbackend sends out of the httpserver, you would need to add something to libmythupnp/httprequest.cpp: HTTPRequest::SendResponse. Right before we zip up the content.
[17:14:07] dblain: (line 289)
[17:19:31] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[17:27:56] natanojl: paul-h: Isn't that python snippet on -users missing the assignments back to title?
[17:34:16] natanojl: paul-h: Another thing. http://code.mythtv.org/cgit/mythtv/tree/mythp . . . der.cpp#n264 is using a pointer into the temporary QByteArray returned by toLocal8Bit()
[17:42:21] stuartm: dblain: ok thanks
[17:59:31] brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 246 seconds)
[18:00:28] brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv
[18:06:47] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[18:10:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[18:12:27] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[18:16:38] MythBuild: build #2408 of cppcheck-master is complete: Failure [4failed shell shell_1] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/2408 blamelist: Marko Punnar <mythtv@aretaja.org >
[18:18:21] stuarta: i need to tweak the max jobs settings on the buildmaster
[18:18:26] stuarta: do that in a bit
[18:31:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[18:35:21] paul-h: natanojl: Oh! Obvious now you've pointed it out. Thanks :)
[18:35:41] gigem: stichnot: (Hey to bad timeing) I don't see anything obviously wrong, but unfortunately, there is no logging for the thing I really wanted to see. Can you add a LOG() when the SCHEDULE_CHANGE event is sent near the end of Scheduler::run(). That being delayed is the only thing I can think of that mythweb would be waiting on.
[18:35:48] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[18:38:20] gigem: stichnot: Check the log for right after you got bumped off.
[18:51:11] danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv ()
[19:03:05] natanojl: paul-h: :)
[19:03:17] natanojl: yw
[19:48:17] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection)
[19:48:50] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv
[19:52:57] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[19:53:30] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[19:57:28] stuartm: some of these software upnp/dlna clients I'm testing are badly behaved, one re-requests the artwork for all tracks/videos in the current playlist every few seconds – something that is going to negatively impact on the network and the performance of the backend that is having to serve up all those images :(
[19:58:57] dekarl: hmm, is it at least asking for modified-since or changed etag? some caching might help then
[20:01:09] stuartm: dunno yet, something I'll investigate later
[20:02:02] stuartm: at least one client says that the 'server doesn't support content browsing', so now I'm going to read the specs a little more to find out what response the client was expecting to that query
[20:19:17] skd5aner: Is the "logging" table no longer used in 0.27?
[20:27:26] skd5aner: ever since upgrading to 0.27, my logging table hasn't had any new entries
[20:33:18] paul-h: skd5aner: db logging is disabled by default in 0.27 you need to add --enable-dblog to enable it
[20:34:55] skd5aner: ah, that's what that flag meant... I saw that and interpreted it wrongly...
[20:35:45] skd5aner: as an FYI, mythweb still has a "Backend Logs" tab by default, so that might confuse some people as to why it has old, stale data in it – or, for new users, why it's empty
[20:51:31] SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[20:52:22] stuartm: I didn't even know that mythweb had been updated to display stuff from the new logging table
[20:53:24] stuartm: skd5aner: where is that tab?
[20:54:35] mrand: stuartm: I realize it might increase complexity a lot, but perhaps a per-client timeout (perhaps with the ability to adjust or disable) on serving up the stuff that gets re-requested?
[20:54:56] skd5aner: stuartm: yea, as of 0.25 or 0.26 it was there
[20:55:13] stuartm: skd5aner: doesn't appear to be there in 0.27
[20:55:16] skd5aner: stuartm: at the top of the screen
[20:55:20] skd5aner: weird, it's there for me
[20:55:28] skd5aner: and was in 0.26 for sure too :)
[20:55:43] skd5aner: To the right of "Backend Status" near the top of the screen
[20:56:30] skd5aner: stuartm: http://www.mythtv.org/img/screenshots/mythweb_upcoming.png&nb sp;:)
[20:56:56] stuartm: not there for me in 0.27, there was an old link to an old log table in earlier releases – that table wasn't really a full log, more of a selected events log that contained largely useless information (e.g. every single reschedule was listed)
[20:57:39] skd5aner: I'm using the mythweb RC release... let me go find the file it shows up in...
[20:58:05] skd5aner: btw, is there any "easy" way to search through the source ?
[20:58:27] stuartm: skd5aner: I'm using an earlier 'master' package from the ubuntu repo
[21:03:59] stuartm: stuarta: cppcheck builder is failing
[21:04:25] stuartm: stuarta: n/m, missed your earlier comment
[21:07:05] stuarta: it's still failing :(
[21:07:16] skd5aner: stuartm: https://github.com/MythTV/mythweb/blob/master . . . der.php#L226
[21:07:32] dekarl: skd5aner: git grep? and git log --grep?
[21:07:45] skd5aner: dekarl: thanks
[21:10:32] stuartm: strange, guess I don't have the backed_log module but I've no idea why as I presume it's part of the default package
[21:20:50] skd5aner: yea, I don't think I did anything special...
[21:24:27] skd5aner: stuartm: figured it out... if LogEnabled is set to 1 in the settings table, it'll show up
[21:24:52] skd5aner: I set it to 0, and it disappears in mythweb
[21:25:08] skd5aner: is there any harm in keeping that at 0? Is that setting even needed in the DB anymore?
[21:26:36] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[21:26:57] stuartm: that's the old logging mechanism, thought it had been ripped out alreadt
[21:27:00] stuartm: already
[21:28:40] jya: paul-h: i didn't do anything about the archive utils, so it defines a player it too will need to be modified so it handles being stop/restarted by other players
[21:28:43] stuarta: cppcheck build should work again now
[21:28:47] stuarta: it's building atm
[21:30:40] skd5aner: stuartm: Apparently, not :) ^sphery
[21:32:30] jya: stuartm: if the recording rule actually created a recording; then the detail page shows a "play in this frontend" and does so for each frontend responding… that can take a while to be rendered
[21:33:32] stuarta: jya: while you were out we had this "< dblain> stuartm, stuarta, sphery: re:frontend discovery – The backend already caches all SSDP announcements and makes it available with the "getDeviceList" method. It's not a service API implementation (only returns XML), but part of the upnp http extensions.
[21:34:02] stuarta: jya: maybe that's something we could leverage in mythweb?
[21:35:58] jya: gigem: it seems that whenever mythweb cause the scheduler to kick; it now takes a long time for the page to complete loading/saving… that happens when you create a recording (but I was seeing this with 0.26 too) and when you edit the channel list.
[21:37:03] ** jya why such a hatred toward Bonjour/ZeroConf… it now comes by default on most OS and linux distributions. it works well, and does everything we need…. **
[21:37:32] stuarta: i need to look into it, i'm all for nice easy config
[21:38:08] skd5aner: jya: I had pointed the same thing out to gigem a few times over the last several months in regards to creating new recording rules in mythweb via 0.26
[21:38:31] skd5aner: Many times, the page would finally load as if the rule had never been created...
[21:38:52] jya: stuarta: i had just read about dblain suggesting… just catching up on all the emails..
[21:39:13] stuarta: hah, i'm still 4k emails behind :)
[21:39:29] ** stuarta goes to install libdns_sd onto his build slaves **
[21:39:41] MythBuild: build #2413 of cppcheck-master is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/2413
[21:40:00] jya: stuarta: every single stuff I use that works straight out of the box are all bonjour based. Got a new printer for my uncle last week. Plugged it, connected to wifi. bang was shown in the list of printers … drivers got installed automatically… perfect
[21:40:16] jya: anyone else got an email from google about seeing our profile on ohlo ?
[21:41:04] jya: skd5aner: validating the recording creation takes a while (so long I never even bother waiting for it to complite) so I just press refresh. and each time the recording has been properly created...
[21:41:19] jya: it just takes forever to save, but it is actually done very quickly
[21:41:42] skd5aner: yea, I have had instances where even after 5+ minutes, the rule still doesn't show up in mythweb
[21:42:08] jya: I got an email from google "scouting team" that they saw my C++ stuff on ohlo and wanted to chat… we're all linked on ohlo I believe
[21:42:32] jya: skd5aner: when that occurs, if I press the recording rule link: i always find that the rule has been created
[21:43:07] skd5aner: I'll give it a shot, but I know that if I go and search for the rule in the recording rules list, or search for hte show, that it still doesn't show as scheduled – and if I refresh the recording rule page, it still won't show up
[21:43:19] skd5aner: that said, I havne't really tested with 0.27 to see if it's any better
[21:43:53] stuarta: jya: not me, it's your turn this time, they've emailed me a few times before
[21:44:00] skd5aner: I did have a miserable time with an HD-PVR recording that consantly kicked back to the menu while trying to playback in 0.27 last night... didn't really analyze it too much, but I'm hoping that was a fluke
[21:44:19] jya: the other thing I can do. I press save for the recording rule (or update not sure), then I go to tv listing (while it's still waiting) and I see the program being highlighted … it really feels that other than the wait , everything is okay
[21:44:44] jya: ohhh… made platinum on virgin … 4 confirmed upgrade
[21:44:47] skd5aner: yea, in that scenario for me, it still wouldn't be highlighted :(
[21:46:15] stuartm: jya: yeah, had that email last year
[21:46:33] jya: did you contact them?
[21:46:38] taylorr: skd5aner: is the HD-PVR recording an old before the changes to start recording on a keyframe went in?
[21:49:59] stuartm: yeah, but it didn't amount to much, got the impression that despite the email claiming to know quite a bit about me and being impressed with my resume that it was a standard copy/paste job :) They were looking for 'Sys admins with C/C++' stills to work on 'infrastructure'
[21:51:01] stuartm: that much didn't appeal to me, and once it became clear that it would mean relocating to London I just sent them a polite 'not interested'
[21:51:34] skd5aner: taylorr: it was a new recording – in progress at the time
[21:53:12] stuarta: libs installed
[21:53:28] skd5aner: taylorr: occasionally, the video seems to be at a weird resolution... the video will only fill the center portion of hte screen – I have to go in to the zoom mode and go to "full" and then it fits almost exactly. This hapened to be one of those times
[21:53:50] skd5aner: taylorr: I'm not sure why that is – if it's becasue the STB is outputting it at that size, or if the HDPVR is encoding it wrong, or what
[21:54:23] stuartm: of course my deep seated distrust of Google probably wouldn't have got me far through the interview process, but had they been offering me something interesting and not based in London I may have pursued it
[21:55:22] stuarta: they chased me a few times for "site reliability engineering"
[21:55:22] jya: stuartm: I'm not interested to work for anyone… but I like knowing what I'm still worth on the market… I'm not getting any younger :)
[21:55:51] jya: they mentioned opportunities in Australia, or leadership positing in california...
[21:56:10] jya: site reliabilitiy engineering :)
[21:56:14] jya: lol
[21:56:27] jya: they like their titles the americans
[21:56:33] stuarta: you too?
[21:56:37] stuartm: jya: yeah, the email was flattering certainly, although I do still wonder how many people received an identical one
[21:56:54] jya: stuarta: no no… was just repeating what you said
[21:57:03] jya: stuartm: exactly, why I ask here
[21:57:23] stuarta: i can summarize the interview process with "you want me to tell you about what? go read the bloody rfc if you want to know"
[21:57:46] stuarta: i'm not a smegging walking rfc reguritator
[21:57:47] stuartm: "I am currently looking for Engineers with hybrid Unix/Linux Systems
[21:57:48] stuartm: Administrators who possess experience in coding in C/C++ or Java and/or scripting skills (Python, Perl, or Shell)."
[21:57:59] stuartm: is the exact quote from the initial email
[21:58:10] stuarta: that is about as useful as a chocolate teapot
[22:00:30] stuartm: I thought that was an impressively broad spread – shotgun approach to head hunting – "here's a list of programming and scripting languages, pick one"
[22:01:18] stuarta: yeah, then they work through what you know about each one afterwards
[22:01:35] stuarta: i'd much rather be where i am
[22:11:30] paul-h: jya: the archive utils uses the normal handleMedia() function so if it's broke there it's broke everywhere that is used
[22:18:14] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 264 seconds)
[22:20:55] paul-h (paul-h!~Paul@2.216.195.232) has quit (Quit: Konversation terminated!)
[22:21:07] jya: paul-h: if you can tell me how to reproduce your setup.. I can give it a try..
[22:31:16] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[22:33:17] taylorr: skd5aner: are you using a more recent HD-PVR firmware?
[22:39:49] gigem: jya: If I knew what mythweb was expecting, it would probably an easy fix. Itried looking throught the php code, but quickly got lost. xris or kormoc, if you see this, what does mythweb expect after it creates/modifies a recording rule?
[22:39:51] gigem: skd5aner: I don't recall hearing about this problem before. If I did, I must not have understood it.
[22:40:38] xris: gigem: not sure what you mean. the record format? or a specific response?
[22:40:56] skd5aner: gigem: yea, now orries... it was part of the issues I was reporting to you when the scheduler seemed to be taking an extremely long amount of time, and I had mentioned that it was impacting mythweb's ability to even register that a rule had been created...
[22:41:04] skd5aner: *no worries
[22:41:37] skd5aner: taylorr: Yes, although I don't recall which revision off the top of my head, but I know I updated it sometime earlier this year
[22:42:41] jya: gigem: everytime I validate in mythweb, I can see in the backend log something related to the scheduler
[22:48:36] gigem: xris: jya or stichnot can probably describe it better, but as I understand it, whenever they create a new rule or modify a rule, the mythweb page doesn't update for quite some time. For example, stichnot had a log where he clicked on "Don't record" and the page didn't refresh until about 30 seconds later even thought the reschedule only took 0.4 seconds.
[22:50:08] gigem: skd5aner: Okay, I probably assumed it was the result of your unusually long schedule times and didn't think anymore about it.
[22:50:55] skd5aner: gigem, xris: even worse for me, the page eventually loads and NONE of the changes are reflected, so it appears like nothing at all happened – be it adding a rule, or editing a rule
[22:51:16] skd5aner: gigem: me too, honestly – so glad to hear that it might not be just me :)
[22:51:29] xris: skd5aner: mythweb shoudl query the server immediately for the data
[22:51:46] xris: if you manually refresh and still get the same outdated results, it's not mythweb
[22:51:51] xris: unless kormoc added caching that I don't remember
[22:52:50] skd5aner: I haven't given it a go in 0.27, but in 0.26... after 15–30 seconds after creating a rule, the page would refresh, and it would still have all the data exactly as if the rule had never been set up. I could go in an hour later, refresh, and see the rule
[22:53:10] skd5aner: yes, if I manually refresh, same issue
[22:53:39] skd5aner: as jya mentioned, I can see the backend logs kicking off the scheduler each time, and I think the metadata grabber launching too
[22:54:48] skd5aner: there were times where I'd end up with multiple of the same exact rule set up because at first I thought that maybe it just didn't go through – then once everything "caught up", I'd see the same rule in the system 2, 3, 4 times because I kept trying to resubmit the rule
[22:54:51] jya: FWIW, 0.26 behaved the same for me… cfreating a recording, saving would always take forever
[22:55:33] skd5aner: I actually really love mythweb for setting rules way more than I do the frontend... when it works :)
[22:56:42] skd5aner: does daniel frey hang out in here?
[23:04:01] jya: skd5aner: ditto, I always create my recordings using mythweb
[23:23:18] stichnot: gigem: Adding -v network to the backend also gives an indication of when MythEvents are being dispatched. In my case, a SCHEDULE_CHANGE event is sent immediately after the reschedule, then you can see that it's sent over several sockets, presumably to the connected frontends plus the mythweb instance. 30 seconds later, mythweb responds over the socket with DONE and appears to disconnect.
[23:24:17] stichnot: This 30 seconds is consistent on my machine, but surprising given that listenForEvent() in MythBackend.php uses a default timeout of 120 seconds.
[23:26:34] stichnot: skd5aner: If your reschedule was taking longer than 120 seconds, I think the mythweb page would come back and appear that no schedule change was made, though a refresh later might change that
[23:33:18] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[23:35:11] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:51:56] stichnot: and guys, don't judge a company solely on the quality of its recruiting sourcers :)

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