| Tuesday, December 17th, 2013, 00:54 UTC | ||
| [00:54:23] | skd5aner: | stuarta: I wouldn't say there's an urge, per say, to download hi-res icons for non-HD channels, in fact... I don't think lyngsat has any hires icons for non-HD channels... |
| [00:55:18] | skd5aner: | stuarta: but, I'd prefer to have hi-res icons anytime one was available... and I really wish it was for everything. It's just always nicer to have something with a transparent background that's hires that you can scale however you want for whatever circumstance you might want it... |
| [00:57:14] | skd5aner: | ugh... "per se"... sorry, that would have bugged me for getting it wrong and not correcting myself |
| [01:03:02] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer) | |
| [01:05:20] | arescorpio (arescorpio!~arescorpi@35-201-17-190.fibertel.com.ar) has joined #mythtv | |
| [01:44:58] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [02:28:03] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [03:07:25] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [03:07:25] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [03:07:25] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [03:20:05] | _nyloc_ (_nyloc_!~quassel@p3EE2C120.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:24:05] | nyloc (nyloc!~quassel@p5B26F0A7.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [03:32:34] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:35:25] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 245 seconds) | |
| [03:35:25] | peper03_ is now known as peper03 | |
| [03:40:22] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [04:10:07] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:11:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:34:09] | tonsofpc1 is now known as tonsofpcs | |
| [04:34:16] | tonsofpcs (tonsofpcs!~mythbuntu@cpe-67-255-119-102.stny.res.rr.com) has quit (Changing host) | |
| [04:34:17] | tonsofpcs (tonsofpcs!~mythbuntu@rivendell/member/tonsofpcs) has joined #mythtv | |
| [05:04:02] | arescorpio (arescorpio!~arescorpi@35-201-17-190.fibertel.com.ar) has quit (Excess Flood) | |
| [05:55:00] | neufeld` (neufeld`!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [05:56:21] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has quit (Ping timeout: 252 seconds) | |
| [05:56:39] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has joined #mythtv | |
| [05:58:55] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (Ping timeout: 272 seconds) | |
| [06:13:26] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [06:16:15] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:c457:ef1d:60fd:2177) has quit (Ping timeout: 240 seconds) | |
| [06:37:41] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [06:59:00] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has joined #mythtv | |
| [07:07:50] | jams (jams!~jams@CPE-72-131-4-141.wi.res.rr.com) has quit (Ping timeout: 245 seconds) | |
| [07:10:21] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [07:10:32] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:50:06] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [07:53:09] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Ping timeout: 248 seconds) | |
| [07:54:13] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 248 seconds) | |
| [07:54:25] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [08:12:46] | warped (warped!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [08:24:09] | dekarl: | stuartm: there's still one coverity patch open at http://code.mythtv.org/trac/report/29 but its to long for me to look at it now |
| [08:34:11] | warped (warped!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warped) | |
| [08:46:29] | dekarl: | stuartm: how can we mark http://code.mythtv.org/cppcheck/#L66 as false positive? (there is no static const member functions, so it can't be solved IIUIC) |
| [08:46:49] | dekarl: | ^- Assert statement calls a function which may have desired side effects: ' IsEIT' . |
| [08:51:33] | stuarta: | that's weird |
| [09:02:36] | Merlin83b (Merlin83b!~Daniel@80.82.127.194) has joined #mythtv | |
| [09:07:27] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has quit (Ping timeout: 240 seconds) | |
| [09:09:21] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has joined #mythtv | |
| [09:35:41] | stuartm: | that assert should be replaced |
| [09:37:01] | stuartm: | and it is a bug, as cppcheck says – 'Assert statements are removed from release builds' so the check wouldn't be made in a release build, but it should |
| [09:38:33] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [09:39:01] | stuartm: | if (IsEIT(TableID()) { Parse(); } else { LOG( ..., "Danger Will ..."); } |
| [09:39:13] | dekarl-work: | stuartm, all TableID checks are in asserts, EIT stands out as its a bag of IDs instead of one |
| [09:40:54] | dekarl-work: | its just that cppcheck is pointing out a valid concern that can't be fixed with the available expressions allowed by c++, it could check if IsEIT is behaving const though |
| [12:39:53] | Merlin83b2 (Merlin83b2!~Daniel@2a00:1ee0:3:1337:50e6:1eff:4751:fa91) has joined #mythtv | |
| [12:42:39] | Merlin83b (Merlin83b!~Daniel@80.82.127.194) has quit (Ping timeout: 240 seconds) | |
| [12:49:25] | stuartm: | dekarl-work: how much do you remember about https://github.com/MythTV/mythtv/commit/c0c47344 ? Couldn't we just lose the DISTINCT instead? There shouldn't be duplicate values in the program table to begin with |
| [12:49:43] | stuartm: | the subquery is screwing up the sort order for some reason |
| [12:55:35] | dekarl-work: | stuartm, can we get the same speedup by simply leaving out the distinct? IIRC the issue is with mysql needing 3 bytes * 16384 max length of the description in its virtual table which hits the disk once it exceeds the limit of ... hmm, i think the default was around 100mb? So once we hit ~2000 results we sort on disk. |
| [12:57:02] | dekarl-work: | and you'll easily hit 2k in time search |
| [12:59:37] | dekarl-work: | looking at https://github.com/MythTV/mythtv/blob/c0c4734 . . . fo.cpp#L4576 I'm wondering if its because we are sorting the subquery. maybe we can simply sort the superquery |
| [13:00:36] | dekarl-work: | hmm, actually I'm not sure. meeting |
| [13:01:42] | stuartm: | could try it |
| [13:16:27] | stuartm: | won't work, at least not without completely changing the way that we pass in custom join/where/order sql |
| [13:18:46] | stuarta: | can we rework it to be a join instead? |
| [13:19:54] | stuartm: | it was a join, the problem is apparently that cost too much in memory |
| [13:21:07] | jams (jams!~jams@CPE-70-92-146-93.wi.res.rr.com) has joined #mythtv | |
| [13:21:15] | stuartm: | we could break it into two different queries, one which fetches the basic info (chanid, starttime etc) then we iterate over the results from that query adding the extra detail |
| [13:24:46] | dekarl-work: | hmm, maybe we can your program p and program onlyfordescription? |
| [13:24:53] | dekarl-work: | s/your/join/ |
| [13:26:29] | stuartm: | would take avoid the huge temp table? |
| [13:26:31] | stuartm: | that |
| [13:37:02] | _nyloc_ (_nyloc_!~quassel@p3EE2C120.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [13:37:11] | nyloc (nyloc!~quassel@p3EE2C120.dip0.t-ipconnect.de) has joined #mythtv | |
| [13:43:06] | dekarl-work: | hmm, a quick look at mysql join optimization hints that its not going to about the sorting table. Iterating over the result appears sub-optimal and I don't see a way to get away with just one additonal query that adds the description to a result set. |
| [13:44:57] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit () | |
| [13:45:50] | stuartm: | 'to about'? |
| [13:48:43] | stuartm: | I think losing the DISTINCT should help performance, even if it doesn't entirely eliminate the sorting size issue, DISTINCT generally is a bad idea on columns which have no index, let alone a couple of dozen columns at once |
| [13:49:44] | stuartm: | http://dev.mysql.com/doc/refman/5.0/en/distin . . . ization.html |
| [13:49:53] | stuartm: | "DISTINCT combined with ORDER BY needs a temporary table in many cases." |
| [13:50:14] | stuartm: | http://dev.mysql.com/doc/refman/5.0/en/order- . . . ization.html |
| [13:50:19] | stuartm: | In some cases, MySQL can use an index to satisfy an ORDER BY clause without doing any extra sorting. |
| [13:51:50] | stuartm: | dekarl: would be worth reverting c0c47344 locally, then removing the DISTINCT clause and seeing what that does for you in the time search |
| [13:53:48] | stuartm: | apparently my channel table has no indexes ... that needs fixing, wonder what they are supposed to be |
| [13:55:52] | stuarta: | good question |
| [13:55:52] | ** stuarta checks ** | |
| [13:56:09] | tris (tris!tristan@camel.ethereal.net) has quit (Ping timeout: 246 seconds) | |
| [13:57:06] | stuarta: | http://fpaste.org/62492/87288621/ |
| [14:00:32] | stuarta: | stuartm: ^^^ |
| [14:01:39] | Merlin83b2 is now known as Merlin83b | |
| [14:01:55] | tris (tris!tristan@camel.ethereal.net) has joined #mythtv | |
| [14:25:03] | tris (tris!tristan@camel.ethereal.net) has quit (Ping timeout: 240 seconds) | |
| [14:25:47] | tris (tris!tristan@camel.ethereal.net) has joined #mythtv | |
| [15:05:51] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [15:14:24] | neufeld` (neufeld`!~user@69-165-173-139.dsl.teksavvy.com) has quit (Quit: ERC Version 5.3 (IRC client for Emacs)) | |
| [15:31:31] | stuartm: | stuarta: thanks, one of the dangers of restoring from an ad-hoc backup :/ |
| [15:32:18] | stuartm: | we could use a startup check that makes sure all the indexes are present and recreates them if they are missing |
| [15:33:02] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warped_) | |
| [15:49:43] | stuartm: | fwiw, my testing shows that with DISTINCT the query take ~33% longer but returns exactly the same number of results |
| [15:50:09] | stuartm: | err, bad maths, over 50% longer |
| [15:52:20] | stuartm: | heh, with a much larger result set, that leaps to 20x longer |
| [15:52:55] | stuartm: | 9.08 seconds vs 0.41 seconds |
| [15:53:04] | stuarta: | bye bye distinct |
| [15:53:05] | stuartm: | so 22.14x longer |
| [15:53:34] | stuartm: | 2760 rows in set, 312 warnings (9.08 sec), 2760 rows in set, 312 warnings (0.42 sec) |
| [15:53:45] | stuarta: | hmmm warnings bad |
| [15:54:21] | stuarta: | what does 'show warnings\G' have to say? |
| [15:54:25] | stuartm: | yeah, I'll worry about that in a minute |
| [15:55:36] | stuartm: | stuarta: ah, that's because in my example I'm using an integer cast on a string column as a way to get natural sorting by chan number, the warnings are thrown because some numbers cannot be converted |
| [15:56:16] | stuartm: | Warning | 1292 | Truncated incorrect INTEGER value: '7.1' |
| [15:56:58] | stuartm: | but we actually want it to truncate, we're using that to get the desired sort |
| [16:00:09] | stuartm: | dekarl: I'd have to say that reverting the super-query change and removing the distinct seems to have a similar effect on speed, it is slightly slower than using the super query but only by a tenth of a second, vs several seconds against the original version |
| [16:00:52] | stuartm: | for now that seems like the best compromise? |
| [16:02:13] | stuartm: | we can optimise it at the other end too, have the time search batch load instead of fetching everything in one go |
| [16:03:48] | Chutt_ is now known as Chutt | |
| [16:17:12] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:17:29] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [16:19:45] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [16:25:23] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has quit (Ping timeout: 250 seconds) | |
| [16:25:33] | CeilingKitten (CeilingKitten!~CeilingKi@69-196-174-148.dsl.teksavvy.com) has joined #mythtv | |
| [16:32:05] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Ping timeout: 245 seconds) | |
| [16:36:02] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:c599:42c6:dffd:e8fe) has joined #mythtv | |
| [16:36:02] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:c599:42c6:dffd:e8fe) has quit (Changing host) | |
| [16:36:02] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [16:41:26] | stuartm: | I can't remember who brought up the subject of channel sorting in the WebFrontend guide, but it should now be a lot better, especially where subchannels are present e.g. 8_2 or 5.4 |
| [16:42:32] | stuartm: | I've actually adopted .1 for HD channels so that they sort next to the SD versions (livetv/recordings break badly if they use the same chan num!) |
| [16:45:33] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [16:45:51] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
| [16:45:51] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:45:51] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
| [16:47:19] | stichnot: | stuartm: I think I was the one who first brought up the channel sorting request. I'll test it later. Thanks! |
| [16:50:07] | stuartm: | tested with both _ and . they both seem to work |
| [16:54:25] | dekarl1 (dekarl1!~dekarl@p4FCEF022.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:57:27] | dekarl (dekarl!~dekarl@p4FE849C1.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [17:00:19] | stichnot: | Cool. For whatever reason, I have both _ and . in my DB. (Can't test until I get home since I haven't set up the Apache proxy stuff yet) |
| [17:02:05] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [17:02:24] | jheizer_: | Note if you change them check your record only on this channel rules. |
| [17:02:48] | jheizer_: | Happy wife, happy life. No Glee recorded for 3 weeks, no happy wife. |
| [17:04:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds) | |
| [17:15:56] | Chutt_ (Chutt_!~ijr@2605:a000:1208:c08c:c457:ef1d:60fd:2177) has joined #mythtv | |
| [17:18:42] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 250 seconds) | |
| [17:27:45] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:29:51] | brfransen (brfransen!~brfransen@64.179.169.226) has quit () | |
| [17:30:37] | stichnot (stichnot!~stichnot@216.239.45.72) has joined #mythtv | |
| [17:30:37] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:30:37] | stichnot (stichnot!~stichnot@216.239.45.72) has quit (Changing host) | |
| [17:34:00] | stuartm: | yeah, never much liked that 'this channel' rules are keyed off a user-editable channel number |
| [17:35:14] | stuartm: | next to useless in parts of the world where channel numbers can and often do change following a rescan (broadcaster buys a better slot, or the network operator shuffles channels to make room for new ones) |
| [17:35:41] | jheizer_: | After we talked a few weeks ago and I realized me '-' was "old school" and I had to scan a few days later I let it update to the default. |
| [17:36:09] | jheizer_: | Talked about the sorting query that is |
| [17:36:34] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warped_) | |
| [17:37:31] | gigem: | stuartm: Where do you get 'this channel' uses channum? It hasn't done that in at least 10 years. |
| [17:38:13] | stuartm: | gigem: guess the last time I used it, and it bit me in the arse, which could have been 10 years ago :) |
| [17:38:46] | stuartm: | gigem: but jheizer_ has just indicated that's still the behaviour, he changed his channum and it failed to record |
| [17:38:55] | jheizer_: | Hmm, maybe I was wrong and it was the call signs that changed. A lot of the broadcast ones here from SD like to add and remove -DT from the end. |
| [17:39:14] | stuartm: | well callsign or channum, both equally flawed for DVB land |
| [17:40:01] | stuartm: | no such thing as callsign outside North America, that field just gets populated with the channel name, and changes as the channel name changes |
| [17:40:26] | jheizer_: | Sorry, yes they use station call sign. And mine are now WYZZ-DT so they added the -DT or I had removed them before to match the call sign from my Sat recorders. |
| [17:40:41] | jheizer_: | Just checked record table. |
| [17:41:58] | jheizer_: | I had also removed my OTA channels from my Sat tuner at the same time to make sure it was never used so that was why I never noticed. Sorry for the false alarmed warning. |
| [17:42:10] | gigem: | Callsign I can believe. What does DVB land use to identify a channel? I can't imagine there isn't something equivalent to a callsign. As for it being user-editiable, it (or something very much like it) needs to be used for cases where the provided value is just wrong. |
| [17:43:12] | stuartm: | exactly how you uniquely identify a channel for this purpose is tricky, for DVB it might use serviceid but that wouldn't work cross-source ... |
| [17:43:44] | stuartm: | gigem: there is no equivalent to callsign |
| [17:44:13] | jheizer_: | Werid, I would have thought they had an abbreviated name or something. |
| [17:44:29] | jheizer_: | But I don't know jack about non-US tv. |
| [17:44:32] | stuartm: | it's a uniquely US concept, in part due to the unusual way your broadcast network works with lots of little 'affiliate' stations |
| [17:44:33] | jheizer_ is now known as jheizer | |
| [17:45:09] | gigem: | Yes, for non-OTA channels, it's just an abbreviated name the channel calls itself, e.g. BBC2, TV1, etc. |
| [17:46:48] | dekarl1 is now known as dekarl | |
| [17:47:16] | stuartm: | most European countries for example have a national broadcast network that's operated by a single company (terrestrial), broadcasters rent space/bandwidth and mostly broadcast nationwide |
| [17:47:18] | gigem: | FWIW, I think if the scanner was more careful about overwriting the callsign, most of the problems would go away. |
| [17:48:20] | stuartm: | gigem: if we also moved away from display the callsign in the UI, users would be less inclined to edit it for cosmetic reasons |
| [17:48:21] | dekarl: | stuartm... oh my quickly writing down a thought on the way out to catch the craftsmen at home didn't work out... "not going to avoid the sorting table" |
| [17:49:37] | stuartm: | dekarl: I've pushed my changes, I think any remaining slowness can be addressed by modifying the time search so that it's not loading so much in one go |
| [17:50:52] | gigem: | stuartm: I don't see that happening as channum/callsign (or channum/network) is THE way channels are identified here. |
| [17:51:03] | stuartm: | long term I'd redesign it entirely, seems most people use it as they would the guide grid with the axes switched, the mythui guide actually supports that, so maybe we offer both versions? |
| [17:52:42] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:50e6:1eff:4751:fa91) has quit (Quit: Leaving) | |
| [17:53:28] | gigem: | Let me ask you this way: If callsign didn't exist, what would YOU use for 'this channel' rules? It must work across sources. You've already said channel numbers and names can change across rescans, so what else is there? |
| [17:53:38] | stuartm: | gigem: fair enough, it's not ideal but I really don't care too much as 'This channel' rules are never really going to work very well for those in the UK, we have +1 and HD versions of channels so you're shooting yourself in the foot if you don't let the scheduler pick the one that avoids any conflict |
| [17:55:05] | stuartm: | gigem: one simple solution would be to update the recording rule when the channel is updated/edited |
| [17:55:31] | stuartm: | (looking at it from a different angle) |
| [17:56:21] | stuartm: | that's where switching to innodb would be great, we could using foreign key constraints with ON UPDATE ... CASCADE |
| [17:56:45] | stuartm: | no extra code, but bullet-proof referential integrity |
| [17:57:46] | gigem: | stuartm: Yes, but I'd also check with the user before updating the callsign in the first place. |
| [17:58:06] | jheizer: | I usually am against anything but all record rules, but another channel was reboardcasting this show and the episodes were marked as new with a new broadcast date and modified descriptions so they was duplicating up. |
| [17:58:55] | stuartm: | jheizer: doesn't SD provide a unique programid? |
| [18:00:49] | jheizer: | The series IDs were the same, not sure about the program IDs as they were a month or 3 behind. |
| [18:00:55] | dekarl: | gigem,stuartm. the only thing for humans I know of is the service name from the SDT e.g. http://pastebin.com/1nzFYy3B but there you'll get Phoenix/phoenix/PHOENIX depending on the network. For machines its the original_network_id+service_id (but that sometimes gets messed up) |
| [18:00:57] | dekarl: | IIUIC the call sign is the real radio transmitter call sign carried over in the post-analog world? That doesn't make sense in the DVB world. |
| [18:01:35] | gigem: | stuartm: They do have programids. They're usually right, but not always. |
| [18:03:04] | jheizer: | Something different about them (now) as I open one in mythweb to edit the rule and it is not registering it as the same rule for original channel |
| [18:03:26] | jheizer: | so in this case not picking up the reruns I may want even though it is a record any time/channel rule now. |
| [18:03:43] | jheizer: | some how I screwed it all up |
| [18:06:27] | stuartm: | dekarl: original network+serviceid wouldn't work in the UK, they differ between Satellite and OTA |
| [18:06:48] | stuartm: | and they aren't applicable for capture e.g. HD-PVR |
| [18:07:06] | dekarl: | stuartm, wrt the superquery. All I care about is not hitting the disk with multiple gigabytes of emptyness (and some small pieces of actual data). |
| [18:07:25] | dekarl: | If the query take 2 seconds instead of 0.2 that's a no-brainer. Is your tempspace on SSD? 9sec vs. 0.42sec sounds a lot and hints it'll hit disk and slow down to a crawl with just some more results |
| [18:08:21] | dekarl: | stuartm: wrt the "same channel" mapping, sounds like we need a metadata service that carries a map then :( |
| [18:08:51] | stuartm: | dekarl: temp is ramdisk here, disk is ssd |
| [18:09:02] | dekarl: | :( |
| [18:10:01] | dekarl: | the other solution is "kill time search!" but after that didn't happen for years I decided to fix it. But broke your sorting (IIUIC) |
| [18:10:36] | stuartm: | as I said, if there is still a problem in master with the distinct clause removed, I think it's better to fix it from the other end, the idea of loading all programs in the way that it does is crazy |
| [18:12:05] | bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv | |
| [18:12:50] | dekarl: | I'll look at it if it reappears in the slow queries log |
| [18:14:17] | gigem: | stuartm: That DISTINCT was not needed. I'm not sure of the history, but I suspect it was there from the beginnning. |
| [18:15:01] | stuartm: | gigem: yeah, it was obviously bogus, didn't dig into the why though – ancient history |
| [18:16:02] | stuartm: | dekarl: haven't logged slow queries for a long time, how clean is it looking? |
| [18:18:02] | dekarl: | all available logs are empty, I bet some update disabled it though |
| [18:20:24] | bill6502: | v0.28-pre-641-g9c3f0db, Webfrontend->TV->Program Guide: http://pastebin.com/HUB8YKhF . Result on the page is: There are no channels to display. |
| [18:22:16] | stuartm: | so I've just learnt that American 'Yellow Mustard' is extremely mild, I always saw people in films putting it on hot dogs or sandwiches in large quantities and thought they were extremely brave |
| [18:22:39] | stuartm: | English mustard, in those quantities would blow your head off |
| [18:22:47] | jheizer: | Interesting |
| [18:22:47] | stuartm: | bill6502: what version of mysql? |
| [18:23:13] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer) | |
| [18:23:18] | Guest43400 (Guest43400!dblain@mythtv/developer/dblain) has joined #mythtv | |
| [18:23:59] | bill6502: | 5.5.34 |
| [18:25:08] | stuartm: | hmm, works with 5.5.33a here |
| [18:25:36] | stuartm: | INT used to be valid, seems it needs to be UNSIGNED now |
| [18:25:52] | stuartm: | I'll test and push a fix after I've eaten |
| [18:31:18] | stuartm: | bill6502: can you try – SELECT channum, name, CAST(channum AS UNSIGNED) AS foo FROM channel ORDER BY LPAD(CAST(channum AS UNSIGNED), 10, 0), LPAD(channum, 10, 0) LIMIT 100; |
| [18:31:58] | bill6502: | stuartm: I'll try ^^^, but just rebuilt with: "ORDER BY LPAD(CAST(channum AS UNSIGNED), 10, 0), " works for me. |
| [18:33:49] | bill6502: | stuartm: http://pastebin.com/mdvintHC |
| [18:39:19] | bill6502: | Line 5 is for a channel that has visible = 0. |
| [18:41:39] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has joined #mythtv | |
| [18:53:22] | stuartm: | looks good, thanks |
| [18:55:07] | bill6502: | np, any reason for not adding "WHERE visible != 0" to that query? |
| [18:56:12] | stuartm: | bill6502: the query I pasted above was a cut down version, the one in the code does check visible |
| [18:57:05] | stuartm: | 3/4s of the channels in my database aren't visible – satellite is full of crap |
| [18:58:24] | stuartm: | bill6502: heh, I apologise, it doesn't check visible! I just have no guide data for the invisible channels so I never noticed |
| [19:09:01] | dekarl: | meh, mythfilldatabase on master stopped running automatically. (I obviously noticed it only after running out of guide after three weeks) is it just me? |
| [19:10:49] | bill6502: | hopefully, mine just ran 70 minutes ago |
| [19:20:56] | stuartm: | dekarl: are you using a 'min/max window'? |
| [19:23:29] | stuartm: | I started to have issues with my 0.27 box a couple of weeks ago, but I put that down to a bad interaction between the 'suggested runtime', the 'min/max' window and the fact that it spends most of it's time powered down – it would wake up to grab guide data, but outside it's allowed window so it would just shutdown again |
| [19:24:26] | dekarl: | stuartm, my database has 23–20 |
| [19:24:42] | MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has joined #mythtv | |
| [19:25:29] | stuartm: | dekarl: I wonder if it's related then, I need to look at the housekeeper logic again |
| [19:26:06] | dekarl: | min=23, max=20 |
| [19:26:51] | dekarl: | IIRC the idea was to not run in the prime time because I --refresh-all and if rescheduling takes to long it aborted recordings, so I just avoid it ;) |
| [19:27:28] | stuartm: | dekarl: yeah, mine is now something similar, it was a much smaller window |
| [19:27:38] | stuartm: | what is the value of MythFillSuggestedTime? |
| [19:28:03] | dekarl: | 2013-12–18T18:42:57Z after I ran it manually earlier tonight |
| [19:28:40] | dekarl: | was 2013-12–17T00:16:00Z after I ran it manually last night |
| [19:29:13] | dekarl: | the latter being inside the window and in the past when I looked into it today |
| [19:32:03] | stuartm: | strange |
| [19:32:31] | stuartm: | localtime vs gmt thing maybe? |
| [19:33:44] | dekarl: | unlikely as that's only 1 hour offset atm |
| [19:34:09] | dekarl: | hmm, maybe if its applied wrongly and twice, lets see |
| [19:34:45] | bill6502: | dekarl: are your min/max a typo (reversed)? my MythFillMinHour=1 and MythFillMaxHour=23 |
| [19:35:19] | stuartm: | maybe a red herring, we really need some better logging from the housekeeper |
| [19:35:22] | dekarl: | bill6502: its a window starting as 23:00 and lasts until 20:00 the next evening. Or that's the intention :) |
| [19:35:31] | dekarl: | s/as/at/ |
| [19:54:51] | dekarl: | looks like min/first must be less then max/second http://code.mythtv.org/cgit/mythtv/tree/mytht . . . per.cpp#n425 |
| [19:55:57] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 246 seconds) | |
| [19:56:58] | joki (joki!~joki@p54860394.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [20:03:30] | joki (joki!~joki@p54862D3A.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:06:26] | Chutt_ is now known as Chutt | |
| [20:10:01] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [20:10:47] | bill6502 (bill6502!~bill@205.178.26.43) has left #mythtv () | |
| [20:13:45] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 250 seconds) | |
| [20:27:56] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:27:57] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [20:27:58] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [20:27:58] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [20:35:58] | stuartm: | anyone think it's a good time to cut 0.27.1? |
| [20:53:47] | MartinT: | do we have to support <IE10 in the WebFrontend? |
| [20:56:02] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 264 seconds) | |
| [20:56:26] | MartinT: | also, in terms of users bookmarking pages... should we allow history, i.e they can click back through their pages, or simply allow them to bookmark the current page? |
| [20:59:40] | dekarl: | MartinT: google is dropping support for ie9 (from its apps) so i'm not sure why we should pick up the remains ;) |
| [21:00:15] | MartinT: | my thoughts exactly, there's a few others that have, or are planning on doing that |
| [21:03:37] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:04:49] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has joined #mythtv | |
| [21:07:17] | Guest43400 is now known as dblain | |
| [21:07:52] | stuartm: | MartinT: we're only supporting the latest generation of each browser (ignoring dinosaurs like Konqueror) |
| [21:08:35] | MartinT: | fair enough, that makes that easier... what about the page history? |
| [21:09:03] | stuartm: | trying to avoid cluttering things with browser specific hacks too – some exceptions, but as a general rule |
| [21:09:12] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [21:09:31] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has joined #mythtv | |
| [21:09:38] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has quit (Changing host) | |
| [21:09:39] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [21:09:55] | stuartm: | I'm not personally bothered about history, the web frontend isn't some huge website where it will be difficult to find a particular page again |
| [21:10:10] | MartinT: | no worries... |
| [21:11:15] | MartinT: | my thought at the moment is to simplify the loading of the content, instead of passing a url, hold a dictionary that contains the references... e.g. "Guide" points to "/tv/guide.qsp", etc. |
| [21:11:49] | MartinT: | therefore when you want to load the guide in the code, you just do "loadContent("Guide")" |
| [21:12:07] | skd5aner: | stuartm: haha, great example of a culturalism that I didn't even realized existed... Yellow mustard is so common here, I just assumed it was common globally as well. We also use "deli mustard" or "brown mustard" or "dijon mustard" pretty commonly too, which has the spice |
| [21:12:21] | stuartm: | the only older browser I'm actively supporting for now is Opera 12, since they've not yet released a version based on Blink for linux, so until they either officially drop linux support or release a newer version ... |
| [21:12:55] | MartinT: | it will then handle stuff like updating the Title, associated js files, etc. |
| [21:13:43] | stuartm: | MartinT: what about arguments/parameters? |
| [21:14:08] | MartinT: | pass those to loadContent |
| [21:14:19] | MartinT: | let that do the hard work |
| [21:14:53] | MartinT: | I'll knockup something basic on loading the guide and a recording page to see if you like it... |
| [21:15:31] | stuartm: | skd5aner: we have Franch mustard, Djion (wholegrain) mustard and English mustard (to name the more common ones), French/Djion are considered mild, English mustard (Colman's), is explosive – I suspect that it inspired the use of mustard gas as a lethal chemical weapon on the battlefields of World War One |
| [21:16:06] | stuartm: | MartinT: sounds fine |
| [21:20:36] | skd5aner: | stuartm: heh – yea, we have some mustard in the fridge that's got bunch of horseradish in it... WOOOOHOOOO, clears out the sinuses :) |
| [21:22:54] | skd5aner: | fyi – I'm in support of a 0.27.1 release, but I'll add that 0.27 is really broken for me in general... it's the least stable version I've I had in probably 6 years :/ |
| [21:23:17] | skd5aner: | It seems that it isn't impacting many others though, so... |
| [21:25:21] | dekarl: | was that the slave backend issue? |
| [21:26:05] | skd5aner: | dekarl: yea, but the working theory is that it's really a socket's issue in general... |
| [21:26:18] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [21:26:48] | skd5aner: | Every single day, my masterbackend segfaults in the middle of the night... I have an upstart script that will relaunch it automatically, but my slave will then not reconnect without manual intervention... |
| [21:27:10] | skd5aner: | also, mythfilldatabase takes HOURS to run... extremely slow, and sometimes also crashes |
| [21:27:40] | jheizer: | Since hearing about the slave issues I have been checking on my newly added slave with a hd-pvr daily and it has been fine so far. Thought only recorded 5–10 items in 3 weeks. |
| [21:27:53] | skd5aner: | and then, multiple times per day, the frontend becomes slow and unrepsonsive, and then I'll get mythcontext notifications that the backend is offline, and the back online, etc |
| [21:28:14] | skd5aner: | and looking at top on the masterbackend, mythbackend is maxing out CPU, as is mysql |
| [21:28:19] | skd5aner: | (when that happens) |
| [21:28:31] | stuartm: | a socket issue wouldn't affect mythfilldatabase, I wonder if there isn't a hardware issue involved? |
| [21:28:51] | jheizer: | I've had to manually recoonect my slave as well. |
| [21:29:01] | dekarl: | skd5aner: no backtrace? |
| [21:29:17] | stuartm: | dekarl: he's opened a ticket with a backtrace iirc |
| [21:29:25] | skd5aner: | stuartm: I'm happy to admit it might not be a mythtv problem, I just didn't really see the issues with mythbackend in 0.26... although mythfilldatabase has always been a bit slow |
| [21:29:50] | dekarl: | stuartm, I'm looking at #11927 |
| [21:29:50] | ** MythLogBot http://code.mythtv.org/trac/ticket/11927 ** | |
| [21:29:55] | stuartm: | the segfault is definitely a myth issue, but maybe it's exacerbated by a hardware issue that's affecting timings/network stability |
| [21:30:25] | skd5aner: | dekarl: 2 tickets – #11927 and #11929 |
| [21:30:25] | ** MythLogBot http://code.mythtv.org/trac/ticket/11927 ** | |
| [21:30:25] | ** MythLogBot http://code.mythtv.org/trac/ticket/11929 ** | |
| [21:33:49] | skd5aner: | stuartm: part of me hopes it is a hardware issue, and the other part of me dreads that it could be a hardware issue – heh – but, I'm not exactly sure where to start looking :/ |
| [21:37:35] | stuartm: | skd5aner: I wish I could find the energy to figure out the problem for you, I really do want to see the segfault fixed but doing so requires wading through a lot of code that I don't really know particularly well :/ |
| [21:39:22] | stuartm: | I've no doubt Daniel, who re-wrote much of the socket code just 12–18 months ago, could find the problem faster than me, but he's too busy with work |
| [21:42:10] | skd5aner: | I know – I hate to sit here and complain too much either seeings how, even though it's serious, it doesn't appear to be widespread from what I can tell |
| [21:43:04] | skd5aner: | I'll see if there's anything else outside of mythtv that seems to be wonky... |
| [21:43:19] | skd5aner: | nothing obvious, but maybe I'll pull back the onion a bit and see what I can dig up, if anything |
| [21:43:34] | jheizer: | Since it is usually early morning I am assuming it is usually not recording? |
| [21:43:50] | skd5aner: | 95% of the time, no... |
| [21:43:51] | jheizer: | Curious if I could find a way to reproduce it on my MBE/Slave setup. |
| [21:44:30] | skd5aner: | but occasionally. yes... I have some recordings (like sportscenter, etc) that I have set to record in the early AM hours, and I have dozens of children's shows that re-air ALL the time, and sometimes record at that time too |
| [21:53:35] | skd5aner: | jheizer: unlike most segfaults I've seen in mythtv before, I'm not quite even sure what the trigger could be this time |
| [21:59:36] | jheizer: | Ok, I just setup recordings on my slave to go from tonight at 11PM through tomorrow 5PM. Nothing recording on any other tuner during that time as it is holiday schedule already I guess. |
| [21:59:56] | jheizer: | I'll report back if heavy slave activity alone kills it for me. |
| [22:00:51] | skd5aner: | jheizer: I do wonder, though, if that's the usual time that mythfilldatabase runs... |
| [22:03:16] | jheizer: | If I can remember I can throw ina few mythfill's |
| [22:03:56] | jheizer: | but I am on pretty decent hardware so they run pretty fast and don't effect me much. (X6, 16GB, SSD OS/DB) |
| [22:06:18] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [22:06:47] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [22:15:58] | stuartm: | skd5aner: check the settings table for MythFillSuggestedTime |
| [22:16:16] | stuartm: | that should tell you when mfdb is scheduled to run |
| [22:17:21] | stuartm: | the consistency in the time when it segfaults is suspicious, I had assumed before now that there was a particular task (housekeeping) that was relevant somehow |
| [22:18:00] | skd5aner: | MythFillGrabberSuggestsTime = 0 |
| [22:18:28] | stuartm: | MythFillSuggestedRunTime |
| [22:18:40] | skd5aner: | MythFillSuggestedRunTime |
| [22:18:41] | skd5aner: | 2013-12–18T11:52:34Z |
| [22:19:29] | SteveGoodey (SteveGoodey!~steve@host86-143-180-227.range86-143.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:19:30] | skd5aner: | MythFillPeriod |
| [22:19:31] | skd5aner: | 1 |
| [22:19:31] | skd5aner: | NULL |
| [22:19:31] | skd5aner: | MythFillMinHour |
| [22:19:31] | skd5aner: | 3 |
| [22:19:31] | skd5aner: | NULL |
| [22:19:33] | skd5aner: | MythFillMaxHour |
| [22:19:35] | skd5aner: | 6 |
| [22:19:37] | skd5aner: | NULL |
| [22:19:39] | skd5aner: | sorry for the paste :/ |
| [22:20:35] | skd5aner: | Last mythfilldatabase run started on Tue Dec 17 2013, 6:52 AM and ended on Tue Dec 17 2013, 6:52 AM. Successful. |
| [22:22:28] | skd5aner: | well, anyway – I'll try to get some more specifics |
| [22:22:31] | skd5aner: | got to run! :) |
| [22:28:19] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [23:01:41] | rsiebert (rsiebert!~quassel@f052167165.adsl.alicedsl.de) has joined #mythtv | |
| [23:35:15] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 250 seconds) | |
| [23:44:49] | stichnot (stichnot!~stichnot@216.239.45.64) has joined #mythtv | |
| [23:44:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:44:49] | stichnot (stichnot!~stichnot@216.239.45.64) has quit (Changing host) | |
| [23:48:51] | MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has quit (Remote host closed the connection) | |
| [23:59:33] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 248 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.