| Friday, October 21st, 2011, 00:13 UTC | ||
| [00:13:43] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [00:24:57] | mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [00:28:22] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Ping timeout: 258 seconds) | |
| [00:47:58] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq_) | |
| [00:53:23] | sphery: | gigem: hehe, I can't believe I forgot about No grabber--you'd think the guy who submitted the patch for that would have remembered. Glad you found it. |
| [00:56:29] | sphery: | taylorr: my understanding was that it was the number of requests that made it challenging for TMS because once they'd customized the data for one day of a users' listings, adding additional days of data was negligible effort. So, --dd-grab-all does 14 days in one request, default does tomorrow and +13 in 2, but also does additional requests for each day with "substantial missing data"... If so, running one or more --refresh-today run each day ... |
| [00:56:35] | sphery: | ... in addition to normal runs just adds more requests (and still deletes today's data out from under the scheduler and recorders). |
| [00:57:02] | sphery: | taylorr and iamlindoro : also note that if you enable running at grabber-suggested times, the mythfilldatabase window is ignored |
| [00:57:24] | sphery: | (hasn't been mentioned on list, but I think at least one user may think it's doing something that it's not doing for him) |
| [00:58:45] | taylorr: | sphery: the reality is that you want the update to be as close to primetime as possible – but if everyone did that it would cause a problem |
| [01:02:03] | sphery: | s/as close to primetime as possible/between the last update prior to primetime and primetime/ , but, yeah, I'll admit that running just before primetime--with sufficient time to complete the run before primetime shows start--would be the easiest way to maximize likelihood it's in that range |
| [01:04:46] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [01:05:12] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [01:06:57] | danielk22: | Assuming the problems with --dd-grab-all can be addressed, why not run that at any random time of day and then grab just todays listing at some point between 2pm EST and 8 pm local time (i.e. after the daily update but before prime-time) ? |
| [01:07:33] | sphery: | so we know that the last update is 2pm est? that's good to know--and allows spreading out the requests quite a lot |
| [01:08:08] | sphery: | do we really have to worry about number of requests to the server or anything? |
| [01:08:12] | danielk22: | sphery: the file lands at about noon EST then it takes an hour+ for it to be inserted into the DB. |
| [01:09:14] | sphery: | if so, just running the --dd-grab-all between then (especially if accounting for the backend's recording status/schedule in the housekeeper's decision of when to run mfdb) seems like it would be fine |
| [01:10:22] | danielk22: | sphery: yeah, I guess so. |
| [01:10:54] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [01:11:17] | danielk22: | I still think of --dd-grab-all as something you don't run without shutting down the master backend first.. but I think we know approximately what needs to be addressed for --dd-grab-all to be safe. |
| [01:11:22] | sphery: | I'll be getting some mythtv time, again, next week--I'll try to look at updating the housekeeper to take into account recording schedule for mfdb runs |
| [01:12:55] | sphery: | yeah, it sounds like davide's approach for it ignoring data before now + Xhrs is the way to go--just requires someone to work out how to do that |
| [01:13:40] | sphery: | and/or use some of the "update in place" code from that ticket I ref'ed in the thread |
| [01:15:01] | danielk22: | sphery: I don't think that ticket really has what you are looking for. |
| [01:16:22] | wagnerrp: | the barrier issue only takes place per insert statement, right? |
| [01:16:44] | wagnerrp: | if you do one bulk insert of several MB of data, it should go through very quickly? |
| [01:18:09] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [01:18:10] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [01:18:10] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [01:19:27] | danielk22: | wagnerrp: bulk insert? I think it would actually depend on the DB engine.. but you don't want execute any SQL that will lock up the DB for a long time if you are going to be doing this while the user is using the box. |
| [01:20:18] | wagnerrp: | why not populate the download into a temporary table, and then only swap the data once the file is parsed |
| [01:20:38] | wagnerrp: | so instead of tens of thousands of inserts against a file backed table, there is only one |
| [01:20:39] | danielk22: | A lot of the DD action takes place in temp tables, which are by default in /tmp, which is a very fast RAM disk with no barrier on many distros.. |
| [01:22:17] | wagnerrp: | if thats the case, it seems like the program table should only be inconsistent for all of a couple seconds as the processed data is sideloaded in |
| [01:28:33] | danielk22: | wagnerrp: I think you've pretty much described the way it works now. It's very fast when the stars are aligned, but they aren't always and what takes seconds optimally can take over an hour on a system that otherwise runs just fine. |
| [01:30:15] | danielk22: | I should not that my thoughts about needing to shut down mythbackend are out-dated.. I don't really need to with my DB on an SSD and a very fast /tmp.. |
| [01:30:22] | danielk22: | s/not/note/ |
| [01:33:43] | wagnerrp: | so its more having to deal with relying on the distro to set the proper database configuration? |
| [01:36:38] | taylorr: | danielk22: so am I being mean and hurtful to SD by running --refresh-today before primetime each day? |
| [01:36:51] | danielk22: | wagnerrp: I've yet to meet a distro with a good mysql config out of the box. :) |
| [01:37:39] | danielk22: | taylorr: No not at all, but you might possibly lose a recording or get some funky behavior if you try to start a recording while that runs. |
| [01:37:42] | wagnerrp: | so were back to the embedded mysql 'solution' to all our woes... |
| [01:38:48] | taylorr: | danielk22: in your opinion and from a users perspective what is the best way to guarantee you have the latest listings before primetime in the event of last minute schedule changes by the networks? |
| [01:38:55] | danielk22: | wagnerrp: that won't solve the performance issue if the directories the embedded mysql sits on is on an extents based filesystem like ext4, XFS, or jfs. |
| [01:40:27] | ** wagnerrp wonders if that makes freebsd/ufs/softupdates a better mythtv system than linux... ** | |
| [01:40:29] | wagnerrp: | :) |
| [01:40:36] | danielk22: | taylorr: --refresh-today run between 2pm and 8pm or --dd-grab-all But both one can cause problems when run today — by default mythfilldatabase does not refresh the curret days listings. |
| [01:41:31] | taylorr: | why would you want to run --dd-grab-all over --refresh-today? |
| [01:44:08] | danielk22: | taylorr: To get better data for tomorrow. It can effect recordings if say something is available today and tomorrow in yesterday's listings, but only today in todays listings. If both days are updated then MythTV won't erroneously decide to record it tomorrow instead of today for the sake of a less important show. |
| [01:44:37] | taylorr: | ok, makes sense |
| [01:45:17] | danielk22: | taylorr: But there is a downside to --dd-grab-all, it is more likely to break an in progress or just about to start recording. |
| [01:49:18] | taylorr: | danielk22: the v4l guys are requiring me to qualify the picture control changes based on firmware version – I still think we should just use the new values that work on the latest – no one has any evidence that picture controls have ever worked |
| [01:50:21] | taylorr: | AFAIK, there is no method to determine the firmware version of the hdpvr |
| [01:51:15] | taylorr: | (by an appliaction like mythtv) |
| [01:53:34] | reynaldo (reynaldo!~rverdejo@pc-147-56-101-190.cm.vtr.net) has quit (Read error: Connection reset by peer) | |
| [01:53:49] | reynaldo (reynaldo!~rverdejo@pc-147-56-101-190.cm.vtr.net) has joined #mythtv | |
| [01:56:51] | danielk22: | taylorr: I believe we can query the driver version, but not the firmware version. |
| [01:57:40] | danielk22: | I think if you get stoth or krufty from Hauppauge, or janneg you back you up then you will encounter less resistance. |
| [01:58:20] | sphery: | but the only reason --dd-grab-all is more likely to cause problems is due to having a longer period during which data is missing (only due to larger amount of data being processed)... But, since we start inserting data from the beginning of today, now's data goes in first, so it's probably a much smaller time than most realize, right? |
| [01:58:42] | taylorr: | danielk22: I don't think it will be hard to get it committed – knowing the driver version doesn't really tell us anything |
| [01:59:28] | sphery: | granted, that may still affect reschedules--without future reruns showing--for those with reschedmovehigher... but still, for just-about-to-start recordings... |
| [02:00:15] | sphery: | taylorr: and, the thinking was that if you're going to run mfdb to get today's data between 2pm and 8pm, anyway, and ignore the suggested run time, you might as well just get all your data and, therefore, only run mfdb one time per day, anyway |
| [02:01:00] | taylorr: | sphery: gotcha, thanks |
| [02:02:34] | danielk22: | sphery: longer period data is missing + longer time it is hitting the DB hard.. but if it is happening when nothing is recording and no one is watching anything... |
| [02:03:40] | sphery: | ah, yeah, forgot that the I/O issues may cause problems for some |
| [02:06:02] | jpabq: | taylorr, danielk22, the driver reports the firmware version when the driver is loaded: "hdpvr 6–1:1.0: firmware version 0x15 dated Jun 17 2010 09:26:53" |
| [02:07:01] | jpabq: | So, obviously, the driver has access to that info. |
| [02:09:27] | taylorr: | jpabq: yep, but an application such as ourselves doesn't have it via the v4l API |
| [02:10:17] | jpabq: | True, but why would the v4l guys care about it at the app level? |
| [02:10:24] | taylorr: | jpabq: did you catch the conversation earlier about picture controls being normalized and relative to the min/max/default of the driver |
| [02:11:14] | taylorr: | jpabq: they shouldn't, I'm just mentioning it because if we want to override the values in MythTV then we have no way to determine which values we should use |
| [02:12:17] | jpabq: | Yes. Although I don't really understand what happens when 32768 == 25%, then what does 1024 equal, or 65000 equal? Is it a linear scale, or not? |
| [02:12:56] | jpabq: | taylorr, like you said, previous firmware ignores those values, so it doesn't matter. |
| [02:13:23] | taylorr: | jpabq: right but the linuxtv guys want me to based the values off of firmware version to be safe |
| [02:14:01] | jpabq: | Okay. I appreciate you taking care of that. |
| [02:14:37] | taylorr: | jpabq: I think your patch from last night should be all that's needed for this |
| [02:14:46] | jpabq: | I hope so. |
| [02:28:03] | taylorr: | jpabq: when you run modinfo hdpvr what version does it give you? |
| [02:29:42] | jpabq: | It does not list a version, unless you mean: "vermagic: 2.6.35.14–97.fc14.x86_64 SMP mod_unload" or "srcversion: B900EE1C8C22D2BAE7E5F93" |
| [02:41:39] | taylorr: | jpabq: thanks, the newer hdpvr driver has a version number – I'll probably get them to update it |
| [02:41:47] | taylorr: | it's at 0.2.1 currently |
| [02:55:08] | taylorr: | danielk22: here's a dtvrecorder parser update -> http://mythtv.pastebin.ca/2092068 |
| [03:10:30] | map7_ (map7_!~map7@110.140.125.142) has joined #mythtv | |
| [03:19:58] | map7_ (map7_!~map7@110.140.125.142) has quit (Ping timeout: 245 seconds) | |
| [04:28:25] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [04:50:07] | Rubin (Rubin!~rubin@cronor.simplanet.org) has joined #mythtv | |
| [04:50:25] | Rubin (Rubin!~rubin@cronor.simplanet.org) has left #mythtv ("Leaving") | |
| [04:52:25] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [05:14:05] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq_) | |
| [05:58:12] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [06:09:13] | saintdev (saintdev!~saint@unaffiliated/saintdev) has joined #mythtv | |
| [06:30:35] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 255 seconds) | |
| [07:15:22] | willcooke (willcooke!~will@willcooke.plus.com) has joined #mythtv | |
| [07:15:24] | willcooke (willcooke!~will@willcooke.plus.com) has quit (Changing host) | |
| [07:15:25] | willcooke (willcooke!~will@canonical/willcooke) has joined #mythtv | |
| [07:20:47] | markk (markk!~mark@host109-150-240-46.range109-150.btcentralplus.com) has quit (Quit: Ex-Chat) | |
| [07:26:10] | markk (markk!~mark@host109-150-240-46.range109-150.btcentralplus.com) has joined #mythtv | |
| [07:30:20] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [09:08:50] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [10:05:03] | mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:59] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:22:27] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv | |
| [10:22:27] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [10:22:27] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [10:47:04] | jmartens1 (jmartens1!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [10:47:04] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Read error: Connection reset by peer) | |
| [10:47:12] | jmartens1 (jmartens1!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Read error: Connection reset by peer) | |
| [11:45:03] | MythBuild_: | build #941 of master-debian-stable-64bit is complete: Failure [failed git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/941 blamelist: Nicolas Riendeau <nriendeau@mythtv.org > |
| [12:04:07] | reynaldo (reynaldo!~rverdejo@pc-147-56-101-190.cm.vtr.net) has quit (Ping timeout: 258 seconds) | |
| [12:05:42] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [12:06:03] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [12:32:30] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [12:45:07] | stuarta: | MythBuild_: force build master-debian-stable-64bit now |
| [12:45:08] | MythBuild_: | build forced [ETA 12m57s] |
| [12:45:08] | MythBuild_: | I'll give a shout when the build finishes |
| [12:54:08] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 245 seconds) | |
| [12:57:39] | MythBuild_: | build #942 of master-debian-stable-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/942 |
| [13:15:38] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [13:19:55] | j-rod|afk is now known as j-rod | |
| [13:21:38] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:24:05] | cocoa117 (cocoa117!~cocoa117@wk-29-198.guest.rdg.ac.uk) has joined #mythtv | |
| [13:26:58] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [13:31:39] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [13:55:33] | cocoa117 (cocoa117!~cocoa117@wk-29-198.guest.rdg.ac.uk) has quit (Quit: Leaving) | |
| [14:11:52] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [14:11:52] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [14:11:52] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [14:27:38] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [14:35:28] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Remote host closed the connection) | |
| [14:35:34] | stuarta (stuarta!~stuarta@metis.squashedfrog.net) has joined #mythtv | |
| [14:39:18] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [14:39:18] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [14:39:18] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [14:40:01] | stuarta (stuarta!~stuarta@metis.squashedfrog.net) has quit (Changing host) | |
| [14:40:01] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [14:42:28] | danielk22: | taylorr: What is the purpose of that patch? To me it looks like it is just obscuring the type of progressive_sequence and adding two more malloc's and frees without any benefit to offset the added complexity. + the new variables are not tagged with an underscore like the rest of the member variables in that class. |
| [14:45:15] | taylorr: | danielk22: the purpose is that we need to store pc->progressive_sequence persistently because that is contained in a preceding packet |
| [14:46:05] | taylorr: | I went ahead and used the libav struct to make it easier to extend the parser functionality in the future |
| [14:46:44] | wagnerrp: | stuartm: any idea what that spam was about last night? |
| [14:46:57] | wagnerrp: | there were three other attempts before that one got through |
| [14:47:57] | wagnerrp: | all on the same IP address |
| [14:48:04] | wagnerrp: | nothing else in the logs seemingly related to it |
| [14:48:31] | taylorr: | danielk22: why are the member variables tagged with an underscore? |
| [14:48:36] | danielk22: | Ok, just adding an "int _progressive_sequence;" variable to the class is much easier to read. If we start using the the ffmpeg parser then we can add the extra ParseContext1 variable. |
| [14:49:33] | danielk22: | taylorr: It's historic. They really should be tagged with "m_" but that wasn't part of the coding standard when the code was written. If you want to change it in a separate patch feel free. |
| [14:50:31] | danielk22: | Or do you mean why do we tag variables at all? |
| [14:51:25] | taylorr: | ok... I was used to the m_ just not the _ |
| [14:52:16] | taylorr: | danielk22: then do you want me just add an "int _progressive_sequence" instead? |
| [14:53:03] | danielk22: | yeah.. if we start to use more of the ffmpeg parse we can switch, but there are some negatives to using ffmpeg structs. |
| [14:53:12] | taylorr: | I might need more variables if you want me to add support for pts |
| [14:53:33] | taylorr: | I could just copy the struct definition directly into our code |
| [14:53:51] | taylorr: | I'll just go with the single int for now |
| [14:54:23] | taylorr: | and I did comment why pc was need, "// used for storing sequence header information" |
| [14:55:21] | danielk22: | Right, but I meant why is it needed when a basic type will do. |
| [14:56:11] | taylorr: | ok, I'll make the changes and commit |
| [14:59:53] | danielk22: | cool. FYI I have a patch that does some PTS extraction in mythutil --pidprinter.. I didn't add anything to the recorder yet, but I don't have a use for it there yet.. |
| [15:18:34] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [15:58:09] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:06:12] | superm1 (superm1!~superm1@ubuntu/member/superm1) has joined #mythtv | |
| [16:15:53] | andreax (andreax!~andreaz@p4FC1219F.dip.t-dialin.net) has joined #mythtv | |
| [16:21:56] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [16:24:21] | andreax (andreax!~andreaz@p4FC1219F.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [17:02:00] | willcooke (willcooke!~will@canonical/willcooke) has quit (Quit: We will learn more of his wisdom later) | |
| [17:05:43] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [17:06:03] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [17:11:06] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [17:11:06] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [17:11:06] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [17:12:29] | taylorr: | jpabq: sorry to inform you but I had to revert back to 0x15 – I didn't think it was possible to make the HD-PVR more flaky but hauppauge managed to make it worse |
| [17:13:04] | taylorr: | really though, how many products have a "killer" companion for sale :) |
| [17:35:32] | andreax (andreax!~andreaz@p4FC1219F.dip.t-dialin.net) has joined #mythtv | |
| [17:38:57] | dcg_ (dcg_!~tv@dsl-58-6-5-175.wa.westnet.com.au) has quit (Ping timeout: 255 seconds) | |
| [17:39:12] | dcg_ (dcg_!~tv@58.6.5.175) has joined #mythtv | |
| [18:11:37] | Chutt (Chutt!~ijr@cpe-76-190-198-203.neo.res.rr.com) has joined #mythtv | |
| [18:14:35] | stoffel (stoffel!~quassel@p57B4BB1F.dip.t-dialin.net) has joined #mythtv | |
| [18:23:01] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [18:28:26] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has joined #mythtv | |
| [18:35:02] | SteveGoodey (SteveGoodey!~steve@host86-186-250-139.range86-186.btcentralplus.com) has joined #mythtv | |
| [18:53:12] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [19:15:29] | xavierh (xavierh!~chatzilla@178.110.117.148) has joined #mythtv | |
| [19:17:32] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has joined #mythtv | |
| [19:20:10] | xavierh (xavierh!~chatzilla@178.110.117.148) has quit (Ping timeout: 258 seconds) | |
| [19:29:42] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [19:30:00] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has joined #mythtv | |
| [19:44:05] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [20:11:18] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has joined #mythtv | |
| [20:14:17] | xavierh (xavierh!~chatzilla@212.183.140.63) has joined #mythtv | |
| [20:20:17] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [20:33:04] | stoffel (stoffel!~quassel@p57B4BB1F.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [20:36:45] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: If I had to promote the iPhone 4GS I'd die too.) | |
| [20:43:57] | SteveGoodey (SteveGoodey!~steve@host86-186-250-139.range86-186.btcentralplus.com) has quit (Remote host closed the connection) | |
| [20:51:25] | JEDIDIAH__ (JEDIDIAH__!~jedi@76.185.75.39) has quit (Quit: Ex-Chat) | |
| [21:13:11] | j-rod is now known as j-rod|afk | |
| [21:17:24] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [21:17:24] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [21:17:24] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:30:58] | xavierh (xavierh!~chatzilla@212.183.140.63) has quit (Remote host closed the connection) | |
| [21:32:35] | xavierh (xavierh!~chatzilla@212.183.140.63) has joined #mythtv | |
| [21:52:20] | brettser (brettser!~quassel@83.71.20.147) has joined #mythtv | |
| [21:53:28] | brettser (brettser!~quassel@83.71.20.147) has quit (Remote host closed the connection) | |
| [22:03:12] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [22:04:03] | jpabq_: | taylorr: serious bummer. |
| [22:09:42] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (*.net *.split) | |
| [22:09:42] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (*.net *.split) | |
| [22:09:42] | jedix (jedix!~jedix@24-246-5-37.cable.teksavvy.com) has quit (*.net *.split) | |
| [22:09:42] | saintd3v (saintd3v!~saint@unaffiliated/saintdev) has quit (*.net *.split) | |
| [22:09:42] | eugo (eugo!~eugo@unaffiliated/eugo) has quit (*.net *.split) | |
| [22:09:42] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (*.net *.split) | |
| [22:09:43] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) has quit (*.net *.split) | |
| [22:09:43] | gpd (gpd!~gpd@www.grahamdavies.net) has quit (*.net *.split) | |
| [22:10:10] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv | |
| [22:10:10] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [22:10:10] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [22:10:22] | mrec (mrec!~markus@sundtek.de) has quit (Ping timeout: 258 seconds) | |
| [22:10:47] | mrec (mrec!~markus@sundtek.de) has joined #mythtv | |
| [22:10:48] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds) | |
| [22:11:19] | jpabq is now known as 14WAALV0M | |
| [22:11:23] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [22:11:23] | jedix (jedix!~jedix@24-246-5-37.cable.teksavvy.com) has joined #mythtv | |
| [22:11:23] | gpd (gpd!~gpd@www.grahamdavies.net) has joined #mythtv | |
| [22:11:23] | saintd3v (saintd3v!~saint@unaffiliated/saintdev) has joined #mythtv | |
| [22:11:23] | eugo (eugo!~eugo@unaffiliated/eugo) has joined #mythtv | |
| [22:11:23] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv | |
| [22:11:23] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) has joined #mythtv | |
| [22:11:26] | gpd (gpd!~gpd@www.grahamdavies.net) has quit (Ping timeout: 276 seconds) | |
| [22:11:51] | gpd (gpd!~gpd@www.grahamdavies.net) has joined #mythtv | |
| [22:11:52] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [22:14:15] | andreax (andreax!~andreaz@p4FC1219F.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [22:17:05] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq) | |
| [22:17:22] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [22:27:25] | xavierh (xavierh!~chatzilla@212.183.140.63) has quit (Ping timeout: 258 seconds) | |
| [22:42:08] | Captain_Murdoch: | danielk22, not sure if you noticed or not, but your SetChild() is the same as the existing SetParentOf(). I'd be in favor of removing SetParentOf, but that'd be wagnerrp's call. |
| [22:44:12] | wagnerrp: | honestly, i had preferred the ---Of() methods |
| [22:44:36] | wagnerrp: | just because if only conceptually, it meant you were setting a behavior of that object, rather than another object |
| [22:54:39] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) has joined #mythtv | |
| [23:21:37] | Captain_Murdoch: | since it's a doubly linked 'list', then both are true. you're either saying 'this is my child' or 'this is my parent' and then you fixup all the links later right? some things are impossible to use with the SetChildOf if the child is in one of the helpers like AddRecording(). |
| [23:22:28] | Captain_Murdoch: | so in that case we have to use SetParentOf but that reminds me of being called "Olivia's dad" when one of my daughter's kids sees me. :) |
| [23:22:49] | Captain_Murdoch: | I'm fine with either. |
| [23:26:50] | wagnerrp: | in theory, fix up all the links later |
| [23:27:09] | wagnerrp: | but there are some issues if you try to use the AllowOneOf with pre-existing arguments |
| [23:27:29] | wagnerrp: | with one, everything works... with two or more, it doesnt |
| [23:31:03] | wagnerrp: | thats something i should get fixed before 0.25 |
| [23:31:16] | wagnerrp: | i might rework that routine this weekend |
| [23:49:53] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.