Beirdobot, irc.freenode.net

Monday, July 25th, 2011, 14:46 UTC

[14:46:43]

sphery:

stuartm: re: http://code.mythtv.org/trac/ticket/5863#comment:4 , can we do something about the "don't skip long commercial breaks" setting? Any ideas?

[14:49:20]

stuartm:

this is a setting that already exists? We could instead modify the commercial flagger to assume that any commercial over a certain length is a mistake and to discard that data

[14:50:08]

stuartm:

but eliminating the existing setting is a little more work than rejecting a patch to prevent a new one being added

[14:51:12]

stuartm:

I'm suprised that the flagger doesn't already have sanity checks for commercials which are too short/too long and which are therefore likely to be mistakes

[14:54:58]

stuartm:

I know it lacked some basic checks when I last used it, it would flag commercials which were seconds long, others 10–15 minutes long and commercials breaks which were just a minute or two after the last break

[14:55:26]

stuartm:

sphery: I have plenty of ideas, but no motivation to work on implementing them ;)

[14:56:39]

stuartm:

still it should be very easy to do a post-flagging review of the map and discard flags which appear to be in error

[14:56:44]

abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv

[14:57:15]

jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)

[15:02:35]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 258 seconds)

[15:05:29]

sphery:

stuartm: yeah, already exists... Maximum commercial skip (secs): MythTV will discourage long manual commercial skips. Skips which are longer than this will require the user to hit the SKIP key twice. Automatic commercial skipping is not affected by this limit.

[15:06:31]

sphery:

I really want to get rid of it--I think it's a waste. It's just as easy to hit skip back if you skip and notice that you've gone too far as it is to hit skip, have it not skip, then hit skip again, then notice you've gone too far.

[15:07:07]

sphery:

and I think the setting is really a lot less interesting, now, since Capt M fixed commercial skip so it doesn't skip when it would take you to the end of the recording

[15:08:10]

sphery:

There's also a "Merge short commercial breaks (secs)", which borders on related to the #5863 one

[15:08:47]

sphery:

but, like you, I think we should trust the data in the DB--and if it's wrong, fix the code that's adding that data (i.e. better commercial detection)

[15:10:28]

VManiac16 (VManiac16!~Unknown@69.4.155.83) has quit (Read error: Connection reset by peer)

[15:21:29]

Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv

[15:31:31]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv

[15:36:33]

sphery:

stuartm: just figured out what you meant by, "Beirdo: are the trac commit hooks something we control? It would be helpful to know who the commits were made by in the body of the ticket comment and that information is currently missing". You mean since it now just says, "Changes (by Github):". That was changed because some people were concerned about, "Changes (by <person without commit access>):" showing up when we commit with --author .

[15:36:52]

sphery:

but I agree that it makes it harder to see--especially when reviewing tickets--who did what when.

[15:41:21]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds)

[15:45:30]

Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has quit (Ping timeout: 255 seconds)

[16:07:54]

gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)

[16:15:59]

Beirdo:

yes, we control that script. wagnerrp's modified it a few times.

[16:17:20]

wagnerrp:

sphery: we used to have the committer listed as the person making the changes on trac

[16:17:49]

wagnerrp:

but since the committer might not match up with a trac account, or may even be a non-dev, it was decided it was just too confusing

[16:18:06]

wagnerrp:

i can alter the hook so it adds the committer to the bottom, with the commit and branch

[16:19:29]

Beirdo:

danielk22: I thought it was odd too. The root of that crash though is brought on by freeing a NULL pointer, something we can easily avoid doing. Why it's NULL, and why it causes that particular crash, hard to say. Could be something smashing the heap or stack, I guess

[16:19:47]

Beirdo:

as I said, it was not a fix for the cause, but for the symptom

[16:19:57]

Beirdo:

feel free to completely redo it :)

[16:31:41]

aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 252 seconds)

[16:34:57]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Read error: Operation timed out)

[16:38:19]

Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()

[16:39:33]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv

[16:41:29]

gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv

[16:45:27]

aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv

[16:56:36]

andreax (andreax!~andreaz@p57B9422D.dip.t-dialin.net) has joined #mythtv

[17:02:50]

andreax1 (andreax1!~andreaz@p57B93E32.dip.t-dialin.net) has joined #mythtv

[17:03:42]

davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)

[17:03:46]

andreax (andreax!~andreaz@p57B9422D.dip.t-dialin.net) has quit (Ping timeout: 264 seconds)

[17:04:13]

davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv

[17:22:22]

andreax1 (andreax1!~andreaz@p57B93E32.dip.t-dialin.net) has quit (Ping timeout: 264 seconds)

[17:22:55]

andreax (andreax!~andreaz@p57B93469.dip.t-dialin.net) has joined #mythtv

[17:26:30]

andreax1 (andreax1!~andreaz@p57B944D5.dip.t-dialin.net) has joined #mythtv

[17:28:00]

andreax (andreax!~andreaz@p57B93469.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)

[17:30:18]

danielk22:

Beirdo: As stuartm mentioned it's not segfaulting when handling the delete operator, but inside m_ChildrenList.begin() ; the code you committed should be harmless but doesn't actually address the segfault which probably has something to do with m_ChildrenList being invalid.

[17:31:21]

Beirdo:

which happened as a result of freeing a null value, or did I read it completely wrong?

[17:31:47]

Beirdo:

but yeah, it was probably pointless.

[17:32:02]

danielk22:

It looks like the it being null is red herring.

[17:32:06]

Beirdo:

sorry, it looked so easy late at night :)

[17:32:25]

Beirdo:

yeah, something else squashed the list, probably

[17:32:56]

Beirdo:

something like putting a stack pointer in there, maybe? instead of a heap pointer?

[17:36:06]

Beirdo:

anyways, I wouldn't be offended if ya rip that back out. At best, it's a band-aid

[17:39:12]

Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv

[17:40:27]

kth (kth!~kth@unaffiliated/kth) has joined #mythtv

[17:44:19]

zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer)

[17:44:47]

zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv

[17:45:53]

andreax1 (andreax1!~andreaz@p57B944D5.dip.t-dialin.net) has quit (Ping timeout: 258 seconds)

[17:46:33]

andreax (andreax!~andreaz@p57B92FF5.dip.t-dialin.net) has joined #mythtv

