:: #mythtv

Daily chat history

Current users (79):

aloril, Anssi, Beirdo, 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, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stichnot, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wolfgang, XDS2010_, xris, _charly_
Thursday, September 12th, 2013, 00:04 UTC
[00:04:15] stichnot: gigem, xris, jya, skd5aner, dekarl: This seems to be the source of the mythweb reschedule delay problem: . . . 1aa45/mythtv
[00:05:06] xris: odd
[00:05:17] jya: stichnot: that commit is only 5 weeks old.. I've had the problem for much long
[00:05:18] jya: er
[00:06:08] jya: but worth a try
[00:07:16] stichnot: it matches the timeframe that I've seen my problem, so maybe it's not the only problem...
[00:07:54] stichnot: it also explains the exactly 30 second delay I see, due to function receiveData($timeout = 30) in MythBackend.php
[00:09:51] xris: mythweb shouldn't need to handle messages.. php is single-fire so theoretically by the time the event fires there is no more "php" to receive the event.
[00:10:59] stichnot: I thought mythweb wants to wait for a message that the backend has completed the reschedule before displaying the new page
[00:11:21] stichnot: otherwise the user still sees the old data and thinks it didn't work
[00:12:56] stichnot: of course, in this case mythweb will respond to any SCHEDULE_CHANGE message so it still might redisplay too soon
[00:13:19] xris: no clue.. last time I touched that, the message system didn't exist.
[00:13:36] stichnot: (also keep in mind that I know next to nothing about php)
[00:23:08] dblain: anyone available to put a ssh key on alcor for me? stuarta was going to help but I think he's away for the night due to the time difference. (it's for my buildslave so it can access the git repositories)
[00:44:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[00:45:12] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:59:12] gigem: stichnot: Just from the commit message, that looks like the culprit. I was just about to install mythweb, but I guess I don't need to do that now. You're right about mythweb potentially returning to quickly on any SCHEDULE_CHANGE event. We would need to add some sort schedule request ID for anything like that to work.
[01:01:02] IReboot (IReboot! has quit (Quit: Ex-Chat)
[01:28:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[01:45:14] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[01:45:58] skd5aner: gigem: preliminary observation – scheduling is MUCH MUCH more responsive for me since upgrading to 0.27
[01:46:22] skd5aner: subjectively, at least... I haven't really tried to do an objective test and look at the metrics
[01:51:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:51:52] stichnot: skd5aner: do you know if your mythmote/pause/timestretch problem was fixed?
[02:15:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[02:26:25] dekarl1 (dekarl1! has joined #mythtv
[02:27:11] dekarl (dekarl! has quit (Ping timeout: 240 seconds)
[02:37:11] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[02:42:03] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:48:45] _nyloc_ (_nyloc_! has joined #mythtv
[02:53:12] nyloc (nyloc! has quit (Ping timeout: 260 seconds)
[03:04:16] gigem: skd5aner: That's good to hear. Someone posted on the -users mailing list that scheduling was twice as fast for him in 0.27.
[03:14:52] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[03:15:55] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:24:04] CeilingKitten (CeilingKitten! has quit (Ping timeout: 246 seconds)
[03:24:37] CeilingKitten (CeilingKitten! has joined #mythtv
[03:36:16] joki (joki! has quit (Ping timeout: 245 seconds)
[03:41:24] joki (joki! has joined #mythtv
[03:51:27] OldEnK (OldEnK! has joined #mythtv
[04:15:28] OldEnK (OldEnK! has left #mythtv ("Leaving")
[04:34:52] dekarl1: meh, was just wondering if it might be related to me fiddling with the "mythweb doesnt handle events in the recording list" change... but I see stichnot already had the same idea :/
[04:35:56] dekarl1 is now known as dekarl
[04:36:32] dekarl: looks like we need a parameter then. some parts want events others break with them
[04:47:30] SlipperyJack (SlipperyJack! has joined #mythtv
[04:50:52] SlappityJack (SlappityJack! has quit (Ping timeout: 264 seconds)
[05:07:05] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[05:07:45] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[05:09:27] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 260 seconds)
[05:09:28] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 260 seconds)
[05:12:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:09:31] FabriceMG (FabriceMG! has joined #mythtv
[06:12:22] SteveGoodey (SteveGoodey! has joined #mythtv
[06:20:57] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[06:37:42] Tobbe5178 (Tobbe5178! has joined #mythtv
[06:40:42] Sharky112065 (Sharky112065! has joined #mythtv
[06:45:28] FabriceMG (FabriceMG! has quit (Ping timeout: 264 seconds)
[06:45:58] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:52:29] FabriceMG (FabriceMG!~Thunderbi@ has quit (Ping timeout: 256 seconds)
[06:56:20] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[07:06:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[07:29:20] SlipperyJack (SlipperyJack! has quit (Ping timeout: 240 seconds)
[07:46:05] _nyloc_ (_nyloc_! has quit (Remote host closed the connection)
[07:48:39] nyloc (nyloc! has joined #mythtv
[07:59:22] Merlin83b (Merlin83b! has joined #mythtv
[08:07:50] FabriceMG (FabriceMG!~Thunderbi@ has quit (Ping timeout: 256 seconds)
[08:25:42] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[09:09:02] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[09:11:58] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[09:20:55] FabriceMG1 (FabriceMG1! has joined #mythtv
[09:23:02] FabriceMG (FabriceMG!~Thunderbi@ has quit (Ping timeout: 264 seconds)
[10:05:42] CeilingKitten (CeilingKitten! has quit (Ping timeout: 256 seconds)
[10:07:05] FabriceMG1 (FabriceMG1! has quit (Ping timeout: 245 seconds)
[10:36:22] IReboot (IReboot! has joined #mythtv
[11:22:38] Chutt_ (Chutt_! has joined #mythtv
[11:25:55] Chutt (Chutt! has quit (Ping timeout: 260 seconds)
[11:26:29] jheizer__ (jheizer__! has quit (Ping timeout: 248 seconds)
[11:38:09] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[12:03:08] sphery: stuartm / skd5aner : the mythweb logging stuff was a broken/useless implementation that should have been ripped out rather than "updated" to use the new logging table. It's best to just remove it now. It probably only shows up if you have the old DB logging setting set in your system, but it should never show up (not even if the user is using db logging) since it's the old implementation which is completely broken for the new logging stuff.
[12:06:27] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[12:06:51] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[12:46:46] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[13:03:52] bobweaver (bobweaver!~bobweaver@unaffiliated/bobweaver) has joined #mythtv
[13:14:00] stichnot: jya: Did you mean for your "Partially Fixes #11051" commit message to close the ticket?
[13:19:35] jheizer (jheizer! has joined #mythtv
[13:52:50] benklop_ (benklop_! has quit (Remote host closed the connection)
[13:55:56] benklop_ (benklop_!~quassel@2001:470:f400:47:ae81:12ff:fe31:668b) has joined #mythtv
[14:04:24] stichnot: wagnerrp, sphery: Could you review the mythutil patch I just added to #10804 ? The purpose is to allow "--video path/to/foo.mpg" instead of "--chanid c --starttime s" so that we can operate on markup data of Video Gallery videos as well as recordings. The downside is that the rules for --chanid/--starttime/--video no longer appear as clearly in the help message. wagnerrp, maybe there's a...
[14:04:24] ** MythLogBot **
[14:04:25] stichnot: ...better way to express the rules in the command line parser?
[14:07:16] stichnot: The selfish purpose of this ticket is so that I can copy a recording from my production system to the Video Gallery on my laptop for watching away from home, and to easily get the cutlist from the recording.
[14:47:09] Jordack (Jordack! has joined #mythtv
[14:51:40] sphery: stichnot: why not use the --file argument we used for mythcommflag, but make it figure out whether it's a recording or video (so that users don't have to know/care)? (Of course, that would imply that we'd need to update mythcommflag to figure it out, too...  :)
[14:53:03] sphery: otherwise, it seems that if mythcommflag allows --file for recordings and --video for videos, mythutil should, too
[14:54:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[15:14:07] jpabq_ (jpabq_! has joined #mythtv
[15:14:08] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[15:15:04] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Disconnected by services)
[15:15:11] jpabq_ is now known as jpabq
[15:15:23] jpabq (jpabq! has quit (Changing host)
[15:15:24] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[15:16:24] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv
[15:16:48] MythBuild (MythBuild! has quit (Remote host closed the connection)
[15:16:59] MythBuild (MythBuild! has joined #mythtv
[15:17:12] pagios (pagios!~pagios@ has joined #mythtv
[15:17:14] pagios: hi guys
[15:17:15] pagios: hauppage WinTV HVR-4400
[15:17:17] pagios: good or bad
[15:17:17] MythBuild (MythBuild! has quit (Remote host closed the connection)
[15:17:31] MythBuild (MythBuild! has joined #mythtv
[15:17:46] stuarta: pagios: #mythtv-users
[15:18:42] MythBuild (MythBuild! has quit (Remote host closed the connection)
[15:18:50] pagios (pagios!~pagios@ has left #mythtv ("Leaving")
[15:19:04] MythBuild (MythBuild! has joined #mythtv
[15:26:05] Chutt_ is now known as Chutt
[15:30:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:35:33] stichnot: gigem: another backend deadlock, possibly scheduler related:
[15:37:51] stuarta: build network is now building dblain's msvc branch instead of the logging branch
[15:43:08] stichnot: sphery: let me look into the --file argument. TBH, I've never had much luck with it, but...
[15:45:46] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[15:54:45] bobweaver (bobweaver!~bobweaver@unaffiliated/bobweaver) has quit (Quit: Leaving)
[15:55:58] dblain: one build failed in code I didn't change... guess I need to do another merge from master. (it may get noisy in here for a bit)
[15:59:51] gigem: stichnot: Is that after a resume? If so, I really need the log with -v schedule to see why the main loop isn't relinquishing the lock. Even if not so, I need the same log because your backtrace looks normal. Yes, there is a thread waiting on the lock, but the main thread is not in a place where it should be holding the lock for long.
[16:04:26] stichnot: gigem: yes, after a suspend, I resumed the laptop and found mythbackend in this state. I'll add -v schedule logs next time. If it happens to be an autoexpire problem, is there any logging option that would help there?
[16:17:44] stichnot: stuartm: I apparently have a bug in SubtitleScreen::Clear708Cache(), in which I create an iterator over m_ChildrenList and then sometimes call DeleteChild() on some of the iterator values. Do you have any suggestions on how to do this correctly, and possibly even efficiently? Otherwise I'm thinking of just iterating over a copy of m_ChildrenList.
[16:21:19] stuartm: stichnot: assuming you don't know ahead of time which children you need to delete (i.e. by name), then no I can't think of a better way atm
[16:22:45] dblain: stuarta: looks like your out of space on stuarta-f18–64bit
[16:22:49] stuartm: well you could just call delete directly, DeleteChild() isn't virtual and it's behaviour is very simple, it iterates over the child list to find the requested child then just deletes it
[16:22:56] rsiebert_ (rsiebert_! has joined #mythtv
[16:23:56] stuartm: delete child; it.remove(); child = NULL;
[16:26:02] rsiebert (rsiebert! has quit (Ping timeout: 264 seconds)
[16:26:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[16:30:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:31:14] SteveGoodey (SteveGoodey! has joined #mythtv
[16:31:36] stichnot: stuartm: I'm hesitant to delete directly in case the implementation of m_ChildrenList or DeleteChild() changes in the future
[16:32:39] stichnot: I'll probably just go with iterating over a copy of the list, after all what's an extra linear copy on top of a quadratic algorithm? :)
[16:33:45] benklop_ (benklop_!~quassel@2001:470:f400:47:ae81:12ff:fe31:668b) has quit (Ping timeout: 245 seconds)
[16:33:58] stichnot: The number of SubtitleScreen children is usually a single digit, so complexity isn't really a big deal here
[16:38:22] ** dblain guesses the build slaves building my branch don't log errors here... looks like I'm the only one make noise around here! **
[16:40:30] gigem: stichnot: I don't think there's an autoexpire issue, but even if there is, it's not related to why the scheduler isn't relinquishing the lock in the main loop.
[16:41:29] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[16:44:17] SteveGoodey (SteveGoodey! has joined #mythtv
[16:48:48] MythBuild: build #1 of msvc-linux-64bit-qt5 is complete: Success [3build successful] Build details are at . . . qt5/builds/1
[16:52:35] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[16:53:13] MythBuild: build #4399 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at . . . /builds/4399 blamelist: Jim Stichnoth < >
[16:54:02] Merlin83b (Merlin83b! has quit (Quit: Leaving)
[16:54:55] jpabq: stichnot: at least with STL, if you erase an item on a linked-list, the erase can return the 'new' pointer — in other words the pointer to the next item after the item being deleted. I don't know about Qt, though.
[16:56:24] stuartm: jpabq: right, but he wants to use DeleteChild() to perform the actual deletion so he has no access to erase
[16:56:52] stichnot: What might work better here would be a DeleteChild that takes an iterator as its argument
[16:56:56] stuartm: DeleteChild deletes from m_ChildrenList itself
[16:57:35] stichnot: but before going there, it looks like I need to fix a g++ internal error?  :)
[16:57:42] stuartm: stichnot: you could add one, even make it behave like erase, return the next iterator
[16:58:03] stichnot: yeah, that's what I was thinking
[17:01:47] MythBuild: build #987 of master-f18–64bit is complete: Failure [4failed install plugins] Build details are at . . . t/builds/987 blamelist: Jim Stichnoth < >
[17:04:06] MythBuild: build #4400 of master-freebsd-64bit is complete: Success [3build successful] Build details are at . . . /builds/4400
[17:13:11] stichnot: "no space left on device"... I guess that could explain an internal compiler error
[17:22:58] MythBuild: build #53 of 0.27-f18–64bit is complete: Failure [4failed install plugins] Build details are at . . . it/builds/53 blamelist: Nicolas Riendeau < >, Yianni Vidalis < >
[17:31:40] sl1ce (sl1ce! has quit (Ping timeout: 256 seconds)
[17:49:04] stichnot: dekarl: Were you going to try to do anything about the mythweb scheduling latency issue? (If not, I can take a crack at it.) And jya: did reverting that commit change anything in your setup?
[18:02:43] dekarl: stichnot: sure go ahead. I've been thinking a bit about it, but 5 weeks ago I didn't see a nice minimal invasive way to enable both :(
[18:05:00] dekarl: one idea was to switch the upcoming recordings to the service api instead
[18:09:47] sl1ce (sl1ce! has joined #mythtv
[18:10:02] sl1ce (sl1ce! has quit (Client Quit)
[18:12:38] sl1ce (sl1ce! has joined #mythtv
[18:26:46] stichnot: dekarl: ok I'll try fumbling around in that php code :)
[18:31:47] sl1ce (sl1ce! has quit (Quit: Konversation terminated!)
[18:34:41] sl1ce (sl1ce! has joined #mythtv
[18:34:51] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[19:11:52] CeilingKitten (CeilingKitten! has joined #mythtv
[19:43:28] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[19:48:11] Chutt (Chutt! has joined #mythtv
[20:13:36] jya: stichnot: I haven't done anything further on mythweb since I made the mode on the detail screen
[20:21:52] Tobbe5178 (Tobbe5178! has quit (Read error: Connection reset by peer)
[20:25:38] Tobbe5178 (Tobbe5178! has joined #mythtv
[20:33:36] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[20:38:55] Chutt (Chutt! has quit (Ping timeout: 260 seconds)
[20:39:32] Chutt (Chutt! has joined #mythtv
[21:00:01] sl1ce (sl1ce! has quit (Remote host closed the connection)
[21:02:41] sl1ce (sl1ce! has joined #mythtv
[21:39:35] skd5aner: sphery: did you see #11830? Is that something you want to look at before release?
[21:46:07] sphery: skd5aner: the backup and restore scripts both accept the variable names that were used in old and new config.xml... I'd have to see your old config.xml and your backuprc file to figure out why it didn't find DB information in them
[21:47:13] sphery: skd5aner: according to your log, you had both /home/mythtv/.mythtv/config.xml and /home/mythtv/.mythtv/backuprc
[21:47:14] skd5aner: k, I'll send it to you via PM
[21:47:18] sphery: thx
[21:47:24] Jordack (Jordack! has quit ()
[21:49:49] skd5aner: sent
[21:49:55] skd5aner: well... crap...
[21:49:59] skd5aner: now that I think about it...
[21:50:23] skd5aner: after the upgrade could it have upgraded the config.xml to the new format?
[21:50:30] skd5aner: if so, then I don't have the original anymore :/
[21:52:52] sphery: yeah, running a mythtv program other than the backup/restore scripts would have upgraded it
[21:53:10] skd5aner: yea, sorry about that – didn't even think about getting a backup :/
[21:53:49] sphery: from the log I see, it seems to be working fine, but found neither DBHostName nor Host (and the same for user/pass variable names) in the config.xml
[21:54:12] skd5aner: I know the version of the script that shipped with 0.26 worked just fine with whatever version of the config.xml I had a the time... but when I tried to run the version of the script that shipped with 0.27, it failed against my old config.xml
[21:54:21] sphery: could your config.xml have been truncated or something (and then fixed by some other mythtv application running)?
[21:54:44] skd5aner: actually, I know they were in there – as mentioned, the 0.26 version parsed it just fine
[21:55:58] sphery: well, the only change between the 0.26 and 0.27 version is: , and that's for code used long after parsing the config files
[21:57:03] skd5aner: hmmm, interesting!
[21:59:26] sphery: it seems most likely it was some issue with your config files or the environment in which you ran the scripts... the most likely explanation would be a truncated/empty config.xml that got re-created by something in between runs?
[22:01:51] skd5aner: not sure why it would have ran with the 0.26 script version then...
[22:02:07] skd5aner: and it didn't appear truncated to me, but there definitely could have been something
[22:03:01] skd5aner: I tried several times with both scripts – ran everytime with 0.26's version – same error evertime with 0.27
[22:03:18] skd5aner: oh well
[22:03:33] skd5aner: won't ever impact me again, I jsut hope it was a fluke – otherwise, could be a major issue for people trying to upgrade
[22:03:55] skd5aner: that said, I think the built in backup did work...
[22:04:21] sphery: it should have run with either, since the script hasn't changed, so most likely something external (i.e. the config file(s) itself) changed between runs, so the changing version of the backup script wasn't related, but the timing of the runs (and what had changed externally) was the reason for the different results
[22:05:08] skd5aner: for every time I've ever said "it should have worked"... lol
[22:05:51] sphery: the built-in backup would have been run by mythtv-setup or mythbackend, which would have ensured a good config.xml and may have guessed/prompted for the DB info to create it
[22:06:43] skd5aner: I don't know man... I really wish I had the original config.xml...
[22:06:59] sphery: at that point, the backup script should also work, unless there's an environment issue (such as user problem--for example, if running mythbackend with the --user argument, it may not have worked properly due to the differences between real user and effective user and the environment in which the child process is running)?
[22:07:10] skd5aner: but since I don't, all we can do is speculate – I know that the db username and pass were in there, and I never manually edited the config.xml
[22:07:47] sphery: yeah, and since 0.26 and 0.27 use the same config.xml format...
[22:08:00] sphery: fwiw, can you successfully run a backup, now, with the script?
[22:08:06] skd5aner: yes
[22:08:33] skd5aner: actually
[22:08:34] skd5aner: no
[22:08:35] skd5aner: lol
[22:08:54] sphery: same error?
[22:08:59] skd5aner: I forgot that I use mysqldump in my cron job for backups
[22:09:12] skd5aner: yup – same errors
[22:09:46] skd5aner: running as the same user that has the ~/.mythtv/config.xml file
[22:10:16] sphery: what are permissions/ownership of ~/.mythtv/config.xml
[22:11:15] skd5aner: 664 for the same user
[22:11:45] skd5aner: -rw-rw-r-- 1 mythtv mythtv 866 Oct 9 2012 /home/mythtv/.mythtv/config.xml
[22:11:59] sphery: and of ~/.mythtv ? ( ls -ld ~/.mythtv )
[22:12:37] skd5aner: drwxr-xr-x 14 mythtv mythtv 4096 Sep 7 21:45 /home/mythtv/.mythtv/
[22:22:00] sphery: skd5aner: I'm guessing none of the perl-bindings-using scripts work, either?
[22:22:31] skd5aner: want to suggest one for me to try?
[22:23:09] sphery: , and use: --plain_text --recordings -1 --no_show_scheduled --heading 'Recording Conflicts\n\n' --no_conflicts_message 'No Conflicts'
[22:23:29] sphery: which should say "No Conflicts" (assuming you have no conflicts in your schedule)
[22:23:54] skd5aner: I have conflicts
[22:23:59] sphery: then it should list them
[22:26:11] skd5aner: seems to be working
[22:26:26] skd5aner: dumped out a bunch of shows
[22:27:47] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 268 seconds)
[22:44:14] skd5aner: stichnot: yes, that change fixed it (just verified) – thanks
[23:09:15] stuartm: OK, best reason never to use an android tablet for note taking, there's no undo – if you accidentally delete text you're screwed
[23:10:38] stuartm: someone thought it was a good idea for a long press on the delete button in swiftkey to lock the delete ON, so it will just keep on deleting – lost all the notes I made tonight while working on the upnp code
[23:10:42] sphery: androids don't make mistakes, so undo was deemed unnecessary ;)
[23:15:27] stuartm: I can't believe no-one at Google thinks the ability to undo changes when typing is important :/
[23:19:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[23:39:22] MythBuild: build #989 of master-f18–64bit is complete: Success [3build successful] Build details are at . . . t/builds/989

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