| Thursday, April 18th, 2013, 00:10 UTC | ||
| [00:10:05] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:18:56] | dekarl (dekarl!~dekarl@p4FE85205.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [00:22:00] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has quit (Ping timeout: 252 seconds) | |
| [00:25:21] | dekarl (dekarl!~dekarl@p4FCEF5AE.dip.t-dialin.net) has joined #mythtv | |
| [00:25:33] | humbug (humbug!~humbug@CPE0026b9f0228d-CM00159a025a8c.cpe.net.cable.rogers.com) has quit (Ping timeout: 240 seconds) | |
| [00:35:19] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [00:39:17] | humbug (humbug!~humbug@CPE0026b9f0228d-CM00159a025a8c.cpe.net.cable.rogers.com) has joined #mythtv | |
| [00:46:09] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has joined #mythtv | |
| [00:46:09] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has quit (Changing host) | |
| [00:46:09] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has joined #mythtv | |
| [00:48:08] | humbug is now known as humbug__ | |
| [00:48:11] | Narr0wM1nd (Narr0wM1nd!1805ace6@gateway/web/freenode/ip.24.5.172.230) has joined #mythtv | |
| [00:51:42] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has quit (Ping timeout: 252 seconds) | |
| [01:00:39] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has joined #mythtv | |
| [01:00:39] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has quit (Changing host) | |
| [01:00:39] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has joined #mythtv | |
| [01:28:54] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [01:46:08] | humbug__ (humbug__!~humbug@CPE0026b9f0228d-CM00159a025a8c.cpe.net.cable.rogers.com) has quit (Ping timeout: 252 seconds) | |
| [02:26:04] | jya: | danielk22: any progress on the IPTV recorder doc? |
| [03:01:58] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [03:02:20] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [03:03:33] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [03:03:53] | unforgiven512 (unforgiven512!~unforgive@65-78-110-218.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Ping timeout: 240 seconds) | |
| [03:05:13] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [03:05:54] | tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [03:07:00] | tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has joined #mythtv | |
| [03:11:06] | unforgiven512 (unforgiven512!~unforgive@65-78-110-218.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [03:20:56] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [03:22:16] | wewewe (wewewe!~AndChat38@ool-435407ad.dyn.optonline.net) has joined #mythtv | |
| [03:37:16] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [03:49:45] | Narr0wM1nd (Narr0wM1nd!1805ace6@gateway/web/freenode/ip.24.5.172.230) has quit (Quit: Page closed) | |
| [03:59:36] | superm1 (superm1!uid4318@gateway/web/irccloud.com/x-erzunmnrushckule) has quit (Ping timeout: 245 seconds) | |
| [04:01:38] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 256 seconds) | |
| [04:02:35] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:12:54] | DJDan (DJDan!~djdan@115-64-177-188.static.tpgi.com.au) has joined #mythtv | |
| [04:45:01] | jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has quit (Ping timeout: 245 seconds) | |
| [05:25:28] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [05:25:28] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [05:25:28] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [05:59:33] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [06:03:02] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:10:03] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:10:23] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [06:15:10] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Read error: Connection reset by peer) | |
| [06:20:13] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:21:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [06:24:31] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [06:25:07] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds) | |
| [06:29:52] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [06:30:52] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [06:39:08] | Sharky112065 is now known as Sharky-Sleep | |
| [07:14:25] | dekarl (dekarl!~dekarl@p4FCEF5AE.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [07:14:54] | dekarl (dekarl!~dekarl@p4FCEF5AE.dip.t-dialin.net) has joined #mythtv | |
| [07:33:29] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7ce4:bce9:d525:7476) has joined #mythtv | |
| [08:13:44] | mickey62ga (mickey62ga!~mick@108.60.131.11) has quit (Remote host closed the connection) | |
| [08:14:03] | mickey62ga (mickey62ga!~mick@108.60.131.11) has joined #mythtv | |
| [08:31:19] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [08:33:00] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:41:42] | paul-h (paul-h!~Paul@176.252.19.2) has joined #mythtv | |
| [09:43:53] | mickey62ga (mickey62ga!~mick@108.60.131.11) has quit (Ping timeout: 245 seconds) | |
| [09:44:08] | mickey62ga (mickey62ga!~mick@108.60.131.11) has joined #mythtv | |
| [09:52:06] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [09:53:23] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [10:28:07] | paul-h: | Isn't this message on the Channel Recording Priorities screen wrong? https://github.com/MythTV/mythtv/blob/master/ . . . -ui.xml#L640 |
| [10:29:52] | stuartm: | definitely, it's a copy/paste error |
| [10:34:16] | paul-h: | Any ideas on what it should be |
| [10:35:15] | AndChat|383616 (AndChat|383616!~AndChat38@ool-435407ad.dyn.optonline.net) has joined #mythtv | |
| [10:35:32] | paul-h: | Don't suppose we can change the textarea's name without breaking a few themes |
| [10:37:38] | wewewe (wewewe!~AndChat38@ool-435407ad.dyn.optonline.net) has quit (Ping timeout: 245 seconds) | |
| [10:43:17] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [10:47:19] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv | |
| [10:49:33] | joki (joki!~joki@p54865F8F.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [10:54:46] | joki (joki!~joki@p54865962.dip.t-dialin.net) has joined #mythtv | |
| [11:31:09] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [11:43:23] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [12:01:29] | danielk22: | jya: Nope. It's on my mind, but we just pivoted last week at work so I'm getting home pretty tired. |
| [12:10:46] | stuartm: | paul-h: message should be 'no channels defined' essentially, the textarea name is a problem, but we could change the code to look for both 'norecordings_info' and 'no_channels_warning' (or whatever we want to call it) |
| [12:55:21] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [12:59:54] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [13:01:01] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [13:25:03] | mickey62ga (mickey62ga!~mick@108.60.131.11) has quit (Ping timeout: 276 seconds) | |
| [13:25:28] | mickey62ga (mickey62ga!~mick@108.60.131.11) has joined #mythtv | |
| [14:24:59] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 256 seconds) | |
| [14:36:15] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [14:51:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [15:21:39] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 256 seconds) | |
| [15:29:42] | Sharky-Sleep is now known as Sharky112065 | |
| [15:33:51] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [15:42:44] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:10:08] | AndChat|383616 (AndChat|383616!~AndChat38@ool-435407ad.dyn.optonline.net) has quit (Ping timeout: 245 seconds) | |
| [16:27:23] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [16:40:23] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7ce4:bce9:d525:7476) has quit (Read error: Connection reset by peer) | |
| [16:52:45] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has joined #mythtv | |
| [16:52:45] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has quit (Changing host) | |
| [16:52:46] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:54:16] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [16:56:02] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has joined #mythtv | |
| [16:56:02] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has quit (Changing host) | |
| [16:56:02] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:56:16] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:56:47] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [17:01:49] | humbug (humbug!~humbug@178-164-247-232.pool.digikabel.hu) has joined #mythtv | |
| [17:07:31] | jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has joined #mythtv | |
| [17:09:37] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has joined #mythtv | |
| [17:09:37] | NightMonkey (NightMonkey!~NightrMon@nat1.sp.collab.net) has quit (Changing host) | |
| [17:09:38] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:12:11] | mickey6637 (mickey6637!~mick@108.60.131.13) has joined #mythtv | |
| [17:14:00] | stichnot (stichnot!~stichnot@216.239.45.87) has joined #mythtv | |
| [17:14:00] | stichnot (stichnot!~stichnot@216.239.45.87) has quit (Changing host) | |
| [17:14:00] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:14:30] | mickey62ga (mickey62ga!~mick@108.60.131.11) has quit (Ping timeout: 276 seconds) | |
| [17:19:55] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [17:21:13] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [17:23:22] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [17:38:38] | mickey62ga (mickey62ga!~mick@108.60.131.12) has joined #mythtv | |
| [17:38:58] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Read error: Connection reset by peer) | |
| [17:39:18] | mickey6637 (mickey6637!~mick@108.60.131.13) has quit (Ping timeout: 272 seconds) | |
| [17:39:54] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [17:39:59] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [17:44:27] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Remote host closed the connection) | |
| [17:48:34] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [17:54:09] | mickey6637 (mickey6637!~mick@CPEbcc810003195-CMbcc810003192.cpe.net.cable.rogers.com) has joined #mythtv | |
| [17:55:14] | tafy (tafy!~sebastien@pool-98-116-240-153.nycmny.fios.verizon.net) has joined #mythtv | |
| [17:55:24] | mickey62ga (mickey62ga!~mick@108.60.131.12) has quit (Ping timeout: 264 seconds) | |
| [17:56:34] | mickey62ga (mickey62ga!~mick@108.60.131.14) has joined #mythtv | |
| [17:58:36] | mickey6637 (mickey6637!~mick@CPEbcc810003195-CMbcc810003192.cpe.net.cable.rogers.com) has quit (Ping timeout: 258 seconds) | |
| [18:55:16] | tafy (tafy!~sebastien@pool-98-116-240-153.nycmny.fios.verizon.net) has quit (Quit: tafy) | |
| [19:06:05] | superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv | |
| [19:22:09] | gigem: | I have some general services questions and some specific ones regarding #11495. It appears we use an Add/Update/Remove pattern for servie calls. Should Add and Update check and enforce that the underlying entity doesn't or does already exist, respectively? For example, should UpdateDbChannel fail if the specified channel doesn't already exist or should it silently create it as needed? |
| [19:22:09] | ** MythLogBot http://code.mythtv.org/trac/ticket/11495 ** | |
| [19:22:14] | gigem: | Regarding #11495, the patch should use UpdateRecordSchedule() instead of EditRecordSchedule(), right? More importantly, the existing AddRecordSchedule() is very buggered! It first tries to find a matching program for the specified chanid and starttime and then tries to load the rule for it. This will only work if there is a matcing program for the chanid/starttime and that program is not currently covered |
| [19:22:14] | ** MythLogBot http://code.mythtv.org/trac/ticket/11495 ** | |
| [19:22:17] | gigem: | by a recording rule and has the following consequences. First, there is no way to create an override rule, though, that would probably be a fairly simple fix. Second, there is no way to create a manual rule because you can't specify the title, subtitle or endtimes. Third, there is no way to create a search or custom rule because you can't specify the title, subtitle(extra tables) or description(sql). |
| [19:28:52] | stuartm: | gigem: personally I would not have 'update' perform insertion into the DB, it's not implied by the name of the method and could unintended behaviour e.g. a third party developer takes a shortcut assuming that an update will fail if the subject doesn't exist and so they don't check for it's presence before hand |
| [19:30:03] | stuartm: | or even simpler, the third party app mangles a channel name/callsign/other somehow and instead of updating entries it inserts dozens/hundreds of new bogus entries |
| [19:32:08] | stuartm: | I think we should take as many steps as possible to ensure data integrity isn't comprised by a badly written external application, so duplicate checking, input validation would all be worthwhile |
| [19:32:23] | sphery: | +1 on defining some rules for these behaviors... I don't think we've done so, yet. I like stuartm's approach (and the one I think you were championing) |
| [19:32:53] | sphery: | and, yes, we need to ensure data integrity--that's the main problem with our other "legacy" protocols/api's |
| [19:34:37] | stuartm: | s/could unintended/could cause unintended/ – brain's ahead of my fingers again, or is it the other way around? |
| [19:51:58] | gigem: | stuartm, sphery: I agree on enforcing the semantics of Add/Update/Remove, but I wanted to be sure that was the intent. The other issues regarding Add/UpdateRecordSchedule need more thought. I'd really like to hide some of the implementation details if possible. For example, perhaps there should be additional AddOverrideRecordSchedule, AddSearchRecordSchedule, AddCustomSearchRecordSchedule and |
| [19:52:00] | gigem: | AddManualRecordSchedule so the client doesn't need to know things like the parent rule id or custom SQL goes in the description field, etc. |
| [19:52:50] | stuartm: | I can't speak to the intent ... dblain ^^ |
| [19:53:48] | sphery: | yes, hiding implementation details is critical... Otherwise, it has all the problems of our previous api's/protocols |
| [19:54:23] | sphery: | and especially with recording schedule creation--which is extremely complex (thus the flawed implementation we have) |
| [19:57:31] | stuartm: | ideally once complete the API shouldn't really ever change, I don't think that's possible but that's the goal, but hiding the implementation and keeping the API relatively simple would make that much easier |
| [19:58:00] | sphery: | as a matter of fact, I hope whoever looks at the service api recorded markup patch ( stichnot ?) at #11491 ensures that it's hiding as many implementation details as possible (i.e. a client shouldn't have to know that MARK_CUT_END = 6 or whatever |
| [19:58:00] | ** MythLogBot http://code.mythtv.org/trac/ticket/11491 ** | |
| [19:59:14] | stuartm: | if you start getting too specific with the API e.g. AddSearchRecordSchedule then it's that much harder to drop/re-invent 'search rules' later on without an API version change |
| [19:59:35] | sphery: | and, even whether clients should have to deal with marks the way we use them (if it's byte locations and clients request the recording file by bytes, that makes sense, but if they're requesting/playing by time...) |
| [20:00:49] | stuartm: | you also risk undermining the appeal of the API by cluttering it with dozens of methods which could or perhaps should be handled instead through arguments to just one AddSchedule method |
| [20:09:00] | stuartm: | fwiw, I have no great interest/investment in the API, it's nice to have but pretty low on my radar so I'll take no offence if my opinions on it are ignored |
| [20:14:36] | humbug (humbug!~humbug@178-164-247-232.pool.digikabel.hu) has quit (Ping timeout: 264 seconds) | |
| [20:16:56] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [20:19:39] | danielk221 (danielk221!~danielk@exchange.wgen.net) has quit (Read error: Operation timed out) | |
| [20:29:18] | tgm4883: | I've been making a mythtv internals diagram and was hoping to get some input on A) how it looks (correctness), and B) the parts I'm missing https://creately.com/diagram/hfo8sxpf1 |
| [20:30:40] | tgm4883: | sphery has been a good help in getting some of this done, but I don't want to take all his time on this |
| [20:30:44] | tgm4883: | I'm hoping to add this to http://www.mythtv.org/wiki/Executive_Overview |
| [20:32:18] | stuartm: | heh, mythlogserver makes that diagram look much more complicated than it really is |
| [20:33:02] | stuartm: | I wonder whether we'll even have mythlogserver when danielk22 is finished with his re-write |
| [20:33:06] | tgm4883: | yea, the diagram looks complicated |
| [20:33:30] | sphery: | the whole point of mythlogserver was to allow getting logs up to and through application crashes |
| [20:35:13] | sphery: | I think mythlogserver is nice, but it may be triggering issues--like rsyslog has rate-limiting that defaults to dropping messages after 200/5s from a single process, which I'd guess we could easily hit with mythlogserver writing log messages from mythbackend + mythfrontend + a slew of mythpreviewgens that were started when the user went to Watch Recordings + any running mythcommflag and mythtranscode jobs ... |
| [20:35:42] | tgm4883: | stuartm, that said, it's not like mythtv isn't complicated anyway. It's just necessarily complicated in order to do what it does |
| [20:35:55] | sphery: | The main problem we're having, now, is that it requires a very specific configuration (that users can't seem to get right) or applications will spawn too many copies of it |
| [20:35:56] | stuartm: | sphery: well that was always possible before because log entries were written in real time, not buffered as they are now, at some point during the creation of mls it was realised that the rate limiting/buffering that had been added caused a loss of log detail if the app crashed so further work/code when into mls to prevent that |
| [20:36:11] | sphery: | stuartm: the "through the crash" wasn't possible |
| [20:37:06] | sphery: | i.e. at one point, at least, it was capturing stack traces (like gdb stack traces--not the glibc garbage) |
| [20:37:11] | stuartm: | sphery: well at the instant of the crash no more log entries are being produced, so it doesn't matter if we keep logging? Except maybe to print a 'We've crashed' entry |
| [20:37:42] | sphery: | anyway, my main concern right now is that the "start when needed and shut down after 5 minutes of inactivity" doesn't work |
| [20:37:52] | stuartm: | sphery: interesting, never saw that in action or heard of it |
| [20:38:04] | sphery: | so I'd like to change it to be started once and just run forever, and have it be started explicitly |
| [20:38:51] | dblain: | gigem, sphery, stuartm: I haven't looked at MythTV code in a long time (wish I had time...), so my opionion doesn't mean much these days. Someone else started to standardize on add/update/remove symantec's. When I created the Service API, the vision I had was very much what stuartm just described. I understand the need for a maintenance/setup type interface that add/update/remove provides, |
| [20:38:51] | dblain: | but I don't think end users of the API should need to use them to provide a rich UI. Other higher level services/methods should be created for that use. |
| [20:39:32] | sphery: | and I'd like to do that by creating mythtvd (MythTV Daemon Runner), that distros would start with a start script, and it would start up mythlogserver, then check to see if the system is configured as a backend (i.e. has tuners) and if so, starts mythbackend, if not, then it checks to see if it's configured to run jobs and if so starts mythjobqueue, and it checks to see if the system is configured to host files and if so starts mythmediaserver ... |
| [20:39:39] | sphery: | ... and ... |
| [20:41:35] | stuartm: | sphery: it's not that I don't appreciate the hard work that went into MLS, but I never really had an issue with the old logging, it worked and it was simple, MLS is complicated and just getting more complicated as time goes on but the benefits just aren't really that tangible |
| [20:42:06] | danielk221 (danielk221!~danielk@ip66-104-227-162.z227-104-66.customer.algx.net) has joined #mythtv | |
| [20:42:56] | tgm4883: | So what I need for this diagram are 1) What is mythtranscode, mythjobqueue, mythmediaserver, and mythpreviewgen writing to the database, 2) What is mythfrontend doing with the database, 3) what is the master backend doing with the secondary backend (and vice versa) 4) what is mythweb doing with the database and backends |
| [20:43:22] | sphery: | stuartm: I don't care what happens--other than we should not have 2 different logging apis |
| [20:43:42] | sphery: | (i.e. our logging and our "every once in a while chuck a message in the db, if the user configured db logging") |
| [20:44:05] | stuartm: | a single monolithic app for me, KISS (hate the acronym, but like the principle) |
| [20:46:18] | tgm4883: | I'm doing this because there doesn't seem to be anyone that knows (even a broad overview) what each of the parts of mythtv does. And that's not saying anything bad about anyone, just that mythtv does a lot of stuff and is a bit complicated (as any project that has been developed for 10 years would be) |
| [20:47:01] | stuartm: | sphery: I can't see the point of DB logging really, not when we're also writing to files, all it does is swamp the filesystem, it's not like we're using that information internally so why does it need to be stored in a database? |
| [20:47:08] | tgm4883: | and it changes often enough that it's hard to keep up on things when you aren't the person who changed it (see http://www.youtube.com/watch?v=FLt7dD8uJWI ) |
| [20:48:07] | tgm4883: | stuartm, well, ideally you would write to mythlogserver, then the user could determine where to log to (since mythlogserver can write to file/syslog/db) |
| [20:48:13] | sphery: | the whole idea behind db logging--before the changes and after--was to make logging information available about any host and from any host |
| [20:48:23] | sphery: | without the user having to ssh in and read some text file in a terminal or whatever |
| [20:48:47] | sphery: | it's meant as a short-term location for storing logging that's easily accessible from any system |
| [20:48:53] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [20:49:25] | sphery: | unfortunately, due to constriants in our backend web server app design and my getting busy with other stuff, we don't have a great log viewer (either in mythfrontend or backend web app) |
| [20:49:26] | danielk221 (danielk221!~danielk@ip66-104-227-162.z227-104-66.customer.algx.net) has quit (Read error: Operation timed out) | |
| [20:50:05] | tafy (tafy!~sebastien@pool-98-116-240-153.nycmny.fios.verizon.net) has joined #mythtv | |
| [20:50:08] | stuartm: | tgm4883: I'd guess we all know, to reasonable degree, what is happening and where, but not everyone has the patience to explain it :) That's why sphery is so remarkable, he's not only a walking encyclopaedia of all things MythTV but he has the infinite patience and generosity to share that knowledge with just about everyone |
| [20:50:11] | danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv | |
| [20:50:23] | sphery: | but we do have a nice services api that could be used to create a viewer – http://www.gossamer-threads.com/lists/mythtv/ . . . 04119#504119 |
| [20:50:37] | tgm4883: | for reference, in that video when a file changes the filename shows up in white for a few seconds (it fades away completely after a few seconds). So you can see how many files are changing and how often |
| [20:51:15] | stuartm: | sphery: if there was a log viewer in the API, then it could just have the mbe read the log file for display through html, the DB isn't really necessary |
| [20:51:43] | tgm4883: | stuartm, I'd venture that is not the case. You guys know quite a bit, but I've run into issues (or seem them happen in #mythtv-users) where a dev won't know too much about a particular thing because it's not what they work on |
| [20:51:47] | sphery: | stuartm: true--assuming there's a backend on every host or mythmediaserver or something that can access the file and make it available |
| [20:52:00] | tgm4883: | again, that isn't anything against the developer, mythtv is a complicated application |
| [20:52:01] | sphery: | but on dedicated frontends... not to mention the issues we'd likely have with permissions and ... |
| [20:52:12] | sphery: | unless you just start writing out logs to a location in a storage group |
| [20:52:59] | sphery: | but the db is nice for the filtering... The service allows filtering using any combination of the twelve parameters (see the commit I linked, above) |
| [20:53:32] | sphery: | so that you don't have to tell the user "no, you're looking at old stuff from a different process, before you fixed the problem" |
| [20:53:37] | sphery: | or whatever |
| [20:53:52] | stuartm: | tgm4883: the features of mls such as writing to any target could just as easily be in a lib shared by all apps, it's not something that having a standalone log server enables |
| [20:54:21] | sphery: | yeah, the standalone was just to catch logs up to and including and through crashes |
| [20:55:00] | tgm4883: | stuartm, true, I'm not arguing for MLS (or against it) |
| [20:55:06] | sphery: | (and there were /many/ cases where we didn't get all the log messages before mls--when doing debug logging of playback of bad streams and such--and I can find mentions of it in the IRC logs if you really want) |
| [20:55:20] | sphery: | regardless of "not buffered" |
| [20:55:22] | stuartm: | we'll see what danielk22 comes up with, until then there are much more important tasks to argue over :) |
| [20:55:58] | sphery: | but also, it seems like it's nice to be able to have log messages written out, and not have the log message writing slow the application/prevent it from working |
| [20:56:24] | tgm4883: | stuartm, I'm just trying to get an accurate representation of the inner workings of mythtv (even a simplified representation). I think it will help troubleshooting efforts if we knew how things were supposed to work together |
| [20:56:31] | stuartm: | sphery: I'll take your word for it, I don't understand how that could be possible, but if you say it happened, it happened ;) |
| [20:56:41] | sphery: | anyway, as long as we don't come up with VERBOSE(<whatever>); DBLOG(<something else>);, I don't care where we go with it |
| [20:56:52] | sphery: | I just think we need to fix the startup/shutdown issue |
| [20:57:02] | sphery: | meaning don't try to shut down after 5min |
| [20:57:08] | sphery: | and have it started explicitly |
| [20:57:18] | sphery: | as long as we have a separate process that is |
| [20:57:32] | stuartm: | tgm4883: I'll try to find some time to look at the diagram and offer some feedback, but I make no promises |
| [20:57:55] | tgm4883: | stuartm, that is all I can ask for :) |
| [20:58:56] | sphery: | tgm4883: and I recommend sending it to the mailing list, too, to get more eyes on (and give people more time to look/think/respond) |
| [20:59:10] | tgm4883: | sphery, will do |
| [21:01:16] | tafy: | gigem, stuartm, sphery, I created the 2 patches 11491 11495 (edit recording schedules), I was reading through what you mentioned earlier; should I change the semantics to Update as opposed to Edit or should I scrap it completely because the approach is wrong ? |
| [21:01:23] | stuartm: | sphery: I guess whatever happens I can still redirect console output to a file, and that's really all I'll ever need from logs :) I could just disable mythlogserver entirely and never notice it's absence |
| [21:05:29] | stuartm: | right after that I'll probably re-write mbe in a couple hundred lines of perl and become a true grumpy old man |
| [21:07:12] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:07:28] | stuartm: | <grumpy old man>in my day one application would do everything!</grump old man> |
| [21:11:01] | paul-h: | I'd love to see the old simple logging to come back and mythlogserver to die a fiery death. It's overkill for what we need IMHO |
| [21:11:06] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [21:29:38] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Do not kick me when I'm down, cause when I get up I'm going to kick your ass.) | |
| [21:39:58] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [21:40:25] | paul-h: | stuartm: any ideas what's happening to the layout of the grid in the MythCenter version of MythGallery the grid items are overlapping one another |
| [21:41:00] | paul-h: | I'm sure it's something simple but I'm not seeing it |
| [21:59:43] | stuartm: | paul-h: I'm just as baffled atm |
| [22:01:41] | stuartm: | ah, no I'm not, I just copied the fixed file to the wrong directory :) |
| [22:02:52] | stuartm: | paul-h: the 'active' state is missing an <area>, in this case you can just copy the area from the <state> or go for <area>0,0,100%,100%</area> (I think) |
| [22:03:26] | gigem: | stuartm: It sounds like you're advocating a single, all-encompassing API. For example, one where there is both "description" and "searchTarget" files and the client has to know (and the code should enforce) that description is not used for search rules and searchTarget is not used for non-search rules. |
| [22:03:29] | gigem: | FWIW, I understand the benefits of mythlogserver, but have never felt is was worth the added complexity, particularly the automatic shutdown and restarting. |
| [22:03:31] | gigem: | tafy: Edit definitely needs to change to Update. I'm still pondering the rest. I'll try to decide soonish (a day or two) and let you know. Pester me if I don't. If you'd then like to update your patches, that would be great. If not, I'll get to it when I get to it. |
| [22:04:21] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [22:05:14] | stuartm: | it used to be that we'd automatically expand the area to the size of any images it contains, but that went away for a couple of reasons (one practical to do with thread image loading and the other was to do with least surprise') |
| [22:05:26] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [22:08:33] | stuartm: | gigem: I'm talking in generalities rather than specifics, I've not given any thought to how the recording API might work in practice and therefore my 'ideal' scenario may simply not be possible |
| [22:12:20] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:12:34] | paul-h: | stuartm: That's fixed it thanks :) |
| [22:18:24] | stuartm: | paul-h: I'll have it throw a warning if an area hasn't been defined or inherited, I think that's a pretty common and easily overlooked mistake |
| [22:20:08] | stuartm: | it's a reasonable assumption that, like most widgets, you only need to define the area for the widget, the statetype and not each state |
| [22:21:14] | stuartm: | it may even be worthwhile having <states> inherit their parent's area unless one is explicitly defined |
| [22:24:03] | dekarl: | who came up with that "the mailing list archive is only for subscribers" crap? |
| [22:24:17] | dekarl: | stuartm: forwarding it to you the new way |
| [22:39:54] | paul-h: | stuartm: I tried using <area>0,0,100%,100%</area> but that didn't work as intended you end up with just one button but using the same area as the parent statetype worked |
| [22:40:40] | paul-h: | making a state inherit it's area from the parent statetype sound like a good idea |
| [22:45:34] | paul-h (paul-h!~Paul@176.252.19.2) has quit (Quit: Konversation terminated!) | |
| [22:49:36] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [23:00:49] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:15:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [23:34:21] | stichnot (stichnot!~stichnot@207.198.105.24) has joined #mythtv | |
| [23:34:21] | stichnot (stichnot!~stichnot@207.198.105.24) has quit (Changing host) | |
| [23:34:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:46:42] | rsiebert_ (rsiebert_!~quassel@g225049204.adsl.alicedsl.de) has joined #mythtv | |
| [23:49:10] | skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv | |
| [23:49:56] | rsiebert (rsiebert!~quassel@g225048126.adsl.alicedsl.de) has quit (Ping timeout: 256 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.