[18:03:51]

danielk22:

Beirdo: It looks like the instance that m_ChildrenList is in is corrupted.. but I don't see how that is happening.

[18:07:56]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Remote host closed the connection)

[18:08:13]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv

[18:08:24]

danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.)

[18:17:39]

_gunni_ (_gunni_!~Gunni@koln-4db460d6.pool.mediaWays.net) has joined #mythtv

[18:20:06]

sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)

[18:27:02]

wagnerrp:

stuartm: check out the second and third logs

[18:28:29]

wagnerrp:

track 12 on Laika Come Home fails at roughly 5:25 on the same file

[18:29:14]

wagnerrp:

the last timed log entries put are within a few seconds of that from when playback started

[18:29:40]

stuartm:

if it's memory corruption then it's an ffmpeg bug

[18:29:53]

stuartm:

but it's difficult to be sure of that without a sample

[18:30:32]

wagnerrp:

but yeah, i was confused by all three log files and both backtraces showing completely different errors

[18:32:21]

Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has joined #mythtv

[18:34:15]

sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv

[18:44:40]

Beirdo:

paul-h: I just saw your comments on #9523. This is confirmed to be bad? I'll try to test some tonight to see if I can trace that down. At worst, I guess, a revert isn't out of the question if I can't find the issue.

[18:46:46]

kth (kth!~kth@unaffiliated/kth) has quit (Read error: Connection reset by peer)

[18:51:16]

kth (kth!~kth@unaffiliated/kth) has joined #mythtv

[18:55:18]

andreax1 (andreax1!~andreaz@p57B9308E.dip.t-dialin.net) has joined #mythtv

[18:55:55]

andreax (andreax!~andreaz@p57B92FF5.dip.t-dialin.net) has quit (Ping timeout: 260 seconds)

[18:56:13]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv

[19:07:34]

paul-h:

Beirdo: Definitely breaks things here I've had to revert that change on all the systems I maintain

[19:08:59]

Beirdo:

OK

[19:09:23]

Beirdo:

I'm sorry I missed it for so long. I'll look at it tonight, and one way or the other, it should be fixed :)

[19:10:01]

Beirdo:

not sure HOW that change would have the effect you are seeing, but it's gotta be fixed for sure

[19:18:31]

abqjp:

sphery: so, I take it that I am supposed to use QTextStream instead of std::stringstream ?

[19:19:30]

sphery:

kormoc: warpme posted a SHOW ENGINE INNODB STATUS at http://www.mythtv.org/pipermail/mythtv-users/ . . . /318469.html . Do you see anything of interest there. (My understanding is that would have shown us if, for example, the recorded table were locked, right?)

[19:20:52]

sphery:

abqjp: not sure... Makes sense to me (would use the Qt-detected locale/codec settings and all?)

[19:21:55]

_gunni_ (_gunni_!~Gunni@koln-4db460d6.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 5829, sources date: 20110403, built on: 2011-05-08 08:20:36 UTC 5829 http://www.kvirc.net/)

[19:22:12]

abqjp:

sphery: looks like it. QTextStream does not provide a peek function, so I would have to change the logic a bit.

[19:22:38]

sphery:

stuartm: Looking at http://code.mythtv.org/trac/ticket/9936 , the problem is that lastScreen is false (because GetMythMainWindow()->GetMainStack()->TotalScreens() == 3) after we change themes. Any idea why that would be?

[19:25:41]

stuartm:

no, I haven't a clue

[19:28:58]

Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv

[19:29:42]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Quit: leaving)

[19:30:31]

iamlindoro:

Beirdo: Know anything about this?

[19:30:32]

iamlindoro:

mythbackend

[19:30:32]

iamlindoro:

Unknown log level: unknown

[19:30:35]

iamlindoro:

and no start

[19:30:39]

iamlindoro:

maybe I need a distclean?

[19:30:49]

Beirdo:

worth a try

[19:31:08]

Beirdo:

I haven't seen it do that, but I did change some of the logic around over the weekend

[19:31:08]

iamlindoro:

giving it a shot

[19:31:17]

Beirdo:

if it still does it, let me know

[19:33:18]

iamlindoro:

Beirdo: same thing after a distclean

[19:33:26]

iamlindoro:

No init of mythcontext or anything, just that one line

[19:33:31]

Beirdo:

OK, one sec

[19:33:46]

Beirdo:

what's the commandline? just mythbackend?

[19:34:02]

iamlindoro:

but mythbackend alone, and mythbackend --logfile /foor/bar/blah.log

[19:34:09]

Beirdo:

OK, one sec

[19:39:03]

Beirdo:

what does mythbackend --help show as the default for -v?

[19:39:31]

Beirdo:

err, for --loglevel, rather

[19:41:37]

Beirdo:

ooooh

[19:41:43]

Beirdo:

heh, one moment.

[19:41:59]

** Beirdo had a light bulb moment, please hold. **

[19:42:27]

iamlindoro:

Sorry, stepped away

[19:43:10]

iamlindoro:

I am not sure how to see default values

[19:43:27]

stuartm:

--help

[19:43:29]

iamlindoro:

oh, "defaults to unknown"

[19:43:30]

Beirdo:

should be in the text of --help

[19:43:43]

Beirdo:

yeah, it's that I hadn't initialized the map yet.

[19:43:46]

Beirdo:

fixing that

[19:44:07]

stuartm:

err, -v help

[19:44:36]

Beirdo:

the --loglevel one is in --help :)

[19:46:49]

Beirdo:

there.

[19:47:53]

Beirdo:

-v help still needs some help, I should look at that one after danielk's tweak.

[19:48:07]

iamlindoro:

Beirdo: Yeah, that seems better, thanks

[19:48:22]

sphery:

Captain_Murdoch / stuartm : The problem for #9936 is that the Theme Chooser calls the Reload Theme jump point with the pop argument set to false. All other uses of Reload Theme jump point use the default value of pop, which is true. Captain_Murdoch, I'm assuming that "false" meant you wanted it to stay on the Theme Chooser screen after it loaded the new theme, but it's not doing that--it's actually ending up on the Main Menu (which explains ...

[19:48:28]

sphery:

... the extra screens on the stack). I don't know if it's going to the Main Menu is how it originally worked or if this is something that was broken in mythui or in mythfrontend's reloadTheme() (though no changes in there from this year look like they could be related).

