| Monday, February 27th, 2012, 00:03 UTC | ||
| [00:03:12] | stuarta: | has a 0.24 build been run since you pushed those changes? |
| [00:04:08] | jya: | tbh, I haven't tried 0.24.. but provided they share a common Qt build, I can't see a problem |
| [00:04:42] | stuarta: | i can forsee lots of breakage |
| [00:05:24] | stuarta: | i put in buildprofiles specifically so we could bump the Qt version without breaking the older release |
| [00:05:41] | jya: | I can certainly start a 0.24 build on my side… I won't be able to test that build however… |
| [00:05:52] | stuarta: | MythLogBot: force build master-osx-snow-leopard now |
| [00:06:06] | stuarta: | MythLogBot: build master-osx-snow-leopard now |
| [00:06:07] | jya: | currently, the build script uses the exact same qt build between the two |
| [00:06:34] | stuarta: | so next time someone commits to 0.24 that buildslave will break too |
| [00:06:38] | jya: | but again, us the old builder if you want to.. it is still there |
| [00:06:59] | stuarta: | i'd set it up so the one script knew how to build both |
| [00:07:01] | jya: | however, all functions, options and settings in the new one are there |
| [00:07:03] | ** stuarta sighs ** | |
| [00:08:01] | stuarta: | erm, where's the buildbot gone? |
| [00:08:04] | jya: | I don't understand why you want to make things more difficult than they really are… If you want I just revert the lot and you can deal with that shit yourself… |
| [00:08:11] | stuarta: | Beirdo: where's the buildbot gone? |
| [00:08:24] | stuarta: | no, i'm happy you've done it |
| [00:08:31] | jya: | doesn't seem that way... |
| [00:08:34] | stuarta: | osx-packager need a broom through it |
| [00:08:51] | stuarta: | just a little pissed that all the work i did got thrown out |
| [00:08:58] | jya: | All I've been getting from you are bad vibes |
| [00:09:05] | jya: | nothing got thrown out |
| [00:09:12] | jya: | absolutely NOTHING |
| [00:09:47] | stuarta: | sorry, i must be reading the commit diff wrong |
| [00:09:54] | jya: | it works identically to how it was working before |
| [00:10:04] | stuarta: | anyway, i've cleaned out qt and it's building now |
| [00:10:08] | jya: | and I tested build on 10.7, 10.6, 10.5 |
| [00:10:37] | jya: | do you know how long it takes to get that crap to build on a 10.5 VM, find why Qt fail to build, patch it and restart from zero? |
| [00:10:48] | jya: | I spend the whole last week on that |
| [00:10:58] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [00:12:11] | jya: | you /must/ be reading the diff wrong, because everything is exactly the same as it was before… other than the version of qt used and so it could be built on lion. it doesn't change anything for 10.6. The only thing I did in regards to the depends defininion it moving it later in the script |
| [00:12:34] | jya: | as it was defined at the top of the perl script, none of the variable were defined then |
| [00:12:49] | stuarta: | i've just started reading the new osx-packager |
| [00:12:49] | donce (donce!~donce@d86-33-121-66.cust.tele2.at) has joined #mythtv | |
| [00:12:50] | jya: | so you had hacks looking for the name of the variable and doing replacement |
| [00:13:30] | stuarta: | a lot it was inherited |
| [00:13:31] | jya: | now that I've put it after all the main global variables are defined, there's no need to replace those strings and you can use "$OPTION" directly in the config line.. |
| [00:14:01] | jya: | stuarta: I know.. this stuff of having to replace the variable name before running the command had been there for years |
| [00:14:11] | jya: | and it has annoyed me for years... |
| [00:14:23] | stuarta: | it needed a broom putting through it, for which i'm grateful |
| [00:14:27] | jya: | like you had to use ' ' strings instead of " " |
| [00:14:58] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120216080748]) | |
| [00:15:27] | jya: | well, I hope you will reconsider your position as the changes actually made, realise that really, nothing has changed that would break what was working before… So we shake hand, and kiss and makeup if need be |
| [00:15:51] | stuarta: | i'm getting over it |
| [00:16:02] | stuarta: | a heads up would have been appreciated |
| [00:16:14] | jya: | ?? I certainly did |
| [00:17:10] | jya: | I've been mentioning my progress here for a while. and even wrote a nice README, just for you btw: https://github.com/MythTV/packaging/tree/master/OSX/build |
| [00:17:30] | jya: | even put a common troubleshooting for precisely what the buildbot broke |
| [00:18:28] | stuarta: | fair enuf, i clearly didn't understand what you were intending from what you said in here last week |
| [00:18:51] | jya: | having said that, you only have to change 5 bytes to make it work without any delay for you |
| [00:19:07] | jya: | call osx-packager-10.4.pl instead of osx-packager.pl |
| [00:19:27] | stuarta: | i'll go clean out the 0.24 build tree too |
| [00:19:33] | stuarta: | i don't care about how long it takes |
| [00:20:04] | jya: | what about you let me test the 0.24 build, and in the meantime you use osx-packager-10.4.pl |
| [00:20:22] | stuarta: | i'm happy to keep it |
| [00:20:42] | stuarta: | like i said before, the head osx-packager is used by the buildbot for both revisions |
| [00:21:01] | stuarta: | so i'm cleaning the old version out |
| [00:21:20] | jya: | I'm sure changing it so it use the -10.4 one is not a great deal of effort ... |
| [00:21:37] | jya: | ok… that's fine too… just going to take a while |
| [00:21:40] | jya: | or … better |
| [00:21:55] | stuarta: | tbh, it doesn't really matter if 0.24 does break, since we'll (in theory) be releasing soon |
| [00:21:55] | jya: | you wait a few hours, and you won't need to compile Qt at all ever |
| [00:22:12] | jya: | you'll have to download the 1.2GB Qt SDK though |
| [00:22:17] | stuarta: | it's already building :-p |
| [00:24:49] | jya: | we need a new flag so it doesn't even try to build the dependency |
| [00:24:52] | jya: | and keep the existing one |
| [00:25:02] | jya: | a bit like your -bootstrap |
| [00:25:25] | stuarta: | i seem to have used the 177Mb Qt download |
| [00:25:32] | jya: | yes |
| [00:25:41] | jya: | right now it compiles Qt from source |
| [00:25:41] | stuarta: | for my attempts at getting the framework builds working |
| [00:25:46] | jya: | (which was no small effort) |
| [00:26:04] | stuarta: | does it run? |
| [00:26:12] | jya: | of course it runs |
| [00:26:14] | stuarta: | :) |
| [00:27:05] | jya: | you make it sounds like suddenly you have a massive effort ahead of you and something to fix… there's nothing to do for you other than using the old build script, or deleting the old .os-packager directory |
| [00:27:16] | stuarta: | i've fixed it already |
| [00:27:32] | stuarta: | i however have done none of the things i set out todo this evening as a consequence |
| [00:27:41] | jya: | what a fix ! :) |
| [00:27:54] | stuarta: | that tends to make me grumpy |
| [00:28:23] | jya: | that's by your choice only…. instead of getting hot-headed you would have called the old script and problem solved |
| [00:28:41] | jya: | or delete the old build tree and let it run in the background |
| [00:28:49] | stuarta: | there's no point in that, i like to know what's been done, and make it work with it, thats all |
| [00:29:04] | jya: | we're just going around in circles… But that's okay, I accept your apologies :) |
| [00:29:16] | stuarta: | it's the not knowing, and finding it broken that winds me up |
| [00:29:21] | stuarta: | it's on a postcard :) |
| [00:30:02] | jya: | the core issue is that Qt has the bad habit of having two version of the header installed to break things |
| [00:30:26] | jya: | so if you had installed the 4.7 header, 4.8 wouldn't have built |
| [00:30:50] | jya: | that's damn stupid from them, they shouldn't even try loading external header of their own code. |
| [00:30:57] | jya: | surely it can't be that difficult for the |
| [00:31:12] | stuarta: | hah! |
| [00:31:14] | jya: | why would building Qt look for header from another Qt version |
| [00:31:29] | stuarta: | poor include rule building |
| [00:31:44] | jya: | on a mac, using the SDK |
| [00:32:12] | jya: | my core issue was finding on how to add to the linker flags so Qt would add its own path |
| [00:32:36] | jya: | it needed to add to LFLAGS -Fpath_to_qt |
| [00:32:45] | jya: | it only added -Lpath_to_qt |
| [00:32:52] | jya: | so it wouldn't link the framework |
| [00:33:10] | jya: | and the mythtv configure file has no way to pass extra linker flags |
| [00:33:18] | jya: | the --extra-ldflags does nothing |
| [00:34:23] | jya: | anyhow, having to build Qt ourself is ridiculous.. I totally agree with your earlier attempt at using the Qt SDK |
| [00:35:46] | stuarta: | yeah, its stupid to build it when upstream release an installable that'll be consistent for everyone |
| [00:36:11] | jya: | though you won't like the latest SDK |
| [00:36:20] | jya: | it's 64 bits only on a mac |
| [00:37:03] | jya: | I still need to manually compile the MySQL Qt plugin from the 4.8 Qt source |
| [00:37:33] | jya: | so I need to find an elegant way to determine the version of the Qt SDK installed, download the source code for it and compile the plugins |
| [00:39:43] | stuarta: | dvb-s eit need a whole bunch of fixup lovin |
| [00:40:15] | jya: | I'm fairly sure that the new mac build script has nothing to do with that :) |
| [00:40:27] | stuarta: | i'll let you off on that one |
| [00:41:10] | jya: | I'm sure it caused the shit weather in the UK too |
| [00:41:22] | stuarta: | nah that's natural |
| [00:41:25] | jya: | I'll take full responsability for that one too |
| [01:01:33] | wagnerrp: | knightr: do you know if nick has any desire to move that translation status into the buildbot system, similar to how doxygen and cppcheck are run? |
| [01:02:16] | stichnot: | jpabq, stuartm: Making CCBackground a percentage instead of a bool is a good idea. I thought a bit about how one might sneak it into 0.25 (with or without a DB update to deal with people who currently have CCBackground=1). But the biggest problem I see is that it would require changes to the globalsettings.cpp help text translations, which puts extra work on a lot of people. |
| [01:02:56] | stichnot: | if you haven't already found it, it's probably a 1-line change to hard-code it to alpha=128 |
| [01:03:52] | knightr: | wagnerrp, I don't think he would mind since he made the source code available, I could check with him if you want. I have to contact him about something anyway so it wouldn't be a problem for me to ask that question at the same time... |
| [01:04:51] | ** knightr thinks he would love not to have to run it manually... ** | |
| [01:05:01] | wagnerrp: | just a thought, something to put on the new server as we migrate over to it |
| [01:05:30] | knightr: | wagnerrp, like I said I can ask and I already have to contact him anyway so it's no trouble... |
| [01:05:55] | Beirdo: | heh, we can run more autobuild stuff from the buildbot and push to the server (similar to cppcheck and doxygen) |
| [01:07:21] | ** stuarta goes to bed ** | |
| [01:08:00] | knightr: | Good night stuarta, sorry for pinging you by mistake earlier today... |
| [01:09:40] | Beirdo: | !seen mousey |
| [01:09:41] | MythLogBot: | mousey was last seen 30 days 4 hours 2 minutes 12 seconds ago |
| [01:09:44] | Beirdo: | grr |
| [01:09:54] | Beirdo: | was hoping he'd be in this weekend |
| [01:18:39] | stichnot: | the plans for 0.26 regarding caption formatting are to push much/most/all of this into the theme. |
| [01:20:10] | donce (donce!~donce@d86-33-121-66.cust.tele2.at) has quit () | |
| [01:27:53] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [01:32:52] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [02:06:05] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [02:06:26] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [02:08:40] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [02:22:47] | superm1 (superm1!u4318@ubuntu/member/superm1) has quit (Ping timeout: 248 seconds) | |
| [02:22:56] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-nnrrncmoxwpvpjwz) has quit (Ping timeout: 252 seconds) | |
| [02:25:19] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [02:34:30] | Anduin_ (Anduin_!~awithers@pdpc/supporter/professional/anduin) has quit (Ping timeout: 244 seconds) | |
| [02:35:38] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [02:43:10] | tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 272 seconds) | |
| [02:43:29] | tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [02:48:44] | jpabq- (jpabq-!~jpabq@174-28-149-119.albq.qwest.net) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [02:48:44] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [02:49:40] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [02:50:00] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Client Quit) | |
| [02:50:31] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [02:50:43] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Client Quit) | |
| [02:51:11] | jpabq (jpabq!~jpabq@174-28-149-119.albq.qwest.net) has joined #mythtv | |
| [02:51:11] | jpabq (jpabq!~jpabq@174-28-149-119.albq.qwest.net) has quit (Changing host) | |
| [02:51:12] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [02:52:29] | jpabq- (jpabq-!~jpabq@174-28-149-119.albq.qwest.net) has joined #mythtv | |
| [02:59:44] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-yeyziqzlvluskpsq) has joined #mythtv | |
| [03:12:22] | superm1 (superm1!u4318@ubuntu/member/superm1) has joined #mythtv | |
| [04:29:50] | knightr: | wagnerrp, I contacted Nick and asked him about incorporating his status page into the buildbot system, I'll let you know what his answer is... I'm going to be afk now, I have to reinstall my backend OS and apps (OS got hosed...)... |
| [05:45:33] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Operation timed out) | |
| [05:46:25] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [06:10:07] | ** xris grumbles about translation strings stored in the db. ** | |
| [06:22:14] | jasonnz (jasonnz!~jason@122-57-229-88.jetstream.xtra.co.nz) has joined #mythtv | |
| [06:41:37] | Guest27529 is now known as ybot_ | |
| [06:47:04] | tranqu (tranqu!4c15556e@gateway/web/freenode/ip.76.21.85.110) has joined #mythtv | |
| [07:43:10] | Malard (Malard!Malard@xbmc/staff/malard) has quit (Ping timeout: 276 seconds) | |
| [07:47:33] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds) | |
| [07:47:46] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [07:57:23] | jasonnz (jasonnz!~jason@122-57-229-88.jetstream.xtra.co.nz) has quit () | |
| [08:22:28] | Beirdo: | heh |
| [08:38:23] | nutron|h (nutron|h!~nutron@unaffiliated/nutron) has quit (Quit: Whoosie Electroniums) | |
| [09:39:52] | xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [09:46:50] | Malard (Malard!Malard@xbmc/staff/malard) has joined #mythtv | |
| [10:20:37] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has joined #mythtv | |
| [10:21:12] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has left #mythtv () | |
| [10:42:17] | stuarta: | jya: let me know when you have fixed osx-packager.pl to use the installed framework |
| [10:42:35] | jya: | did it compile okay with the current one ? |
| [10:42:40] | stuarta: | my mac seems to run out of memory building Qt |
| [10:42:50] | stuarta: | see the buildbot logs |
| [10:42:59] | jya: | I'm having issue getting the mysql driver to be loaded :( |
| [10:43:53] | stuarta: | btw. i thought it was quite ironic to read your posts on the mailing list saying leave it to 0.25, after the discussion we had yesterday :) |
| [10:44:21] | stuarta: | but anyway, lets not go over that again |
| [10:44:40] | jya: | except I'm not touching in any ways myth source code… |
| [10:45:01] | stuarta: | just it's fundamental building block |
| [10:45:22] | stuarta: | but anyway, i'm going to leave that alone and lets move forward |
| [10:45:30] | jya: | fundamental? great… one that doesn't work with what's probably the most common OS |
| [10:45:46] | stuarta: | fundamental in that we use it for everything |
| [10:46:52] | ** stuarta goes back to deciphering log files ** | |
| [10:47:08] | jya: | how so? you use it to verify that it builds on mac… it does.. and I've given you options on what to do so you don't have to rebuilt Qt.. I'm sorry but here there's no one but yourself to blame for the consequence of *your* choices. |
| [10:47:25] | jya: | I'm starting to get really pissed of about this… |
| [10:47:56] | stuarta: | i'm happy to wait for you next incarnation which uses the installed framework, and i'm leaving it at that |
| [10:48:03] | jya: | you know |
| [10:48:21] | jya: | I'm going to revert the change… and you can deal with it from now on. Im done |
| [10:48:34] | stuarta: | i said i'd wait for what you are working on |
| [10:48:39] | stuarta: | i'm happy with it |
| [10:48:59] | jya: | I'm not working on anything.. Obviously I've wasted my time once again…. |
| [10:49:06] | stuarta: | no you haven't |
| [10:49:12] | jya: | so I'm going to revert the change… and that's it |
| [10:49:12] | stuarta: | i appreciate what you've done |
| [10:49:32] | jya: | rubbish.. as if you did.. You haven't stopped giving me grief about it… talk about ungrateful |
| [10:50:08] | stuarta: | i started by saying i would like to wait for what you do next |
| [10:50:20] | stuarta: | sorry for pointing out the irony |
| [10:51:32] | jya: | plus, as it seems it's okay to just rewrite history … there will be no trace of it, and everyone will be happy |
| [10:51:41] | stuarta: | i agree with you on that |
| [10:51:54] | stuarta: | er hang on |
| [10:52:03] | stuarta: | i agree with you not liking what nigel did |
| [10:52:38] | stuarta: | okay, i'll stop about it if you leave it as it is? deal? |
| [10:54:45] | jya: | tad to late for that… I've been pulling my hair on that stuff for days… only to get that type of reaction… thanks.. but I've got better things to do with my time. |
| [10:55:01] | stuarta: | i've no time |
| [10:56:05] | stuarta: | sorry i've pissed you off |
| [10:56:33] | jya: | bloody git, i don't even know how to revert a bunch of commits at once :( |
| [11:05:02] | Guest7109 (Guest7109!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [11:05:49] | mike (mike!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [11:06:15] | mike is now known as Guest10365 | |
| [11:08:42] | jya: | done… hopefully, I won't hear about that crap again, and now I can have time for something more interesting |
| [11:10:03] | stuarta: | i'll revisit it after 0.25 is out |
| [11:11:51] | jya: | Now I understand how markk or iamlindoro felt... |
| [11:12:46] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [11:15:05] | stuarta: | so long and thanks for all the fish. |
| [11:15:52] | CaCtus491: | :( |
| [11:21:19] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 252 seconds) | |
| [11:24:07] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:27:19] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-yeyziqzlvluskpsq) has quit (Remote host closed the connection) | |
| [11:31:24] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-blqrbsxmnqltrgmy) has joined #mythtv | |
| [11:36:08] | jya: | danielk22: your patch 10377–3 works perfectly for me…. tuning to another card is a bit slower than tuning to the same card for some reason.. but other than that it's fantastic.. thanks again for looking into it |
| [11:40:27] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [11:43:52] | stuartm: | it is a bit strange that tuning to another source takes so much longer than tuning to another mplex on the same card, yes you have to close one and open the other but that doesn't really explain the delay, especially when the other card should already be available/warmed up because we've been using it for active EIT |
| [11:46:30] | stuartm: | if we're serious about improving the livetv experience though, we'll get to that another day |
| [11:49:29] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:50:01] | jya: | stuartm: what is even more strange, is that actually all my cards are recording something one their own multiplex |
| [11:50:09] | jya: | so it goes from virtual card to another |
| [11:51:34] | jya: | it doesn't have to open a card as such, it's already opened. Having said that, the time difference is not that great.. I'm sure most wouldn't notice, or only put it into the "tuning in mythtv is slow" category |
| [11:52:25] | stuartm: | it might have improved lately, in the past I've found it to be seconds slower than tuning on the same card |
| [11:53:00] | jya: | With gigem last commits, and danielk22 now, LiveTV is really working like anyone could expect |
| [11:54:13] | jya: | yeah, maybe 2s more… the effect is also amplified by the fact that it takes a good 3–4s for my hdmi amp to get a lock … so between channel change, I don't hear a thing for a good 5–6s |
| [11:58:54] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [12:00:44] | ** stuarta sighs ** | |
| [12:54:42] | lolcat` (lolcat`!~xae8koo@zebra719.startdedicated.com) has joined #mythtv | |
| [12:54:44] | lolcat`: | Helo |
| [12:58:16] | stuartm: | CONFLICT (content): Merge conflict in mythtv/programs/mythfrontend/proglist.cpp << Honestly hard to be impressed by git when it can't even manage a merge that SVN had no trouble with :( |
| [13:01:18] | mag0o_ (mag0o_!20001@slackhost.lynchmv.com) has quit (Ping timeout: 245 seconds) | |
| [13:02:50] | mag0o (mag0o!20001@slackhost.lynchmv.com) has joined #mythtv | |
| [13:04:56] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [13:05:05] | ** peitolm wonders how hard it would be to insert a stream of silence into the audio, to keep the app happy whilst the channel switches, ** | |
| [13:05:19] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [13:35:26] | tranqu (tranqu!4c15556e@gateway/web/freenode/ip.76.21.85.110) has quit (Ping timeout: 245 seconds) | |
| [14:00:03] | j-rod|afk is now known as j-rod | |
| [14:09:33] | joki (joki!~joki@p54862A68.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [14:09:52] | joki- (joki-!~joki@p54865145.dip.t-dialin.net) has joined #mythtv | |
| [14:10:02] | joki- is now known as joki | |
| [14:20:16] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [14:20:28] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [15:32:42] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has left #mythtv () | |
| [15:40:11] | davide: | stuartm: i know what's happening in the failed recording case. it's a variation of the problem described in commit 9551bce2. it only showed up now because of the tuning timeout failure initiated by the scheduler that danielk22 added. failures initiated by the recorders would still work. anyway, i have a work-around, but need to test it for a day or two. |
| [16:03:38] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [16:07:24] | Beirdo: | There, fixed the OSX scripts around. Rather than go crazy, all that needed to be done to not lose the new work, but yet have the buildbot happy for now... rename the new script, and rename the old one back to the previous name |
| [16:07:55] | Beirdo: | That way we have both, and can work on real bugs until release, then can revisit it later |
| [16:08:39] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [16:11:29] | rsiebert_ (rsiebert_!~quassel@e179133034.adsl.alicedsl.de) has joined #mythtv | |
| [16:14:43] | rsiebert (rsiebert!~quassel@e179168178.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
| [16:31:06] | stuartm: | davide: if you need me to test the fix then I'd be happy to |
| [16:38:33] | davide: | stuartm: i'll mail it to you. |
| [16:41:13] | davide: | stuartm: the fix for #9536 to support faster expiry can wait. telling user to use the work-adounf of enabling justexpireinsteadofdelete and setting deletedmaxage to 1 should be sufficient should be sufficient for 0.25. i was one of those who was severly annoyed by orphaned preview images. |
| [16:44:13] | Sash (Sash!~Sash@server1.spsn.net) has left #mythtv () | |
| [16:48:47] | stuartm: | davide: lots of users (all?) are affected by that 'bug' and I'm not comfortable just relying on them to stumble across that ticket for a workaround when we can implement a temporary fix instead, e.g. the one danielk22 suggested where we kill the preview generator prior to performing the deletion |
| [16:50:03] | stuartm: | it's one of those really frustrating usability issues, even waiting for a second or two before deleting isn't sufficient for H.264 channels where it can take 20–60 seconds to produce a preview image |
| [16:53:24] | davide: | i don't want to see us go in circles. the inuse check was done specifically to avoid orphaned preview images because trying to kill the previewgenerator cleanly was deemed too difficult at the time. if danielk22 thinks he can do it now, then more power to him. if he can't, don't put a regression back in when there is a valid work-around. |
| [16:58:05] | stuartm: | as far as orphaned images, sphery has talked about having the housekeeper look for and delete them, if it's a question of avoiding orphans then that would be a smaller and less significant change to behaviour than dropping immediate deletes for 0.25 |
| [16:59:06] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [17:01:56] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [17:02:23] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [17:03:40] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [17:04:49] | stuartm: | I really do not want to leave this unfixed for 0.25 though, so either we remove the immediate deletes facility for 0.25 or we kill the preview generator or we ignore the preview generator and have the housekeeper clean up orphans |
| [17:07:21] | Goga777 (Goga777!~Goga777@2.95.186.229) has joined #mythtv | |
| [17:08:35] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [17:13:31] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Read error: Connection reset by peer) | |
| [17:14:57] | davide: | as long as it doen't create a regression, i'm ok. fwiw, though, after using expireinsteadofdelete mysel for a couple of weeks now, i think it's the most elegant solution so far. someone, perhaps sphery, suggested making it the default. |
| [17:20:49] | stuartm: | yeah, I don't have a problem with making it not only the default, but the only way we delete recordings, it would simplify the code and settings – having the option to delete even faster though, say within a few minutes would be necessary though, not everyone has their recordings stored on a dedicated partition |
| [17:21:09] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [17:23:26] | stuartm: | because historically I didn't have the space to move recordings off the disk to allow re-partitioning I have recordings sharing space with videos and music, having to manually purge each time I want to rip a DVD or import more music would be a regression |
| [17:24:34] | stuartm: | being able to un-delete something upto 10 minutes after it was deleted would be nice balance though, after that period the deletion probably wasn't accidental and I really did want it to go to make space |
| [17:28:54] | davide: | but there's a work-around for immediate deletes, too! just delete from the Deleted recgroup. :-J (that's supposed to be tounge in cheek) anyway, this was all discussed to death very recently, but perhaps you weren't there. now, that would be ironic. me involved in an irc discussion and you not. |
| [17:30:58] | xavierh: | stuartm: time to ask on the mailing list how to get a deleted recording back > 10mins :p |
| [17:31:00] | stuartm: | I don't follow every discussion even when I'm here, unless something about it in particular catches my attention I skip over things and put the time to better use :) |
| [17:48:05] | Goga777 (Goga777!~Goga777@2.95.186.229) has quit (Read error: Operation timed out) | |
| [17:57:41] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [18:01:19] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 276 seconds) | |
| [18:02:11] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [18:03:29] | davide (davide!~david@host70.16.intrusion.com) has quit (Quit: Konversation terminated!) | |
| [18:07:24] | cattelan_away is now known as cattelan | |
| [18:31:16] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [18:42:09] | Seeker`_ (Seeker`_!~cjo20@host109-152-102-163.range109-152.btcentralplus.com) has joined #mythtv | |
| [18:42:21] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Read error: Operation timed out) | |
| [18:47:43] | donce (donce!~donce@d86-33-121-66.cust.tele2.at) has joined #mythtv | |
| [18:48:03] | zombor_ is now known as zombor | |
| [18:48:28] | danielk22: | stuartm: davide_: gigem: Killing preview generator instances is not something I want to attempt right now. But I think leaving some stray images behind isn't the only thing deletion while the generator is running can do. If slow deletes are enabled it will truncate the recording the preview generator is using. |
| [18:52:13] | danielk22: | I'm wondering if we can drop slow deletes now.. No distro ships with ext3 as the default anymore.. |
| [18:52:39] | stuartm: | the problem doesn't affect ext4? |
| [18:53:39] | danielk22: | stuartm: AFAIK just ext2/ext3 |
| [18:53:57] | stuartm: | danielk22: much as I'd like to drop slow deletes, I'd be concerned about those users who have ext3 partitions and no way to backup and reformat them ? |
| [18:54:03] | danielk22: | Also ReiserFS, but I doubt anyone is still using that. |
| [18:56:09] | danielk22: | stuartm: you can upgrade an ext3 partition to ext4... |
| [18:56:15] | sphery: | stuartm / davide_ : Yeah, I'd like to make AutoExpireInsteadOfDelete not only the default, but the only way of deleting. After 0.26, it just means adding a new value for DeletedMaxAge (currently 0 means never, but we should change it so 0 means "immediately--as soon as not in use" and -1 means never). |
| [18:57:52] | stuartm: | sphery: IMHO 'immediate' should still leave some grace time, a chance to undo a mistaken deletion that doesn't mean keeping it around for a whole day either |
| [18:58:28] | sphery: | danielk22: also, I'm a huge fan of slow deletes--even though with current ext3, I can delete 10+GB files in <1s (but sometimes they take many seconds). Also, note that upgrading partitions to ext4 doesn't rewrite structures that are required to allow fast deletion. AIUI, you need a full reformat. |
| [18:59:00] | jams: | heh i was just typing that out |
| [18:59:30] | danielk22: | sphery: you actually just need to defrag.. but I just looked and e4defrag is still considered experimental :[ |
| [19:00:02] | danielk22: | (any copy of a file will convert it) |
| [19:00:12] | stuartm: | does it make sense to remove the slow deletes setting and just auto-enable it per storage group directory if the filesystem is found to be ext2 or ext3? I'm sure some people enable it without really needing it |
| [19:00:18] | sphery: | stuartm: that works for me, too... If you can come up with a "don't make the user decide" value (i.e., no more settings or, even, no more values for DeleteMaxAge), then whenever it deletes is fine with me |
| [19:00:39] | stichnot: | stuartm: I love that idea |
| [19:01:03] | sphery: | I say if we remove it, really remove it.\ |
| [19:01:07] | danielk22: | sphery: do you run ext3 just to to feel end user pain or another reason? |
| [19:01:53] | sphery: | danielk22: actually with current ext3, there is no pain--only people remembering pain |
| [19:02:00] | danielk22: | sphery: BTW not suggesting removing it pre-0.25, just putting it on the plate for 0.26.. obviously we'd need to have a howto for people on ext. |
| [19:02:23] | sphery: | I just run it because I prefer to let someone else find all the bugs in ext4 before I start to rely on it :) |
| [19:02:53] | jams: | plus by waiting till post .25 you will have real data from users about what FS they use |
| [19:02:57] | stuartm: | sphery: some argument against xfs? |
| [19:04:13] | sphery: | anyway, I completely agree we need to simplify deletes |
| [19:05:44] | stuartm: | anyway, we're getting away from the original topic without having made any firm decision what to do for 0.25 ... so do we remove immediate deletes for 0.25 and always delay? If so do we default to deleting after 5 or 10 minutes unless the user has configured a longer duration via DeleteMaxAge? |
| [19:06:24] | sphery: | In truth, even if you do remove slow deletes, I'm sure my system would be fine, even with ext3. Especially if we turned AutoExpireInsteadOfDelete into a proper delete queue (meaning you could delete something even when in use, and it's deleted in the background by the expirer). |
| [19:06:52] | stuartm: | it's technically a change in behaviour, but it would solve at least one bug to everyone's satisfaction |
| [19:07:08] | sphery: | and I'd /much/ rather we completely remove the functionality than remove just the setting |
| [19:07:45] | peitolm (peitolm!~moreyc@unaffiliated/peitolm) has quit (Quit: leaving) | |
| [19:08:29] | sphery: | (completely remove the slow deletes functionality, that is) |
| [19:08:46] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [19:12:15] | sphery: | FWIW, I /do/ think we should completely remove the AutoExpireInsteadOfDelete setting, always use it, and have a "now" (= ASAP or next expirer run (where they occur every 5–15min) or after 10min or ...) value for DeletedMaxAge. It would be nice to do so before 0.25, but I'll let you all determine if it counts as a "safe for feature freeze" bug fix. |
| [19:12:29] | peitolm (peitolm!~moreyc@unaffiliated/peitolm) has joined #mythtv | |
| [19:23:20] | stichnot: | stuartm: I'm in favor of your 0.25 suggestion: immediate deletes turn into slightly delayed deletes. I assume that deleting from the Deleted group would be truly immediate, with all of today's potential for "failure to delete" problems, and could be used by users who really need to recover space *now*. |
| [19:23:26] | donce: | hi guys,first thanks for mythtv, great job! I read about the LIVE555 problems on trac. Now i have seen that in qt 4.8 there is multicast support. (http://developer.qt.nokia.com/doc/qt-4.8/qudpsocket.html) what version is mythtv using? sorry for my bad english. thanks |
| [19:24:08] | donce: | http://code.mythtv.org/trac/ticket/9670 |
| [19:24:11] | donce: | for example |
| [19:24:28] | sphery: | danielk22: Also, according to http://www.gossamer-threads.com/lists/mythtv/users/506006#506006 , there's an issue with the new DB code (separate DB connection per thread code or ?) that's causing the 1216 charset conversion update to deadlock due to "waiting for schema metadata lock". I haven't tested it or tried to track it down, but I'm assuming it's similar to the other issues you fixed when we switched the DB code around. Do you think ... |
| [19:24:34] | sphery: | ... it's worth fixing or--when I do the initial schema rollup to the current schema version--should I just remove support for upgrading from versions prior to 1244 (i.e. users on versions before 0.22 would need to upgrade to 0.22 or 0.23 or 0.24, then upgrade again to 0.25+? (we currently have support for upgrading from 1027 to 1298 ( https://github.com/MythTV/mythtv/blob/master/ . . . eck.cpp#L548 ), which seems a bit much ... |
| [19:24:40] | sphery: | ... (0.21 was 1214 and 0.22 was 1244. |
| [19:25:48] | sphery: | donce: our current minimum Qt versions is 4.6, so we need to support 4.6+ |
| [19:26:39] | sphery: | donce: I /think/ the plan is to use ffmpeg/libav* code to provide RTSP support in the future, allowing us to remove Live555 support, but others would know better than I. |
| [19:27:01] | sphery: | (i.e. we don't want to create our own library if one we already use can be used instead) |
| [19:27:21] | donce: | i understand thank you |
| [19:28:20] | sphery: | if you can find a way to rework it to use ffmpeg, I'm sure it would be a very-well-received patch. If you need help/advice/information on future plans as you're doing so, please feel free to ask here on IRC or on the mailing lists |
| [19:28:43] | donce: | i allready startet googling ;) |
| [19:28:50] | sphery: | nice, thanks |
| [19:28:57] | donce: | thanks for your offer |
| [19:31:34] | stichnot: | Any idea why JobQueue::GetJobsInQueue() only reports the last 4 hours worth of (non-erroring) jobs? I have mine patched to report the last 2 days, since I find that part of the Backend Status page to be a good summary of recent backend activity. |
| [19:35:09] | wagnerrp: | stichnot: are successful jobs actually kept in the database that long? |
| [19:37:07] | stuartm: | danielk22: I guess we're really asking you whether you'd sign-off on this change to delete behaviour for 0.25? Since killing the preview generator or deleting from under the preview generator are both out of the question I can't think of another solution we can apply to fix the 'cannot delete recording' bug for 0.25 |
| [19:38:38] | stichnot: | wagnerrp: apparently... I have some that are almost 3 days old |
| [19:39:53] | sphery: | JobQueue::CleanupOldJobsInQueue() is supposed to delete any done, non-erroring jobs in the queue that are > 48hrs old, but since that's called, daily, by HouseKeeper::RunHouseKeeping(), you can have jobs up to almost 3 days old in there. |
| [19:40:40] | stuartm: | well, aside from not creating new previews when exiting the recording ... arguably that behaviour doesn't serve any useful purpose at all |
| [19:41:15] | stichnot: | wagnerrp: JobQueue::CleanupOldJobsInQueue says 2 days for non-errored, 4 days for errored. |
| [19:41:27] | wagnerrp: | stichnot: yeah, sphery just said that |
| [19:41:45] | sphery: | I'd guess the main reason we only show about 4hrs worth of jobs is to ensure a good signal/noise ratio for users. Note, also, that you /can/ just create your own Miscellaneous Status Script to add additional sections to your backend status page (including "Other completed jobs" or whatever) |
| [19:41:47] | stichnot: | oops, missed it |
| [19:42:26] | wagnerrp: | yeah, just the idea that if they successfully completed, who cares? |
| [19:42:41] | wagnerrp: | everything is working as it should, and it has already passed, so its not something to be concerned about |
| [19:43:03] | wagnerrp: | where as errors indicate something that needs to be resolved |
| [19:43:20] | sphery: | stichnot: I'm using http://www.mythtv.org/wiki/Myth_recent_recordings.pl to show all recordings from the last 24 hrs (could easily be 48, by changing --hours=24 to --hours=48 in the Misc Status Info Script Usage section), and I'm using http://www.mythtv.org/wiki/Myth_upcoming_recordings.pl to show all conflicts in the next 2 weeks |
| [19:44:05] | stichnot: | actually, I don't think failed recordings show up there |
| [19:44:21] | wagnerrp: | they currently dont, but failed jobs do |
| [19:44:23] | stichnot: | sphery: thanks, that may be just what I need |
| [19:44:48] | wagnerrp: | for up to 4–5 days, depending on how they fall with relation to run of the daily housekeeper |
| [19:44:52] | sphery: | granted, I want to eventually get the Misc Status Info stuff cleaned up and working better (better integrated with services API stuff), but it's not a bad way to do it for now. |
| [19:45:09] | stichnot: | I like having the mythweb status page as a brief summary of past and future. |
| [19:45:54] | wagnerrp: | IMHO, the status page should really only show details of things that could invoke action by the user |
| [19:46:59] | wagnerrp: | i.e. a user might have to clear out some space if there is little storage available, or fiddle with the recording rules based off upcoming recordings, or fix a failed job |
| [19:47:12] | sphery: | stichnot: yeah, I did the Misc Status Info stuff primarily so we could remove libsensors from the backend status page (it wasn't thread safe and was killing the backend), but when trying to come up with scripts to help "sell" the approach (rather than just the sensors script), someone (jams, I think) mentioned showing additional recent or upcoming recordings, so I wrote the scripts, and they've turned out to be /very/ useful--as you said, for ... |
| [19:47:18] | sphery: | ... showing a summary of what it's done recently |
| [19:47:38] | wagnerrp: | id rather see a "previous job log" as something stuffed in another page |
| [19:48:14] | wagnerrp: | potentially documenting weeks worth or more, not just the 2 days kept in the database |
| [19:48:57] | sphery: | wagnerrp: I agree... default page should be only "what's happening now or what do you need to know to keep it running well" info... additional stuff can go elsewhere (or be added to status page with scripts or whatever) |
| [19:51:32] | danielk22: | sphery: The DB upgrade problem is probably as you suspect, but I think we should just force people to upgrade to 0.23 or 0.24 before upgrading to 0.25.. Updating from 0.22 or earlier is a big jump... |
| [19:52:07] | wagnerrp: | danielk22: i dont see why there should be any difference |
| [19:52:42] | wagnerrp: | since the way the schema update is managed, people are effectively upgraded through 0.23 and 0.24, and all the other schema versions in between, before reaching 0.25 |
| [19:53:44] | sphery: | danielk22: yeah... I'll test it with my 0.21-fixes backup, today, just to see if it fails for me, too. If we do require a 0.22+ schema for upgrade, do you want me to just change the 1017 to 1244 (0.22 schema version) in the "unrecognized schema version" check or actually remove all the upgrade code for 1017 – 1244? |
| [19:54:10] | wagnerrp: | nevermind, you're discussing skipping over sections of schema update |
| [19:54:18] | danielk22: | stuartm: I'll go along with the deletion change prior to 0.25, but I don't think we should rip out the immediate delete code prior to 0.25 as ripping out code itself can introduce bugs. |
| [19:56:09] | danielk22: | sphery: Remove the old upgrade code.. As long as new database creation works and schema 0.23+ get upgraded to 0.25 we're good. |
| [19:57:45] | danielk22: | wagnerrp: the 0.21->0.23 schema upgrade code will work with 0.23, but that same code doesn't work in 0.25 because how it uses DB connections is no longer supported. |
| [19:58:11] | sphery: | yeah, I'm going to do a rollup so that initial db is created at current version (1298--I did a "practice" rollup during development to 1280, and all went well), so creation won't be a problem. Removing all those strings will also make compiling dbcheck.cpp /much/ simpler and less memory intensive. :) |
| [19:58:23] | stuartm: | danielk22: ok, so hardcode the auto-expire setting on? |
| [19:58:30] | wagnerrp: | danielk22: ah, thanks for the clarification |
| [19:58:43] | danielk22: | stuartm: yeah, that's my thinking. wagnerrp: np |
| [20:00:33] | danielk22: | stuartm: Consider that the neutral observer view, I don't know the code in question very well. I'm just following the arguments. |
| [20:01:40] | stuartm: | sphery, danielk22: we should definitely have a cut-off for the schema upgrades, say no more than two major version in one upgrade, so the minimum version to upgrade to 0.26 would be 0.24 – if we do that we should widely advertise that fact, so everyone will know that they can't go from 0.24 to 0.27, they have to go through 0.25 or 0.26 first |
| [20:02:42] | sphery: | Yeah, sounds like ripping out the extra paths for deletion will be a good post-0.25 project, which is likely to simplify deletion considerably. (And, if we also rip out the trucating-deletes (slow delete) code, it will get /much/ simpler, too.) |
| [20:04:43] | stuartm: | danielk22: we've got agreement from everyone participating in the discussion here today, that represents a majority of the active developers and multiple 'senior' devs too, so I'm happy to go ahead |
| [20:05:31] | sphery: | stuartm: yeah, that seems quite sensible... I know that users who try to do more than that tend to encounter problems along the way, anyway, just because the old code paths don't get tested very often at all (especially with new Qt's and new MySQLs and new MythTV code). For now, I'll allow 0.22+ (DB schema versions 1244 -> 1298). We can reduce that down, even farther, with 0.26, if desired (requiring 0.24+ schema for upgrade to 0.26). |
| [20:15:08] | danielk22: | gigem: I tried turning on caching in browse mode for IsTunable and it didn't have much of an effect. This led me to add some timing and it turns out it is the remote DB access taking most of the time. |
| [20:15:08] | wagnerrp: | what exactly has changed with the database code that prevents the previous schema updates from working? |
| [20:16:25] | danielk22: | gigem: davide_: The two ChannelUtil:: and the one CardUtil:: function calls in TV::IsTunable() sometimes eat up 10 ms and other times 50 ms each. |
| [20:16:34] | sphery: | wagnerrp: see my 14:24:28 (EST) comment |
| [20:39:38] | stuartm: | danielk22: should we not be caching the pertitent bits of the channel and capturecard tables? Sourceid isn't going to change and neither is cardid |
| [20:41:02] | stuartm: | those are the sorts of things I'd expect us to be querying from Card and Channel structs/objects which are loaded once with just two queries on livetv startup |
| [20:41:55] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:42:24] | danielk22: | stuartm: I was surprised that those are taking so long. |
| [20:45:36] | stuartm: | even if they took 1ms each, we know from experience that a single big query loading all the data at once is faster than lots of little queries pulling in bits and pieces, the cost is a small memory hit and in this case it really would be tiny compared to something like the programinfo cache |
| [21:10:05] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [21:10:48] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [21:11:58] | davide_: | danielk22, stuartm: yeah, we need to get as much info in frewer queries and cache it. it looks like the browse code does lots of little queries. |
| [21:12:50] | Seeker`_ is now known as Seeker` | |
| [21:12:58] | Seeker` (Seeker`!~cjo20@host109-152-102-163.range109-152.btcentralplus.com) has quit (Changing host) | |
| [21:12:59] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [21:15:56] | davide_: | sphery: fyi, if you start working on the delete code, i've got a pending patch i'm still testing that touches MainServer::DoHandleDeleteRecording(), so there might be some minor conflicts to deal with. |
| [21:17:59] | stuartm: | a while back I decided that I'd try and refactor all the channel structs and classes into one single class, I'm happy to look at that post 0.25 with the aim of fixing this at the same time, but if someone has the time/inclination then an interim fix done for 0.25 would obviously be good |
| [21:20:10] | stuartm: | davide_: if we do as suggested by danielk22 and just hard code the setting so that the existing delete code remains largely intact then that should minimise conflicts, the only functional change would be the addition of the quick delete behaviour and I'm guessing that won't amount to much at all but I've yet to look at the code |
| [21:32:25] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [21:38:09] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [21:42:27] | stichnot: | If my frontend, whose IP address is 192.168.0.207, has BackendServerIP set to 127.0.0.1, then doing "nc 192.168.0.207 6546" from another machine gives Connection refused. But if BackendServerIP is set to 192.168.0.207, it works. Is this a bug or a feature? |
| [21:43:28] | stuarta: | standard networking behaviour |
| [21:43:50] | stuarta: | if the backend is on 127.0.0.1 then it only accepts connections from itself |
| [21:44:07] | stuarta: | if you want to be able to connect from the network, then you need to use a non localhost address |
| [21:45:24] | stichnot: | so "backend" here does not refer to the machine running mythbackend? |
| [21:46:16] | stuarta: | hmmm, there's definitely something not right with what you've just described |
| [21:47:33] | joki (joki!~joki@p54865145.dip.t-dialin.net) has quit (Ping timeout: 248 seconds) | |
| [21:47:36] | stuarta: | the part about the frontend using the backend ip |
| [21:47:56] | stichnot: | yeah, I tried switching back and forth several times, and it was consistent |
| [21:48:21] | stichnot: | I can nc from the same machine, but not from another machine, when the setting is 127.0.0.1 |
| [21:48:50] | stichnot: | I assume this is from some refactoring of listener code? |
| [21:49:07] | davide_: | stuartm: i don't expect there to be major conflicts. but both types of deletes go through the same function and my patch slightly touches both path, so there probably will be some. i just wanted to give sphery the heads up. |
| [21:51:10] | joki (joki!~joki@p548625D7.dip.t-dialin.net) has joined #mythtv | |
| [21:53:13] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Remote host closed the connection) | |
| [21:53:22] | sphery: | stichnot: wagnerrp was making some changes and knows the current implementation best |
| [21:53:34] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [21:54:05] | sphery: | davide_: yeah, I probably won't even look at simplifying delete code until after 0.25 is released |
| [21:54:19] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out) | |
| [21:54:37] | sphery: | but if I do, I can handle any merging required (I'm used to it since I generally work on any new feature over a period of months before pushing :) |
| [21:55:46] | wagnerrp: | stichnot: yes, that is intended behavior |
| [21:56:05] | stuartm: | sphery: you're going to handle the pre-0.25 change to delete behaviour? |
| [21:56:12] | wagnerrp: | if BackendServerIP is set, it listens to that and 127.0.0.1 only |
| [21:56:27] | wagnerrp: | if BackendServerIP is not set, it listens on any "private" address |
| [21:56:38] | stuartm: | I'm losing track of who is committing to making that change |
| [21:56:46] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [21:57:00] | wagnerrp: | that means the 10/8, 172.16/12 , and 192.168/16 ranges |
| [21:57:13] | stichnot: | I see. |
| [21:57:21] | wagnerrp: | stichnot: similarly, if BackendServerIP6 is set, it only listens on that address and ::1 |
| [21:59:34] | sphery: | stuartm: I thought you or davide_ were. I can if you guys like, but we should definitely decide who is. :) (I might look into simplifying delete code paths after 0.25 if no one else beats me to it.) |
| [22:00:40] | sphery: | wagnerrp: note that he's talking port 6546, which is the frontend network remote control port... (In case that part wasn't clear from above.) |
| [22:00:43] | stuartm: | sphery: I thought I might be, but davide_'s comment to you before confused me |
| [22:01:01] | wagnerrp: | sphery: still the case |
| [22:01:38] | stuartm: | wagnerrp: the frontend only listens on an external IP if it's configured to connect to the backend on an external IP? |
| [22:02:04] | wagnerrp: | all listen servers i could find in mythbackend, mythfrontend, and mythlcdserver currently follow those rules |
| [22:02:06] | stichnot: | wagnerrp: I must have just buggered that setting up by myself. |
| [22:02:14] | stuartm: | i.e. if the frontend is set to connect to the backend on localhost, you can't connect to the frontend remotely? |
| [22:02:21] | sphery: | stuartm: I definitely don't mind if you do it, but would be happy to work on it if you have other, more-important things on your TODO list for 0.25 and need someone else to look at it. |
| [22:02:26] | wagnerrp: | stuartm: no, if BackendServerIP is not set, it will fall back to listening on all private IPv4 addresses |
| [22:02:43] | stichnot: | I think the only place to explicitly set that is mythtv-setup, and it clearly states "Enter the IP address of this machine." |
| [22:03:10] | wagnerrp: | correct, those values will be unset on that host until the user goes through mythtv-setup |
| [22:03:12] | stichnot: | though the page is entitled "Host Address Backend Setup" |
| [22:03:23] | stuartm: | wagnerrp: I'm still confused why the addresses the frontend listens on is related to the address it connects to the backend with |
| [22:03:24] | wagnerrp: | which only needs to be done if setting up a backend or jobqueue |
| [22:03:42] | stuartm: | anyway ... |
| [22:03:53] | wagnerrp: | stuartm: it was either that, or add two more additional variables to restrict what the frontend listened to |
| [22:04:27] | stichnot: | That mythtv-setup page has two sections, one for the current host and one for the master backend |
| [22:04:42] | stichnot: | so you have to be pretty dense (like me?) to get into trouble |
| [22:04:55] | stuartm: | sphery: I have other things to work on, but I really can't say whether they are more important or that I won't have the time, the only thing that I can honestly say is that I'm lazy enough to let someone else do it if they are offering ;) |
| [22:05:50] | wagnerrp: | stuartm: a bit of an odd quirk i came across when converting all this stuff, mythtv-setup also listens for mythmessage signals through mythudplistener |
| [22:06:24] | wagnerrp: | although since thats likely going away in 0.26, i figured it wasnt important enough to bother doing anything about |
| [22:06:52] | stuartm: | wagnerrp: if the behaviour confuses me, then I can only imagine that it's going to confuse a few users too, does the help text for those settings explain that frontend won't bind to the external IP if it's set to connect to the backend on 127.0.0.1? |
| [22:07:28] | wagnerrp: | currently, i dont think it does |
| [22:07:54] | wagnerrp: | although i would expect that to be more confusing to existing users than new ones |
| [22:08:21] | wagnerrp: | it would not be all that difficult to allow those fields to accept a semicolon-separated list if so desired |
| [22:08:22] | stichnot: | there's not enough space in the help text area for all that |
| [22:08:40] | sphery: | stuartm: hehe, that's pretty much where I'm at. Only things I can say are more important are a couple of db schema upgrade things (including the "frontend segfaults if it's not allowed to upgrade schema" thing you mentioned). So, at this point, I'll let you know if I get a chance to work on it before you. |
| [22:09:48] | davide_: | stuartm: i thouhg sphery agreed to do it, but then, i'm old and forgetful. i can even prove it now. i got my first invitation to join aarp this past weekend! |
| [22:09:56] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [22:10:24] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [22:10:41] | stichnot: | Enter the IP address of this machine. Use an externally accessible address (ie, not 127.0.0.1) if you are going to be running a frontend on a different machine than this one. Note, in IPv6 setups, this is still required for certain extras such as UPnP. |
| [22:10:46] | stuartm: | sorry, irc client segfaulted |
| [22:10:56] | stuartm: | it's been doing that too often |
| [22:12:17] | davide_: | s/thouhg/thought/ a couple messages ago. |
| [22:15:32] | stuartm: | davide_: I had to google aarp ;) |
| [22:16:59] | stuartm: | There's no equivalent organisations in the UK, I suppose a mix of Saga and Age Concern – although Saga is mostly commercial in nature and 'members' must be over 60, and Age Concern is a charity with no membership as such, it merely advocates for those above 60 and provides assistance/advice to those who want it |
| [22:17:28] | stichnot: | so maybe the BackendServerIP help text could be changed to something like this? ... (ie, not 127.0.0.1) if this machine will provide MythTV network-based services to other machines. ... |
| [22:18:01] | davide_: | stuartm: i figured you would [have to google] :) |
| [22:22:01] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [22:28:33] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [22:30:01] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Remote host closed the connection) | |
| [22:30:30] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [22:31:50] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [22:31:50] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [22:31:50] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [22:33:24] | ** skd5aner hugs danielk22 ** | |
| [22:33:41] | Beirdo: | whoah. get a room ;) |
| [22:33:44] | Beirdo: | just kidding |
| [22:34:16] | skd5aner: | danielk22: thanks for the live tv mux fix... seriously, that single bug has been the #1 irritant for me for 4 years – very grateful a fix is finally going in |
| [22:38:17] | Beirdo: | I'm sure it will be making a lot of people happy |
| [22:38:29] | Beirdo: | one major scratch finally itched and all :) |
| [22:38:54] | Beirdo: | err, major itch finally scratched. must be Monday |
| [22:41:55] | stuarta: | heh, i'm having a fixit day, and so far things are good |
| [22:42:26] | danielk22: | I just wish I had caught it earlier. jya provided the key info, the 3rd or 4th time I asked for more detail. |
| [22:44:59] | skd5aner: | well – if I had only known what to provide – but that's neither here nor there |
| [22:45:28] | Beirdo: | danielk22: if only you could collect all the beers owed to ya for that fix :) |
| [22:45:49] | skd5aner: | ... he'd end up in the hospital? |
| [22:46:13] | Beirdo: | heh. Yeah, likely. Poor liver! |
| [22:53:58] | j-rod is now known as j-rod|afk | |
| [22:59:57] | danielk22: | Heh, I just wish I had more time to brew my own. My wife was drinking a beer a couple weeks ago and remarked that it wasn't quite as smooth or quite as strong as the stuff we'd brewed but it was pretty good. She was drinking a Westmalle triple. |
| [23:07:22] | stuarta: | haha |
| [23:27:35] | MythBuild: | build #417 of master-osx-snow-leopard is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/417 |
| [23:27:46] | Beirdo: | YAY |
| [23:27:47] | stuarta: | \o/ it's fixed |
| [23:28:19] | Beirdo: | danielk22: you should come out here and try some of the stuff xris has concocted :) |
| [23:28:33] | Beirdo: | good stuff, I tell ya |
| [23:28:38] | stuarta: | i've poked the 0.24 build to check it still lives |
| [23:28:46] | Beirdo: | yay! |
| [23:29:12] | xris: | well.. the stuff my cousin makes is better. |
| [23:29:14] | Beirdo: | we'll try upgrading to the new scripts et al after the release? Seems like a plan anyways |
| [23:29:25] | xris: | only homebrew beer I have left is all sour (2/3 intentionally) |
| [23:29:34] | Beirdo: | yes, that is true, but even yours is good stuff ;) |
| [23:29:47] | stuarta: | yeah, that's the plan, ideally make it use an installed framework |
| [23:30:15] | Beirdo: | I'm reading up on how to write git hooks :) |
| [23:31:00] | Beirdo: | as we will be needing to retrofit our email hook to go directly off the repo rather than the JSON feed from github that so often skips |
| [23:31:17] | Beirdo: | why did my fingers start typing "giggety-hub"? |
| [23:31:18] | Beirdo: | hehe |
| [23:31:31] | Beirdo: | been watching too much Family Guy, I think |
| [23:31:37] | stuarta: | give that man another beer |
| [23:42:03] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:44:07] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Remote host closed the connection) | |
| [23:45:32] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.