| Tuesday, March 15th, 2011, 00:02 UTC | ||
| [00:02:06] | dlblain (dlblain!~androirc@79.sub-75-194-28.myvzw.com) has quit (Ping timeout: 240 seconds) | |
| [00:05:25] | cdev (cdev!~androirc@218.sub-69-98-100.myvzw.com) has joined #mythtv | |
| [00:06:01] | cdev: | true. |
| [00:06:29] | cdev is now known as dlblain | |
| [00:12:31] | kormoc is now known as kormoc_afk | |
| [00:19:07] | xris: | dlblain: sorry, afk too much at work. was wondering if you had docs for the new api stuff you put in recently. json? |
| [00:20:40] | dlblain: | Im cleaning up a few issues with the code and then was planning on putting docs in wiki. |
| [00:20:47] | xris: | excellent |
| [00:20:55] | xris: | I might have some free time by then. not. heh |
| [00:21:06] | dlblain: | any specific questions? |
| [00:21:16] | xris: | noep |
| [00:21:20] | xris: | well.. does it do json? |
| [00:22:15] | dlblain: | yes. if the request header has Accept: application/json |
| [00:22:39] | dlblain: | I'm planning on adding jsonp support once I fix wsdl |
| [00:23:51] | clever: | jsonp should have extra safety's to keep cross-site scripting ont |
| [00:25:19] | dlblain: | clever: I'm open to suggestions. I was just going to support the callback parameter. not sure all the x site scripting issues. |
| [00:25:56] | clever: | <script src="http://192.168.1.100/something?prefix=data=&q . . . ;/script> |
| [00:25:59] | clever: | on any site |
| [00:26:15] | clever: | then the browser happily loads it, and sets data to all the goodies |
| [00:26:17] | xris: | dlblain: there's no way to just ask it to give json, without mucking with the http headers? |
| [00:26:56] | clever: | xris: that should be posible with ?format=json for example |
| [00:27:11] | dlblain: | xris. not currently. |
| [00:27:17] | xris: | clever: and we *want* xss... want to be able to use it with no referrer.. as a straight api. |
| [00:27:36] | clever: | xris: if its from a non-browser program, then you can do bare json and use it |
| [00:27:41] | xris: | dlblain: interesting. assumed it would be something more like json-rpc |
| [00:27:50] | clever: | jsonp is for when you want to load it in a <script> tag |
| [00:28:26] | xris: | clever: shouldn't be using it directly from a browser. not even sure the settings app should. but that may have to |
| [00:28:34] | clever: | any non-browser (qhttp, wget) will just let you dl the json directly from any domain |
| [00:28:53] | dlblain: | I wanted the API to be format/protocol agnostic. the parsings of the parameters is done using the metadata of the methods in the API class |
| [00:29:05] | clever: | jsonp is so that the json data gets wrapped with foo=... or func_call(...), letting you 'eval' the jsonp reply in <script> tag |
| [00:29:06] | xris: | clever: xss protection is about server side stuff, too. not browser xss concerns |
| [00:29:36] | clever: | xris: the browsers cross-domain stuff should protect most of the time, but jsonp can let you arround that |
| [00:29:39] | xris: | oh. yeah. raw json would be preferred |
| [00:30:30] | xris: | anyway, I'll wait for docs. |
| [00:30:35] | xris: | time to go home now. |
| [00:30:39] | dlblain: | raw json is what it currently does |
| [00:30:40] | clever: | raw json would return a string like {"servers":{"f":{"playerid":"71808"},&qu ot;g":{"playerid":"984"},"j":{"playerid& quot;:"28310"}}} |
| [00:30:54] | clever: | jsonp would be returning callback({"servers":{"f":{"playerid":"71808&q uot;},"g":{"playerid":"984"},"j":{" playerid":"28310"}}}); |
| [00:31:11] | xris: | oh. so what's with the jsonp talk, then? |
| [00:31:32] | clever: | jsonp can be used in a <script> tag without needing xmlhttprequest |
| [00:31:32] | dlblain: | someone else asked for it. |
| [00:31:51] | clever: | <script src="something.jsonp"> will effectively run <script>callback(....);</script> |
| [00:32:19] | clever: | and since the same-origin policy doesnt effect script.src, it can call other domains |
| [00:33:01] | clever: | ive run into a greasemonkey script that winds up having to cross-site script attack its own host, due to not using greasemonkey properly |
| [00:34:02] | xris: | sounds dangerous/overkill |
| [00:34:15] | xris: | and like a lazy dev. |
| [00:34:27] | xris: | anyway, really afk now. |
| [00:34:32] | clever: | the dev has almost no clue what he is doing |
| [00:34:51] | clever: | and ive seen signs that he just copied it from another project |
| [00:39:26] | Dave123-road (Dave123-road!~dave@64.134.241.217) has quit (Ping timeout: 260 seconds) | |
| [00:44:52] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [00:45:37] | iamlindoro: | markk, It appears CrystalHD may be broken in current master-- requires a patch just to compile right now (the ticket I commented on a bit ago) but video frames seem never to be returned from the decoder |
| [00:51:44] | dlblain (dlblain!~androirc@218.sub-69-98-100.myvzw.com) has quit (Quit: AndroIRC) | |
| [00:58:48] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [00:59:17] | gigem (gigem!~david@host103.16.intrusion.com) has joined #mythtv | |
| [00:59:17] | gigem (gigem!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [00:59:17] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [00:59:41] | dblain: | xris: I did post this to the dev list: http://www.gossamer-threads.com/lists/mythtv/dev/474623 which gives some details. |
| [01:00:19] | dblain: | Please note that the status page url has changed even though that e-mail says it didn't. There was another e-mail with those details sent. |
| [01:06:36] | Captain_Murdoch: | xris, dblain: I believe the jsonp will be necessary if we want to use json from mythweb since mythweb will be running on a different IP/port combination. |
| [01:11:43] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has joined #mythtv | |
| [01:13:07] | kormoc_afk is now known as kormoc | |
| [01:13:37] | dekarl (dekarl!~dekarl@e180141098.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds) | |
| [01:14:49] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Ping timeout: 240 seconds) | |
| [01:15:47] | dekarl (dekarl!~dekarl@e180140113.adsl.alicedsl.de) has joined #mythtv | |
| [01:17:16] | markk (markk!~mark@cm180.omega173.maxonline.com.sg) has quit (Remote host closed the connection) | |
| [01:18:38] | Dave123-road (Dave123-road!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv | |
| [01:19:04] | markk (markk!~mark@cm180.omega173.maxonline.com.sg) has joined #mythtv | |
| [01:21:34] | markk: | iamlindoro: didn't know you were using crystalhd |
| [01:21:43] | iamlindoro: | I'm not... yet :) |
| [01:22:06] | iamlindoro: | Have a dell nettop that I got recently with a big order, forgot it came with CrystalHD |
| [01:22:20] | iamlindoro: | So decided to make a project of it this evening |
| [01:23:20] | markk: | which version of the device? |
| [01:23:57] | iamlindoro: | 70015 |
| [01:24:15] | clever: | Captain_Murdoch: if jsonp is used like that, then its the very definition of cross-site scripting, might need a whitelist of what referers to allow |
| [01:24:34] | iamlindoro: | I also saw some odd threading-related messages I've never seen before-- let me see if I can get some -v playback logs real quick |
| [01:25:20] | markk: | iamlindoro: and what happens if you roll the driver/lib back to before the commit that broke compilation? |
| [01:25:30] | iamlindoro: | haven't tried that yet |
| [01:25:44] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [01:26:52] | iamlindoro: | "Application asked to unregister timer 0x0 which is not registered in this thread. Fix application." |
| [01:27:03] | iamlindoro: | That went to stderr instead of stdout |
| [01:27:39] | iamlindoro: | http://www.fecitfacta.com/chd.log |
| [01:27:53] | markk: | iamlindoro: I've seen a few of those recently – I don't think it's crystalhd related. |
| [01:27:54] | iamlindoro: | Log, three playback attempts: H.264, MPEG-2, H.264. All H.264 from the HD-PVR |
| [01:28:34] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [01:30:52] | markk: | iamlindoro: out of interest, what happens if you use vdpau or xvideo for the video renderer |
| [01:31:18] | iamlindoro: | No change w/ Xv, hardware isn't VDPAU capable. Switching decoders does make it work w/ GL and Xv |
| [01:33:11] | markk: | ah – ok, good old trashy intel gpu :) |
| [01:33:25] | iamlindoro: | yep |
| [01:33:37] | iamlindoro: | Though in this case it seems fair to blame the decoder |
| [01:33:45] | iamlindoro: | (since rendering works properly with software decode) |
| [01:34:54] | markk: | iamlindoro: nothing in the logs to suggest a problem (before the problem) – if you can try an older version, that would be helpful. It'll be a while before I can plug my 70015 into my ion and fix it. |
| [01:35:23] | iamlindoro: | sure, will try to do that a little later |
| [01:35:43] | iamlindoro: | 2011-03–14 18:26:13.795 CrystalHD: Failed to pause fetcher thread |
| [01:35:43] | iamlindoro: | DtsAllocIoctlData Error |
| [01:35:45] | iamlindoro: | seemed relevant |
| [01:39:22] | xris: | Captain_Murdoch: mythweb will only ever communicate directly with the backend. no json direct from the backend. that's how you protect against xss. :) |
| [01:39:44] | xris: | plus, data from the backend will be un-optimized. likely WAY more info than we'd ever want to expose to mythweb. |
| [01:40:10] | wagnerrp: | im confused |
| [01:40:19] | wagnerrp: | mythweb will only communicate directly with the backend |
| [01:40:25] | wagnerrp: | but never directly with the backend? |
| [01:40:35] | xris: | the browser will not talk to the backend. |
| [01:40:36] | xris: | mythweb will |
| [01:40:48] | wagnerrp: | ah, right |
| [01:41:59] | xris: | otherwise would also mean those of us with public-facing mythwebs would have to open the backend port up to the world |
| [01:44:34] | wagnerrp: | well you could proxy the requests through, and let javascript on the client side do what it wants with it |
| [01:45:07] | xris: | yeah. but then you still run into the too-much-info stuff. |
| [01:45:20] | xris: | the whole point of ajax/json requests is optimization. |
| [01:45:30] | xris: | if you only need the title/subtitle/desc, then you only send that. |
| [01:45:38] | sphery: | and--though I'll admit that I don't know for sure what was meant--but if the referrer list talk meant anything about using client-generated Referer header to determine who can ask the backend for something, it's a broken solution since a) some of us disable sending Referer and b) client-generated data is not a valid security token (as it's easy to fake) |
| [01:45:47] | xris: | either way, you wouldn't use jsonp for that. |
| [01:48:37] | xris: | mythweb also has local caches of stuff from the backend. |
| [01:49:43] | xris: | for mythweb (or the perl bindings, for that matter), the point of json in the backend has to do with the fact that json is smaller and easier to parse than xml, and more flexible than mythproto, not that browsers can understand it. |
| [02:04:13] | iamlindoro: | markk, Rolled back the CHD lib and driver, and now works with Xv (but not with GL, which is obviously a seperate issue) |
| [02:07:51] | markk: | iamlindoro: thanks. btw – what is the intel gpu? |
| [02:08:39] | Captain_Murdoch: | xris, ok. dblain, "what he said". :) guess we don't need jsonp after all. |
| [02:09:46] | iamlindoro: | markk, Looks like it's the GMA 3100, http://en.wikipedia.org/wiki/Intel_GMA#GMA_3100 |
| [02:20:36] | xris: | Captain_Murdoch: if we were to do anything, I'd say we should look into json-rpc |
| [02:21:10] | xris: | I'm not sure we've had anything like that on the xml side. but we'd need *something* like it to replace mythproto |
| [02:22:59] | xris: | would allow us to version our API structure, too. |
| [02:23:54] | xris: | if possible, maintain one stable version backwards worth of API calls during unstable development.. then app writers could interact without too much fear of things breaking for users running trunk/master |
| [02:27:22] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [02:30:40] | Captain_Murdoch: | yeah, it would be nice to have something like that, but that's another manpower thing. |
| [02:31:37] | xris: | yup |
| [02:32:11] | xris: | json vs mythproto will go a long way toward making myth work more consistently between versions, though |
| [02:38:49] | Captain_Murdoch: | s/will/could/ since I don't believe any decision has been made. :) I get the idea and reasons though. |
| [02:51:39] | dblain: | xris: I've been focusing on the REST, POX and SOAP models not XXX-RPC. But I see no reason why RPC can't be supported too. With my current design, the Methods & data classes would not be changed regardless of the protocol/transport used. |
| [02:51:50] | Captain_Murdoch: | dblain, is there a reason that for methods like Myth::GetSetting() that the actual method's args start with 's',but the prototype's args don't? |
| [02:52:27] | xris: | dblain: SOAP is *RPC |
| [02:52:50] | dblain: | The prototype defines what the actual parameter names are in the serialization/parameterization. But I like having the type for the actual variable. |
| [02:53:01] | xris: | dblain: but we can also simplify things. mythproto requires that you send it an entire program record for some things when just an ID would be enough |
| [02:53:04] | xris: | and REST might cover that |
| [02:53:05] | dblain: | xris, yes, I guess it is. |
| [02:54:19] | dblain: | although JSON-RPC & XML-RPC have different data payloads (At least that's my understanding of it... no soap envelope) |
| [02:54:38] | xris: | right |
| [02:54:39] | dblain: | But that is where the serializer classes come in. |
| [02:54:49] | clever: | ive got an example of using xml-rpc from php |
| [02:55:09] | xris: | you basically pass method name and parameters in POST data instead of query string encoded data. |
| [02:55:17] | Captain_Murdoch: | dblain, ok, thanks on the var names. |
| [02:55:39] | clever: | http://privatepaste.com/c2bcd51ec6 |
| [02:55:40] | dblain: | xris: that is already supported. |
| [02:56:16] | clever: | i think xml-rpc puts XML in both the post body and the reply body |
| [02:56:17] | dblain: | application/x-www- form-urlencoded |
| [02:56:33] | clever: | and then just uses certain tags to form the rpc and reply structure |
| [02:56:44] | dblain: | that's been there since mythxml was first introduced. |
| [02:57:05] | dblain: | clever: I think I'm just missing the header format for standard xml-rpc |
| [02:57:26] | clever: | Content-Type: text/xml is what the php script uses, for the request side |
| [02:58:05] | clever: | i can get the reply header also |
| [02:58:13] | dblain: | We currently support parameteres in: query String, form-urlencoded (posted), and XML body (posted) |
| [02:58:48] | clever: | dblain: http://privatepaste.com/b10d725875 |
| [02:58:57] | dblain: | I think I just need to make sure the xml schema for the parameters is compliant to whatever protocol that is used. |
| [02:59:33] | clever: | a simple call of system.listMethods |
| [02:59:53] | clever: | hmmm, cut out the post body by mistake |
| [02:59:55] | dblain: | That looks a lot like what I am already parsing / responding with :) |
| [03:00:06] | clever: | write(3, "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<methodCall>\r\n<methodName>sys tem.listMethods</methodName>\r\n<params>\r\n</params>\r\n</ methodCall>\r\n", 135) = 135 |
| [03:00:51] | clever: | looks to be text/xml for both the reply and request |
| [03:02:42] | xris: | dblain: post data? that's what json-rpc is |
| [03:02:58] | dblain: | We may want to focus on a select number of protocols/encoding types. I like REST for the simple calls, and I'm persuing SOAP (wsdl generation is almost complete) so I can use it with .net. |
| [03:03:19] | dblain: | anything else should be decided on by the setup rewrite & mythweb needs. |
| [03:03:41] | xris: | I avoid soap if I can. it's overly complicated |
| [03:04:28] | dblain: | xris: currently the post data support is limited to xml and urlencoded payloads, but we can add json parsing |
| [03:04:57] | xris: | doesn't .net to json-rpc? |
| [03:05:17] | dblain: | xris: SOAP is nice for interfacing with microsoft .net. I add a simple service reference pointing it to http://mythbackend:6544/Myth/wsdl and it generates all the client proxy code. |
| [03:05:26] | xris: | yeah |
| [03:05:36] | xris: | we use SOAP with TMS |
| [03:05:48] | clever: | dblain: nice |
| [03:05:56] | xris: | it's just... a lot of overhead |
| [03:05:58] | clever: | i had to do all that by hand last time i used soap |
| [03:06:09] | clever: | yeah, xml has plenty of overhead |
| [03:06:10] | xris: | clever: yeah, if you have a wsdl, soap can work pretty well |
| [03:06:12] | dblain: | I have all the wsdl working except the complex arrays. |
| [03:06:20] | xris: | dblain: nice. |
| [03:06:39] | xris: | granted, if you get a full SOAP implementation, and the wsdl is maintained, that might be good enough |
| [03:06:43] | clever: | take the xml-rpc for example, </string></value>\r\n<value><string> times 400 |
| [03:07:01] | kormoc: | anyone generating xml by hand is doing it wrong |
| [03:07:04] | dblain: | To me, we are talking guide data, setting information, and other non-time critical methods. A little overhead to parse soap or xml isn't that big of deal |
| [03:07:34] | dblain: | xris: I'm making it so the wsdl is generated in realtime, so there is no maintenance needed. |
| [03:07:42] | clever: | kormoc: its all auto-generated, but thats 14kb of markup just for the string list in the reply |
| [03:09:16] | dblain: | clever: that is why I offer a replaceable serialization model. You can serialize to any format you want to code for. WITHOUT having to write specific code for each method. |
| [03:09:36] | clever: | yeah that can be handy |
| [03:09:40] | dblain: | clever: if you wanted a binary format, you can add it by implementing 1 interface (abstract class) |
| [03:10:00] | clever: | hmmm, does QT provide an abstract way to list methods on a QObject? |
| [03:10:03] | dblain: | (not that I'm suggesting a binary format!) |
| [03:10:13] | clever: | you could use that to auto-expose any QObject |
| [03:10:15] | dblain: | clever: QMetaMethod. |
| [03:10:25] | dblain: | That is what I'm doing. |
| [03:10:34] | clever: | ah, nice:) |
| [03:10:40] | dblain: | But the data classes need to implement Q_PROPERTY. |
| [03:11:09] | clever: | ive done a bit of work with QScript before |
| [03:11:40] | clever: | i began patching myth to allow it in themes, but lost sight of where everything should be |
| [03:11:56] | dblain: | if you look at my changes, it may be clearer. The developer writing a new Method just needs to create a C++ method that returns one of the QObject data classes that has Q_Properties and My API framework code does all the rest to expose it. |
| [03:12:34] | dblain: | The side effect of my current implementation is all the methods exposed as services and there data classes are usable in QScript. |
| [03:14:25] | clever: | i was thinking that opening up QScript to themes could allow more complex animations |
| [03:14:29] | dblain: | take a look at libmythservicecontracts to see all the service interfaces and the data contracts exposed. |
| [03:15:09] | clever: | instead of pre-rendering a large (mostly transparent) animation of something moving around the screen, just move it thru QScript calls and a timer |
| [03:15:11] | xris: | clever: does your xml protocol stuff stream, or is it all-or-nothing? |
| [03:15:13] | dblain: | Currently the implemenation of the service interfaces is done in mythbackend... but they can be pulled out if needed. |
| [03:15:26] | clever: | xris: in the php client i wrote, its all or nothing |
| [03:15:34] | xris: | serverside, though. |
| [03:15:46] | xris: | there are streaming xml/json encoder/decoder libraries out there for a lot of languages |
| [03:15:55] | clever: | server side, i have no idea, i havent read that part of rtorrent |
| [03:16:40] | clever: | but i have used the xml stream decoders in php before, for i think the SOAP interface |
| [03:17:09] | dblain: | xris: FYI the http server re-write I put on hold to finish the API stuff was going to allow the rendering of the XML, json, ... using chunked encoding so it can be returned (streamed) as it was generated. I never liked having to form the entire object in memory before returning results. |
| [03:18:21] | dblain: | xris: it may take me a while before I can focus on it again ( want to make sure the API stuff is complete for the setup re-write) |
| [03:21:40] | xris: | yeah. working is more important than working efficiently. :) |
| [03:21:47] | xris: | I'm just glad to see it finally in place. |
| [03:23:04] | dblain: | The one thing I need help with is for someone to stop me adding too many features! Let me know how you would like to call the services for mythWeb, so I at least have a protocol someone will use! |
| [03:25:46] | xris: | don't even know what the future of mythweb *is* |
| [03:25:54] | xris: | 2 days ago I was thinking about rewriting it in python. |
| [03:26:02] | xris: | and kormoc didn't work too hard to slap sense into me |
| [03:26:26] | xris: | php can do SOAP well enough if there's a wsdl |
| [03:26:33] | xris: | afk, dinner |
| [03:26:43] | clever: | what about mostly static html pages served by mythbackend? |
| [03:26:49] | dblain: | xris: have a good night. |
| [03:26:54] | Captain_Murdoch: | dblain, I've been playing around with a storage groups editor using the json interface. :) |
| [03:27:04] | clever: | with only some basic rules (repeating a chunk for each tv show), and basic substitution |
| [03:27:31] | dblain: | Captain_Murdoch: feel free to add new methods! and let me know if you run into any issues |
| [03:28:31] | Captain_Murdoch: | working great so far. I was just looking at adding a DTC::StorageGroupDir and DTC::StorageGroupDirList |
| [03:29:21] | dblain: | clever: xslt would work well for what you're talking about... but without having server side script in the html server yet, all dynamic content would need to be written in c++ which I don't think xris knows. (appologies if I'm wrong) |
| [03:29:23] | clever: | what id like to see, is some RPC methods for channel scanning |
| [03:29:51] | clever: | dblain: i'm thinking something like that, with c++ providing the input variables |
| [03:30:26] | clever: | so other then changing the variable rules, you can edit things without compiling the entire backend again, and you get the speed of c++ for the most part |
| [03:30:37] | dblain: | clever: feel free to add the methods to the API classes for the channel scanning. |
| [03:30:45] | Captain_Murdoch: | and already played with adding new methods to create and delete dirs. need to modify those to use the new DTC code when I add those. |
| [03:30:53] | clever: | any comands like deleting shows, changing schedule, scanning would then be done from an rpc like json-rpc maybe |
| [03:31:33] | clever: | dblain: at the moment, nothing is connected to my tuner |
| [03:31:38] | clever: | its all handled by the external cable box |
| [03:31:51] | dblain: | Captain_Murdoch: I already have diskSpace, diskSpaceGroup, JobQueueEntry and scriptStatusItem classes created... I was going to replace the status page generation with them... just never committed them. |
| [03:31:53] | clever: | and i'm running an accient copy of 0.23 trunk |
| [03:32:03] | clever: | i really need to get around to upgrading things |
| [03:32:39] | Captain_Murdoch: | dblain, nice. yeah, I was thinking the same thing about the status page. thinking it should just be tabs or broken into separate menu pages with menu items off the /index.html page. |
| [03:33:23] | dblain: | clever: all the methods listed are fair game to add. Eventually I would like to see all the current Myth Prototype methods ( or simular functionality) added. |
| [03:33:36] | Captain_Murdoch: | want to get that css out of cpp as well. :) |
| [03:33:59] | dblain: | Captain_Murdoch: definitely. |
| [03:34:01] | Captain_Murdoch: | dblain, was that s/Prototype/Protocol/ ? |
| [03:34:04] | clever: | dblain: yeah, but its hard to devel that stuff when it refuses to compile due to alsa AND qt being too old |
| [03:34:27] | dblain: | Captain_Murdoch: yes, protocol... typeing too fast. |
| [03:34:38] | Captain_Murdoch: | thought so,but wanted to verify. |
| [03:35:11] | dblain: | clever: true... could always put a Development Virtual machine together... that's what I did |
| [03:36:19] | dblain: | Captain_Murdoch: I invision the current myth protocol code being functionalized into a set of API classes that it would call, but would also be exposed as part of the new service model. |
| [03:36:20] | Captain_Murdoch: | my physical dev box has been off 95% of the time the past couple years, I do most of my work inside a VM. |
| [03:36:23] | clever: | dblain: my frontends are new enough for git master |
| [03:36:36] | clever: | but the frontends lack tuners, so its a bit pointless to try and devel scanning code on them |
| [03:36:48] | clever: | VM's also generaly dont agree with tuners |
| [03:37:18] | dblain: | Captain_Murdoch: I'm just worried about the amount of testing that would be needed making that kind of change to Myth Protocol's code base. |
| [03:38:15] | Captain_Murdoch: | it would be huge. I've wondered if something like that may be best implemented in parallelwith the existing code. |
| [03:38:58] | Captain_Murdoch: | could have 2 connections to the MBE and gradually switch over commands to using the new code. |
| [03:39:08] | dblain: | I would just not want to maintain two versions of the same code for too long. |
| [03:39:40] | Captain_Murdoch: | right, I mean cut over methods and remove old code for each as it was cutover. would be a lot of small protocol changes rather than one or a few big ones. |
| [03:39:51] | Captain_Murdoch: | s/methods/commands/ |
| [03:40:13] | dblain: | I figured I would add the methods I want (stealing code from mainserver.cpp when available) and eventually swith mainserver.cpp to call the new implementation. |
| [03:40:23] | dblain: | makes sense. |
| [03:40:59] | iamlindoro: | doing a couple of simple ones in isolated commits would help people understand how to convert one, and then it'd be easier to help out |
| [03:41:03] | dblain: | definitely not high on my todo list right now! (took over a year for me to commit the current api framework code!0 |
| [03:41:14] | dblain: | iamlindoro: true. |
| [03:41:28] | Captain_Murdoch: | mainserver.cpp will also be getting some love as part of some code that wagnerrp is working on. may eventually support backend plugins which could process commands sent over the proto. |
| [03:41:40] | dblain: | clever: with our cable co switch to 98% encrypted digital, I need to re-think the tuner issue as well. My HDHomerun works for now, and allows for recording in a VM, but my channel selection is way down. |
| [03:41:57] | dblain: | Captain_Murdoch: cool |
| [03:42:20] | clever: | dblain: since i only have a pvr-150, i can only capture 480i from the SDTV box |
| [03:42:36] | clever: | the HDTV box is 'uselessly' sitting on the hdtv upstairs, without any dvr functionality |
| [03:43:20] | dblain: | Captain_Murdoch: Ultimately, I envison a Myth Protocol serializer (stringList anyone) and a raw socket ServiceHost implementation, so even the standard Mythprotocol could use my new Framework :) |
| [03:43:38] | Captain_Murdoch: | yeah, that would be nice. |
| [03:43:41] | clever: | dblain: have you see QBinaryStream i think it is? |
| [03:43:47] | dblain: | But I know I'd hear about performance issue since it serializing in realtime. |
| [03:44:12] | dblain: | clever: haven't really looked at it. |
| [03:44:50] | clever: | dblain: you basicaly just << various basic data types or QT data types (QString, QDateTime) and then you can >> them out the other end |
| [03:45:07] | clever: | i think it has type codes embeded in, so you can figure out what type is next |
| [03:45:22] | clever: | though its up to you to keep track of where each frame/msg begins/ends |
| [03:45:44] | dblain: | yes, but does it give you any control what format it hits the wire in? Part of my framework design was for foreign systems to be able to call the methods. |
| [03:46:04] | clever: | in this case, its a private QT format |
| [03:46:14] | clever: | best used with QBinaryStream on the other end |
| [03:46:19] | dblain: | It may work for Backend -> frontend myth specific protocol. |
| [03:46:26] | clever: | yeah, i was just going to say that |
| [03:46:33] | xris: | but better to avoid custom protocols if we can |
| [03:46:36] | wagnerrp: | Captain_Murdoch: for now, im just moving the handling loop in mainserver.cpp into libmythbase |
| [03:46:56] | wagnerrp: | and then letting mythbackend and mythjobqueue have their own independent sets of commands they listen to |
| [03:47:02] | dblain: | I personaly like more open standards... just need to get over the perceived/real performance issues. |
| [03:47:10] | wagnerrp: | easier to get things running in the near term |
| [03:47:30] | wagnerrp: | and the single registered handler can be migrated to multiple that are looped through at some point in the future |
| [03:48:43] | clever: | dblain: you could just continue with your idea, implement many transports |
| [03:48:59] | clever: | and then pick the 'best' (cpu or bytes of overhead wise) that is compatible with both ends |
| [03:50:12] | clever: | if its backend/frontend, then they probly have your class on both ends, and changing the transport is as simple as 2 lines of code |
| [03:50:23] | dblain: | clever: I don't see a performance problem with even the slowest protocol for simple control / guide methods. I just know other developers seem to think (and maybe rightfully so) that performance matters when making these kind of calls. |
| [03:50:38] | Captain_Murdoch: | wagnerrp, ok. sounds like a good way to get things started. |
| [03:51:10] | dblain: | wagnerrp: yes, pulling out the networking into a base class seems like a good start to me. |
| [03:53:33] | clever: | another idea ive seen mentioned before that makes sense |
| [03:53:38] | clever: | split the master backend and the capture into seperate daemons |
| [03:53:53] | Captain_Murdoch: | dblain, I think a lot of those performance issues could be classified as design issues. a screen may be blazingly fast when you only have a couple hundred recordings,but when you get to 1000 or 2000, it can slow down drastically. |
| [03:54:12] | wagnerrp: | clever: something sphery is planning on doing in the near future |
| [03:54:44] | clever: | Captain_Murdoch: yeah, ive seen that myself, and ive talked to one nut in #mythtv-users with over 10k recordings |
| [03:54:45] | Captain_Murdoch: | even with recording groups we still load the whole list and filter on the FE. that makes it fast to switch between groups, at the expense of load time. |
| [03:55:24] | dblain: | Captain_Murdoch: agreed, there is no reason the backend can't serve up just a page worth of data at a time. |
| [03:55:31] | sphery: | something sphery is working on piece by piece, now, actually |
| [03:56:05] | Captain_Murdoch: | dblain, biggest issue with that is we have to sort on the backend and add sort order to the request. |
| [03:56:33] | clever: | Captain_Murdoch: no passing it off to mysql? |
| [03:56:39] | dblain: | yes. (I don't see that as an issue looking from my api standpoint... Adding to existing protocol is another matter!) |
| [03:56:54] | wagnerrp: | clever: i think a lot of those people with >10k recordings have inserted their own content into the recordings |
| [03:56:58] | wagnerrp: | rather than using mythvideo |
| [03:57:21] | Captain_Murdoch: | clever, BE or mysql, but not the FE if the FE doesn't get the whole list at the same time. |
| [03:57:23] | clever: | wagnerrp: id just use mythvideo for that |
| [03:57:23] | dblain: | clever: I think it's understood that mysql would ultimately do the sort. |
| [03:57:25] | sphery: | agreed--even I (who has a hopeless backlog of recordings) only have 1400-and-change recordings |
| [04:01:52] | ** dblain calls it a night. ** | |
| [04:10:47] | loVolt (loVolt!ae0180d2@gateway/web/freenode/ip.174.1.128.210) has joined #mythtv | |
| [04:11:04] | ** loVolt is looking for teh right place ** | |
| [04:11:38] | loVolt: | I have a wintv-usb2-fm em28xx based , but infor on setu pis sparce |
| [04:14:15] | ** clever points at topic ** | |
| [04:14:30] | loVolt: | gratis |
| [04:26:56] | hobiga (hobiga!~hobiga@173.210.255.195) has quit (Ping timeout: 260 seconds) | |
| [04:29:05] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [04:31:54] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [04:32:11] | xris: | dblain: there's a reasonable amount of processing that has to be done on the recording objects after loading from mysql, though, no? |
| [04:32:30] | xris: | that's one of the reasons we used to talk about a mythtv data server.. db+caching interface |
| [04:32:51] | xris: | though improving db performance is one reason why a number of us talk about redoing the db schema. |
| [04:33:04] | xris: | iamlindoro did some of it for video stuff, but the tv stuff is missing a bunch. |
| [04:34:23] | xris: | ... ok, that was too many ideas in too few sentences. |
| [04:35:35] | hobiga (hobiga!~hobiga@173.210.255.195) has joined #mythtv | |
| [04:38:13] | The_Thing (The_Thing!4c1b6b79@wikipedia/The-Thing-That-Should-Not-Be) has joined #mythtv | |
| [04:51:55] | clever: | xris: sounds more like something to shove into the mythmaster that sphery is working on |
| [04:52:33] | clever: | mythmaster handles scheduling,waking slaves, db |
| [04:52:35] | clever: | slaves handle capturing |
| [04:56:16] | loVolt (loVolt!ae0180d2@gateway/web/freenode/ip.174.1.128.210) has left #mythtv () | |
| [04:56:46] | xris: | yeah |
| [04:57:04] | xris: | that was one of the architectural ideas. didn't realize someone had started on it. cool |
| [05:13:19] | Beirdo: | OK, bug fixed |
| [05:31:47] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has quit (Ping timeout: 252 seconds) | |
| [05:34:44] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has joined #mythtv | |
| [05:44:10] | abqjp (abqjp!~abqjp@71-37-148-206.albq.qwest.net) has quit (Read error: Operation timed out) | |
| [05:46:25] | abqjp (abqjp!~abqjp@71-37-148-206.albq.qwest.net) has joined #mythtv | |
| [06:05:13] | stoffel (stoffel!~quassel@p57B4A590.dip.t-dialin.net) has joined #mythtv | |
| [06:12:52] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [06:14:59] | hansmuc (hansmuc!~hansmuc@ppp-93-104-178-140.dynamic.mnet-online.de) has joined #mythtv | |
| [06:15:18] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [06:15:29] | hansmuc (hansmuc!~hansmuc@ppp-93-104-178-140.dynamic.mnet-online.de) has left #mythtv () | |
| [06:35:54] | stoffel (stoffel!~quassel@p57B4A590.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [06:44:51] | joe____ (joe____!~jmk@64.73.32.135) has joined #mythtv | |
| [06:45:43] | joe__ (joe__!~jmk@64.73.32.135) has quit (Ping timeout: 240 seconds) | |
| [06:51:56] | stoffel (stoffel!~quassel@p57B4DE17.dip.t-dialin.net) has joined #mythtv | |
| [06:57:39] | stoffel (stoffel!~quassel@p57B4DE17.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [07:03:03] | jstenback (jstenback!~jstenback@dp.jstenback.com) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [07:07:34] | jstenback (jstenback!~jstenback@dp.jstenback.com) has joined #mythtv | |
| [07:13:28] | Goga777 (Goga777!~Goga777@shpd-92-101-134-246.vologda.ru) has joined #mythtv | |
| [07:16:10] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Operation timed out) | |
| [07:16:21] | dlblog (dlblog!~dlblog@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Ping timeout: 246 seconds) | |
| [07:17:19] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has quit (Quit: No Ping reply in 180 seconds.) | |
| [07:17:24] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has joined #mythtv | |
| [07:17:45] | Splat1 (Splat1!~Splat1@rf1.splat1.com) has quit (Ping timeout: 246 seconds) | |
| [07:18:27] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [07:18:27] | Goga777 (Goga777!~Goga777@shpd-92-101-134-246.vologda.ru) has quit (Ping timeout: 246 seconds) | |
| [07:18:59] | dlblog (dlblog!~dlblog@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [07:30:07] | Splat1 (Splat1!~Splat1@rf1.splat1.com) has joined #mythtv | |
| [07:31:05] | Goga777 (Goga777!~Goga777@shpd-92-101-134-246.vologda.ru) has joined #mythtv | |
| [07:43:12] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [07:43:26] | Goga777 (Goga777!~Goga777@shpd-92-101-134-246.vologda.ru) has quit (Read error: Connection reset by peer) | |
| [07:46:36] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [07:48:20] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 246 seconds) | |
| [08:03:45] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [08:12:56] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [08:14:11] | deaman (deaman!~deaman@nat/trolltech/x-nvtyylcxkmqezgrp) has joined #mythtv | |
| [08:52:44] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 246 seconds) | |
| [09:09:49] | tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) has quit (Excess Flood) | |
| [09:14:13] | tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [09:38:27] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [09:41:22] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [09:42:50] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [10:05:02] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:52] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:22:45] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [10:26:13] | paul-h: | '/;.,ljht / |
| [10:45:18] | stuarta: | i agree entirely |
| [11:29:50] | hansmuc (hansmuc!~hansmuc@ppp-93-104-178-140.dynamic.mnet-online.de) has joined #mythtv | |
| [11:49:29] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 246 seconds) | |
| [11:54:49] | foxbuntu (foxbuntu!~foxbuntu@67-3-65-76.desm.qwest.net) has joined #mythtv | |
| [11:55:00] | foxbuntu (foxbuntu!~foxbuntu@67-3-65-76.desm.qwest.net) has quit (Changing host) | |
| [11:55:00] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv | |
| [11:56:32] | solstice (solstice!~solsTiCe@ARennes-553-1-180-164.w2-2.abo.wanadoo.fr) has joined #mythtv | |
| [11:57:10] | solstice: | hi. anyone heard of the libav "fork" of ffmpeg. what's in the news also is that "inexperienced git user" made errors with git mythtv repo. what kind of errors ? |
| [11:59:16] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [11:59:20] | davide (davide!~david@host103.16.intrusion.com) has joined #mythtv | |
| [12:02:45] | hansmuc (hansmuc!~hansmuc@ppp-93-104-178-140.dynamic.mnet-online.de) has left #mythtv () | |
| [12:04:02] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 276 seconds) | |
| [12:05:08] | waxhead (waxhead!~pete@ppp121-45-201-17.lns20.cbr1.internode.on.net) has joined #mythtv | |
| [12:05:43] | waxhead (waxhead!~pete@ppp121-45-201-17.lns20.cbr1.internode.on.net) has left #mythtv ("Ex-Chat") | |
| [12:26:52] | stuartm: | solstice: that was an incorrect statement, it was the experienced git users who screwed up which is just one reason why we're moving back to svn – it's much safer |
| [12:27:15] | stuartm: | solstice: and we're all aware of the ffmpeg situation |
| [12:29:26] | stuartm: | problems with git included forced merges which 'vanished' previous commits, messy merges which made it difficult to follow the chain of events etc |
| [12:31:48] | markk: | and lets leave it at that, please. |
| [12:45:23] | solstice: | ok. I wouldn't reopen a wound |
| [13:18:57] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [13:19:11] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [13:38:25] | andreax (andreax!~andreaz@p57B93B59.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [13:39:27] | andreax (andreax!~andreaz@p57B93B59.dip.t-dialin.net) has joined #mythtv | |
| [13:44:44] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [14:03:31] | danielk22: | dblain: Captain_Murdoch: I noticed a lot of performance problems when I was using DishNet instead of cable, dealing with just a few hundred extra channels pushed a lot of screens past the slowness tolerance point. |
| [14:04:14] | danielk22: | It wasn't the channels themselves of course, but all the programs they added that needed to fetched and sorted through. |
| [14:19:55] | j-rod|afk is now known as j-rod | |
| [14:50:59] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [14:56:04] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection) | |
| [15:11:19] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [15:17:28] | abqjp (abqjp!~abqjp@71-37-148-206.albq.qwest.net) has quit (Quit: abqjp) | |
| [15:24:49] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Read error: Operation timed out) | |
| [15:28:55] | deaman (deaman!~deaman@nat/trolltech/x-nvtyylcxkmqezgrp) has quit (Quit: deaman) | |
| [16:13:11] | Captain_Murdoch: | danielk22, yeah, that's what it would be nice to work around. it's a bit of work and might need more thought than just doing it a screen at a time since some screens could benefit from the same code if it was flexible enough. if we could ask the theme which fields it needs, we wouldn't have to load a full programinfo if only 5 fields are needed. we could lazy-load the full info later either on-demand or in the background. |
| [16:17:28] | Captain_Murdoch: | danielk22, dblain, have either of you given any thought to requiring authorization for specific methods in the services API? I'm thinking about some gets as well as the sets of course. |
| [16:41:00] | andreax (andreax!~andreaz@p57B93B59.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [16:51:24] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:51:24] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [16:51:24] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:55:21] | davide (davide!~david@host103.16.intrusion.com) has quit (Ping timeout: 260 seconds) | |
| [16:58:19] | stuartm: | for the guide it probably makes sense to load on demand, requesting only two or three hours of listings at a time, how many people bring up the guide grid to schedule a recording 5 days in the future? I know I don't, it's too slow vs using the programme finder |
| [16:58:43] | stuartm: | I use the guide to browse the next few hours of listings |
| [16:58:52] | gigem (gigem!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:58:52] | gigem (gigem!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [16:58:53] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:59:15] | andreax (andreax!~andreaz@p57B92030.dip.t-dialin.net) has joined #mythtv | |
| [17:00:43] | stuarta: | it should definitely only load what i needs to display |
| [17:00:47] | stuarta: | it |
| [17:01:01] | stuartm: | well a little more, to keep scrolling fast |
| [17:01:37] | stuartm: | which is basically what I think was being discussed last night, but I've not really read scrollback carefully |
| [17:02:22] | Captain_Murdoch: | stuartm, pretty much the same here. I occasionally browse to tomorrow in the guide, but that's less than 5% of the time that I even use that screen. most of time we use the finder. to use the guide I'd have to know that something is coming on tonight. :) |
| [17:02:42] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 250 seconds) | |
| [17:04:38] | Captain_Murdoch: | we were just talking about speedups. markk mentioned possible resistance to switching off mythproto and it was mentioned that a lot of the speed issues aren't really the proto but our dataset we're sending over it. we could save some by lazy-loading parts of programinfo, but we'd save more by not having to load 1000+ programinfos when we only want 50. that logic applies on Watch Recordings, Program Guide, Program Finder, anyw |
| [17:04:38] | Captain_Murdoch: | here we load a lot of records. |
| [17:05:33] | stuartm: | yup, either I know something is on tonight because it's been mentioned to me or I'm hunting for something new to record – checking the prime-time schedules once a day is the fastest way I've found to ensure I don't miss anything which sounds interesting |
| [17:07:16] | stuartm: | I think it's a lot less complicated to load the entire PI but only load the programmes we need to display (with some frontend caching to avoid re-requesting the same info time after time) |
| [17:08:23] | stuartm: | I find all screens to be pretty fast with the exception of the Previously Recorded screen which takes an age |
| [17:11:43] | stuartm: | I'm sure there are still small optimisations that can be made in PI, especially analysing what information is really of use to the frontend (not at runtime, but generally) and around the formatting of strings/dates etc |
| [17:12:27] | danielk22: | stuartm: You feel Program Finder is "pretty fast" ? I feel that one is in brew a cup of joe while it loads territory. |
| [17:12:56] | stuartm: | if there was any question of the transfer being slow then it might be interesting to look at some fast compression options – gzip or huffman, especially for the descriptions |
| [17:14:17] | stuartm: | danielk22: pretty fast for me, loads in no more than a couple of seconds |
| [17:15:59] | danielk22: | Is count(*) program pretty low for you? Since I switched back to cable it's down to 300,000 program entries here (1/7th the top size), but the screen is still slow for me. |
| [17:16:30] | stuartm: | 4190 unique titles in my database |
| [17:17:38] | stuartm: | 45518 entries total – note that I disable all the channels I'm never going to watch which is why it's on the low side |
| [17:18:47] | danielk22: | Hmm, 41,063 uniques here.. Vastly different scale on the two sides of the Atlantic... |
| [17:19:43] | stuartm: | oh, and mythfilldatabase hasn't run for two days ... hmm, wonder why |
| [17:20:30] | stuartm: | danielk22: how many channels? |
| [17:20:45] | stuarta: | Last mythfilldatabase run started on 2006-10–17 23:28 and ended on 2006-10–17 23:28. Successful. :) |
| [17:21:07] | stuarta: | EIT data all the way... |
| [17:23:34] | abqjp (abqjp!~abqjp@71-38-211-103.albq.qwest.net) has joined #mythtv | |
| [17:23:44] | danielk22: | stuartm: 46+29+365=440 (OTA, ClearQAM (Cable), Cable (STB)) Obviously a lot of duplicates there, maybe 365 uniques. |
| [17:25:22] | stuartm: | 79 visible channels here, 514 in the database (DVB-T + DVB-S), also a number of duplicates between the two sources but the difference is clearly the number of channels I chose to make visible |
| [17:26:14] | danielk22: | Yeah, just checked and all mine are visible. |
| [17:26:28] | stuartm: | I'm actually surprised that I've hidden so many channels, I wasn't expecting the figures to be so high (or low) |
| [17:35:45] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [17:40:53] | Captain_Murdoch: | 3340 unique titles here out of 60030 total. across 82 chanids, and 3 overlapping sources: cable (NTSC), OTA (ATSC), ClearQAM. all channels visible. I think the program finder is very slow. one thing that will affect user's perception of that is FE speed. parsing 3000+ programinfos is time consuming. |
| [17:41:57] | Captain_Murdoch: | and /me realizes he mixed up 2 things. |
| [17:42:23] | Captain_Murdoch: | programsinfos aren't loaded till later, but the #'s above are still correct. |
| [17:51:32] | dblain: | in case anyone wants to experiment. the Guide/GetProgramGuide(...) & Dvr/GetRecorded(...) already allow you to retrieve only the timeframe / number of recordings you want at a time. Which allows for paging. |
| [17:52:56] | dblain: | Also the GetProgramGuide allows you to specify if you want details or not (no details makes the data per channel/program smaller) and then you can use Guide/GetProgramDetails() on a program to retrieve the additional data if needed. |
| [18:13:21] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [18:16:17] | stuartm: | stuarta: interesting rumours that C4HD has gone FTA on DVB-S prior to an official launch on Freesat in two weeks – haven't checked yet |
| [18:49:32] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv | |
| [19:09:29] | stuartm: | ah crap, looks like it might be DVB-S2 |
| [19:14:17] | stuartm: | well that sucks, DVB-S2 cards are still priced at stratospheric levels |
| [19:22:57] | clever (clever!~clever@142.167.201.71) has quit (Read error: Operation timed out) | |
| [19:31:42] | clever (clever!~clever@142.167.146.131) has joined #mythtv | |
| [20:26:42] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:28:09] | stuartm: | stuarta: we seem to have a problem obtaining the name for some channels during a DVB-S scan, but AFAIK all those channels do have user-friendly names in the SDT |
| [20:30:19] | xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0) | |
| [20:32:05] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [20:34:32] | martin__ (martin__!~quassel@h-39-23.A155.priv.bahnhof.se) has joined #mythtv | |
| [20:45:06] | stuartm: | e.g. STV HD – 3855 |
| [20:47:05] | stuartm: | and we're not obtaining a default authority for all channels with the DVB-T scan e.g. Daystar |
| [20:48:49] | sphery: | markk: On the "try OpenGL and if it fails or it's not direct rendering, use Qt painter" code, Beirdo noticed that his Mac is crashing on the makeCurrent() in the MythRenderOpenGL1 destructor. Is there something we can do to prevent that or detect that the MythRenderOpenGL and/or MythPainterWindowGL is not valid? See http://pastebin.com/3AyS9Cj3 for bt and some log excerpts. |
| [20:49:31] | Beirdo: | to be clear, the process is mythtv-setup, running on my Linux backend with the Mac as the X Server |
| [20:49:38] | Beirdo: | just in case :) |
| [20:55:01] | Beirdo: | and mythfrontend does: http://pastebin.com/ciF2N9WG |
| [20:55:08] | Beirdo: | i.e. fails back nicely |
| [21:09:14] | SteveGoodey (SteveGoodey!~steve@host86-160-33-68.range86-160.btcentralplus.com) has joined #mythtv | |
| [21:22:13] | solstice (solstice!~solsTiCe@ARennes-553-1-180-164.w2-2.abo.wanadoo.fr) has left #mythtv ("Ex-Chat") | |
| [21:27:46] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [21:37:20] | martin__ (martin__!~quassel@h-39-23.A155.priv.bahnhof.se) has quit (Read error: Operation timed out) | |
| [21:49:30] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [21:53:35] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [21:55:23] | SteveGoodey (SteveGoodey!~steve@host86-160-33-68.range86-160.btcentralplus.com) has quit (Remote host closed the connection) | |
| [22:01:41] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.191) has joined #mythtv | |
| [22:07:11] | Mousey (Mousey!~wtfisme@sea02-v600-nat.marchex.com) has joined #mythtv | |
| [22:12:10] | jmartens (jmartens!~jmartens@5ED7B7F4.cm-7-8c.dynamic.ziggo.nl) has joined #mythtv | |
| [22:13:11] | stuartm: | Beirdo: http://pastebin.com/nFhExbNt |
| [22:13:26] | stuartm: | backend crash in eit scanner thread |
| [22:13:57] | stuartm: | null pointer |
| [22:15:03] | Beirdo: | interesting. You want me to go investigate? |
| [22:16:13] | stuartm: | I figure it's likely related to the threading changes so you might be interested, but if not I'll start digging |
| [22:16:35] | Beirdo: | I'll take a look, but feel free to look from the other end too :) |
| [22:16:45] | stuartm: | the frontend has just crashed as well so I've got to start running that under gdb too |
| [22:17:19] | Beirdo: | looks like rec never got set here |
| [22:21:02] | Beirdo: | heh, that thread was changed... 3 years ago |
| [22:21:03] | Beirdo: | wow |
| [22:23:31] | Beirdo: | it looks like it might be a case where it was doing an active scan, then the active scan was stopped, then rec == NULL again, but the event thread still tries to use it |
| [22:24:55] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [22:26:38] | Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Quit: Leaving) | |
| [22:26:39] | stuartm: | Beirdo: heh, well in that case I apologise for laying it at your door, first time I've seen that crash and since it involved a QThread I jumped to conclusions |
| [22:26:47] | Beirdo: | Hey, no problem |
| [22:26:52] | jmartens (jmartens!~jmartens@5ED7B7F4.cm-7-8c.dynamic.ziggo.nl) has quit (Quit: Leaving.) | |
| [22:27:10] | Beirdo: | I don't mind taking a look anyways, I'll have a patch to try in a moment |
| [22:30:50] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.191) has quit (Quit: Leaving.) | |
| [22:31:25] | Beirdo: | stuartm: http://www.beirdo.ca/git/mythtv/commit/?h=eit . . . 29ce634fecf5 |
| [22:31:49] | Beirdo: | that hopefully would keep it from crashing. I can push it to master later if it seems to be useful |
| [22:33:06] | Beirdo: | the only thing I saw to clear out activeScan once it's been set is StopActiveScan() at the end of the file |
| [22:37:40] | stuartm: | I think danielk22, jannau or stuarta should sign off, I don't know that code well enough or maybe I'm just passing the buck because I'd rather be watching a recording right now ;) |
| [22:39:05] | j-rod is now known as j-rod|afk | |
| [22:41:38] | Beirdo: | hehe, sure, no prob. I'll leave it there anyways, and if anyone needs the URL, I can dig it out again. |
| [22:42:41] | Beirdo: | I don't use EIT at all, or I'd be happy to test it here |
| [23:10:08] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [23:34:21] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [23:36:10] | danielk22: | It doesn't look right to me. If there is no rec, should there be an activeScanNextChan? My suspicion would be that some threading start/stop code isn't working right and this is just a band-aid for a symptom. |
| [23:37:10] | danielk22: | But I haven't looked at the EIT code in years so many invariants may have changed since I wrote it... Or I may just not remember the code correctly. |
| [23:45:30] | abqjp (abqjp!~abqjp@71-38-211-103.albq.qwest.net) has quit (Quit: abqjp) | |
| [23:48:13] | danielk22: | Does anyone know how to get the list of commits by a particular developer? The trac time line doesn't do it anymore (at least I can't coax it to). man git-log doesn't seem to have anything useful & google being very un-oracle like on "filter git commits by user" |
| [23:49:43] | danielk22: | Ideally I'd get something like the trac timeline where I'd have a web page with links to view individual diffs, but I can script-fu with just the hashes. |
| [23:52:29] | Beirdo: | danielk22: I agree, that could be a band-aid, however, somehow we are getting there with rec = NULL, and we should deal with the possibility I would think. |
| [23:52:40] | Beirdo: | one sec |
| [23:53:11] | Beirdo: | git log --author=<pattern> |
| [23:53:16] | Beirdo: | i.e. regexp |
| [23:53:36] | Beirdo: | or --commiteter=pattern |
| [23:53:42] | Beirdo: | committer |
| [23:53:47] | Beirdo: | stupid fingers |
| [23:56:37] | Beirdo: | so to list all commits I authored or committed: git log --author=ghurlbut --committer=ghurlbut |
| [23:56:42] | Beirdo: | AFAIK |
| [23:56:45] | danielk22: | Thanks. I'm assuming egrep syntax; with --format that should do nicely. And yes if we can't find the source of the problem that will prevent the segfaults, I'm still hopeful we can find the underlying cause. |
| [23:57:19] | Beirdo: | yeah, the EIT stuff needs some study :) |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.