[19:48:32]

Beirdo:

sorry about that silliness :) I always seem to use --loglevel debug and missed that

[19:48:44]

Captain_Murdoch:

stuartm, in the U.S., during sports events, we often have commercial breaks just minutes after a previous break (think timeouts near the end of a game). also, we already have a 'MaximumCommercialSkip' setting which is the longest break to skip in one SKIP command. we also have the 'CommDetectMaxCommBreakLength' setting which defaults to 395 seconds which should be the max commercial length detected. since we use weights, it

[19:48:44]

Captain_Murdoch:

could be that that is being overruled by other indicators though, so we could start enforcing that value in other locations in the code.

[19:48:52]

sphery:

Changing the false to a true (at https://github.com/MythTV/mythtv/blob/master/ . . . ser.cpp#L619 ) makes it go to the main menu and allows exit

[19:49:23]

Captain_Murdoch:

I'd be fine with getting rid of hte 'max commercial skip (secs)' setting that I just mentioend (and I see sphery mentioned in scrollback).

[19:51:35]

sphery:

Captain_Murdoch: so that means, I can remove max commercial skip (secs) and we can instead make teh CommDetectMaxCommBreakLength setting (not user-facing, right?) so that it's enforcing any min/max we feel is appropriate?

[19:52:06]

Captain_Murdoch:

sphery, actuall, I want it to go to the main menu. I thought there was another reason for that argument, but can't recall off the top of my head.

[19:52:13]

sphery:

but if we are going to suggest users set that value, I want to add a UI widget for it rather than have them edit it directly

[19:52:56]

Captain_Murdoch:

CommDetectMaxCommBreakLength is a hidden setting, only in the code, there's no UI to edit it.

[19:53:20]

Captain_Murdoch:

that was mainly for my testing, but we could expose it to users in favor of the other setting.

[19:53:36]

Captain_Murdoch:

I think some users are editting it, but I set it pretty high to try to prevent that.

[19:54:19]

Captain_Murdoch:

I think some countries actually have commercials longer than 6 minutes 35 seconds during movies

[19:54:45]

Beirdo:

I think I've seen longer than that occasionally in movies in US/Canada

[19:54:53]

Beirdo:

like a triple commercial break

[19:55:16]

Beirdo:

10 minutes of mind-numbingness

[19:55:45]

Captain_Murdoch:

or 20 hits to the SKIP-30-second button. :)

[19:56:15]

Beirdo:

it works for a bathroom and make more popcorn break

[19:56:24]

sphery:

ok, github's blame says that the line "GetMythMainWindow()->JumpTo("Reload Theme", false);" was last modified by stuartm at changeset 1055e580 , but when I go to that changeset ( https://github.com/MythTV/mythtv/commit/1055e580 ), the code is "GetMythMainWindow()->JumpTo("Reload Theme");"

[19:56:33]

sphery:

how could someone have put the false in there without it showing in blame?

[19:56:57]

sphery:

Captain_Murdoch: that's what jump or # INFO is for :)

[19:58:02]

Beirdo:

sphery: line #?

[19:58:09]

sphery:

619

[19:58:13]

stuartm:

and according to that commit I didn't even touch that line

[19:58:21]

sphery:

yeah, this is why I'm so confused

[19:58:45]

stuartm:

github is matching up commits against the wrong lines?

[19:59:47]

stuartm:

caea1c7d (Chris Pinkham 2011-06–22 00:32:17 -0400 620) GetMythMainWindow()->JumpTo("Reload Theme", false);

[19:59:54]

stuartm:

according to git blame

[20:00:17]

stuartm:

https://github.com/MythTV/mythtv/commit/caea1c7d

[20:00:59]

Captain_Murdoch:

sphery, I think at one point, the way we are pushing ESCape key events to 'pop' windows was causing an issue on the theme chooser screen. I thought that when a theme reloaded we reinitialized everthing anyway, so that's why I think I remember passing 'false', to not bother popping if we were reinitializing anyway.

[20:01:36]

sphery:

yeah, stuartm found the commit where you put in the false...

[20:01:37]

Captain_Murdoch:

yeah, 'blame' here shows both of those lines as mine.

[20:02:24]

Captain_Murdoch:

it seems that a theme reload would have to pop all windows whether you want to or not.

[20:02:38]

sphery:

mine still says, "Not Committed Yet" changes--even though I backed out my changes...

[20:03:43]

Beirdo:

yeah, it was off by one line on the line number

[20:04:02]

Beirdo:

a git blame from the command line shows the JumpTo on line 620,

[20:04:21]

sphery:

So that's just a crazy github issue... guess I can't trust github for blames, either :)

[20:04:40]

Beirdo:

they trimmed the blank line a tthe top of the file

[20:04:43]

Beirdo:

argh!

[20:04:51]

sphery:

heh

[20:04:52]

Beirdo:

that's a bug, and should be reported to github

[20:05:15]

Beirdo:

of course, we don't NEED that blank line, but they should track it properly

[20:05:57]

sphery:

you want the honors? I think they don't like me--they moderated out my report of their javascript key bindings breaking for users with certain firefox settings because they don't want to allow you to disable their stupid keybindings

[20:06:18]

Beirdo:

my brain hurts too much to deal with them right now :)

[20:06:49]

sphery:

so, how long 'til we're on our own server and can make our repo the main one and have it just push changes to github?

[20:07:00]

sphery:

:)

[20:07:19]

Captain_Murdoch:

sphery, so that screen works fine for you without the 'false' in there? might have been an interaction with old code on our end or a specific Qt version issue. I added the false because the jumpto wasn't executing correctly when it tried to pop the ThemeChooser window out from under the user.

[20:07:44]

sphery:

it works fine, but I'm on a single combined frontend/master backend system

[20:07:52]

sphery:

no clue how it works with remote backends

[20:08:03]

Captain_Murdoch:

and I figured (wrongly) that everything was initialized again when we (re)loaded a theme.

[20:08:25]

Captain_Murdoch:

shouldn't matter local vs remote. by the time we jumpto, we already have the theme local and ready to use.

[20:09:36]

sphery:

