| Friday, April 19th, 2013, 00:04 UTC | ||
| [00:04:20] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:12:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [00:23:44] | skd5aner: | is anyone looking at improving the performance of the EPG while in Live TV? |
| [00:26:38] | dekarl (dekarl!~dekarl@p4FCEF5AE.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [00:27:02] | dekarl (dekarl!~dekarl@p4FCEFCCA.dip0.t-ipconnect.de) has joined #mythtv | |
| [00:46:25] | tafy: | gigem: I updated ticket 11495 with new patches |
| [00:50:45] | tafy: | gigem: what about 11491 (exposing the recordedmarkup entries)? This is a key feature in order to implement a commercial skip capable thirdparty player; I understand that somebody needs intimate knowledge of what a given type id is, but I would say that no matter what there should be a given in order to implement proper commercial skip... |
| [01:14:28] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [01:16:35] | wahrhaft_ (wahrhaft_!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv | |
| [01:18:46] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Ping timeout: 245 seconds) | |
| [01:36:48] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [01:43:28] | tafy (tafy!~sebastien@pool-98-116-240-153.nycmny.fios.verizon.net) has quit (Quit: tafy) | |
| [01:59:21] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:09:08] | danielk22 (danielk22!~danielk22@96.57.9.142) has quit (Ping timeout: 252 seconds) | |
| [02:50:21] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [03:14:30] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 256 seconds) | |
| [03:15:37] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:20:17] | danielk22 (danielk22!~danielk22@96.57.9.142) has joined #mythtv | |
| [03:25:48] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [03:38:53] | unforgiven512 (unforgiven512!~unforgive@65-78-110-218.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Ping timeout: 245 seconds) | |
| [03:39:57] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [04:23:53] | len (len!~quassel@75-161-175-43.mpls.qwest.net) has joined #mythtv | |
| [04:30:02] | humbug (humbug!~humbug@123.201.97.31) has joined #mythtv | |
| [04:55:58] | len (len!~quassel@75-161-175-43.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [05:35:25] | mickey62ga (mickey62ga!~mick@108.60.131.14) has quit (Ping timeout: 245 seconds) | |
| [05:45:27] | mickey62ga (mickey62ga!~mick@108.60.131.13) has joined #mythtv | |
| [05:58:11] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [06:09:34] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:20:11] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:29:42] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Read error: Connection reset by peer) | |
| [06:30:14] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [06:33:53] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [06:34:39] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Ping timeout: 276 seconds) | |
| [06:36:07] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 246 seconds) | |
| [06:36:27] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has quit (Ping timeout: 252 seconds) | |
| [06:36:27] | ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 252 seconds) | |
| [06:38:12] | ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv | |
| [06:41:13] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [06:44:59] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has joined #mythtv | |
| [06:44:59] | HeXiLeD (HeXiLeD!~L3D@69.196.165.41) has quit (Changing host) | |
| [06:44:59] | HeXiLeD (HeXiLeD!~L3D@unaffiliated/hexiled) has joined #mythtv | |
| [07:00:00] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [07:00:31] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [07:13:19] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [07:14:26] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [07:19:18] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 264 seconds) | |
| [07:23:35] | humbug (humbug!~humbug@123.201.97.31) has quit (Ping timeout: 255 seconds) | |
| [07:30:10] | Sharky112065 is now known as Sharky-Sleep | |
| [07:35:06] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:b566:f9d:a8d9:603f) has joined #mythtv | |
| [07:54:40] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [07:55:54] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [09:48:32] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [09:59:15] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [10:00:26] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Read error: Connection reset by peer) | |
| [10:06:29] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [10:11:00] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [10:13:16] | IReboot (IReboot!~doug@cpe10bf48e67915-cm78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [10:49:26] | joki (joki!~joki@p54865962.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [10:54:34] | joki (joki!~joki@p5486599D.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:12:01] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [11:29:14] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Ping timeout: 256 seconds) | |
| [11:30:13] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [12:40:26] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 245 seconds) | |
| [12:44:57] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [12:53:14] | ikonia_ (ikonia_!~irc@unaffiliated/ikonia) has joined #mythtv | |
| [12:54:07] | ikonia_ (ikonia_!~irc@unaffiliated/ikonia) has quit (Client Quit) | |
| [14:12:22] | gigem: | tafy: I hope you read the logs. I'll respond to your #11495 email later today. As for #11491, I'll leave that to others much more familiar with the markup tables. |
| [14:12:22] | ** MythLogBot http://code.mythtv.org/trac/ticket/11495 ** | |
| [14:12:22] | ** MythLogBot http://code.mythtv.org/trac/ticket/11491 ** | |
| [14:19:12] | sphery: | FWIW, for #11491 (and for the Services API, in general), I'd much prefer that clients be given some value to represent meaning that's unrelated to our DB values, so that DB values can change or evolve without affecting the API. So, for example, don't give the mark type values (i.e. 6 or whatever), but some other value that's defined in the API to represent a cut end. In this case--where there's no need/benefit for the value to be numeric (and ... |
| [14:19:12] | ** MythLogBot http://code.mythtv.org/trac/ticket/11491 ** | |
| [14:19:19] | sphery: | ... unintelligible)--it makes sense to make that value more human-readable or at least more intuitive than "6", something like "cut_end" or "mark_cut_end" or whatever... So the RecordedMarkupItem DC would just translate DB values to API values, and 3rd-party developers would find the API easier to understand without having a list of lookup tables.. |
| [14:27:25] | sphery: | Or, even go so far as to change it to a totally different representation from that used by the DB. Rather than a bunch of marks, process those marks into meaning. So, similar to what the recording/cut list editor does, rather than work with individual cut points, process those points to sections/areas and give a list of cut sections and a lit of skip sections and ... That way 3rd-party developers don't each have to figure out how to handle ... |
| [14:27:31] | sphery: | ... invalid markup, like <cut start> --- <cut start> --- <cut end> or whatever (because we wouldn't even give them that middle/redundant/enclosed cut start that shouldn't be there. |
| [14:28:11] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:29:21] | sphery: | My main concern is that with the old APIs/protocols, we've required every single client to do the interpretation of the data, so we have tons of clients writing redundant code that tries to encapsulate the logic in mythtv, then when we fix logic issues in mythtv, they don't often make it to other clients, and even if there are no changes, often clients misinterpret the data and do the wrong thing. So, the less they have to interpret, the better. |
| [14:49:17] | tafy (tafy!~androirc@2600:1001:b016:e48b::103) has joined #mythtv | |
| [14:49:18] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [14:50:29] | tafy: | gigem: i read the logs, thanks |
| [14:55:58] | tafy2 (tafy2!~androirc@158.sub-174-227-142.myvzw.com) has joined #mythtv | |
| [14:56:24] | tafy2: | (tafy) sphery: i will modify the patch in 11491 and remove the raw type for a more friendly value. |
| [14:56:54] | tafy2 (tafy2!~androirc@158.sub-174-227-142.myvzw.com) has quit (Client Quit) | |
| [14:58:11] | tafy (tafy!~androirc@2600:1001:b016:e48b::103) has quit (Ping timeout: 258 seconds) | |
| [15:35:27] | dblain: | sphery: I thought I had implemented enum support in the Services API framework. I'd have to check to see what state it's in or if I even commited it. I think that would give you what you are looking for since it would use the enum name in the xml/json instead of its value. |
| [15:36:37] | dblain: | I believe one limitation I ran into was that the enum must be defined in the class that is being exposed, so either they enums would need to be moved or duplicates created (former I didn't feel I had the rights to do and the latter seemed like a bad idea) |
| [15:53:30] | sphery: | dblain: That sounds pretty good--but the limitation may actually be a good thing. Rather than seeing it as needing to duplicate enums in the Services API classes, I see it as our having to define Services-API-specific enums that can remain unchanged, even in the event we later change names and/or values of the "internal" enums. |
| [15:55:22] | dblain: | Problem is, since the API implementation still calls other library functions (instead of replacing other libraries like I had originally hoped). It means there is a translation of enum data types that would need to take place whenever sending/updating values which I didn't like. |
| [15:59:05] | sphery: | well, with an external api, won't we either have to do translation or expose our internal api and external apps have to do translation/interpretation--and adapt for every single internal api change (meaning constantly-changing Service API version and apps having to either have forwards compatibility built in or support only one version or (worst of all) do like some and just ignore version, fake it, and hope they don't mess things up too bad |
| [15:59:40] | sphery: | I'd see having a Service-API-specific enum as a first step toward making the API itself handle some of the forwards-compatibility issues |
| [16:00:01] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [16:00:34] | sphery: | (and without having to litter the internal-only code with translations for old-version values every time we use the values) |
| [16:01:39] | sphery: | that said, I'm pretty much in the same camp as stuartm--I won't be using 3rd-party clients with my system, so I'll leave it up to those of you who will to decide. |
| [16:02:11] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [16:05:27] | sphery: | I know that a lot of users see the Service API as being the ultimate solution to having an external API ("Since it's XML instead of a MythTV-specific protocol, it's standard, so it will just work no matter what!"--where they don't get the fact that XML is just a data representation, but has no impact on interpretation or use of that data, which is where we've had problems--not with []:[] representation), and I don't really care to write extra ... |
| [16:05:34] | sphery: | ... code to support old 3rd-party clients as we change MythTV, so as long as others are willing to say we're not going to do it, then exposing internal values/names/etc. is probably fine |
| [16:06:29] | dblain: | I agree with everything you said. except the last part. Someone will need to translate if we want a stable API, but I had hoped that these services would one day be the only protocol used by our fontend... not just 3rd partly clients. |
| [16:07:48] | dblain: | Like I said yesterday, I haven't contributed anything in a long time, so I don't expect my opionion to carry much weight. |
| [16:09:33] | dblain: | But, I believe a single, unified standards based protocol used though out all mythtv would be the best long term solution. |
| [16:10:17] | dblain: | The agument that xml or json is slower than our current protocol never made much sense to me since we are talking about the control channel and not the streaming protocol. |
| [16:15:56] | sphery: | Agreed--the Services API is definitely a great solution, but if the frontend starts using the Services API (which sounds good to me), it becomes just another "external" client, so it wouldn't be using internal values, either. But it still makes sense to me to do the translations on the periphery/point of entry, which would be the Services API (or some layer between it and the application), so that internal code only has to work with current ... |
| [16:16:02] | sphery: | ... internal values. |
| [16:17:10] | sphery: | So, I guess if you don't want the translation inside the Services API code, we'd need to have a layer between it and the application and not only would the Services API have to pass incoming data from clients through that layer, but it should also be using that layer to retrieve "internal" data (i.e. no direct DB access or direct enum usage or whatever), right? |
| [16:17:57] | sphery: | And, I haven't done anything with MythTV for a long time, so my opinion shouldn't carry too much weight, either. (Though now that I finished up a big project, I'm hoping to get some time to work on it.) |
| [16:19:00] | sphery: | If we do decide to do a translation layer, maybe that should be part of the data server that's a requirement for embedded DB... |
| [16:19:27] | sphery: | (and hope we/I get that done before we need to change some of these values used by the API :) |
| [16:20:31] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:22:47] | dblain: | sphery: I can agree with the point you are making. A translation layer, although not ideal may be needed. To keep it simple for now, I think the enums exposed by the API should be the same values as internal values when appropriate, but they become final. Any internal value change (which shouldn't happen often) would cause the service api to translate the value before rendering the data. |
| [16:22:47] | dblain: | If there becomes a large amount of translation, we can introduce an official translation component if it will simplify the code (that is still TBD). |
| [16:23:52] | dblain: | Also keep in mind, if use are using enums for the API, it's the name that is being sent around. The internal value should still be hidden. |
| [16:25:40] | dblain: | I just found out they are moving all the jobs in my area of the country 700 miles south (over 2400 jobs total), which I'm not willing to move for, so, depending on how fast I find a job once I'm offically let go, I may actually have time to work on MythTV code again :/ |
| [16:29:09] | dblain: | Regarding my statement about using the Service API thoughout mythtv, I don't know if people remember, these service classes are just standard classes that can be called by code in the backend with NO http or Serialization involved. So, if designed/implemented well, they could replace the existing library functions instead of just being a wrapper to call them. |
| [16:30:17] | dblain: | That also applies to the datacontract classes. |
| [16:38:11] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 256 seconds) | |
| [16:42:55] | humbug (humbug!~humbug@112.167.211.69) has joined #mythtv | |
| [16:49:15] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [16:56:56] | wolfgang2 (wolfgang2!~wolfgang@178-27-144-160-dynip.superkabel.de) has quit (Ping timeout: 260 seconds) | |
| [17:03:23] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:b566:f9d:a8d9:603f) has quit (Read error: Connection reset by peer) | |
| [17:13:07] | wolfgang2 (wolfgang2!~wolfgang@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [17:15:01] | tgm4883: | stuartm, sphery I switched some things around and added some color coding. It looks way less complicated now I think https://creately.com/diagram/hfo8sxpf1 |
| [17:28:44] | stoffel (stoffel!~quassel@pD9E435DB.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:10:08] | Sharky-Sleep is now known as Sharky-AFK | |
| [18:16:06] | SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:17:29] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:32:16] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [18:58:39] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!) | |
| [19:06:11] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [19:07:19] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Client Quit) | |
| [19:26:44] | stoffel (stoffel!~quassel@pD9E435DB.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [19:48:48] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Ping timeout: 264 seconds) | |
| [19:51:57] | stichnot (stichnot!~stichnot@216.239.45.87) has joined #mythtv | |
| [19:51:57] | stichnot (stichnot!~stichnot@216.239.45.87) has quit (Changing host) | |
| [19:51:57] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [19:55:09] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [20:03:50] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv | |
| [20:14:30] | humbug (humbug!~humbug@112.167.211.69) has quit (Quit: humbug) | |
| [20:15:17] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
| [20:21:15] | stichnot: | tafy, sphery: in #11491, how is the markup data intended to be used by a third-party player? My first guess would be that the commflag data would be used to construct a cutlist argument to mythtranscode or similar. My second guess would be that the commflag data would be used to generate chapter marks. |
| [20:21:15] | ** MythLogBot http://code.mythtv.org/trac/ticket/11491 ** | |
| [20:27:31] | stichnot: | I agree that it would be better to construct a representation of "cut" and/or "keep" regions instead of making the client interpret the marks (and ignore things like temporary marks and many other mark types). |
| [20:28:07] | stuartm: | stichnot: skipping over commercials would probably be the most frequently used feature, although if they were streaming it would probably be better for the backend to handle that for them, seamlessly |
| [20:29:35] | stichnot: | Other things to consider: Does the client want frame numbers, or timestamps? Should the frame numbers or timestamps be adjusted for an existing cutlist? There is some fairly complex code that computes these mappings, best not duplicated in the client. |
| [20:31:11] | stichnot: | I've never had any involvement (or interest tbh) in the services API, so I would probably limit myself to the technical discussion here. |
| [20:32:41] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Read error: Connection reset by peer) | |
| [20:35:17] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
| [21:16:43] | tgm4883: | what specs is smolt running on? |
| [21:37:10] | Steve-Goodey (Steve-Goodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:45:12] | stuartm: | tgm4883: the server, or what specs is it collecting? |
| [21:45:37] | tgm4883: | stuartm, the server, since it's down again |
| [21:46:43] | stuartm: | 2x Dual Core AMD Opteron(tm) Processor 285, 16GB ram |
| [21:47:06] | stuartm: | it's up for me, but maybe the smolt process has fallen over ... |
| [21:49:05] | stuartm: | restarted smoon |
| [21:50:19] | stuartm: | tgm4883: better? |
| [21:51:22] | stuartm: | I'm not sure that the process was even started after the reboot two days ago |
| [21:53:30] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds) | |
| [22:06:40] | tgm4883: | stuartm, yea looks much better |
| [22:06:58] | tgm4883: | stuartm, the process doesn't start on boot? |
| [22:08:00] | tgm4883: | stuartm, would it be at all beneficial and/or a security risk to have the smolt hardware ID attached to bug reports? |
| [22:20:07] | unforgiven512 (unforgiven512!~unforgive@65-78-111-80.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [23:37:18] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [23:46:46] | rsiebert (rsiebert!~quassel@g225062156.adsl.alicedsl.de) has joined #mythtv | |
| [23:50:00] | rsiebert_ (rsiebert_!~quassel@g225049204.adsl.alicedsl.de) has quit (Ping timeout: 272 seconds) | |
| [23:57:56] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.