:: #mythtv

Daily chat history

Current users (81):

aloril, Anduin, anykey_, Beirdo, ben1066, brfransen, brtb, CaCtus491, Captain_Murdoch, cattelan, Chutt, clever, coling_, Cougar, damaltor, danielk22, dekarl, dlblog, ElmerFudd, foobum, foxbuntu, ghoti, gigem, gregL, GreyFoxx, highzeth, J-e-f-f-A, J-LAW, j-rod|afk, jafa, jarle, jcarlos, joe_, joki, jpabq-, jstenback, jwhite, k-man, knightr_, kormoc, kurre2, kwmonroe, laga, mag0o_, markcerv, MavT, mike|2, mrand, MythBuild, MythLogBot, mzanetti, peitolm, pheld, poptix, purserj, rhpot1991, seld, skd5aner, Slasher`, sphery, sraue, stuarta, superm1, sutula, tgm4883, TheAsp, The_Ball, ThisNewGuy, tomimo, tris, Unhelpful, vallor, wagnerrp, wahrhaft, wseltzer, xavierh, xris, Yancho, yb0t, zCougar, _charly_
Wednesday, March 21st, 2012, 00:00 UTC
[00:00:44] sphery: stuartm: specifically, you're using the "Templated Logging to local7 Facility" approach but on your system the "It also assumes that no other non-MythTV applications are using the local7 facility for logging" assumption isn't true.
[00:00:44] gregL (gregL! has quit (Read error: Connection reset by peer)
[00:01:31] sphery: stuartm: so you should probably switch to the "Simple rsyslog Configuration" approach
[00:02:04] ** stuarta just went for the simple --syslog daemon and uncomment daemon.log in the rsyslog.conf **
[00:04:39] kenni: Captain_Murdoch, yes, thanks, we just wanted to update the strings before the server sync if possible, since we're already several days into the string freeze (and hence shouldn't be making any changes at all). But I think we'll just wait for it to sync now, as knightr might also have some other changes.
[00:09:27] knightr: kenni, I'm back and I'm now working on that theme fix...
[00:16:10] gregL (gregL! has joined #mythtv
[00:23:52] pheld (pheld! has quit (Quit: Leaving.)
[00:27:20] knightr: kenni, I'll go test my theme fix, then have it approved (I got Stuart's blessing to do it but blessing != review)...
[00:44:19] jpabq-: knightr, kenni, stuartm, I just got home. I did a quick scan of the of today's conversation, and get the impression there are still some descriptions wrong? For the most part, I pulled the "language" from the default theme, to avoid having to translate new sentences. May be some cut-n-paste errors, though.
[00:48:15] jpabq-: knightr, kenni are you pulling Steppes from git, or from the theme downloader? Via git, they are *now* available from . I have noticed that it seems to take a couple of days for them to show up in the downloader, after chris says they have been updated. (there).
[00:53:04] jpabq-: Okay, that is strange. When I "fixed" steppes, I must have been pointing to the wrong location on github. Damn.
[00:56:34] stichnot: stuartm, jya, danielk22: I have a new patch to speed up the Watch Recordings screen. It instantiates strings for 20 button list items at a time in the background. It seems to me to give the same scrolling responsiveness as unpatched.
[00:56:37] stichnot: . . . gs_v11.patch
[00:57:11] knightr: jpabq-, . . . (ie not the repo)
[00:57:14] stichnot: jya: it would be great if you could repeat your scrolling responsiveness test.
[00:57:56] knightr: jpabq-, kenni says the sentence which was missing spaces is fixed in -narrow...
[00:58:40] knightr: BTW, as long as you reuse the same sentences, we don't have any new sentences to translate (they are only extracted and translated once...)
[00:58:52] jpabq-: Captain_Murdoch, knightr, kenni I just pushed the change for Steppes. I must have still had a Steppes "check out" from my private git repo, instead of the MythTV one. Sorry about that.
[00:59:16] knightr: jpabq-, np...
[00:59:44] stichnot: But after thinking about the patch some more, I don't see why I should have to use the PBB helper thread at all, since all the hard work is being done in the UI thread. I'd appreciate any thoughts on this.
[00:59:51] jpabq-: knightr, that was my hope, and is why I tried to use the same language that was in default-wide. Except for those case missing the space after a comma, are there other places I need to look at?
[01:00:47] knightr: jpabq-, I know Stuart had some problem with your directives about pressing M, etc...
[01:01:01] knightr: let me see if I can find what he said...
[01:01:25] stichnot: It would be different if I wanted to use extra cores to do the work, but that's not the case here.
[01:01:53] knightr: jpabq, <stuart m> knightr: fwiw, we should avoid stuff like "press M", it assumes two things, the user is using a keyboard and that the user hasn't reconfigured their keys
[01:02:41] knightr: that's what he was pointing at..
[01:03:52] knightr: jpabq-, I'm going to test something on my backend, I should be back in at most 15 minutes...
[01:13:40] jpabq-: Captain_Murdoch, I did not bump the version number. I will if you think it would be a good idea, but if you can just repackage with the same version, I think that would be okay.
[01:16:22] jpabq-: knightr, I found a where I said "press "M" (or the MENU key)" and have changed that to be "press MENU"
[01:26:19] jams (jams! has quit (Read error: Operation timed out)
[01:29:38] hoshi411 (hoshi411! has joined #mythtv
[01:29:54] hoshi411: do most tv pci cards run on linux?
[01:30:17] hoshi411: im hoping to stop by my local electrical appliance shop and pick something up
[01:30:29] hoshi411: want to do live tv streaming and recording with mythtv
[01:30:57] hoshi411: is there a card you recommend? or something I should stay away from?
[01:32:10] hoshi411: do most tv pci cards run on linux? im hoping to stop by my local electrical appliance shop and pick something up. want to do live tv streaming and recording with mythtv. is there a card you recommend? or something I should stay away from?
[01:32:17] hoshi411: woops wrong channel
[01:32:20] hoshi411: sorry
[01:44:04] knightr: jpabq-, thanks! Sorry I was away for a longer time then planned..
[01:46:02] knightr: jpabq-, I got Stuart's blessing to replace "My speaker support" with "My audio subsystem support" in the default themes and in Terra but I would have to resize those boxes and I am having problems...
[01:57:31] dekarl (dekarl! has quit (Read error: Operation timed out)
[01:58:52] dblain: Beirdo: in case you're curious, there is a spec for upnp over ipv6
[01:58:53] dblain: . . . e-documents/
[01:59:19] Beirdo: oooh, cool
[01:59:46] Beirdo: wonder how many devices support it yet :)
[02:00:36] dblain: not sure, but overall the upnp spec is moving fast. Looks like they are up to version 4 for MediaServer (I only implemented version 1 when I wrote it)
[02:01:28] dblain: Maybe some day I can give the upnp stack some needed love... but not until I finish a few more other projects.
[02:06:07] hoshi411 (hoshi411! has left #mythtv ("Konversation terminated!")
[02:15:52] Captain_Murdoch: jpabq-, knightr, kenni, I just repackaged both Steppes themes, and the ftp rsync doesn't happen for a while longer, so the changes should make it in tonight.
[02:16:43] Captain_Murdoch: I will need to recreate the index .zip sometime after the index rsync though.
[02:21:02] jpabq-: knightr, something like gets you most of the way there.
[02:21:41] jpabq-: the non-wide stuff really needs more than that to look good — the alignment is off. May be good enough, though.
[02:31:18] mgpaulus (mgpaulus! has joined #mythtv
[02:31:27] mgpaulus (mgpaulus! has quit (Client Quit)
[02:31:28] jpabq-: Captain_Murdoch, sorry, but I just pushed a new config-ui.xml. knightr wants to replace "My speaker suppors" with "My audio subsystem supports".
[02:32:25] NightMonkey (NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:33:38] Captain_Murdoch: no problem. :) both are repackaged now.
[02:34:47] jpabq-: Captain_Murdoch, thanks!
[02:40:27] knightr: jpabq-, sorry, just came back... Thanks! This is what I had come up with: Seems to worked with just about anything except bloobtube which seems to use a font a lot bigger than the rest...
[02:41:01] knightr: I see though that instead of biigger values, you used nagative values, I guess these are relative to the right side of the screen?
[02:41:12] knightr: s/nagative/negative
[02:42:28] knightr: Captain_Murdoch, is it just me or the retro-wide we offer for 0.24 is broken, there seems to be no way to know on which entry you are (or is it a local problem?)?
[02:43:29] Captain_Murdoch: not sure what you mean. the theme itself is responsible for showing which theme is highlighted in the button list.
[02:44:26] danielk22: TheAsp: The HDHRRecorder is pretty simple, but I believe all the other MPEG-TS recorders use a StreamData class to allow overlapping recordings, that is probably overkill for the firewire recorder.
[02:44:58] knightr: Captain_Murdoch, if I use that theme, I don't see which entry I'm on... Looks like this theme has problems with 0.25 to me...
[02:45:19] markcerv (markcerv! has joined #mythtv
[02:46:03] knightr: jpabq-, thanks for fixing that in your theme too!
[02:46:37] jpabq-: knightr, correct — using negative "width" makes it relative to the right edge of the area.
[02:48:23] jpabq-: Yeah, retro-wide is broken as far as the "selection" is concerned. No idea how long it has been that way.
[02:48:28] markcerv (markcerv! has quit (Client Quit)
[02:48:36] markcerv (markcerv! has joined #mythtv
[02:49:23] jpabq-: I don't know who Chris Candreva is.
[02:50:05] markcerv (markcerv! has quit (Client Quit)
[02:50:53] markcerv (markcerv! has joined #mythtv
[02:51:43] markcerv (markcerv! has quit (Client Quit)
[02:51:58] markcerv (markcerv! has joined #mythtv
[02:52:29] knightr: jpabq-, could it be a 0.25 issue? If so can we restrict its use to 0.24 and below (I'm not sure we can do that or not, I thought be could but I'm not sure...)?
[02:52:40] knightr: jpabq-, Thanks!
[02:53:14] knightr: BTW, I'm tempted to use your patch, mine seemed Ok but I'm not themer and I trust your judgement on this more than mine....
[02:55:11] markcerv (markcerv! has quit (Client Quit)
[02:55:49] markcerv (markcerv! has joined #mythtv
[02:56:06] knightr: jpabq-, last time he posted on -users was less than a month ago...
[02:56:27] markcerv (markcerv! has quit (Client Quit)
[02:56:33] markcerv (markcerv! has joined #mythtv
[03:00:38] Captain_Murdoch: knightr, we are going to add something to MythUI post-0.25 to allow us to specify what versions of MythTV a particular theme version works with. Retro-wide is up on git in MythTV-Themes now. you might want to try that version and see if it works better. I need to find out what MythTV versions that is for and I can package it up from the git repo sometime.
[03:00:41] Captain_Murdoch:
[03:02:02] knightr: Captain_Murdoch, thabk you, I will try it...
[03:52:43] knightr: Captain_Murdoch, that one does work...
[03:59:21] knightr: jpabq-, you might as well commit it because there's like no way, with the little experience I got today playing on these themes, I can improve on what you did so the best I could do is put you as author and sign it off which doesn't quite make much sense since I'm the one who must have his modifications reviewed, not you...
[04:43:24] knightr: jpabq-, thank you!
[05:03:09] cattelan is now known as cattelan_away
[05:04:25] knightr_ (knightr_! has joined #mythtv
[05:05:28] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[05:06:57] knightr_: kenni, I'm going to sleep now, we haven't got the latest fixes yet, we really need to looks into a way of to bypass the syncro for some themes and get the from the repos... ttyl
[05:55:55] knightr_ (knightr_! has quit (Read error: Connection reset by peer)
[05:56:59] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[06:42:14] highzeth (highzeth! has quit (Ping timeout: 245 seconds)
[06:49:28] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds)
[07:05:13] dekarl (dekarl! has joined #mythtv
[07:09:00] xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0)
[07:13:29] pheld (pheld! has joined #mythtv
[07:17:07] highzeth (highzeth! has joined #mythtv
[07:22:58] xris (xris! has joined #mythtv
[07:22:59] xris (xris! has quit (Changing host)
[07:22:59] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[07:30:45] OldEnK (OldEnK! has quit (Quit: Leaving)
[07:47:54] peeaivo (peeaivo!~peeaivo@unaffiliated/peeaivo) has joined #mythtv
[07:48:05] peeaivo (peeaivo!~peeaivo@unaffiliated/peeaivo) has left #mythtv ()
[08:21:14] joki (joki! has quit (Ping timeout: 252 seconds)
[08:21:32] joki- (joki-! has joined #mythtv
[08:21:41] joki- is now known as joki
[08:51:02] AndyUbuntu (AndyUbuntu! has joined #mythtv
[08:57:21] knightr_ (knightr_!~knightr@ has joined #mythtv
[09:01:26] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 272 seconds)
[09:29:08] m15k (m15k! has joined #mythtv
[09:37:32] m15k (m15k! has quit (Ping timeout: 244 seconds)
[09:57:51] m15k (m15k! has joined #mythtv
[09:59:44] m15k1 (m15k1! has joined #mythtv
[09:59:49] m15k (m15k! has quit (Client Quit)
[10:00:28] m15k1 (m15k1! has left #mythtv ()
[10:05:57] mike|2 (mike|2! has joined #mythtv
[10:16:45] kenni: jpabq-: There's a syntax typo in netvision-ui.xml in both Steppes themes, the file begins with << on the first line instead of <
[10:19:42] markk (markk! has joined #mythtv
[10:19:52] kenni: knightr_: I've updated the themestrings with a git master checkout of Steppes + Steppes-narrow + the audio corrections from Terra. I'm going to post a message to -translators now, if we want to fix further strings, let's do it through the translations.
[10:20:48] markk (markk! has left #mythtv ()
[10:40:13] AndyUbuntu (AndyUbuntu! has quit (Remote host closed the connection)
[10:55:58] m15k1 (m15k1! has joined #mythtv
[10:56:09] m15k1: .
[10:56:20] m15k1 (m15k1! has quit (Quit: Leaving.)
[11:07:05] m15k (m15k! has joined #mythtv
[11:07:51] m15k: Hi, could anyone say where the backend reads the dvb adapters?
[11:16:06] stuarta: um /dev/dvb ?
[11:17:40] m15k: yap
[11:18:22] m15k: got the problem that backend says the Bad Adress, I would like to have a look what's exactly happening...
[11:18:53] stuarta: bad address? what like a segfault?
[11:19:30] m15k: "Warning: Opening DBD front device failed. eno: Bad addres (14)
[11:19:30] m15k: "
[11:20:55] TheAsp: danielk22: I'll look into that tonight. The problem I appear to be having is that the first recording off an h264 channel after myth starts works fine, but the next one is always 0 bytes
[11:23:40] TheAsp: I hacked a check for h264 into the processtspacket function like I had in my old patch, like iptvrecorder does, but still have the same result.
[12:01:08] danielk22: TheAsp: Are you reading in data for the second recording or is getting filtered out in StreamData? BTW Yesterday I meant to say the other MPEG-TS recorders use a StreamHandler, all the MPEG-TS recorders use a StreamData class.
[12:04:11] stuartm: gigem: I had an idea just now, it might be a non-starter but ... most users don't clear out old recording rules so over time the number of unused rules grows and affects the scheduling speed; we now mark the last time a rule resulted in a recording and the next time it will record so we have an indicator as to the obsolescence of a rule; what would be the downside to having two different scheduler runs – a fast run which ignores older/less
[12:04:12] stuartm: frequently used rules and is used when speed is more important – reacting to the creation of new schedules allowing a faster update of the UI etc
[12:04:58] stuartm: then a longer run which is performed every x schedule calls for EIT (which reschedules every 5 minutes) or only after a mfdb run
[12:05:00] stuarta: now there's an idea
[12:06:31] stuartm: the chances of a rule which hasn't matched for years suddenly matching as the result of a last minute EIT update is unlikely, so there's no need IMHO to check every recording rule every 5 minutes throughout the day
[12:07:44] stuartm: nor is it necessary when I hit RECORD in the guide, because the guide data itself hasn't changed and if it wasn't recording using that rule before, then it's not suddenly going to change it's mind
[12:25:01] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 252 seconds)
[12:28:04] stuarta: once a day would even be enough if the rule hasn't been used >1 month
[12:28:35] stuarta: consistent with feeding mythtv your data via MFDB too
[12:55:05] stuartm: right, I just figured a little more often for EIT since there's the possibility that a user looking at the guide data two weeks from today notices that a new series of X is starting but that MythTV isn't scheduling it to record
[12:57:25] stuartm: a full reschedule doesn't take that long, even on slow machines with thousands of rules/channels, so there's no harm in running it once an hour or similar, it's just too slow when we're wanting to update the UI to reflect changes – more than once I've hit RECORD in the guide and then wondered if I pressed the button hard enough because takes several seconds to finish the scheduling and show as Recording/Will Record
[12:58:18] stuartm: plus with users wanting to try running on ever lower power hardware, reducing the load of the scheduler can only be a good thing
[12:59:50] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[13:01:56] stuartm: fwiw I've got a separate idea for giving immediate feedback to the user that their request to record was received and that's a 'scheduling' state with a corresponding statetype, so we can indicate that we're acting on the request even before the results come back
[13:10:16] stichnot (stichnot!~chatzilla@ has joined #mythtv
[13:10:16] stichnot (stichnot!~chatzilla@ has quit (Changing host)
[13:10:16] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[13:21:33] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:31:09] stuarta: don't we already generate an event for that?
[13:32:16] stuartm: there might be one, but I'm not sure if it contains the necessary information to mark specific programmes in the guide as 'scheduling'
[13:36:07] stuarta: i think we should make sure such a mechanism works well
[13:36:15] ** stuarta loves event driven systems **
[13:36:24] stuarta: makes programming much more fun
[13:37:17] stuarta: anyway, i now have my prod and dev backend running on the same box each having 1x dvb-t and 1x dvb-s2
[13:40:04] highzeth_ (highzeth_! has joined #mythtv
[13:40:50] highzeth (highzeth! has quit (Ping timeout: 260 seconds)
[13:43:19] stuarta: which makes for interesting comparisons, like why is the dev instance (aka master) using more cpu
[13:43:24] m15k (m15k! has quit (Ping timeout: 260 seconds)
[13:44:23] stuarta: still adding EIT data rapidly by the look of it
[13:51:37] jpabq-: Thanks kenni, I pushed a fix.
[13:52:43] kenni: Captain_Murdoch: jpabq- updated a number of strings yesterday in Terra, I've extracted these from git master for the themestrings, but we'll need to update the Terra theme in the downloader for the strings to match. Can you help with that? Thanks.. :)
[14:09:03] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone -
[14:23:54] j-rod|afk is now known as j-rod
[14:27:21] Jordack (Jordack! has joined #mythtv
[14:33:13] knightr_ (knightr_!~knightr@ has quit (Read error: Connection reset by peer)
[14:33:36] knightr_ (knightr_! has joined #mythtv
[14:34:58] knightr__ (knightr__! has joined #mythtv
[14:39:00] knightr_ (knightr_! has quit (Ping timeout: 272 seconds)
[14:43:21] gregL (gregL! has quit (Quit: Leaving)
[15:03:08] knightr__ (knightr__! has quit (Ping timeout: 240 seconds)
[15:04:03] AndyUbuntu (AndyUbuntu! has joined #mythtv
[15:07:12] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[15:08:29] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[15:10:24] knightr_ (knightr_! has joined #mythtv
[15:13:41] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 252 seconds)
[15:45:46] gregL (gregL! has joined #mythtv
[16:03:18] gigem: you touch on a number of things. some improvements might be possible and some not. first thing, i like your 'scheduling' state idea for gui feedback. i was already planning to suggest that as i was reading along.
[16:03:28] gigem: okay, now for scheduling improvements. when the scheduler reports its total run time, it also reports a 'match' time and a 'place' time. i'm curious to see how your time break down. the match time should usually be significantly less than the place time.
[16:03:39] gigem: the match part is where the scheduler determines which programs match the recording rules and the scheduler creates corresponding recordmatch entries. in your pressing record in the epg example, you suggested the scheduler should not do a full run. it already does for the match part. it only runs the match part on the affected rules. compare your scheduler match times when requested by for some recordid >
[16:03:41] gigem: 0 versus for the magic recordids 0 (no rule nor guide data changed) and -1 (guide data changed).
[16:03:49] gigem: the place time is where the scheduler checks for previous and current recording status and runs the scheduling algorithm to decide which specific showings to record. this part is always entirely redone for every reschedule. historically, the place time has been dominated by the join on oldrecorded to determine previous recording status. that is where any significant improvements are to be made.
[16:04:01] gigem: there has been a long standing suggestion to speed up the oldrecorded join by simplifying the on condition. the way to do that is to pre-compute hashes for all of the subtitle/description methods we support, add indexed columns for each hash to program and oldrecorded and then run the join for each rule individually using its specific hash. very simple proofs of concept several years ago weren't promising.
[16:04:03] gigem: mysql has improved since then, though, so it might be worth trying again.
[16:04:13] gigem: another way to speed up the oldrecorded join is to only run it on the matched programs that might have changed. i never thought that was possible before, but you've given me an idea that might work in many, but not all, cases. i'll have to run some tests to see if that's possible. if that proves promising, there might be some value to your suggestion to partially ignore old rules that haven't matched in a
[16:04:15] gigem: long time.
[16:04:38] gigem: stuarta: ^^^
[16:04:50] gigem: dang. stuartm ^^^
[16:06:00] stuarta: dang. 4 page irc comment!
[16:08:11] gigem: yeah, this all probably should have been done in email.
[16:12:35] knightr_: kenni, ok, saw it, Thank you!
[16:15:29] ElmerFudd (ElmerFudd! has quit (Quit: Leaving)
[16:18:58] ElmerFudd (ElmerFudd! has joined #mythtv
[16:26:57] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[16:36:19] AndyUbuntu (AndyUbuntu! has quit (Remote host closed the connection)
[16:37:29] knightr_: stuartm, I got an email back from Piotr, the screen caps I made and sent him did the trick... I'm pretty sure we had mentioned that the screen could be resized but, like they say, a picture is worth a thousand words... I'll document this on the wiki (probably with a few screen caps and things like that..)
[16:39:36] AndyUbuntu (AndyUbuntu! has joined #mythtv
[16:56:04] sphery: stuartm: it's amazing how many people are requesting T-9 like input--after years of complaining about it before it got removed
[16:57:12] AndyUbuntu (AndyUbuntu! has quit (Read error: Connection reset by peer)
[17:02:14] AndyUbuntu (AndyUbuntu! has joined #mythtv
[17:07:47] knightr (knightr! has joined #mythtv
[17:07:50] knightr (knightr! has quit (Changing host)
[17:07:51] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[17:07:56] sphery: stuartm: could paul-h have fixed in
[17:08:39] sphery: danielk22 / gigem : between the live tv/recording order changes and the Live TV channel change fixes, is no longer required?
[17:09:26] knightr_ (knightr_! has quit (Ping timeout: 265 seconds)
[17:10:38] AndyUbuntu (AndyUbuntu! has quit (Remote host closed the connection)
[17:10:49] natanojl (natanojl! has joined #mythtv
[17:11:31] sphery: Anyone mind if I close as an upstream bug, saying it seems to either be a problem with CentOS's messagebus or with Qt's DBus implementation or DBus itself?
[17:12:12] danielk22: sphery: yeah
[17:12:21] AndyUbuntu (AndyUbuntu! has joined #mythtv
[17:13:05] sphery: danielk22: was that a yeah on 10323 not being required?
[17:13:12] danielk22: sphery: my yeah was to 10323, no idea on the other one.
[17:13:43] sphery: hehe, ok, just making sure... want me to close it or do you want to?
[17:17:25] danielk22: feel free to close it.
[17:18:02] sphery: ok, thanks
[17:19:25] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone -
[17:19:41] m15k (m15k! has joined #mythtv
[17:19:52] m15k (m15k! has left #mythtv ()
[17:22:25] cattelan_away is now known as cattelan
[17:23:49] AndyUbuntu (AndyUbuntu! has quit (Remote host closed the connection)
[17:32:37] stuartm: sphery: I don't believe so, but I've no idea what might be causing yet, I've tried to reproduce it yet
[17:35:15] stuartm: gigem: my idea was based at least in part on something I think you said a while back about how you regularly remove old rules to keep the scheduling time as low as possible – does that not make as big an improvement as I understood?
[17:41:04] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[18:06:12] gigem: stuartm: keeping oldrecorded small makes a huge difference. my full reschedule time is currently about 1 second. that's because there are fewer old recordings to check against. the number of rules, especially ones that don't match anything (and i have quite a few of those) has little effect. what matters is number-of-matched-programs times number-of-oldrecorded-enties. i've always attacked the problem by
[18:06:14] gigem: keeping the latter as small as possible. my new idea based on your suggestion will try to lower the former for most cases. i'll know later today if it has any promise.
[18:07:12] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[18:09:10] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[18:12:21] stuartm: understood, and thanks for looking at improving the overall speed :)
[18:14:38] sphery: I keep the latter small by removing old rules once a show is cancelled and I've either watched it all or decided not to watch it--and I use the sort by last recorded to find rules that I should check show status (and my latest reschedule for -1 was 1.3 = 0.04 match + 1.30 place, but some recent ones were as high as 3.5s (0.069/2.77), before cleaning some old rules up)
[18:16:10] stuartm: sphery: right, it's that sort of maintenance that I think most people don't bother with, they probably don't even give it a moments thought
[18:17:21] stuartm: I've attempted a clean up once or twice, but after years of never doing anything at all it's a big and tedious job
[18:17:45] sphery: yeah, just saying that it does make a noticeable difference
[18:18:01] stuartm: plus there are a few rules I keep around in the vain hope they'll commission a new series after all these years ;)
[18:18:20] stuartm: my current schedule is "Scheduled 735 items in 5.5 = 0.82 match + 4.64 place"
[18:18:45] sphery: I have 16K oldrecorded entries, but still get very short scheduler runs because of limiting matches for old shows I'm not interested in
[18:18:58] stuartm: that's actually down a bit on earlier in the year, it was averaging 6.8 or similar, and upto 8–9 before gigem's last optimisations
[18:19:41] stuartm: sphery: 19486 here
[18:20:11] stuartm: 379 rules, even after my last purge
[18:20:39] sphery: though I have to admit that gigem's cleaning up oldrecorded explains the nearly-useless UI for the Previously Recorded screen
[18:20:47] stuartm: bbl, time for some food
[18:21:11] sphery: it works fine as long as you don't have to scroll through 8K entries to find the show you want to allow re-record or whatever
[18:21:29] sphery: (I'd like it to be a 2-level list of title/subtitle, more like watch recordings or something)
[18:21:44] stuartm: sphery: aye, it takes forever to load and even slow to use (and I don't mean scroll speed, but it's just a terrible UI)
[18:22:31] sphery: yeah, we haven't modified the UI as usage/history grew... project for later, though :)
[18:34:24] AndyUbuntu (AndyUbuntu! has joined #mythtv
[18:38:08] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Remote host closed the connection)
[18:38:25] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[18:49:08] dekarl (dekarl! has quit (Ping timeout: 255 seconds)
[18:49:41] dekarl (dekarl! has joined #mythtv
[18:51:21] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[18:55:34] gigem: stuartm: it looks like the idea has promise. using sphery's oldrecorded table (still the best way for me to get longer schedule times on my dev system), it cuts the schedule time for changing a single rule from ~1.8s to ~0.7s. would you mind trying to see what effect is might have for you? DO NOT use it in production. it will miss some schedule changes that should occur, but
[18:55:36] gigem: it should give a reasonable approximation on what improvements might be achievable.
[18:56:29] AndyUbuntu (AndyUbuntu! has quit (Remote host closed the connection)
[18:58:35] gigem: sphery: you can sort previously recorded by title.
[18:59:21] gigem: stuartm: i've thinking about how to make previously recorded use update events similar to pbb. it think it's mostly possible, but don't know when it will happen.
[19:01:32] sphery: gigem: yes, but when you have 16k previously recorded and are trying to allow re-record of an episode of Modern Family (or other mid-alphabet title), you end up having to scroll about 8k records to get there. When sort by time isn't likely to be useful, I use sort by title and swap ascending or descending based on likelihood of finding the shortest path just because it's so unwieldy.
[19:02:29] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone -
[19:03:13] sphery: I was just saying that this isn't something that you've likely found to be an issue since you clean up your oldrecorded (I'm assuming with things like "Remove all episodes of this title", removing large blocks of records at a time), so you don't have that much history.
[19:04:45] gigem: the old qt-ui had a couple of features on category/genre search screen. there were keys to backward and forward to the next "chunk" and to some percentage of the entire list. sadly, those features got lost in the mythui rewrite.
[19:06:28] gigem: i do a small clean up every night right before i check tomorrow's schedule and turn off the tv. it only takes about a minute.
[19:06:41] sphery: gigem: According to MythWeb statistics, I've recorded 1352 titles and 15266 episodes (which is smaller than my 16178 count of oldrecorded?), and I'd much rather be able to scroll through even 1400 titles than half of 15–16k episodes to get to the right title.
[19:09:22] gigem: sphery: oldrecorded also contains recent-past programs that weren't recorded and near-future programs that might or might not be recorded. the name is now misleading as oldrecorded is now more or less 'saved scheduler state'.
[19:09:29] sphery: ah, it's using where recstatus = -3;
[19:09:50] sphery: so doesn't count the never records (11) or others
[19:11:20] sphery: I have about 700 never records (that are shows I've seen elsewhere/before MythTV)
[19:12:15] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[19:12:22] sphery: that said, for recording statistics, mythweb's approach is best... I was just surprised it was that different.
[19:17:12] seld (seld! has joined #mythtv
[19:20:48] highzeth_ is now known as highzeth
[19:23:41] stichnot: oh boy, the Old Recordings screen could use some lazystrings attention
[19:24:09] stichnot: takes a *long* time to load on an ION
[19:26:58] stichnot: I was wondering (particularly from stuartm) if it would be a good idea to add the option of lazy initialization + background full-initialization to MythUIButtonList
[19:33:17] ** kenni will some day have to learn how to correctly rebase newer commits to avoid these unwanted git merge-messages.. **
[19:53:13] gigem: stichnot: lazystrings would help in previously recorded. it still has the issue that currently *any* change causes a full reload.
[19:56:52] stuartm: gigem: special keys tend to be much less useful with remotes
[19:57:33] stuartm: sphery: you can search in buttonlists, although that again is a 'special key', it would perhaps be a good idea to make that accessible via the context menu as well
[19:59:34] stuartm: we should have 'previously recorded' make use of PI update events etc, I might have done that already but I so rarely use the screen (in fact close to never)
[20:00:40] stichnot: stuartm: I agree that buttonlist search in a context menu would be awesome. I bet most people aren't aware it's available
[20:01:23] stichnot: unfortunately, the search window obscures the result, which I guess is mostly a theme issue
[20:02:22] stichnot: though we could probably help by trying to place the button with the search string in the first position (or some other predictable position)
[20:03:34] stuartm: pretty much, we can't stop a themer placing a popup over the list, although there is markup to tell it to place the popup above/below/left/right of the list so it doesn't actually matter if the list position changes from one screen to another
[20:04:51] stichnot: that's nice.
[20:05:25] stichnot: so it is a theme issue — if I were the themer, i would use that markup plus some reasonable alpha background
[20:06:46] stichnot: stuartm: are you at all interested in a patch that lets the buttonlist load in the background, for better UI responsiveness?
[20:07:55] stichnot: it seems that if you give the MythUIButtonList a pointer to the event listener, plus a callback for fully filling in a button list item, it could be done easily
[20:08:44] joki (joki! has quit (Ping timeout: 252 seconds)
[20:08:50] stuartm: stichnot: maybe, it would depend on how it was implemented, callbacks I dislike, fully event driven is better
[20:10:05] stichnot: I'm kind of a newbie to the event driven model, so I'll ponder that
[20:10:44] stuartm: I don't really want to think too hard about it right now if that's alright, I want to see 0.25 out the door before considering what comes next :)
[20:12:33] stichnot: that's fine, that's the guidance I'm looking for
[20:13:08] stuartm: I'm falling behind on both my TV viewing and my reading atm, the last couple of weeks of the feature freeze are a welcome break which I'm happy to take advantage of ;)
[20:15:07] joki (joki! has joined #mythtv
[20:38:37] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 246 seconds)
[20:49:32] gigem: stuartm: those 'special' keys weren't that special. previous/next grouping used PREVVIEW/NEXTVIEW which are pretty useful to have on many screens. i think at one time, they were bound to the same keys as FF/REW. the goto percent in list keys were even less special. how many remotes don't have 0–9 number keys? :) in short, there's little reason that functionality can't or shouldn't be added back.
[20:55:40] stuartm: gigem: I think there must be smarter ways of arranging the UI so that those aren't needed
[20:58:22] gigem: i guess we have different tastes, then. i think they're a hell of a lot easier to move around quickly than having to bring up a virtual keyboard and virtually type in a search term.
[20:59:03] stuartm: fwiw I didn't port those screens, but I can see why those actions were dropped given the overall design and direction of mythui, namely consistency, keys do exactly the same thing on each screen for example – which is reinforced by having widgets handle their own key presses and keeping everything contained, you can stick a list in a screen and it will just work, it doesn't need special handling on a per-screen basis which gets tiresome to
[20:59:05] stuartm: maintain and keep straight
[21:00:00] stuartm: gigem: I'm not saying the search in list is the solution, I'm just saying that I think more and more actions are not IMHO it
[21:00:37] stuartm: is there any particular reason why 'previously recorded' needs to be a huge long linear list?
[21:00:54] gigem: it still wouldn't need special key handling selected screens. the buttion list just needs to understand the concept of groupings and moving within the list as a whole.
[21:00:56] stuartm: or could we re-think that entirely
[21:03:20] stuartm: we've got PAGETOP, PAGEMIDDLE and PAGEBOTTOM already, I just happen to think the profusion of 'actions' is as based as the number of settings on offer
[21:03:31] gigem: i think there are two main use cases. 1) show the entries near a certain time, usually now. 2) show the entries for a series or recording rule.
[21:03:35] stuartm: gigem: I think we might be pulling in fundamentally different directions :)
[21:05:51] stuartm: in fact, I do foresee a time when this project rips in two down the middle, with those on one side aiming for a very simple UX for ordinary people and those on the other looking for a more complicated UX for power users
[21:06:54] gigem: stuartm: we might be. i mainly never liked that the mythui rewrite made the category/genre search unusable. i used to really like to browse it looking for odd combinations. it was a good way to find 'new and unusual' programs.
[21:08:35] stuartm: gigem: unusable how? I must admit I don't use it, and I feel the need to stress that I wasn't the one who re-wrote those, but it seems to function just fine here
[21:09:09] stuartm: although 'fine' isn't 'great' but that's again got a lot to do with the very long linear list issue
[21:09:40] stuartm: wouldn't hurt to break that down with a second list running A-Z just like the programme finder
[21:11:19] gigem: stuartm: that might happen. personally, i think if myth gets dumbed down too much, then what's the point of it? anyone who wants that should just use the cable co's dvr. as far as i'm concerned, the value that myth adds is it can do thing the others can't — things that make my life easier.
[21:15:24] stuartm: simple != dumb, an application can be well presented and easy to use without being totally useless
[21:18:17] stuartm: at the end of the day if we want MythTV to continue it has to reach a wider audience and therefore more developers, our existing user base is dwindling away because those STBs and DVRs are actually getting to be pretty good, while other applications such as XBMC are offering much of our existing functionality but with a better user experience
[21:18:49] gigem: it's unusable, imo, because the list is too big to page through one at a time, and typing a search is too clumsy when browsing is the intened use case. think how you'd like the epg if you could only see a few channels at a time and to move around you either had to go through 10s or 100s of pages or type in a new channel name. anyway the idea of viewing guide data that way came from tivo. it's one of those
[21:18:50] gigem: things you have to see before it 'clicks'.
[21:19:13] stuartm: I guess I don't want to see the day when the only people still using MythTV are the developers, that's not exactly what we had in mind when the mantra was 'By developers for developers'
[21:20:29] stuartm: gigem: err, you've lost me ... "think how you'd like the epg if you could only see a few channels at a time and to move around you either had to go through 10s or 100s of pages or type in a new channel name." – isn't that how it works right now?
[21:24:52] damaltor (damaltor! has quit (Remote host closed the connection)
[21:25:13] sphery: And it seems like you're saying the reason that the channel/genre search is unusable is the same reason we're saying previously recorded is unusable--a huge single list that's too hard to navigate/browse. Perhaps you're both agreeing about the idea of changing the UI, just using different examples?
[21:25:58] stuartm: fwiw, I can't be sure, but the 'grid' layout of guide data precedes the Tivo by a few years, in print TV guides and later early digital tv services in Europe and elsewhere
[21:30:23] stichnot: I'd like to see the day when STB DVRs offer commercial detection, cutlists, adding an arbitrary number of tuners, myth-quality scheduling, playback of external content (e.g. ripped discs), etc.
[21:30:38] gigem: stuartm: i know simple doesn't necessarily mean dumb. but it still scares me everytime some of you guys get into the mode of 'we need to rip this and that out because i don't understand it or care about it therefore nobody else should need it. after iamlindoro's (mostly) leaving, i was hoping the 'myth needs to conquer the world' mentaility would die off a little. personally, i want myth to make my life
[21:30:40] gigem: and tv viewing easier. if in doing so, i cna do it such that it helps others too, then i'll do my best. when it stops making my life easier, i'll be the one to start 'son-of-torqs' or whatever it's called. :) actually, i'd probably go see how dvr6 is doing first.
[21:34:35] stuartm: I'm not looking to have MythTV conqueror the world, just to remain competitive
[21:35:19] stuartm: and the whole drive is to make life and tv viewing easier, it's just that we have vastly different ideas of what easier means
[21:36:51] sphery: stichnot: fwiw, few "real people" see those things as being that interesting when AT&T offers their Uverse with "record up to 4 things at once and play back on any TV" and they have a ffwd button that allows them to skip over commercials in 2–3 seconds and scheduler works well enough and ... (commercial detection replaced by ffwd, arbitrary tuners by "4 is plenty", scheduling is "good enough", cutlists are unnecessary because most won't ...
[21:36:52] gigem: stuartm: sorry, trying to do too many things at once, and writeing coherently quickly isn't something i do well. the main thing about the category search and epg analogy is they are primarily (imo) for browsing as opposed to searching for something specific. for example, the epg has (or had) key bindings for moving around in various ways such as a day at a time.
[21:36:57] sphery: ... archive or have Netflix or Hulu Plus or iTunes or ... and get playback of external content on external players, like PS3 or Roku or ...)
[21:38:03] sphery: (and uverse is just one example... I think directv and fios and ... has similar.)
[21:39:23] stuartm: gigem: ok, I'm just not sure I see how jumping by large amounts facilitates 'browsing' of a long list, seems to me that would be more useful if you were trying to reach a particular point in the list? If the point is to browse to find something of interest then you don't want to skip over large numbers of entries?
[21:39:39] sphery: I think that MythTV needs simplified, but in most cases, the simplification is just "finishing" what someone started--i.e. much of the complexity is because we haven't yet written the code such that it just "does the right thing" because it was easier to slap in a setting and make the user tell us which way to do things
[21:41:16] stuartm: as far as splitting up long lists, the programme finder and upcoming recordings (in Terra at least) are maybe some of the better examples, a secondary list grouping what's in the list either by alphabetical listing as in the finder or by date as in upcoming recordings
[21:42:20] stichnot: I think the debate between gigem and stuartm is (or at least was) about how to make the browsing experience scale as the number of items gets huge. This is very unlikely to be an issue (in the U.S., at least) with STBs given the leasing model the cable/satellite providers all use these days.
[21:42:23] damaltor (damaltor! has joined #mythtv
[21:43:08] stuartm: for the search lists I was actually going to have a list allowing faster switching between 'searches', so in the category view it would show the possible categories ... a third list there though splitting A-Z or even by % if that was preferred ...
[21:43:32] gigem: stuartm: the point is to skip over potentially large numbers of entries and move to the next logical grouping. for example, i'm looking at sports-event/backeball. i'm not interested in basketball at the moment, so move me to the next entry under sports-event whatever that is.
[21:44:07] stuartm: gigem: ah, so you want a quicker way to change categories?
[21:44:07] damaltor (damaltor! has quit (Remote host closed the connection)
[21:44:52] stichnot: For today, I agree with gigem that I'd like faster browsing through long button lists. For tomorrow, I agree with stuartm that the data should be presented automatically in a way that better supports grouping.
[21:44:54] stuartm: gigem: either that or the category stuff in the US is completely different to elsewhere
[21:45:07] damaltor (damaltor! has joined #mythtv
[21:47:02] stuartm: crap, didn't notice the time, so much for catching up on my viewing tonight
[21:48:08] stuartm: gigem: are you saying that in the US for each category there are a number of sub-categories which are displayed together in one huge list and in sub-category order?
[21:49:38] gigem: stuartm: yes, sort of for moving. yes, for sd, our categorization is very different. essentially, we have a variable number of ordered tags (genres) that can apply to any program. the 'category' is merely the genre tag with the highest precedence. the categore/genre search page automatically detects the use of genres and provides a two level search. the two-level search essentially shows what programs
[21:49:40] gigem: intersect any two genres. as i noted for above, it is the minig ofr odd combinations of genres that i used to really enjoy.
[21:50:06] stuartm: if it's that structured, why aren't 'sub-categories' under the main 'category' selection dialog, or for that matter why hasn't the program finder model been used instead? Category > Sub-category > Programme
[21:50:50] stuartm: gigem: the 'breakage' as it were probably then comes from the fact that Paul is in the UK and had no knowledge of that stuff, outside the US we have just one level
[21:51:02] dekarl: I'm looking forward to all the HbbTV stuff (video on demand in formats already supported by MythTV, yeah) and atlas (metadata collector from the UK). It should make it super simple to add most german public (and some private) VoD libraries to mythnetvision... that would give us a good head start on other solutions :) see e.g.
[21:51:08] gigem: probably because i nveer (and still don't) liked the program finder model. different tastes. :)
[21:51:13] stuartm: but it seems to me that the 'long list' approach for such structured information was wrong from the start
[21:51:40] gigem: also, it was written to try to acommodate case with and without genres.
[21:51:40] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[21:52:08] stuartm (stuartm! has joined #mythtv
[21:52:08] stuartm (stuartm! has quit (Changing host)
[21:52:08] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[21:53:01] AndyUbuntu (AndyUbuntu! has joined #mythtv
[21:55:39] stuartm: it doesn't seem particularly user-friendly to me to present the user with a long list and not tell them that x% down that list are the entries for Sport > Basketball, much friendlier to present them with an initial selection showing either – "sport, comedy, news, entertainment" and then when they've chosen 'sport' show "basketball, cricket, football, hockey, rugby"
[21:56:46] stuartm: or to present the same UI to both users in North America and outside North America, an initial list showing "Sport (Basketball), Sport (Cricket), Sport(Rugby)"
[21:57:00] j-rod is now known as j-rod|afk
[21:58:45] stuartm: anyway, I've just looked at the clock and realised I've blown the entire evening here in IRC on an 'argument' which probably hasn't helped my blood pressure when I'd been looking forward all day to catching up on my recordings, so I'm off to salvage whatever time I can
[21:58:58] gigem: anyone know how/where i can post a screen shot?
[21:59:19] skd5aner:
[21:59:28] gigem: skd5aner: thanks.
[21:59:44] skd5aner: rofl – the last image posted there is this –
[22:00:47] gigem: stuartm: if there is a better way, i'll be all for it. it really bils down to what i was used to before and what was good enough.
[22:03:12] gigem: now i remember why i forgot about how do i agree to the terms of service?
[22:06:19] gigem: nevermind. operator error.
[22:17:17] gigem: stuartm: sorry about your blood pressure. i don't think it's helped mine either. :) anyway, see for how the category search list looks for me. there are 34 subcategories under "Action" so it takes 5 or 6 page downs to find the next major category. with the old ui, the PREV/NEXTVIEW keys moved to the previous/next major category. even with 118 major categories
[22:17:18] gigem: like i have now, those operations made it easy to quickly navigate the thousands of major/minor combinations.
[22:24:09] gigem: as for me not liking the progfinder model, i admit a lot of it is personal taste as i really don't like any rolodex type things. fwiw, the progfinder was my inspiration to write the original proglister which only showed the upcoming episodes for a single title. proglister grew a lot after that, mostly due to bjm.
[22:24:55] Jordack (Jordack! has quit ()
[22:27:42] stichnot: gigem: I don't think that was the right imagebin link
[22:30:16] gigem: stuartm: i'm not trying to belabor the issue. i'm just trying to catch up on a couple points i missed before i fell hopeless behind. i really don't know how some of you guys can think and type so fact! :) anyway, i'm pretty sure i brought up the category navigation issue at least once after the ui rewrite. fwiw, i also quickly forget that the rest of you don't have the extra genre data and don't know what
[22:30:18] gigem: you're missing.
[22:32:01] gigem: anyway, i think the main point i want to make is i have no issue with making the easy things easier, but please keep the hard things 'easy' and possible too.
[22:33:30] gigem: stichnot: thanks. it should be
[22:33:33] gigem: stuartm: ^^^
[22:48:06] AndyUbuntu (AndyUbuntu! has quit (Read error: Connection reset by peer)
[22:50:29] damaltor (damaltor! has quit (Remote host closed the connection)
[23:04:31] TheAsp: danielk22: How can I tell if it's getting filtered out?
[23:11:06] TheAsp (TheAsp! has left #mythtv ("Client exiting")
[23:11:42] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[23:12:06] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[23:13:12] damaltor (damaltor! has joined #mythtv
[23:14:55] damaltor (damaltor! has quit (Remote host closed the connection)
[23:14:56] [TheAsp] ([TheAsp]! has joined #mythtv
[23:15:23] [TheAsp] is now known as TheAsp
[23:15:54] damaltor (damaltor! has joined #mythtv
[23:25:59] danielk22: TheAsp: Just put something in the device read loop to tell you if there is data coming in, if there is data coming in and it is not being written to disk then it's getting filtered out.
[23:26:23] TheAsp: gotcha
[23:29:03] natanojl (natanojl! has quit (Read error: Operation timed out)
[23:34:57] knightr_ (knightr_! has joined #mythtv
[23:38:08] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 240 seconds)
[23:43:52] Captain_Murdoch: kenni, I'm re-running the theme packaging script now to pickup any changes since yesterday, so those changes will get on the ftp site tonight and I can re-index tomorrow
[23:44:34] mike|2 (mike|2! has quit (Ping timeout: 260 seconds)
[23:52:04] TheAsp: danielk22: LinuxFirewireDevice::run()? Doesn't that already print something out if I'm not getting data?
[23:53:55] mike|2 (mike|2! has joined #mythtv

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