OK, if that's the case, I'll push the change to remove the false arg (from both (using github's numbers) lines 619 and 799?)

[20:10:05]

sphery:

I'm not sure how to test the later one--with the THEME_INSTALLED message (is that for remote frontends?)

[20:10:22]

sphery:

or maybe that's only when it downloads a new theme

[20:10:30]

Beirdo:

I get that event :)

[20:10:39]

Captain_Murdoch:

yeah, that's triggered by the downlaod and install.

[20:11:01]

Beirdo:

I will be using it (still haven't coded it) to override background images

[20:11:14]

Captain_Murdoch:

and that was the case I think I was trying to fix specifically, so please test that before you commit anything that changes that line.

[20:11:26]

sphery:

ok, I'll test the download and install case, too

[20:12:37]

Captain_Murdoch:

thanks.

[20:13:22]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds)

[20:24:40]

Captain_Murdoch:

iamlindoro, how hard would it be to put in a check into the python grabbers to see if they work at all before we try to run grabbers for all recordings when each and every time it fails because of missing dependencies. in my case, it's not a new enough libxml2, but the housekeeper job is churning away getting an error message each and every time it tries to run the grabber. I assume this would happen every day as well looking

[20:24:40]

Captain_Murdoch:

at the housekeeper task setup.

[20:25:28]

iamlindoro:

Captain_Murdoch: I'll look into that, I believe there's a define for the python bindings

[20:26:14]

Captain_Murdoch:

ok, just something I noticed when starting up my dev MBE w/out the --nohousekeeper option for the first time in a while.

[20:26:47]

wagnerrp:

meaning if the deps to run the bindings and the grabbers are missing, ifdef out the code to run the housekeeper lookup?

[20:26:49]

Captain_Murdoch:

need to upgrade the MBE/fileserver sometime.

[20:27:05]

Captain_Murdoch:

wagnerrp, I just mean check that the grabber runs before trying to run it hundreds of times.

[20:27:24]

wagnerrp:

well iamlindoro was talking about the configure define, it sounded like

[20:27:36]

iamlindoro:

Captain_Murdoch: Can you try enclosing the run for the job in #ifdef CONFIG_BINDINGS_PYTHON ?

[20:28:15]

iamlindoro:

If the bindings are installed, it's because we have the deps, and if we have the deps, the job can run

[20:28:17]

Captain_Murdoch:

does that check for the version of libxml2, etc..?

[20:28:22]

Captain_Murdoch:

sorry, hit enter too soon.

[20:28:43]

wagnerrp:

we require lxml2, not libxml2

[20:28:44]

Captain_Murdoch:

is that configure #define set based on whehter we find the new enough libxml2?

[20:28:55]

wagnerrp:

lxml may in turn require libxml

[20:29:02]

Captain_Murdoch:

! Error – The installed version of the "lxml" python library "libxml" version is too old.

[20:29:05]

Captain_Murdoch:

yeah.

[20:29:06]

iamlindoro:

It's defined based on whether or not the bindings are installed, which is contingent upon new enough deps, yes

[20:29:23]

iamlindoro:

configure won't install the bindings without the deps being met

[20:29:50]

wagnerrp:

it tries to import 'lxml' during configure, and if it fails, refuses to install them

[20:30:07]

iamlindoro:

Realistically, though, it would be nice if we could require the python bindings to be installed at this point

[20:30:14]

iamlindoro:

We're building a lot of functionality around them

[20:30:16]

stuartm:

did we ship mythffplay in 0.24?

[20:30:21]

iamlindoro:

stuartm: yes

[20:30:27]

stuartm:

thanks

[20:30:35]

iamlindoro:

stuartm: At least... I think we did :)

[20:30:39]

wagnerrp:

i still cant figure out why i dont have one of those

[20:32:17]

stuarta:

iamlindoro: well if you do that you have to make sure configure can find them if you pass a prefix to it

[20:33:32]

stuarta:

ie. i build with --prefix=/usr/local/myth-0.24 or myth-svn and iirc the plugins can't find them

[20:34:02]

iamlindoro:

stuarta: pretty sure we have an argument to specify which python to use, which in turn would know where to look for its libs

[20:34:24]

Captain_Murdoch:

--python=/usr/bin/python2.6

[20:34:33]

stuarta:

it's not where to find python

[20:34:41]

stuarta:

it's where to find where we install our libs

[20:34:58]

wagnerrp:

eh?

[20:35:04]

iamlindoro:

python doesn't work that way

[20:35:35]

wagnerrp:

if you set prefix to /usr or /usr/local, the bindings will ignore the setting and install where they want to

[20:35:54]

wagnerrp:

if you set it elsewhere, they will install elsewhere, and its up to you to configure python to know about the new path

[20:36:43]

wagnerrp:

it was decided if the user wants to install outside the standard paths

[20:36:50]

wagnerrp:

we shouldnt be doing tinkering to ensure it works

[20:37:05]

stuarta:

hmmm, i only pass a prefix, not tinker with the python paths

[20:37:41]

stuarta:

wagnerrp: btw. are our libs versioned. ie. can the 0.24 and master libs coexist?

[20:38:09]

sphery:

stuarta: pretty sure it wasn't shipped with 0.24, but was added to -fixes, and is shipped with 0.24.1

[20:38:10]

wagnerrp:

depends on the distro i think

[20:38:48]

stuarta:

when building from source

[20:39:06]

sphery:

er, wrong stuart...

[20:39:10]

Captain_Murdoch:

iamlindoro, needed a #ifdef CONFIG_BINDINGS_PYTHON since that is always defined as either 0 or 1

[20:39:12]

wagnerrp:

actually no, the trunk bindings are still listed as 0.24.0, so they will overwrite previous bindings regardless

[20:39:14]

sphery:

stuartm: pretty sure it wasn't shipped with 0.24, but was added to -fixes, and is shipped with 0.24.1

[20:39:21]

Captain_Murdoch:

odd, that didn't paste correctly.

[20:39:37]

stuarta:

hmmm, no idea which python libs i'll end up with then

[20:39:40]

Captain_Murdoch:

it needed "#if CONFIG_BINDINGS_PYTHON

[20:39:50]

** stuarta has co-habiting installs of 0.24 and master **

[20:39:52]

iamlindoro:

Captain_Murdoch: OK... if that works for you, feel free to commit

[20:40:01]

