| Wednesday, August 10th, 2011, 00:30 UTC | ||
| [00:30:37] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has joined #mythtv | |
| [00:35:50] | jpabq_ (jpabq_!~jpabq@174-28-172-82.albq.qwest.net) has joined #mythtv | |
| [00:35:50] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [00:35:50] | jpabq_ (jpabq_!~jpabq@174-28-172-82.albq.qwest.net) has quit (Changing host) | |
| [01:04:52] | davide (davide!~david@host103.16.intrusion.com) has quit (Remote host closed the connection) | |
| [01:08:43] | davide (davide!~david@host103.16.intrusion.com) has joined #mythtv | |
| [01:15:23] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has left #mythtv () | |
| [01:50:56] | davide (davide!~david@host103.16.intrusion.com) has quit (Read error: Connection reset by peer) | |
| [01:51:18] | davide (davide!~david@host103.16.intrusion.com) has joined #mythtv | |
| [02:36:32] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [03:00:28] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has joined #mythtv | |
| [03:06:21] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:12:46] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [04:18:54] | jpabq- (jpabq-!~jpabq@174-28-172-82.albq.qwest.net) has quit (Read error: No route to host) | |
| [04:19:11] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Read error: No route to host) | |
| [04:20:20] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [04:21:31] | jpabq- (jpabq-!~jpabq@174-28-172-82.albq.qwest.net) has joined #mythtv | |
| [04:42:48] | MitchCapper (MitchCapper!~UNIX@unaffiliated/mitchcapper) has joined #mythtv | |
| [05:11:14] | cattelan is now known as cattelan_away | |
| [05:22:50] | Beirdo: | danielk22: if you're in... wondering if the db upgrades are borked. A user just reported this: http://pastebin.com/wbhHx8u1 |
| [05:24:23] | superm1 (superm1!~superm1@ubuntu/member/superm1) has quit (Ping timeout: 258 seconds) | |
| [05:24:28] | superm1 (superm1!~superm1@204.8.45.13) has joined #mythtv | |
| [05:24:28] | superm1 (superm1!~superm1@204.8.45.13) has quit (Changing host) | |
| [05:24:28] | superm1 (superm1!~superm1@ubuntu/member/superm1) has joined #mythtv | |
| [05:40:17] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [05:43:51] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Read error: Connection reset by peer) | |
| [06:04:49] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [06:24:50] | Beirdo: | danielk22: it's now #9975 |
| [06:56:04] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [06:59:29] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [07:26:18] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [09:47:11] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [09:47:31] | stuartm (stuartm!~stuartm@cpc3-derb9-0-0-cust911.8-3.cable.virginmedia.com) has joined #mythtv | |
| [09:47:31] | stuartm (stuartm!~stuartm@cpc3-derb9-0-0-cust911.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [09:47:31] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [09:52:51] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 276 seconds) | |
| [09:53:24] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [09:56:24] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has joined #mythtv | |
| [10:05:01] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:55] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:27:37] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) has quit (Ping timeout: 255 seconds) | |
| [10:31:15] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [10:35:52] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) has joined #mythtv | |
| [11:32:32] | zCougar (zCougar!~cougar@2001:67c:32c:600:250:56ff:fe81:5f) has quit (Quit: zCougar) | |
| [11:38:24] | chainsawbike (chainsawbike!~chainsawb@chainsawbike-1-pt.tunnel.tserv25.sin1.ipv6.he.net) has quit (Quit: yep... i broke it good that time...) | |
| [11:38:45] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has quit (Remote host closed the connection) | |
| [11:38:49] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has joined #mythtv | |
| [11:39:41] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has quit (Remote host closed the connection) | |
| [11:40:10] | chainsawbike (chainsawbike!~chainsawb@chainsawbike-1-pt.tunnel.tserv25.sin1.ipv6.he.net) has joined #mythtv | |
| [11:41:48] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has joined #mythtv | |
| [11:42:47] | danielk-phone (danielk-phone!~androirc@96.57.9.142) has quit (Remote host closed the connection) | |
| [12:04:54] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [12:04:55] | davide (davide!~david@host103.16.intrusion.com) has quit (Remote host closed the connection) | |
| [12:05:23] | davide (davide!~david@host103.16.intrusion.com) has joined #mythtv | |
| [12:09:23] | zCougar (zCougar!~cougar@2001:67c:32c:600:250:56ff:fe81:5f) has joined #mythtv | |
| [12:27:54] | Goga777 (Goga777!~Goga777@shpd-92-101-136-185.vologda.ru) has joined #mythtv | |
| [12:41:08] | Goga777 (Goga777!~Goga777@shpd-92-101-136-185.vologda.ru) has quit (Remote host closed the connection) | |
| [12:48:14] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [12:54:07] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [13:11:55] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has joined #mythtv | |
| [13:21:32] | stoffel (stoffel!~quassel@p57B4A9BF.dip.t-dialin.net) has joined #mythtv | |
| [13:37:12] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:44:43] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [13:48:46] | jpabq- (jpabq-!~jpabq@174-28-172-82.albq.qwest.net) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [13:49:12] | jpabq- (jpabq-!~jpabq@174-28-172-82.albq.qwest.net) has joined #mythtv | |
| [14:03:28] | stoffel (stoffel!~quassel@p57B4A9BF.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [14:06:20] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Quit: brfransen) | |
| [14:23:15] | danielk22: | Beirdo: http://pastebin.com/LGmQsBwq <-- these are the errors ??? |
| [14:23:41] | j-rod|afk is now known as j-rod | |
| [14:23:59] | danielk22: | those queries succeed a dozen times before they fail there.. |
| [14:28:08] | NightMonkey (NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [14:30:48] | Beirdo: | seems odd, doesn't it? |
| [14:38:03] | stuarta: | why aren't the bindings working... |
| [14:38:07] | danielk22: | CREATE TABLE IF NOT EXISTS schemalock ( schemalock int(1)); LOCK TABLE schemalock WRITE; <-- executed before the query fails... the second settings query succeeds when run before taking this lock.. |
| [14:38:44] | danielk22: | (the first query always fails since the schemevar is not a per host thing) |
| [14:39:07] | danielk22: | stuarta: I even tried reissuing the prepare and rebinding.. |
| [14:39:16] | stuarta: | a null result is different to failing tho |
| [14:39:29] | danielk22: | right.. |
| [14:39:31] | Beirdo: | is this somehow due to the "don't use NULL on strings" change, I wonder? |
| [14:39:51] | danielk22: | Beirdo: nope checked that. |
| [14:39:58] | stuarta: | the first query should succeed, but return 0 rows |
| [14:39:59] | Beirdo: | K. :) |
| [14:40:06] | danielk22: | it's as if the bindings just don't take |
| [14:40:22] | Beirdo: | yeah. |
| [14:40:26] | stuarta: | well the binding in the first query don't match the bindings in the sql |
| [14:40:37] | stuarta: | er. |
| [14:40:42] | ** stuarta retracts that ** | |
| [14:42:33] | Beirdo: | hmm, how do we re-bind after a disconnection? |
| [14:43:08] | Beirdo: | sorry, I just woke up, and should really be in bed another hour or so :) |
| [14:43:12] | danielk22: | If I comment out the contents of DBUtil::lockSchema() and DBUtil::unlockSchema() the queries succeed. |
| [14:43:21] | Beirdo: | wow. |
| [14:44:52] | Beirdo: | It's not suddenly getting bitchy about the ; at the end of the query, is it? |
| [14:44:52] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [14:45:13] | Beirdo: | most queries we send don't have em |
| [14:45:26] | danielk22: | Beirdo: nope.. I tried adding the ";" |
| [14:45:39] | Beirdo: | also, those are not prepared statements, that may be the difference |
| [14:49:40] | Beirdo: | although the code for MSqlQuery::exec(QString) seems simple enough |
| [14:53:26] | Beirdo: | hmmm |
| [14:54:12] | Captain_Murdoch: | the original pastebin is gone, but I thought that the errors in the user's log were during the 'CompareAndWait() phase, not after we lock the schema. |
| [14:54:36] | Beirdo: | it's on a ticket though :) |
| [14:55:41] | Beirdo: | #9975 to be exact |
| [14:55:45] | danielk22: | Captain_Murdoch: CompareAndWait() locks the schema and then calls Compare() where we try to pull the DBSchemaVer and it fails. then it unlocks the schema and repeats |
| [14:56:46] | danielk22: | Hmm if I lock the settings table instead of the schemalock table the check succeeds... |
| [14:57:23] | danielk22: | Since we now share a DB connection per thread does this mean that when we lock a table that is the only table we can perform queries on in that thread? |
| [14:57:59] | Beirdo: | I would hope not |
| [15:00:50] | Beirdo: | seems we lock that table in UpgradeTVDatabaseSchema too |
| [15:01:57] | Kunalagon (Kunalagon!~Kunalagon@212.200.240.146) has joined #mythtv | |
| [15:05:59] | Captain_Murdoch: | Beirdo, a long time ago, we used to have race conditions on DB upgrades. I implemented the schemalock table lock as a mutex on the DB server side. the reason it is a separate table is because when we had multiple connections doing the DB upgrade potentially, we couldn't lock the settings table or any other normally used table(s). |
| [15:06:16] | Beirdo: | yeah, makes sense |
| [15:06:28] | Beirdo: | and you can't read other settings while upgrading either |
| [15:06:39] | Captain_Murdoch: | danielk22, yeah, that's a mysql-ism it appers. try "lock table schemalock write;" in a mysql session then try "select count() from settings;" and you'll get an error. "ERROR 1100 (HY000): Table 'settings' was not locked with LOCK TABLES" |
| [15:07:43] | danielk22: | So one solution is to give the schemalock stuff it's own connection to the database.. are there better options? |
| [15:09:01] | jpabq_ (jpabq_!~jpabq@174-28-172-82.albq.qwest.net) has joined #mythtv | |
| [15:09:01] | jpabq_ (jpabq_!~jpabq@174-28-172-82.albq.qwest.net) has quit (Changing host) | |
| [15:09:01] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [15:09:11] | stuarta: | Captain_Murdoch: you have to tell it what type of lock you want, so the select will fail because you've locked it for write, not read |
| [15:09:14] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Client Quit) | |
| [15:09:27] | Beirdo: | hmm, I guess you could lock settings, create a temporary LOCKED setting, then unlock.. probably would end up with race conditions though |
| [15:09:29] | Captain_Murdoch: | stuarta, we didn't lock settings, just schemalock; |
| [15:09:41] | stuarta: | heh |
| [15:10:00] | danielk22: | stuarta: & read locks aren't exclusive so that wouldn't work.. |
| [15:10:38] | stuarta: | the write lock is correct for what we want to do |
| [15:10:42] | Beirdo: | I guess giving it back it's own connection would be the simplest |
| [15:11:04] | stuarta: | or more to the point, why is it not getting the same conection? |
| [15:11:30] | danielk22: | stuarta: it is getting the same connection.. that's the problem :) |
| [15:11:40] | stuarta: | i think i'll shutup now... |
| [15:12:52] | Captain_Murdoch: | found a quote somewhere... "ERROR 1100 (HY000): Table 'settings' was not locked with LOCK TABLES" |
| [15:13:07] | Captain_Murdoch: | doh, stupid cut and paste between sessions. |
| [15:13:09] | Captain_Murdoch: | :) |
| [15:13:44] | Captain_Murdoch: | "when you use lock tables, you must lock all tables that you are going to use in your queries. while the locks obtained with a lock tables statement are in effect, you cannot access any tables that were not locked by the statement." |
| [15:13:53] | stuarta: | yup |
| [15:14:03] | Beirdo: | I was just about to paste that |
| [15:14:03] | stuarta: | so you either be specific, or let mysql do the work |
| [15:14:13] | Beirdo: | or rather |
| [15:14:15] | Beirdo: | A session that requires locks must acquire all the locks that it needs in a single LOCK TABLES statement. While the locks thus obtained are held, the session can access only the locked tables. |
| [15:14:20] | Beirdo: | from the mysql docs |
| [15:14:25] | Beirdo: | same gist thoguh |
| [15:14:28] | stuarta: | that's what i was about to say |
| [15:14:44] | danielk22: | it looks like a deadlock prevention mechanism.. |
| [15:14:50] | stuarta: | either lock *everything* you are going to play with, or nothing |
| [15:15:10] | Captain_Murdoch: | danielk22, makes sense. |
| [15:16:16] | Beirdo: | so looks like you need a specific extra session for locking |
| [15:16:21] | danielk22: | k, I'll just give it it's own connection to the DB. Compiling... :) |
| [15:16:41] | stuarta: | locks are connection specific |
| [15:17:04] | ** Captain_Murdoch can't think of any other better way. we still need to lock because you can still upgrade the schema in more than one place. ** | |
| [15:17:05] | stuarta: | you have to stick to one way of locking in a single connection |
| [15:17:49] | stuarta: | the bit i've no idea about is the relationship between connections and sessions |
| [15:17:54] | stuarta: | in our code |
| [15:18:07] | Beirdo: | I think they are synonymous |
| [15:18:24] | stuarta: | then an "extra session" would serve no purpose |
| [15:18:32] | Beirdo: | unless it gets reconnected, a connection in our code is a session in mysql |
| [15:19:03] | stuarta: | if it gets reconnected all previous locks would have been cleared |
| [15:19:11] | Beirdo: | sure it does. Use connection A to lock a shared table. if that succeeds, use connection B to access another table |
| [15:19:31] | stuarta: | another table is fine |
| [15:19:41] | stuarta: | B wouldn't be able to access A's locked tables |
| [15:19:49] | Beirdo: | correct |
| [15:19:58] | danielk22: | stuarta: With my recent changes we try to share one DB connection for all the QSqlQueries in the same thread.. before each query got it's own connection to the DB. |
| [15:20:08] | Beirdo: | so A would have to drop the table as well, when unlocking |
| [15:20:09] | stuarta: | k |
| [15:20:28] | Beirdo: | if it's gonna get dropped, of course |
| [15:20:57] | danielk22: | stuarta: This can be disabled by changing REUSE_CONNECTION 1 to 0, but that's not my preference... |
| [15:21:07] | Beirdo: | which I guess we don't need to, we are just using the table lock as a code semaphore, basically |
| [15:21:07] | Captain_Murdoch: | looks like we might be able to use GET_LOCK(str, timeout) and RELEASE_LOCK(str) if we wanted. they are named locks that are server-wide according to the MySQL docs. |
| [15:21:52] | stuarta: | they work well for that, used that myself :) |
| [15:23:00] | Captain_Murdoch: | just set an insanely large timeout since it doesn't look like it's optional. |
| [15:23:46] | stuarta: | Captain_Murdoch: is that Qt Mysql? |
| [15:24:33] | Captain_Murdoch: | stuarta, stock mysql. reading it in the 5.1 docs. |
| [15:24:59] | stuarta: | the raw LOCK TABLE .. syntax doesn't need a timeout |
| [15:25:30] | stuarta: | it'll just block until the lock is released |
| [15:25:35] | Captain_Murdoch: | right, but LOCK TABLE needs a different connection becuase we can't lock all tables. |
| [15:25:49] | Captain_Murdoch: | I was saying GET_LOCK() and RELEASE_LOCK() are an alternative. |
| [15:26:52] | Captain_Murdoch: | there's even an IS_FREE_LOCK(str) for checking the status of a lock so we don't have to block. |
| [15:27:05] | stuarta: | so basically the issue is that some of the queries lock tables and some don't |
| [15:27:15] | danielk22: | Ok giving it it's own connection works.. but I think this mythtv be more elegant.. |
| [15:27:17] | Captain_Murdoch: | no, we don't use locks. the only lock we use is for schema upgrades. |
| [15:27:44] | ** stuarta sighs with relief ** | |
| [15:28:18] | danielk22: | also locking all tables wouldn't work so well for the schema updates. altering a table releases the table lock... |
| [15:28:22] | Captain_Murdoch: | and the only reason we use a lock tables for schema upgrades is as a mutex. but that was done prior to knowledge about GET_LOCK/RELEASE_LOCK |
| [15:29:05] | Beirdo: | nice |
| [15:29:19] | Captain_Murdoch: | danielk22, yeah, I went through a couple iterations I believe before I settled on the separate schemalock table way back when. |
| [15:45:36] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [15:57:50] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [16:07:21] | kormoc is now known as kormoc_afk | |
| [16:24:34] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [16:25:20] | cattelan_away is now known as cattelan | |
| [16:44:25] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:05:18] | davide (davide!~david@host103.16.intrusion.com) has quit (Remote host closed the connection) | |
| [17:05:43] | davide (davide!~david@host103.16.intrusion.com) has joined #mythtv | |
| [17:32:13] | kormoc_afk is now known as kormoc | |
| [17:40:37] | stuartm: | is there any particular reason that local frontends don't always use the loopback ip? I've got a issue where the local frontend loses connectivity with the backend if the wireless connection drops, which seems easy to remedy |
| [17:41:39] | stuartm: | if (localip == backendip) connectionip = 127.0.0.1; |
| [17:44:39] | Beirdo: | having to add extra code for that seems rather a maintenance issue |
| [17:48:43] | Beirdo: | but other than having special case code in a few places, I see no reason why it wouldnt' work |
| [17:50:58] | stuartm: | we don't use common socket code throughout? |
| [17:59:43] | andreax1 (andreax1!~andreaz@p57B951A6.dip.t-dialin.net) has joined #mythtv | |
| [18:01:11] | andreax (andreax!~andreaz@p57B958F8.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [18:02:21] | stuartm: | http://pastebin.com/t8X06wgc |
| [18:03:35] | Beirdo: | It's only in the once place? |
| [18:04:00] | stuartm: | I'm looking for others now |
| [18:04:24] | Beirdo: | that doesnt' look bad at all |
| [18:05:11] | Beirdo: | although we may at some point want to use the IPv6 localhost instead of IPv4, but at this point we need to be dual stack anyways if we use IPv6 |
| [18:05:26] | Beirdo: | as mysql ain't v6 friendly IIRC |
| [18:06:01] | stuartm: | it could go lower level still, i.e. in MythSocketDevice() but that would make some debugging stuff display the wrong values |
| [18:06:13] | Beirdo: | yeah |
| [18:06:22] | Beirdo: | it would probably confuse people |
| [18:06:33] | stuartm: | and I've not tested it, but I don't see why it wouldn't work |
| [18:07:15] | Beirdo: | it does seem reasonable to me, especially if done in one place. It's the duplication that kinda worried me, but meh :) |
| [18:07:41] | Beirdo: | loopback should be significantly faster too in some cases |
| [18:07:45] | kormoc: | 5.5.3 supports localhost ipv6 and starts support for the rest |
| [18:08:15] | Beirdo: | ahh. We are still shying away from 5.5.x for other reasons though, are we not? |
| [18:09:21] | kormoc: | I think everything has been fixed for safe 5.5 mysql support |
| [18:09:32] | Beirdo: | sweet |
| [18:10:59] | kormoc: | I ran 5.5 for at least 6 months |
| [18:10:59] | kormoc: | and I ran innodb all that time too. I'm pretty confident that the majority of stuff (recording, watching, commflagging, myth music, myth video) work under 5.5 and innodb |
| [18:11:26] | Beirdo: | yeah, about half my tables (the bigger ones) have been innodb for me for months now too |
| [18:11:33] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has joined #mythtv | |
| [18:11:57] | Beirdo: | the problem with innodb is that distros tune it horribly if at all |
| [18:12:22] | Beirdo: | and trying to educate our users on tuning it... won't be fun |
| [18:12:25] | stuarta: | "default settings" comes to mind |
| [18:12:37] | stuarta: | which are crap |
| [18:12:37] | Beirdo: | default settings for innodb are ass |
| [18:12:54] | Beirdo: | aye |
| [18:13:17] | wagnerrp: | Beirdo, stuartm: at least with freebsd, forcing 127.0.0.1 will cause problems, as the code will only listen on IPv6 is such an address is found on the backend |
| [18:13:28] | wagnerrp: | regardless of what the listen address defined in mythtv-setup is |
| [18:13:38] | stuartm: | whoops, obvious typo fixed in above path |
| [18:14:04] | stuarta: | wagnerrp: does a bind to a v6 address also bind the v4 address or does it do an exclusive bind? |
| [18:14:05] | Beirdo: | wagnerrp: ahhh, so instead of putting just the IPv4 addr, we need to choose wisely. I'd forgotten that |
| [18:14:31] | wagnerrp: | stuartm: technically, it doesnt bind to anything |
| [18:14:38] | stuarta: | some distro/kernels auto bind to the v4 & v6 when you bind to the v6 address |
| [18:14:48] | wagnerrp: | we listen to everything, and generally on linux, everything means both v4 and v6 |
| [18:14:58] | stuarta: | it's distro specific |
| [18:14:59] | stuartm: | if someone wants to suggest a sane fix for BSD craziness I'll happily work it in |
| [18:15:10] | wagnerrp: | on freebsd, you only get one or the other (unless were simply doing it improperly) |
| [18:15:30] | stuarta: | there's a kernel sysctl to tell it to automatically bind to both v4 and v6 when doing the bind to the socket |
| [18:15:36] | wagnerrp: | although to be honest, i dont know why were binding to all accessible addresses |
| [18:15:49] | Beirdo: | hehe, there is that too |
| [18:15:51] | wagnerrp: | why not just do so to 127.0.0.1 and whatever is defined in mythtv-setup |
| [18:15:58] | stuarta: | what's wrong with the wildcard ! |
| [18:16:11] | wagnerrp: | what advantage is the wildcard? |
| [18:16:35] | Beirdo: | it can make for odd issues on a multi-homed box, not that we are likely to find many of those as mythboxes |
| [18:16:36] | stuarta: | instead of (find all ips, bind all ips) you bind (wildcard) |
| [18:16:46] | stuarta: | which has the same effect (generally( |
| [18:17:03] | stuarta: | turns up in netstat as 0.0.0.0:<port> rather than a specific ip |
| [18:17:09] | Beirdo: | anyone who runs their backend/frontend on a firewall (essentially) needs their head checked anyways |
| [18:17:18] | ** stuarta hides ** | |
| [18:17:22] | wagnerrp: | hehe |
| [18:17:32] | wagnerrp: | yeah, i yelled at one of my friends way back in 2006 for doing that |
| [18:17:47] | stuarta: | my backend is my firewall. it's always on so i makes sense |
| [18:17:53] | Beirdo: | heh |
| [18:18:04] | stuarta: | and funnily enough it is firewalled up the wazoo |
| [18:18:06] | Beirdo: | as long as you don't mind the security issues |
| [18:18:10] | stuartm: | Why we don't listen on then all them all? At least by default and only if a specific address is configured do we then restrict it? I'm refering to the ease of setup here – we assume that all users will know the IP of their backend machine by heart – it won't be true for IPv4 and it's extremely unlikely for IPv6 |
| [18:18:35] | Beirdo: | I sure wouldn't suggest that config to the unaware |
| [18:18:43] | stuarta: | nor would i |
| [18:18:51] | stuarta: | but i'm a special case |
| [18:19:15] | wagnerrp: | stuartm: but why does the user care where their backend is located? they dont tell mythfrontend where it is |
| [18:19:20] | stuarta: | i need a linux box to terminate my DSL as none of the CPE available does native ipv6 properly |
| [18:19:22] | stuartm: | I'd think most clueless users are using a NAT router |
| [18:19:25] | Beirdo: | stuartm: especially in the v6 case, I would not want it listening on every v6 address |
| [18:19:26] | wagnerrp: | they tell mythfrontend where the database is, and the database tells it where the backend is |
| [18:19:56] | stuarta: | well with v6 the upnp backend discovery should hopefully take care of it |
| [18:19:56] | wagnerrp: | any mythtv application will only ever connect on the address defined in the database |
| [18:20:07] | stuartm: | wagnerrp: huh, that's true, I was forgetting for a moment that we ask for the database IP, not the backend IP |
| [18:20:07] | Beirdo: | my backend box has 4 or 5 v6 IPs already, and only one of them should be used by mythtv (although I haven't switched from v4 binding in my setup yet) |
| [18:20:38] | ** stuarta toddles off for dinner ** | |
| [18:20:51] | stuartm: | Beirdo: right, but you're not the average user in that case and you know to configure a specific IP |
| [18:21:07] | Beirdo: | hehe |
| [18:21:27] | stuartm: | anyhow, as wagnerrp reminded me it's a moot point, we don't allow for the backend IP to be configured anywhere |
| [18:21:28] | Beirdo: | yeah, I would assume that most using v6 would fall in that category at this time, but you make a good point |
| [18:21:41] | Beirdo: | master backend IP is specified |
| [18:21:57] | Beirdo: | first time you setup a backend, IIRC |
| [18:22:06] | Beirdo: | (so it puts it into the db) |
| [18:22:29] | Beirdo: | but not local backend IP? hmmm |
| [18:22:33] | stuartm: | heh, right, so it wasn't an irrelevant discussion then :p |
| [18:23:05] | stuartm: | Beirdo: yeah, I'm a little confused now about what gets asked, where and why |
| [18:23:28] | Beirdo: | yeah, and we're confused... imagine how the average user would feel :) |
| [18:23:42] | ** stuarta suggests beer ** | |
| [18:23:54] | Beirdo: | very good suggestion |
| [18:24:16] | ** stuarta fancies whiskey tho ** | |
| [18:24:30] | Beirdo: | nice. just don't pour it on the Mac Mini :) |
| [18:24:36] | stuartm: | on a side note, now that I know about QNetworkInterface we should easily be able to pre-populate a drop-down with IP addresses for that config option, at least when selecting an IPv6 address that would make it a little easier |
| [18:24:57] | Beirdo: | YAY. ;) |
| [18:25:21] | stuartm: | I wonder how difficult auto-discovery for mysql would be ... |
| [18:25:33] | ** Beirdo channels nmap ** | |
| [18:25:36] | Beirdo: | oh wait. |
| [18:26:22] | kormoc: | outside of port hitting, I don't see how else we'd do it? |
| [18:26:33] | Beirdo: | srv records? |
| [18:26:34] | Beirdo: | heh |
| [18:26:55] | Beirdo: | like the average sysadmin could handle that let alone home users |
| [18:26:58] | kormoc: | srv records are a bit complex for a app that doesn't support hostnames :P |
| [18:27:07] | Beirdo: | so true |
| [18:28:12] | Beirdo: | and unless something has changed, God help you if you run djbdns... unless you like entering stuff in octal |
| [18:28:21] | stuartm: | well for the first backend we can at least test for a local database which should be what most users have configured, for slaves we don't need it, we just need the master IP which we can get through auto-discovery |
| [18:28:53] | Beirdo: | yeah, assuming the usual case of the db being physically on the backend |
| [18:28:54] | stuartm: | kormoc: we do now support hostnames ... although I'm not sure how well it works |
| [18:29:47] | stuartm: | well that gives me some useful ideas for the new setup, steps that can be eliminated/automated etc |
| [18:31:22] | Beirdo: | cool. New ideas are always useful |
| [18:32:05] | stuartm: | I don't know if they are original ;) However if they haven't already been implemented then they should be |
| [18:33:02] | Beirdo: | well, at least it gives ya some inspiration too, I guess. I dunno about you, but sometimes that's all it takes for me. |
| [18:36:32] | Nachtschatten (Nachtschatten!~rooms@p4FC730E3.dip.t-dialin.net) has joined #mythtv | |
| [18:40:44] | stuartm: | http://pastebin.com/Hr0exWpQ |
| [18:41:10] | stuartm: | uses the IPv6 loopback if the configured IP was also IPv6 |
| [18:41:19] | stuartm: | should work for BSD? Or not? |
| [18:41:35] | stuartm: | I'd like to avoid an ifdef .. |
| [18:41:53] | Beirdo: | I think that would work |
| [18:42:02] | Beirdo: | we can test it :) |
| [18:42:07] | stuartm: | yup |
| [18:42:51] | Beirdo: | looks like my Windows Qt build likes it better with more RAM and more disk space |
| [18:43:13] | stuartm: | I still haven't determined whether there are other places we make connections to the backend, hopefully not |
| [18:43:14] | Beirdo: | it's well past the one that consistently gacked |
| [18:43:39] | Beirdo: | well, there's 6543 and 6544 |
| [18:43:49] | Beirdo: | does the frontend connect on both? |
| [18:44:11] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [18:48:14] | stuartm: | crap, I've just realised that the patch isn't going to work in the case of a dropped network connection – if the interface goes down then the IP won't be listed in the available addresses any-more |
| [18:48:30] | stuartm: | any more |
| [18:48:40] | Nachtschatten (Nachtschatten!~rooms@p4FC730E3.dip.t-dialin.net) has quit (Ping timeout: 246 seconds) | |
| [18:48:44] | Beirdo: | eek |
| [18:49:42] | Beirdo: | I guess you could make a static var that latches the condition the first time it sees it, and caches it |
| [18:49:43] | stuartm: | we'd have to do it at a much higher level, when the frontend first connects to the backend and cache the result :( |
| [18:49:52] | Beirdo: | heh, yeah |
| [18:50:11] | Beirdo: | you could do the caching right in that code though |
| [18:50:29] | Beirdo: | if it ever matched, it won't need to loop again |
| [18:53:07] | stuartm: | yeah, and the patch as it exists now isn't entirely without merit since it prevents existing connections from being dropped just not new ones from failing |
| [18:56:29] | Beirdo: | yeah |
| [18:56:40] | Nachtschatten (Nachtschatten!~rooms@tmo-103-183.customers.d1-online.com) has joined #mythtv | |
| [19:00:55] | Nachtschatten (Nachtschatten!~rooms@tmo-103-183.customers.d1-online.com) has quit (Client Quit) | |
| [19:09:43] | stuartm: | I'm not sure about the static, I don't know if we're likely to re-use the same socket for a different address, the comments around there suggest that's a possibility |
| [19:10:02] | stuartm: | it could be a static map I guess |
| [19:10:23] | Beirdo: | yeah, a static map would do the trick |
| [19:16:56] | Beirdo: | OMG... Qt finally finished |
| [19:17:52] | Beirdo: | I'm setting up a Windows VM to build via the mythbuild.sh script, in case you were wondering |
| [19:21:39] | Beirdo: | I still chuckle every time I see "libass" flying by in the configure output |
| [19:26:41] | jrr (jrr!~jrr@c-98-253-76-24.hsd1.in.comcast.net) has joined #mythtv | |
| [19:26:52] | jrr (jrr!~jrr@c-98-253-76-24.hsd1.in.comcast.net) has left #mythtv () | |
| [19:35:15] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 276 seconds) | |
| [19:36:43] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [19:38:30] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has joined #mythtv | |
| [19:38:50] | stuartm: | Beirdo: heh, that's not going to run every time a commit is pushed I hope? |
| [19:39:08] | Beirdo: | I sure hope not |
| [19:39:37] | danielk22: | Anyone know if there is a limit to Linux memory over-commit? I was just generating some dummy video with a obviously leaky program when the machine started acting funny top told me it was using 160GB of ram.. shouldn't the OOM killer kick in at some point? |
| [19:45:21] | Beirdo: | hehe |
| [19:45:41] | Beirdo: | I think you can tweak how much over-commit it does, but I honestly haven't looked into it much |
| [19:46:44] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [19:52:31] | stuartm: | ugh, http://pastebin.com/1gYd3fZA |
| [19:52:54] | Beirdo: | wha??? |
| [19:53:51] | danielk22: | 0.0.0.2? |
| [19:54:40] | stuartm: | ah, ok, seems that there is a SpecialAddress constructor, but no equivalent for setAddress() |
| [19:55:36] | danielk22: | So 0.0.0.2 is some Qt sentinel? It's not an RFC 3330 address. |
| [19:57:29] | stuartm: | danielk22: no, it's taken the enum value QHostAddress::LocalHost (with a integer value of 2) and translated it into an IP of 0.0.0.2 |
| [19:57:55] | stuartm: | which is dumb, but easy enough to work around |
| [19:58:49] | danielk22: | ah...I this would not happen in C++11 with an explicit constructor :) |
| [19:59:02] | stuartm: | http://doc.trolltech.com/4.5/qhostaddress.html – note although the constructor will accept both the SpecialAddress value and an IP, setAddress() does not |
| [19:59:38] | stuartm: | which was my fault, I just assumed that it would |
| [20:00:20] | danielk22: | Ah.. C++11 wouldn't help there. |
| [20:00:26] | stuartm: | so instead of using setAddress on an existing QHostAddress you need to do a copy assignment |
| [20:06:06] | stuartm: | ok, so far, so good |
| [20:07:21] | stuartm: | http://pastebin.com/tt2vKL0B |
| [20:08:04] | stuartm: | backend is configured to listen on 192.168.159.2 but local frontend is connecting over 127.0.0.1 which it wouldn't previously do |
| [20:10:38] | Beirdo: | cool. |
| [20:14:41] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [20:15:01] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [20:15:05] | stuartm: | and it continues to work when I pull the ethernet cable :) |
| [20:16:50] | stuartm: | so ... who wants to test it on windows/bsd/osx and linux with ipv6? |
| [20:16:51] | danielk22: | stuartm: Hmm, I've never had a combo fe/be box fall down just because the ethernet cable was pulled.. Did you also bring down the network device? |
| [20:17:37] | wagnerrp: | danielk22: i assume something like networkmanager is detecting the lack of network and resetting the ip to a 169 address |
| [20:18:24] | stuartm: | danielk22: no, but it's a DHCP assigned IP that goes away when it detects that the network is no longer reachable – to be honest I've only seen this with wifi before now because I don't make a habit of yanking ethernet cables out when I'm watching TV |
| [20:18:34] | danielk22: | wagnerrp: ah, networkmanager is banned in this household. |
| [20:18:42] | wagnerrp: | :) |
| [20:19:22] | stuartm: | and yes, this is with my 0.24 production box which uses mythbuntu for simplicity so networkmanager is a factor |
| [20:20:02] | Beirdo: | stuartm: I can give it a shot with IPv6 this evening on my devel setup |
| [20:20:57] | stuartm: | Beirdo: http://pastebin.mandriva.com/23380 |
| [20:23:18] | Beirdo: | cool |
| [20:24:00] | Beirdo: | grabbed it to the appropriate box. thanks |
| [20:29:11] | Kunalagon (Kunalagon!~Kunalagon@212.200.240.146) has quit (Remote host closed the connection) | |
| [20:41:15] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has joined #mythtv | |
| [20:47:24] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [20:47:34] | stoffel (stoffel!~quassel@p57B4B368.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [21:27:49] | stuartm: | wagnerrp: not true, we can close the ticket as invalid ;) |
| [21:34:12] | Beirdo: | heh |
| [21:44:19] | marsilainen (marsilainen!~matt@host-78-145-174-218.as13285.net) has joined #mythtv | |
| [21:52:08] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Read error: Connection reset by peer) | |
| [21:52:59] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [21:54:01] | j-rod is now known as j-rod|afk | |
| [22:27:52] | Nachtschatten (Nachtschatten!~rooms@tmo-103-183.customers.d1-online.com) has joined #mythtv | |
| [22:28:07] | Nachtschatten (Nachtschatten!~rooms@tmo-103-183.customers.d1-online.com) has quit (Client Quit) | |
| [22:34:51] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [22:46:22] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [22:52:41] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [22:58:44] | wagnerrp: | markk or danielk22: just a thought in relation to the stuttering users experience when shifting programs during livetv |
| [22:59:02] | wagnerrp: | playback can only begin at an I-frame, since that is the first time you have a fully decoded frame to operate from |
| [22:59:23] | wagnerrp: | when the player transitions from one file to the next, is that old frame storage flushed out of the buffer? |
| [22:59:51] | wagnerrp: | or does the new playback instance still have access to it? |
| [23:10:25] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [23:35:47] | marsilainen (marsilainen!~matt@host-78-145-174-218.as13285.net) has quit (Read error: Operation timed out) | |
| [23:45:52] | danielk22: | wagnerrp: The files are transitioned at I-frames with MPEG-2. With H.264 files aren't always splittable at I frames, but that's probably not the issue. It's probably just that a lot of stuff is going on in the UI thread at that point. |
| [23:47:30] | wagnerrp: | did you see Paul Gardiner's claim in the -dev list that his broadcasts are showing up with frames referencing several I-frames previous? |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.