wagnerrp:

stuarta: if you are installing them outside of /usr or /usr/local, you will get neither

[20:40:25]

wagnerrp:

configure your backend init script to alter the environment and tell it where to pull additional modules from

[20:40:39]

stuarta:

so after having a quick look

[20:40:45]

wagnerrp:

with the PYTHONPATH environmental variable

[20:41:06]

zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)

[20:41:12]

stuarta:

0.24 stuck it into /usr/local/myth-0.24/lib/python.....

[20:41:36]

wagnerrp:

i.e. PYTHONPATH=/usr/local/myth-0.24/lib/python2.6 mythbackend

[20:42:41]

wagnerrp:

i could add a line to the bottom of configure to warn that the modules are being installed to a non-standard location

[20:42:47]

stuarta:

no idea where it went in master

[20:42:49]

wagnerrp:

and that users will have to update their system to match

[20:43:05]

stuarta:

i'll check it wasn't missing a lib at build time as this is a new box

[20:45:14]

Captain_Murdoch:

iamlindoro, committted. (also tested by changing the 0 to a 1 in the config .h file and verifying that it tried to run the grabber after recompiling/reinstalling.

[20:45:19]

iamlindoro:

Captain_Murdoch: Of course this now introduces the assumption that grabbers will always be python, and will always require the python bindings (versus perl, or a python script which doesn't use the bindings)

[20:45:37]

iamlindoro:

Captain_Murdoch: Sure I can't convince you it's a good idea to just require the bindings?

[20:45:37]

Captain_Murdoch:

now ya tell me. :)

[20:46:00]

iamlindoro:

Well, I think this works for now, there's only two mythtv-compatible grabber scripts, and both require the bindings

[20:46:04]

Captain_Murdoch:

IMHO, I think that if the script fails once, we should remember that and not try to run it again.

[20:46:28]

Captain_Murdoch:

if it fails for dependency reasons. in fact, this is probably an old version of the script anyway, so I probably shouldn't have it installed I guess.

[20:46:31]

wagnerrp:

did we ever remove those additional requirements picked up by smolt?

[20:47:18]

iamlindoro:

Captain_Murdoch: I really don't have any visibility on why grabbers fail-- It could just as easily be that the conneciton was down, the API on the far side was malfunctioning, etc... how would you forsee me handling all that?

[20:47:46]

iamlindoro:

And why, in an otherwise working system that has an intermittent problem, would we want to give up forever on looking up an item, or even worse, everything?

[20:47:48]

Captain_Murdoch:

iamlindoro, I know, that's why I asked my original question. wondering if grabbers should return some specific value to indicate that they'd never ever work, so why run them again.

[20:48:03]

wagnerrp:

iamlindoro: you have a trio of babies from drug addled mothers in a tank in your basement

[20:48:08]

Captain_Murdoch:

it's one thing if the site is down or the internet is down, those will recover (hopefully).

[20:48:29]

iamlindoro:

That would only be of value in a single run of the script... how would we handle when the user fixed the problem?

[20:48:51]

Captain_Murdoch:

hence the comment saying these may be old scripts installed since configure doesn't set it up to install python bindings currently. I may be on old bindinds.

[20:49:01]

Captain_Murdoch:

restart MBE, continue.

[20:49:28]

Captain_Murdoch:

or else just rmemeber it for that running sequence. if it fails the first time out of 200, because of some reason, then it will probably fail the other 199.

[20:49:52]

iamlindoro:

I dunno, I have had a failure or two in a large run before, it happens

[20:49:56]

Captain_Murdoch:

if the internet is down when the artwork housekeeping job starts, it will probably still be down when the 200th grabber is run a few minutes later.

[20:50:11]

iamlindoro:

This begins to sound worryingly like mindreading

[20:50:22]

Captain_Murdoch:

that's why I said it's one thing if the internet is down, but it's another if the script won't run at all.

[20:50:24]

iamlindoro:

or where we tryi to cover a corner case and end up hobbling the dominant case

[20:50:40]

Captain_Murdoch:

and why I said it's probabl due to my old bindings installed.

[20:50:56]

iamlindoro:

You are starting a lot of sentences with "that's why I said"

[20:51:09]

wagnerrp:

iamlindoro: is the housekeeper set up that you can postpone a task until later?

[20:51:32]

iamlindoro:

I am just expressing that I see a lot of cases where trying to handle a single failure sould hobble an otherwise working system

[20:51:37]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv

[20:51:53]

wagnerrp:

you could add another query to the grabber format to 'test connection to data source'

[20:51:57]

iamlindoro:

wagnerrp: I don't believe so

[20:52:04]

wagnerrp:

if that fails, postpone the task an hour or so

[20:53:46]

iamlindoro:

wagnerrp: don't think we have a facility for doing so right now

[20:55:11]

iamlindoro:

wagnerrp: Alternately, could add an argument to mythpython which tests everything and returns a known value

[20:55:29]

iamlindoro:

I could easily run that at the top of a mythmetadatalookup run

[20:55:53]

wagnerrp:

it could test for availability of dependencies

[20:55:59]

wagnerrp:

but it wouldnt know anything about the grabber scripts

[20:56:06]

iamlindoro:

A failure at the sources will time out-- we already handle that, so I don't think we need the deferral necessarily

[20:56:17]

sphery:

for delaying, you could modify the wantToRun() period values (since they're hard coded to 0/24, it wouldn't be messing with anyone's settings/desired config)

[20:56:39]

Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Dog + 10 hours alone = Carpet Cleaning Duty.)

[20:57:21]

Captain_Murdoch:

wouldn't it make sense to have a 'test mode' for each grabber to see if that grabber worked? with 3rd party grabbers, will we assume they work and just run them over and over when they're failing because of a missing dependency, etc..?

[20:57:37]

iamlindoro:

Captain_Murdoch: Something occurs to me, also... if you don't want the housekeeper job to run, why don't you just turn it off using the UI control?

[20:57:52]

iamlindoro:

Setup->Artwork and Data Sources, turn off the checkbox

[20:58:04]

Captain_Murdoch:

why can't it automatically detect? :) we're trying to reduce settings...

[20:58:20]

Captain_Murdoch:

you're one of the main proponents of that. :)

[20:58:32]

iamlindoro:

For all the good it does me

[20:58:56]

Captain_Murdoch:

I think mine is a broken system, but think that we should autodetect whether a grabber works before running it 1000 times every day for a user's 1000 recordings.

[20:59:33]

iamlindoro:

I honestly have myface in my hands right now

[20:59:45]

iamlindoro:

If it's a broken system, you fix the system

[20:59:55]

iamlindoro:

you don't write a bunch of code to avoid annoying the user with a broken system

[21:00:18]

Captain_Murdoch:

if (testcommandresult != 1) then return;

[21:00:18]

sphery:

Captain_Murdoch: OK, I think the reason you added false was because with pop = true, it pops the theme chooser screen and goes to the main menu as shown for the old theme, then eventually updates to the new theme. with pop = false, it stays on the theme chooser page until it flips to main menu of new theme.

[21:00:41]

sphery:

so if we want to allow that, maybe we need to rework the reload theme to pop all screens?

[21:00:45]

Captain_Murdoch:

sphery, sounds like that might have been the case. I don't recall, it was a while ago and a late night I believe.

[21:00:53]

iamlindoro:

Captain_Murdoch: So now we bog the whole system down even more running unnecessary commands on what is acknowledged to be a broken system?

[21:01:10]

Captain_Murdoch:

I think reload theme needs to pop all by default since the underlying screens would be totally hosed I'd think if we're using a new theme.

[21:02:17]

sphery:

yeah, that sounds like a better fix, anyway, so that we don't get this same problem some other way in the future

[21:02:20]

Captain_Murdoch:

iamlindoro, run a test command once vs running the grab command 1000x? forget about it. my system is broken. I'm just trying to eliminate user issues after release. not all users are on 24x7, not all will know about the new automated artwork grabber. not all will want the new automated artwork grabber even if most of us like it.

[21:02:33]

Captain_Murdoch:

s/users are on/users are online/

[21:03:16]

iamlindoro:

Captain_Murdoch: Each of those is a disparate issue-- But to address not every user wanting it, they *do* have the capacity to turn it off

[21:03:48]

Captain_Murdoch:

right, and autodetecting is a simple check. "does the test command work", if not, then abort the housekeeper job, if it does work, then continue.

[21:04:19]

** Captain_Murdoch goes to think about other things like having to changing a dirty diaper, etc.. :) **

[21:04:39]

iamlindoro:

Captain_Murdoch: Well, setting aside the fact that it's not just one command that you can test and run, the decision about what grabber gets run is deep in the metadata classes, so minimally it would have to run through all configured scripts and test them

[21:05:24]

iamlindoro:

That said, fine, I'll implement it, but since I have no python capabilities at all, someone is going to have to write a test command into each of the grabbers

[21:06:10]

iamlindoro:

wagnerrp: If you are game to scratch the itch of others, -t is probably the sensible choice of switch-- I can add code to test all the grabbers to the metadata classes

[21:07:22]

wagnerrp:

sure, ill look through the APIs and see if there is a real way to test the servers

[21:07:34]

wagnerrp:

otherwise, ill just try to pull the main page

[21:07:54]

iamlindoro:

wagnerrp: Well, I'd rather just test the local functionality

[21:08:26]

iamlindoro:

otherwise, we will fail for *all* grabbers if even one is intermittent

[21:08:37]

iamlindoro:

since I need to be able to test the whole environment in one step

[21:09:23]

iamlindoro:

I really don't want to have to build in some half baked functionality where we try to guess what grabber we're going to use, and only handle that content

[21:10:34]

wagnerrp:

so just check to see if all dependencies are available? that should be easily doable

[21:12:10]

iamlindoro:

sigh, I just know that if we do it this way, someone will still complain that we don't test connectivity... so whatever, might as well add that in too

[21:12:19]

iamlindoro:

Doesn't mean we have to check for it everywhere

[21:12:23]

iamlindoro:

just where we do batch jobs

[21:16:20]

stuartm:

ok, the flac crash isn't an upstream bug :(

[21:18:45]

stuartm:

it's a shame janneg isn't around

[21:19:38]

kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)

[21:20:02]

iamlindoro:

wagnerrp: I assume we'll communicate this through return codes... know of the top of your head how to get the return code with MythSystem?

[21:23:56]

wagnerrp:

should be whatever returns from .wait()

[21:24:34]

iamlindoro:

as an int?

[21:24:43]

iamlindoro:

uint, looks like

[21:24:47]

wagnerrp:

Wait(), uint

[21:24:48]

wagnerrp:

right

[21:25:22]

iamlindoro:

What do you want to return for good v bad?

[21:25:55]

wagnerrp:

just the normal, 0 for good, anything else for bad

[21:26:13]

wagnerrp:

actually

[21:26:18]

wagnerrp:

cant you just use -v for that?

[21:26:56]

wagnerrp:

just make sure -v loads everything it might need

[21:27:07]

wagnerrp:

if it fails to load, it errors out

[21:29:18]

foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv

[21:30:43]

iamlindoro:

wagnerrp: I suppose so, and had been thinking that, but it does introduce the kink that -v must now import/include all deps

[21:30:52]

iamlindoro:

which is not an expected requirement

[21:31:16]

iamlindoro:

We have at least one perl grabber script (for games) that simply echos the correct version XML

[21:31:33]

iamlindoro:

that's not an unreasonable way of doing it, and I expect that other grabber authors might do the same

[21:33:48]

iamlindoro:

It also requires that it connect to and test the site if we're going to do that

[21:34:10]

iamlindoro:

which means you can't even configure the script in the UI (which requires -v output) if the site isn't up

[21:36:21]

okolsi:

Beirdo: reg #7118, just about to go for a trip, i'll try to find an example file after ~5–6 days

[21:38:08]

Beirdo:

OK, that's fine :)

[21:38:24]

Beirdo:

thanks. It's sat a long time anyways, another week won't kill it

[21:38:49]

wagnerrp:

jams: patch committed

[21:42:45]

iamlindoro:

wagnerrp: Added code to the metadata classes to test each grabber with -t. Can always change it if you want to do things a different way. It's not actually tested anywhere but the infrastructure exists when you are done with the scripts

[21:42:51]

paul-h (paul-h!~paulh@mythtv/developer/paul-h) has quit (Remote host closed the connection)

[21:52:56]

paul-h (paul-h!~paulh@5adce259.bb.sky.com) has joined #mythtv

[21:52:56]

paul-h (paul-h!~paulh@5adce259.bb.sky.com) has quit (Changing host)

[21:52:56]

paul-h (paul-h!~paulh@mythtv/developer/paul-h) has joined #mythtv

[21:57:14]

j-rod is now known as j-rod|afk

[22:03:34]

jams:

thx..the server side is ready to go. Just waiting on the new mythtv server to be reimaged/account setup.

[22:05:26]

iamlindoro:

wagnerrp: http://pastebin.com/5zE1vtrH

[22:05:41]

iamlindoro:

That, on top of the stuff to master just now, should test the movie and tv grabbers with -t

[22:06:23]

** xris wonders if it's worth preordering a hauppauge WinTV-DCR-2650 **

[22:06:45]

wagnerrp:

dont do it from amazon

[22:07:51]

xris:

heh

[22:07:57]

xris:

no. would be straight from hauppauge

[22:08:08]

xris:

they're giving a $20 discount on it now. $130 vs $150

[22:09:02]

iamlindoro:

xris: Per the Hauppauge guys, it will work with libhdhomerun

[22:09:08]

xris:

well, $10 off if you take the $10 shipping into account.

[22:09:17]

xris:

iamlindoro: yeah, just reading your reply on -users

[22:09:19]

xris:

+

[22:09:28]

iamlindoro:

yeah, should be nice-- suddenly we have all these options

[22:09:38]

jams:

but only for the exclusive club of hauppauge facebook friends

[22:09:42]

xris:

hard to beat the price on the hauppauge one.

[22:10:00]

xris:

jams: the discount link is in google's index...

[22:10:20]

xris:

granted, I think I liked them on Facebook, but wouldn't have a cookie on their site.

[22:10:26]

jams:

was just reading whats on their page

[22:10:43]

xris:

yeah

[22:10:52]

iamlindoro:

wagnerrp: Captain_Murdoch: http://pastebin.com/HJSsCKQt

[22:11:06]

xris:

then will come the difficulty of getting a cable card from Comcast...

[22:11:23]

xris:

(mostly an inconvenient drive up north to their office)

[22:12:19]

stuartm:

xris: they won't deliver it?

[22:12:46]

xris:

stuartm: not for free.. at least not when I've ordered/exchanged cable boxes.

[22:18:10]

PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 252 seconds)

[22:22:17]

xris:

nice. cable card cost is WAY less than a cable box.

[22:26:13]

xris:

then again, they won't let me self-install a cable card. wtf. $25 fee for them to come out and plug a card into the slot.

[22:26:51]

PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv

[22:28:45]

sphery:

xris: http://www.gossamer-threads.com/lists/mythtv/users/477956#477956 (not sure which day in July, but there aren't many left)

[22:29:29]

sphery:

xris: might also want to read this thread: http://www.gossamer-threads.com/lists/mythtv/users/486214#486214

[22:29:45]

xris:

ah, nice

[22:30:40]

stuartm:

"Either the server is down or the master server settings in mythtv-settings does not contain the proper IP address"

[22:30:49]

stuartm:

shouldn't that be mythtv-setup?

[22:32:15]

iamlindoro:

definitely

[22:43:40]

xris:

sphery: local office knows more than the online people. they have them at the store, and will someday ship, but can't at the moment.

[22:44:29]

xris:

now to decide if $25 install fee is worth not driving 30–40 minutes each way out of my way to go to the comcast store.

[22:45:21]

iamlindoro:

For me I'd take the drive to avoid having to fight with some installer about what Linux is, and whether it's okay to install the card in the system, and explain that Windows doesn't live here

[22:46:55]

xris:

heh

[22:47:04]

xris:

I can always boot win7 up in vmware

[22:47:31]

mrand:

hahaha

[22:47:54]

xris:

.. which lives on the mac. not the mythtv box. that'll surely help avoid confusion. :)

[23:00:45]

zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv

[23:04:31]

PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Read error: Connection reset by peer)

[23:08:54]

danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv

[23:15:10]

PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv

[23:57:35]

stuartm:

Beirdo: mythpreviewgen no longer seems to be respecting the fact that the backend is daemonized and it's logging to the console

[23:58:25]

stuartm:

it was working a couple of days ago

[23:58:49]

Beirdo:

I was afraid that would happen

[23:59:27]

Beirdo:

sigh, that's due to the request danielk had to allow logging to the console when we are in quiet mode (for LOG_ERR and above)

[23:59:49]

Beirdo:

I'll hit it again with a clue-by-4 and get it back into submission

[23:59:58]

Beirdo:

sorry about that.

Tuesday, July 26th, 2011

[00:00:46]

zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 264 seconds)

[00:02:55]

stuartm:

np

[00:12:23]

abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Quit: abqjp)

[00:16:29]

andreax1 (andreax1!~andreaz@p57B9308E.dip.t-dialin.net) has quit (Read error: Connection reset by peer)

[00:22:26]

Mousey (Mousey!~wtfisme@ross154.net) has quit (Ping timeout: 240 seconds)

[00:22:49]

zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv

[00:35:01]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds)

[00:43:46]

danielk22:

Beirdo: That's only necessary when apps are run on the console. I'm pretty sure I was redirecting background mythpreviewgen logging to /dev/null before the logging changes.

[00:44:07]

danielk22:

BTW Thanks for fixing the loglevel stuff earlier. I had actually just noticed the problem when you committed the fix :)

[00:44:57]

Beirdo:

well, we shouldn't be redirecting to /dev/null, we should be disabling console output :)

[00:45:16]

Beirdo:

I'll have it fixed soon enough, not to worry

[00:45:30]

Beirdo:

but of course, work got in the way of play...

[00:45:36]

danielk22:

stuartm: the problem was that mythcommflag would exit silently when it ran into trouble, like for instance it couldn't open a file.

[00:46:41]

Beirdo:

I'll have it propagate better :) Just have to sit down and think the precise way, should only take a short time

[00:48:20]

danielk22:

Beirdo: Take your time. Measure twice, cut once..

[00:58:27]

kormoc is now known as kormoc_afk

[01:04:04]

gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv

[01:04:05]

gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host)

[01:04:05]

gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv

[01:04:37]

Beirdo:

yeah, good plan. Been doing too much double-cutting these days.

[01:05:09]

davide_ (davide_!~david@mythtv/developer/gigem) has quit (Read error: Operation timed out)

[01:06:40]

danielk22:

Beirdo: Is there a wiki page documenting the new logging? It looks like when I run my mythbackend init.d script from the console it sends logging to the console despite being run with --daemon and with --logfile I'm guessing I need to change my init.d script..

[01:07:20]

jpabq:

How do you tell if you successfully read in the data you wanted with QTextStream? It does not seem to have a ! operator like iostream does.

[01:07:33]

danielk22:

Here's the command line: /usr/local/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythtv/mythbackend.pid -v record,channel but I can figure out the problem myself with some docs..

[02:02:26]

Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving)

[02:07:30]

Beirdo:

danielk22: not as of yet, no. Before adding the console logging for LOG_ERR and above, it was nearly all under control with the --daemon though. You may want to add --loglevel to your magic incantation if you want other than default

[02:10:57]

Beirdo:

now, let me put on the thinking cap :)

[02:11:54]

yates (yates!~yates@nc-71-54-143-100.dhcp.embarqhsd.net) has joined #mythtv

[02:13:06]

Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv

[02:23:35]

yates (yates!~yates@nc-71-54-143-100.dhcp.embarqhsd.net) has quit (Quit: rcirc on GNU Emacs 23.2.1)

[03:33:05]

gandalfcome (gandalfcome!~gandalfco@mithrandir.anu.edu.au) has joined #mythtv

[03:40:04]

zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)

[03:53:49]

Beirdo:

OK, I *think* that's got it.

[04:00:20]

bill6502 (bill6502!~bill6502@2002:d850:4778:7cd3:9ef4:32ea:c6ea:200) has left #mythtv ()

[04:16:12]

iamlindoro:

jpabq: #9945 is a failure to check for the validity of m_filtersButton in the schedule editor... I am a little confused by the define for the widget-- why this way rather than just using UIUtilW and checking if (m_filtersButton) in the couple places it is used?

[04:18:22]

iamlindoro:

jpabq: http://pastebin.com/Ecuw1tyj Can you see if that works for you? This is how I've seen optional widgets done elsewhere in the UI, but if there's something different here, I can just add the null check in that one spot

[04:56:25]

stoffel (stoffel!~quassel@p57B4B445.dip.t-dialin.net) has joined #mythtv

[04:59:38]

gandalfcome (gandalfcome!~gandalfco@mithrandir.anu.edu.au) has quit (Ping timeout: 250 seconds)

[05:21:09]

stoffel (stoffel!~quassel@p57B4B445.dip.t-dialin.net) has quit (Remote host closed the connection)

[05:51:25]

kormoc_afk is now known as kormoc

[06:04:36]

sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has quit (Ping timeout: 260 seconds)

[06:32:30]

jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 276 seconds)

[06:32:42]

jpabq- (jpabq-!~jpabq@174-28-184-228.albq.qwest.net) has quit (Ping timeout: 276 seconds)

[07:07:26]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Ping timeout: 250 seconds)

[07:30:33]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv

[07:46:51]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Ping timeout: 240 seconds)

[07:55:31]

jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv

[07:57:01]

jpabq- (jpabq-!~jpabq@71-37-153-77.albq.qwest.net) has joined #mythtv

[08:04:42]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv

[08:30:11]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Read error: Operation timed out)

[08:41:14]

natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv

[09:06:10]

xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 258 seconds)

[10:05:02]

mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection)

[10:05:51]

mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv

[10:20:49]

ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has quit (Read error: Connection reset by peer)

[10:21:04]

MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv

[10:21:34]

ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv

[10:24:49]

XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 250 seconds)

[10:36:59]

stuartm:

iamlindoro: heh, just committed the fix for that

[10:46:40]

zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv

[10:49:14]

zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)

[10:49:21]

laga_ (laga_!~laga@h1626373.stratoserver.net) has quit (Read error: Operation timed out)

[10:50:41]

laga (laga!~laga@h1626373.stratoserver.net) has joined #mythtv

[11:01:57]

xris (xris!~xris@xris.forevermore.net) has joined #mythtv

[11:07:14]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv

[11:11:41]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Ping timeout: 240 seconds)

[11:34:18]

coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv

[11:58:31]

gandalfcome (gandalfcome!~gandalfco@mithrandir.anu.edu.au) has joined #mythtv

[12:05:09]

gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)

[12:05:36]

gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv

[12:05:36]

gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host)

[12:05:36]

gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv

[12:27:51]

okolsi (okolsi!~mythtv@unaffiliated/okolsi) has quit (Ping timeout: 260 seconds)

[12:29:17]

okolsi (okolsi!~mythtv@a88-115-32-206.elisa-laajakaista.fi) has joined #mythtv

[13:07:42]

gandalfcome (gandalfcome!~gandalfco@mithrandir.anu.edu.au) has quit (Ping timeout: 276 seconds)

[13:22:03]

zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv

[13:44:05]

bill6502 (bill6502!~bill6502@216-80-50-206.c3-0.alc-ubr4.chi-alc.il.cable.rcn.com) has joined #mythtv

[13:46:42]

jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Read error: Connection reset by peer)

[13:46:42]

jpabq- (jpabq-!~jpabq@71-37-153-77.albq.qwest.net) has quit (Read error: No route to host)

[13:50:17]

jpabq (jpabq!~jpabq@71-37-153-77.albq.qwest.net) has joined #mythtv

[13:50:17]

jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv

[13:50:17]

jpabq (jpabq!~jpabq@71-37-153-77.albq.qwest.net) has quit (Changing host)

[13:51:31]

jpabq- (jpabq-!~jpabq@71-37-153-77.albq.qwest.net) has joined #mythtv

[13:56:12]

sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has joined #mythtv

[14:06:34]

bill6502 (bill6502!~bill6502@216-80-50-206.c3-0.alc-ubr4.chi-alc.il.cable.rcn.com) has left #mythtv ()

[14:15:21]

Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv

[14:24:57]

j-rod|afk is now known as j-rod

[14:44:41]

abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv

MythLogBot@irc.freenode.net :: #mythtv

Current users (85):