| Thursday, April 7th, 2011, 00:00 UTC | ||
| [00:00:45] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [00:03:44] | abqjp (abqjp!~abqjp@97-119-174-22.albq.qwest.net) has quit (Quit: abqjp) | |
| [00:29:55] | kormoc is now known as kormoc_afk | |
| [00:31:49] | jya (jya!~jyavenard@gw2.hydrix.com) has joined #mythtv | |
| [00:31:49] | jya (jya!~jyavenard@gw2.hydrix.com) has quit (Changing host) | |
| [00:31:49] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:33:03] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has quit (Remote host closed the connection) | |
| [00:35:11] | naf (naf!4cb887ce@gateway/web/freenode/ip.76.184.135.206) has joined #mythtv | |
| [00:35:44] | naf (naf!4cb887ce@gateway/web/freenode/ip.76.184.135.206) has left #mythtv () | |
| [00:45:18] | abqjp (abqjp!~abqjp@71-37-148-206.albq.qwest.net) has joined #mythtv | |
| [00:51:34] | abqjp (abqjp!~abqjp@71-37-148-206.albq.qwest.net) has quit (Quit: abqjp) | |
| [00:53:53] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [00:57:46] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 246 seconds) | |
| [00:57:58] | sailerboy (sailerboy!~sailerboy@ipv61.sailerboy.net) has quit (Ping timeout: 260 seconds) | |
| [01:12:24] | elmojo: | markk: I'll get you the code in a little while |
| [01:19:39] | ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has quit (Quit: Leaving.) | |
| [01:28:04] | Beirdo: | markk: just so you know, there was a user of the screenshots in jpeg format: mythweb |
| [01:28:18] | Beirdo: | but anyways, good stuff |
| [01:29:58] | elmojo: | markk: http://pastebin.com/GQ1Ma01V |
| [01:31:56] | markk: | Beirdo: does it actually need jpeg? |
| [01:32:40] | Beirdo: | well, it makes the remote interface a LOT faster over the web due to the far smaller files being transferred. |
| [01:32:56] | markk: | elmojo: doesn't look to complicated – is that 'complete' ? |
| [01:33:09] | markk: | too |
| [01:33:11] | Beirdo: | I left the jpeg there for that particular purpose when I was asked to put it back, so don't be surprised if you get a similar request :) |
| [01:33:30] | elmojo: | markk: only works for software decode but it should work correctly |
| [01:33:40] | Beirdo: | but whatever :) Good to see it get some more love. |
| [01:34:24] | elmojo: | markk: an obviously we get corruption if we use the OSD :) |
| [01:34:40] | elmojo: | but that's where we will have to make a copy if we modify the buffer |
| [01:34:45] | Beirdo: | I think the hail may have stopped. Time to go home |
| [01:36:08] | elmojo: | markk: do you have the TNGs01e03.mkv video a user posted a while back? – great for testing high ref material |
| [01:37:45] | elmojo: | I probably should have just reused the displayed queue instead of adding the done queue |
| [01:38:07] | elmojo: | I don't even think the displayed queue is used at all for software decode but is used for VDPAU |
| [01:38:39] | markk: | elmojo: TNGs ?? what's the content ? |
| [01:38:55] | elmojo: | star trek |
| [01:39:15] | elmojo: | something called The Next Generation – I guess that's Star Trek |
| [01:40:47] | markk: | elmojo: no – I don't think I've ever seen that. I use killasampla and a planet earth mkv with 9 refs |
| [01:41:25] | markk: | iamlindoro: be prepared to update that sendmessage code:) I'm going to extend it in a few days... |
| [01:41:26] | Anssi_ (Anssi_!hannulaa@mandriva/developer/anssi) has joined #mythtv | |
| [01:41:40] | iamlindoro: | nwo you tell me |
| [01:42:25] | Anssi_ is now known as Anssi | |
| [01:44:41] | markk: | don't worry – just going to add some fields for from, time, source, priority etc |
| [01:49:44] | elmojo: | markk: should we increase the num of buffers now that we are holding them until decoding and displaying is finished with them |
| [01:51:26] | elmojo: | ffmpeg uses 32 buffers and we replace them with only 31 right now |
| [01:52:50] | markk: | Beirdo: why is mythweb taking screenshots? |
| [01:53:49] | markk: | elmojo: if we need to increase the buffer size then it pretty much defeats the purpose. I want to decrease the buffer size for vdpau. (software decode shouldn't need 32 anyway) |
| [01:55:32] | elmojo: | markk: I agree on the decode side by we queue up decoded frames for display too |
| [01:55:58] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Ping timeout: 276 seconds) | |
| [01:57:01] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has joined #mythtv | |
| [01:57:20] | andreax1 (andreax1!~andreaz@p57B944FE.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [02:03:41] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has joined #mythtv | |
| [02:03:53] | Beirdo (Beirdo!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv | |
| [02:03:53] | aloril (aloril!~aloril@84.249.126.153) has joined #mythtv | |
| [02:03:53] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [02:03:53] | superm1 (superm1!~superm1@ubuntu/member/superm1) has joined #mythtv | |
| [02:08:12] | markk: | elmojo: it doesn't playback perfectly here – but it's just a matter of cpu performance – there is no picture breakup |
| [02:11:16] | markk: | elmojo: http://pastebin.com/sgNyVPHt – is my solution to terminally ill av sync. seems to work well. |
| [02:13:36] | mycoDA (mycoDA!~mycoDA@unaffiliated/mycosys) has quit (Read error: Connection reset by peer) | |
| [02:26:20] | elmojo: | markk: nice! but doesn't that cause the audio to drop everytime it drops a frame? |
| [02:32:05] | markk: | elmojo: yes – but I don't see any other way of handling it – unless jya has any ideas. if software decode is marginal and we're well behind, we just don't catch up unless we pause the audio. |
| [02:32:46] | elmojo: | markk: agreed |
| [02:33:01] | elmojo: | most players seem to have audio breakup when video can not keep up |
| [02:33:27] | Beirdo: | markk: it's a remote access type of thing where you can send keypresses, and see what's on the screen, kinda alpha/beta quality at this point |
| [02:33:39] | elmojo: | going to see if it allows me to play killasample on my laptop |
| [02:35:59] | markk: | Beirdo: ?? why? talk about re-inventing the wheel |
| [02:36:11] | Beirdo: | which wheel exactly? |
| [02:36:34] | Beirdo: | it's the only remote access to the frontend that we have in our codebase that I've heard of |
| [02:37:07] | Beirdo: | I've used it maybe twice to check a frontend setting from work |
| [02:37:11] | Beirdo: | that's about it |
| [02:37:25] | wagnerrp: | markk: its the same exact command socket weve had since pluto contracted for it |
| [02:37:31] | wagnerrp: | just now with a screenshot loop |
| [02:38:13] | wagnerrp: | not the most efficient utility, but its not really supposed to be used frequently |
| [02:38:15] | Beirdo: | gives some feedback anyways. I wouldn't be heartbroken to use png there too, personally |
| [02:39:41] | markk: | Beirdo: isn't that what vnc is for? |
| [02:40:59] | Beirdo: | heh. Perhaps so :) |
| [02:41:18] | mycoDA (mycoDA!~mycoDA@unaffiliated/mycosys) has joined #mythtv | |
| [02:41:47] | Beirdo: | anyways, I'll let xris and or kormoc fight for its survival or whatever, but just wanted you to be aware of it. |
| [02:45:24] | elmojo: | markk: killasample now plays! |
| [02:54:15] | markk: | elmojo: buffer fix or audio fix? |
| [02:55:54] | elmojo: | both :) |
| [02:56:36] | elmojo: | looks like some cleanup is needed in DiscardFrames with my patch but it seems more cosmetic than functionally needed |
| [02:57:10] | elmojo: | I say go ahead and check in the pause audio code |
| [03:00:55] | elmojo: | markk: I still don't know why we want a decode and used queue |
| [03:01:06] | elmojo: | maybe it's useful for vdpau |
| [03:03:59] | iamlindoro: | dblain, Doesn't making it use POST only prevent its use from a browser? |
| [03:17:49] | elmojo: | markk: the audio fix alone made the video playable |
| [03:24:05] | markk: | elmojo: have a beer or two on me:) planet earth with 9 ref frames now plays back without a problem with vdpau and default settings. killasampla plays fine if you bump up the vdpaubuffersize to 20 – but that is perfectly reasonable for a clip with 16 reference frames :) |
| [03:24:23] | clever: | iamlindoro: XMLHttpRequest can be used from javascript to send both GET and POST requests to the same domain as the .htm they are running from |
| [03:24:37] | elmojo: | markk: you mean vdpau works better? |
| [03:24:50] | iamlindoro: | clever, Right, which is worth exactly nothign to those wanting to access the service directly |
| [03:25:05] | markk: | elmojo: yes :) vdpau now works as it should... |
| [03:25:12] | clever: | ajax directly to mythbackend? |
| [03:25:17] | elmojo: | markk: I don't know how I did that |
| [03:25:24] | iamlindoro: | Again, useless and unfriendly |
| [03:25:34] | iamlindoro: | or rather, unfriendly to the point of uselessness to the average user |
| [03:26:09] | elmojo: | markk: DoneDisplayingFrame in vdpau doesn't even call DoneDisplayingFrame in videobuffers which contains part of the fix |
| [03:26:15] | iamlindoro: | If the only way to access a service is through ajax/javascript/HTML, then 99% of users will never use it where thye might have happily invoked a plain URL |
| [03:27:00] | elmojo: | markk: maybe just not removing limbo frames too early helped or something |
| [03:27:25] | markk: | elmojo: I haven't analysed what's going on yet – all I can say is, it works! |
| [03:27:49] | elmojo: | markk: I need to revisit your video buffer refactor and see what you changed |
| [03:28:34] | markk: | still get a bit of verbosity/complaining and picture breakup at the beginning of killasampla – but it soon settles down to normal |
| [03:28:47] | elmojo: | markk: I think we understand how things should work which is a big step – we just need to implement it correctly |
| [03:29:26] | Captain_Murdoch: | the 'biggest' issue I see with allowing GET for sending a message is ease of use for the masses to spam. at least a POST would require them to look at the man page before running apache bench against mythbackend DOS-ing the FE's. :) |
| [03:29:44] | elmojo: | markk: are you sure you wanna hold off any video buffer changes till after 0.25 release? |
| [03:29:46] | Captain_Murdoch: | and 'biggest' is in quotes because i don't see it as a big issue really. |
| [03:30:30] | iamlindoro: | Captain_Murdoch, If I wanted to cause harm to Myth I'd just tell it to delete all someone's recordings with the proto and watched as it happily did so ;) |
| [03:31:25] | Captain_Murdoch: | iamlindoro, that requires knowlege, wget and 'ab' don't. but like I said, I don't see it as an issue. the ease of use of allowing wget or similar to be used to send a message can be nice. |
| [03:32:10] | Beirdo: | wget can do post if you need it to, of course |
| [03:32:25] | Beirdo: | still not friendly :) |
| [03:33:19] | Captain_Murdoch: | right. |
| [03:34:25] | markk: | elmojo: if we can clean up your patch and get it in then I will refactor the vdpau buffer management to make it dynamic – i.e. number of reference frames + X (where X will be around 5–7). Given how much effort has gone into stabilising playback in recent times, I'd rather just leave it at that for now. |
| [03:36:32] | elmojo: | markk: ok, sounds good – the only remaining issue is to understand the relation between decoded and used queue and adjust DiscardFrames for the changes to how we control limbo and done queues |
| [03:38:52] | elmojo: | markk: ideally I'd like to get it down to available, limbo, decoded, displayed (and paused) |
| [03:46:13] | elmojo: | markk: and if you want to take the patch and improve it then please be my guest since BASIC is my most proficient language |
| [03:57:10] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [04:03:11] | markk (markk!~mark@cm180.omega173.maxonline.com.sg) has quit (Ping timeout: 276 seconds) | |
| [04:12:29] | jya: | elmojo: markk: will you backport that playback fix to 0.24 ? |
| [04:13:07] | dblain: | iamlindoro: The main reason to limit to POST, as was told to me a long time ago, was to stop web crawler type actions from modifing data. |
| [04:13:15] | jya: | I wouldn't mind backporting a lot of things myself, in a 0.24.1 while 0.25 continues evolving, so there's no so much delay between two releases |
| [04:13:39] | iamlindoro: | dblain, Understood, but in the case of the message send, nothing is modified, right? |
| [04:14:18] | dblain: | Well... an action it taken and not just data being returned. |
| [04:14:29] | elmojo: | jya: mark left the channel |
| [04:14:48] | jya: | righto... |
| [04:15:11] | iamlindoro: | dblain, It just seems such a shame to expose a method that could be simply and easily used by minimally technical users and then lock it away behind an arbitrary decision |
| [04:15:20] | markk (markk!~mark@srv120.dedicated.netrino.co.uk) has joined #mythtv | |
| [04:17:26] | dblain: | iamlindoro: I don't see it as being locked away, especially since the backend web pages exposes it now. I understand your point of view, I just figured I'd give my opinion. (I was trying to keep it as close to REST as possible. Taking an action technically shoulded be done with a POST). |
| [04:19:03] | dblain: | Not sure who has the final say... I said my peace, and am okay with however you decide to keep it. |
| [04:19:40] | iamlindoro: | dblain, I won't complain if you decide to make it POST only, and yes, I added the web page to make it even more accessible, I guess I'm mostly thinking of the new-to-linux user (and heck, some experienced ones) who wants to automate messages with something like wget + bash... meh, I don't feel strongly enough about it to fight it out |
| [04:19:56] | iamlindoro: | I would say you have the final say |
| [04:20:39] | iamlindoro: | (and yes, I know you can technically do POST with wget, but I only learned that last week, and that's the truth) |
| [04:21:34] | iamlindoro: | I won't be heartbroken either way ;) |
| [04:21:38] | dblain: | I'm not too sure I should have final say :)... Lets leave it as-is for now. It's a 1 line change to make it post only. We can audit all the methods in the future if and when a standard gets decided on. |
| [04:23:43] | Gene425 (Gene425!~textual@c-98-203-229-76.hsd1.wa.comcast.net) has joined #mythtv | |
| [04:39:33] | mikejf (mikejf!~mikejf@fabre.id.au) has quit (*.net *.split) | |
| [04:54:03] | mikejf (mikejf!~mikejf@fabre.id.au) has joined #mythtv | |
| [05:09:54] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [05:53:15] | andreax (andreax!~andreaz@p57B944FE.dip.t-dialin.net) has joined #mythtv | |
| [05:58:38] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [05:58:38] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [05:58:38] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:00:51] | andreax (andreax!~andreaz@p57B944FE.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [06:03:17] | aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 240 seconds) | |
| [06:03:20] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [06:04:02] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [06:04:02] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Client Quit) | |
| [06:04:25] | Gene425 (Gene425!~textual@c-98-203-229-76.hsd1.wa.comcast.net) has quit (Quit: Computer has gone to sleep.) | |
| [06:08:31] | martin__ (martin__!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [06:16:15] | aloril (aloril!~aloril@84.249.126.153) has joined #mythtv | |
| [07:10:34] | mikejf (mikejf!~mikejf@fabre.id.au) has quit (Ping timeout: 252 seconds) | |
| [07:42:26] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [07:45:23] | andreax (andreax!~Andreaz@tmo-100-84.customers.d1-online.com) has joined #mythtv | |
| [08:38:32] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [08:39:53] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [08:46:00] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Read error: Operation timed out) | |
| [08:56:29] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [08:58:37] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [09:06:39] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has quit (Ping timeout: 252 seconds) | |
| [09:15:17] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has joined #mythtv | |
| [09:40:06] | rambo3 (rambo3!~adnan@18.174.241.83.in-addr.dgcsystems.net) has joined #mythtv | |
| [09:52:36] | rambo3: | why u no ban rambo3 ? |
| [09:53:15] | stuarta: | it can be arranged |
| [09:55:35] | rambo3: | to the basement! |
| [10:05:02] | Guest13169 (Guest13169!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:53] | mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:19] | mike is now known as Guest33480 | |
| [10:36:14] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [10:49:41] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has quit (Ping timeout: 252 seconds) | |
| [10:59:04] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 248 seconds) | |
| [11:17:36] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [11:19:20] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [11:20:27] | purserj_ is now known as purserj | |
| [11:53:48] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [11:57:31] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 246 seconds) | |
| [11:57:52] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has joined #mythtv | |
| [12:02:32] | markk (markk!~mark@srv120.dedicated.netrino.co.uk) has quit (Ping timeout: 248 seconds) | |
| [12:19:19] | markk (markk!~mark@cm180.omega173.maxonline.com.sg) has joined #mythtv | |
| [12:25:50] | kwmonroe (kwmonroe!~kwmonroe@cpe-70-113-204-146.austin.res.rr.com) has quit (Quit: Ex-Chat) | |
| [12:56:22] | rambo3 (rambo3!~adnan@18.174.241.83.in-addr.dgcsystems.net) has quit (Ping timeout: 276 seconds) | |
| [12:57:50] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has joined #mythtv | |
| [12:58:27] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Read error: Operation timed out) | |
| [12:58:34] | kc (kc!~Casper@unaffiliated/kc) has quit (Read error: Operation timed out) | |
| [12:58:41] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has quit (Read error: Operation timed out) | |
| [13:00:47] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [13:01:39] | rambo3 (rambo3!~adnan@18.174.241.83.in-addr.dgcsystems.net) has joined #mythtv | |
| [13:10:09] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv | |
| [13:19:36] | andreax (andreax!~Andreaz@tmo-100-84.customers.d1-online.com) has quit (Read error: Connection reset by peer) | |
| [13:29:56] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [13:33:10] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:41:49] | j-rod|afk is now known as j-rod | |
| [13:46:14] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 276 seconds) | |
| [13:47:13] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [13:48:28] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has quit (Ping timeout: 246 seconds) | |
| [13:58:42] | martin__ (martin__!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection) | |
| [13:59:02] | stuartm: | at the risk of stumbling at the first hurdle, anyone object to importing libmysld? It seems not all distros package a dynamically linkable version, including my own – Mandriva |
| [14:04:45] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 264 seconds) | |
| [14:05:00] | stuartm: | if I don't fall at the first, I'm definitely in trouble at the second – "InnoDB is not reentrant in the embedded server and cannot be used for multiple connections, either successively or simultaneously." |
| [14:05:27] | stuartm: | that's a fairly serious drawback considering that we wanted to switch from MyISAM to InnoDB throughout |
| [14:09:45] | markk: | stuartm: do you mean libmysqld ? |
| [14:32:29] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [14:32:29] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [14:32:29] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [14:35:09] | iamlindoro: | stuartm: Assuming it's possible to make it work acceptably, I am all for it-- sphery may have some insight, I think he's done some more-than-casual investigation |
| [14:35:33] | iamlindoro: | Well, all for it assuming it's not hundreds and hundreds of MB :) |
| [14:38:34] | Captain_Murdoch: | something else we might want to consider is the squeezebox server approach of just starting up their own mysqld instance. I can see performance suffering if we have a single-request-at-a-time pipeline to get to the DB. |
| [14:39:49] | Captain_Murdoch: | ie, the scheduler is running, so I'm held up trying to load the recording list |
| [14:40:01] | Captain_Murdoch: | or the seektable for a recording, etc.. |
| [14:47:11] | Captain_Murdoch: | stuartm, http://forums.mysql.com/read.php?58,298357,298357 also http://bugs.mysql.com/bug.php?id=13768 so that definition of 'reentrant' may not be what we're thinking. |
| [14:55:52] | Captain_Murdoch: | a slow migration to an embedded database could be a possible method as well. start with something like the settings table. it would be easy to convert MythCoreContext::*Setting() to use the MBE connection to get/set settings. then gradually convert other tables over. |
| [14:57:02] | iamlindoro: | You'll never break every user's random bash + mysql hack scripts with that attitude, mister |
| [14:57:46] | Captain_Murdoch: | :) |
| [15:01:34] | andreax (andreax!~andreaz@p57B944FE.dip.t-dialin.net) has joined #mythtv | |
| [15:04:41] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 240 seconds) | |
| [15:05:47] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [15:05:47] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [15:05:47] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [15:14:50] | Captain_Murdoch: | msg stuartm forgive the spaces in their URL. :) |
| [15:14:54] | Captain_Murdoch: | toh |
| [15:14:57] | Captain_Murdoch: | doh even |
| [15:21:13] | martin__ (martin__!~quassel@h-39-23.A155.priv.bahnhof.se) has joined #mythtv | |
| [15:24:18] | Jordack is now known as Jordack-Lunch | |
| [15:28:05] | stuarta: | anyone know or have heard of KaZeR (currently on as KaZeR_W) |
| [15:30:05] | stuarta: | freenode staff have made me aware that he wants control of #mythtv-fr |
| [15:30:29] | stuarta: | and as i'm the GC they've come to me for clarification / authorization / rejection |
| [15:30:52] | stuarta: | having just popped into the channel, he's the only one there :) |
| [15:31:06] | stuarta: | and the linked website in channel doesn't work |
| [15:31:22] | ** stuarta is currently leaning toward *reject* ** | |
| [15:31:44] | stuarta: | answers on a postcard as i'll shortly be away for a few days |
| [15:32:23] | iamlindoro: | He user to turn up in -users a bit |
| [15:32:31] | iamlindoro: | er used |
| [15:32:44] | iamlindoro: | ISTR him being a bit.... outspoken |
| [15:33:07] | iamlindoro: | still in users, in fact |
| [15:33:07] | ** stuarta hmms ** | |
| [15:33:43] | iamlindoro: | You could ask him :) |
| [15:34:10] | ** iamlindoro should really try autocomplete before he runs !seen on people ** | |
| [15:34:21] | stuarta: | well i plan to, once i'm back from my weekend... |
| [15:34:24] | iamlindoro: | embarassing to get caught stalking them :) |
| [15:34:26] | stuarta: | EMOTIVATION |
| [15:34:50] | stuarta: | ah feck it |
| [15:34:58] | ** stuarta joins -users again ** | |
| [15:35:58] | stuarta: | that kazar is not around |
| [15:36:19] | iamlindoro: | sure he is |
| [15:36:29] | iamlindoro: | e-r |
| [15:36:48] | iamlindoro: | He's in users as we speak |
| [15:37:17] | stuarta: | yes, he's there, but not at the keyboard connected to that nick |
| [15:37:29] | stuarta: | he's on an alt which isn't in users |
| [15:38:44] | iamlindoro: | ah, sorry |
| [15:39:02] | stuarta: | no worries. both of him are in #mythtv-fr |
| [15:39:24] | stuarta: | whether either of them are keyboard connected is a different matter |
| [15:40:33] | martin__ (martin__!~quassel@h-39-23.A155.priv.bahnhof.se) has quit (Ping timeout: 260 seconds) | |
| [15:40:51] | abqjp (abqjp!~abqjp@97-119-174-22.albq.qwest.net) has joined #mythtv | |
| [15:46:01] | Cougar (Cougar!~cougar@kkk.version6.net) has quit (Ping timeout: 276 seconds) | |
| [15:57:40] | stuartm: | Captain_Murdoch: embedding wouldn't restrict the number of connections we'd be able to make, and embedded mysql is supposed to be measurably faster than the server, from my research it should be a drop-in replacement except for the direct remote-access issue, but even that is relatively simple to fix |
| [15:57:57] | stuartm: | libmysqld is around 60MB iirc |
| [15:59:42] | Captain_Murdoch: | stuartm, I was referencing your non-reentrant quote. normally that'd mean all access is mutex-ed or single threaded, but it doesn't sound like that is the case based on some comments I've seen. |
| [16:00:40] | stuartm: | if anything, a straight switch would be simpler than a slow migration since everything _should_ be pretty much identical to how it's done now – code changes would be minimal and the only new code would be an extension to the protocol to handle the queries via the backend (or a new app to do the same which I know some people favour) |
| [16:00:49] | Captain_Murdoch: | my comment RE: the settings table is because I think we can take a methodical approach to getting things converted over rather than an all-or-nothing approach. so the migration could take months or MythTV versions. |
| [16:01:37] | iamlindoro: | Or we could stop extending the protocol in favor of standardizing on the new API :) |
| [16:01:41] | stuartm: | Captain_Murdoch: the reenterent issue only comes about if we switched to innodb which would be nice but the benefits of embedding trumps the benefits of innodb |
| [16:01:43] | Captain_Murdoch: | code changes woudl be huge unless we put in a wrapper and pass SQL over the protocol. |
| [16:02:14] | stuartm: | Captain_Murdoch: all the code changes would be at one point, where we make the DB connection, so one file gets modified |
| [16:02:29] | stuartm: | Captain_Murdoch: we're already using a wrapper for DB access |
| [16:02:41] | Captain_Murdoch: | so you're saying pass SQL instead of adding myth proto commands for things |
| [16:02:48] | stuartm: | Captain_Murdoch: yes |
| [16:03:06] | stuartm: | nothing to be gained from re-inventing the wheel |
| [16:04:03] | Captain_Murdoch: | ok, just verifying. I didn't know that approach was being considered. I thought we were talkinga bout replacing all SQL with API calls in non-MBE code. |
| [16:04:11] | sphery: | stuartm: embedded mysql is a single process database--only a single process can access the data, thus the need for a mythdataserver or similar (becomes the network data server)... My plan was to start by converting existing code to use the data server (which I planned to work on as soon as I've got mythtvd pushed--and the mythbackend/mythjobqueue split done as the first step), and I /really/ don't want to pass SQL over the protocol |
| [16:04:24] | stuartm: | iamlindoro: in the spirit of 'just getting it done already' I'm going to implement the changes and then we can worry about making it work with the new protocol afterwards :) |
| [16:04:36] | iamlindoro: | stuartm: I can appreciate that :) |
| [16:05:18] | Captain_Murdoch: | passing raw SQL over proto isn't much better than where we are at if we have the API people can use to send random SQL over the proto. |
| [16:05:20] | stuartm: | sphery: I'm aware, which is why I'm talking about a new app or having the master backend be that process |
| [16:05:29] | sphery: | I'd like to use protobuf for the data server protocol, and create an extensible data protocol that allows varying levels of access |
| [16:05:44] | sphery: | yeah, agreed... if we just pass raw sql over proto, we're back to where we are now |
| [16:06:17] | stuartm: | Captain_Murdoch: it's a million times better if first-time users can avoid the whole DB creation and need to configure/run the mysql server – that's the primary goal for me, at least in the initial implementation |
| [16:06:33] | sphery: | anyway, I planned to stage it as a) create mythdataserver process to hit the current mysqld server, b) slowly migrate existing data access to mythdataserver, c) convert mythdataserver to use embedded mysql |
| [16:06:47] | Captain_Murdoch: | that's my reasoning for saying start with something like (get|save)setting(). add the builtin DB and migrate use cases over slowly. |
| [16:07:02] | sphery: | though I have to admit that I'm wavering on step c), now, because jams was saying that all apps he knows of that use embedded mysql tend to eat their own data files |
| [16:07:12] | sphery: | and that performance is very bad |
| [16:07:17] | stuartm: | the whole reason this project has got no-where in 6 years of talking about it is because a whole bunch of a addendums/goals were added until it collapsed under the weight |
| [16:07:27] | sphery: | so I was planning to do some serious investigation of that |
| [16:07:29] | Captain_Murdoch: | stuartm, yeah, I can agree on that as long as the end goal is to get rid of SQL myth protocol command. |
| [16:08:03] | Captain_Murdoch: | stuartm, where 'that' is the merging it in with a temporary wrapper. |
| [16:08:13] | sphery: | stuartm: I have a patch in my tree right now that's the first step to mythtvd and will likely have a second very soon and then will push mythtvd if I can get approval |
| [16:08:23] | stuartm: | sphery: everything I've read says the opposite, that performance is better, but I'm not adverse to making an external db an option – if it means we can get the embedded DB implemented |
| [16:08:28] | sphery: | (the 2nd is just another, simpler version of the first) |
| [16:08:43] | sphery: | I'm actually working toward that, in conjunction with the split, right now |
| [16:09:55] | sphery: | I'll also admit that my primary motivation is to protect DB access and the lack of DB setup is a secondary motivation, though |
| [16:10:04] | sphery: | which is why I planned for the embedded mysql last |
| [16:10:06] | Captain_Murdoch: | sphery, not sure if you saw my comment earlier, but one other option is a dedicated, self-started instance of mysqld like squeezebox server uses. |
| [16:10:12] | stuartm: | being brutally honest I didn't want to get into a debate over the changes, I was just going to make them and then provide a working patch |
| [16:10:47] | stuartm: | and I don't want to wait for future architectural changes, future protocols etc |
| [16:11:18] | Captain_Murdoch: | stuartm, now you hurt my feelings. :) I say go for it. same mentality that iamlindoro and I are using with the HTML settings rewrite parts we've been working on. |
| [16:12:59] | Captain_Murdoch: | we could give the option of libmysqld or dedicated spawned copy of mysqld. dedicated spawned copy of mysqld gives us the ability to use external backup tools rather than having to rewrite things like that. |
| [16:13:45] | Captain_Murdoch: | as soon as we embed, we have to worry about maintenance tasks. |
| [16:13:46] | stuartm: | Captain_Murdoch: heh, well I'm trying to reignite my interest in working on Myth and finally nailing the issues which I consider core to progressing MythTV is sufficiently interesting – but only if they don't get mired in committee all over again :) |
| [16:14:21] | stuartm: | Captain_Murdoch: that's all possible given how Qt abtracts the interface for us |
| [16:14:31] | Captain_Murdoch: | yeah, fine by me. |
| [16:16:44] | stuartm: | the changes I'm making shouldn't be too hard for everyone to agree on, even if people have plans to make improvements in future releases, but I thought importing the library might be deal-breaker given it's size |
| [16:17:25] | iamlindoro: | I think 60 MB, given the speed of modern connections and what we stand to gain, is a small price to pay |
| [16:18:33] | stuartm: | I need to double check the figure, it's been a while since I looked at it |
| [16:19:23] | sphery: | I'm not worried about the 60MB, but I will remove the SQL in protocol once I have the rest done. :) FWIW, http://code.mythtv.org/trac/attachment/ticket . . . _query.patch (which probably needs a bunch of improvement) |
| [16:19:33] | stuartm: | sat down to work on this only to find that the current release of mandriva doesn't ship with the files and that was a problem :) |
| [16:21:39] | sphery: | yeah, I do /not/ want to rely on system-provided libmysqld, so including the libs in our code is a better approach |
| [16:21:47] | stuartm: | sphery: I don't mind if people want to completely re-write whatever I come up with :) |
| [16:23:07] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [16:23:39] | stuartm: | sphery: so long as re-writing it doesn't mean another six years with users having to mess with my.conf and running bash scripts etc as root before they can even begin to configure/run mythtv |
| [16:23:41] | Captain_Murdoch: | stuartm, might be best to just use a dedicated self-started mysqld instance to simplify things initially then. you don't have to worry about backups, etc. then. then libmysqld can be included once we have the ability to back an embedded DB up. not sure if that's less coding than implementing backup and restore procedures, but it seems like it would be. |
| [16:24:15] | sphery: | stuartm: heh, no--my main interest is in the dataserver stuff. If you have embedded db working, I won't switch back. |
| [16:25:01] | Captain_Murdoch: | to me the goal isn't really 'embedded', it's 'dedicated, under full control of MythTV'. |
| [16:25:08] | stuartm: | Captain_Murdoch: I'll make a judgement when I get past my initial testing |
| [16:25:26] | sphery: | I'll start pushing the patches I need before putting mythtvd (daemon runner) in place (and then get permission to push mythtvd) so that we can get a data server binary in place |
| [16:26:19] | sphery: | that will make it much easier for me--and easier for people to find the code and make it easier for people who want to run the data server on a different machine from the master backend |
| [16:27:01] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [16:27:02] | sphery: | Captain_Murdoch: agreed... dedicated and controlled is a good thing |
| [16:27:04] | Captain_Murdoch: | sphery, if we have embedded database, then I see the MBE (or mythmaster) as the dataserver, no need to break the data serving out IMHO. |
| [16:27:34] | sphery: | why not break it out so we don't have all that garbage cluttering up the mythbackend binary? |
| [16:28:02] | sphery: | actually, if all it is now is a QUERY_SQL proto command, in the mbe is fine |
| [16:28:07] | sphery: | but in my view of it, it's much more |
| [16:28:36] | sphery: | so we can break it out later, if that's the approach that's used |
| [16:28:54] | Captain_Murdoch: | yeah, it's much more, but then we have requests for some things going to the MBE, some going to the data server, some going to the MBE then to the dataserver, etc.. |
| [16:29:12] | stuartm: | UX has become my motivation and I still remember how clumsy it seemed that I needed to configure an external database – it's something I was intimately familiar with at the time as I was doing lots of web-app work and I can only imagine how it must seem to a complete mysql/linux novice |
| [16:29:45] | iamlindoro: | terrifying |
| [16:30:01] | Captain_Murdoch: | if we have a dedicated 'master' process, I don't see a huge benefit of breaking out the dataserver unless we want clients to be able to bypass the MBE to talk to the dataserver (which is valid if that's what we want to do). |
| [16:30:07] | ** iamlindoro was a major linux novice the first time he tried (and the second, and third... and fourth... until he finally got it) ** | |
| [16:31:11] | skd5aner: | maybe today – but in the early 2000s when I first started playing with linux, mysql was the least of my problems with a linux desktop (but I *do* agree with you) |
| [16:32:43] | foxbuntu (foxbuntu!~foxbuntu@67-3-90-63.desm.qwest.net) has joined #mythtv | |
| [16:32:43] | foxbuntu (foxbuntu!~foxbuntu@67-3-90-63.desm.qwest.net) has quit (Changing host) | |
| [16:32:43] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv | |
| [16:32:45] | skd5aner: | but – who cares about 6+ years ago – we now live in the days of "plug-and-play" distros – the concept of an end-user needing to install a service is almost non-existant and the crowd using linux isn't the same as it once was – it's creeping into people who have no clue what a DB is even |
| [16:33:23] | skd5aner: | there are people who want to try out mythtv because it's "free" who barely even know what DVR stands for :D |
| [16:34:31] | stuartm: | fwie, my first run will make the MBE the proxy, that's probably the simplest implementation in code terms and also the easiest for the end-user to understand – I grant that the MBE spawning a new process would be largely transparent to the end-user but it would remain a source of confusion IMHO – "I've run mythdataserver but I cannot record anything!", "My backend keeps starting something called mythdataserver, how can I stop it?!" |
| [16:35:26] | ** dblain hopes that whatever new commands are added that the developer keeps the new API framework in mind. ** | |
| [16:35:32] | skd5aner: | that said, I think the only "flack" that you are hearing is those power users who have been on the FOSS/linux band wagon for the power and flexibility it provides and they may be worried that some of that flexibility is going away – and probably that's not really the case, the just don't understand the scope of the proposal and just hear "OMG MYSQL IS GOING AWAY!!1!" |
| [16:36:08] | dblain: | I always envisioned mythbackend being the main media server (data server) and the recording capability be stripped out into seperate processes. |
| [16:36:45] | dblain: | That way platform specific recorders could easily be swapped in and out leaving the backend alone. |
| [16:37:10] | Captain_Murdoch: | skd5aner, the switch to embedded is so that we can secretly switch to postgresql. basically libmysqld dir will just be a misnamed dir containing postgresql source. |
| [16:38:04] | Captain_Murdoch: | dblain, yeah, that's what I was picturing. I think we want to get away from the FE's going one place for some data and another place for different data. funnel it all through the MBE/mythmaster. |
| [16:38:25] | stuartm: | dblain: I might upset you if I answered that truthfully :) |
| [16:38:26] | dblain: | Captain_Murdoch: agreed. |
| [16:39:26] | stuartm: | I'm sure that the new API will be used for this after I'm done with it but since my whole approach is a 'just do it'/'no distractions' I won't be touching the new API – that would require me to spend time reading up on, discussing and then understanding the new code which I've not had time to do as it was being committed |
| [16:39:31] | Captain_Murdoch: | if mythdataserver is separate, then we now have to worry about multiple sockets w/ timeouts etc., multiple 'can I shutdown' code areas, etc.. |
| [16:39:34] | dblain: | stuartm: when I say "keep the new API framework in mind" I don't mean you must use it. Just implement the functionality is methods that can be exposed using the API (i.e. no protocol specific formatting embedded in it) |
| [16:39:53] | stuartm: | dblain: right, that's fair |
| [16:40:57] | ** stuartm gets to work ** | |
| [16:41:13] | skd5aner: | and don't come back till you're done! ;D |
| [16:41:35] | Captain_Murdoch: | skd5aner, he'll get it done much faster that way. :) |
| [16:42:56] | skd5aner: | well – I haven't had any new stuff to put in the changelog since March – so I'm in support of that :) BTW – good work so far on the setup stuff Captain_Murdoch – I haven't personally played with it, but I'm seeing all the work going into it |
| [16:43:19] | sphery: | skd5aner: yeah, they'll complain that, "I need to be able to connect to the db with mysql client so I can edit my channels or modify my data or ..." (Of course, some have also said that they need to run their mysql on a separate server since their master backend is a pogoplug, but I'll let Captain_Murdoch talk some sense into them. :) |
| [16:43:31] | Captain_Murdoch: | mostly playing around and I'm sure some will get (or needs to be) rewritten. :) |
| [16:44:23] | skd5aner: | sphery: 80/20 rule... 80% of users don't care and embedded is the way to go, but 20% want the transparency/modularness of the externallized solution – eh, both have merits, but 80 always beats 20 :) |
| [16:45:13] | skd5aner: | Captain_Murdoch: hey – a good foundation none-the-less, that's usually the hardest step – creating something from nothing |
| [16:45:19] | Captain_Murdoch: | sphery, hey, no bashing the pogoplug, I picked up one off ebay a few months ago. use it as a backups server and squeezebox slave. plan is to put it at the opposite end of the house from the servers since it's silent and can serve as a music player in the MBR (master bedroom) |
| [16:45:30] | anykey__ (anykey__!~guedel@46-126-247-133.dynamic.hispeed.ch) has quit (Quit: leaving) | |
| [16:46:03] | skd5aner: | Captain_Murdoch: hope you don't have a SBR – eek! |
| [16:50:03] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [16:50:27] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [16:50:27] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [16:50:27] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [16:51:36] | sphery: | Captain_Murdoch: Heh, wasn't bashing it, per se... Just the usual "right tool for the job" argument against using it as a master backend. |
| [16:52:41] | Captain_Murdoch: | :) just kidding. my target for my MBE is my old BEFW11S4 (not even the more powerful WRT54G) |
| [16:53:13] | gigem (gigem!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:53:13] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:53:13] | gigem (gigem!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [16:53:38] | Captain_Murdoch: | skd5aner, those are called the KBRs (Kids BedRooms) |
| [16:54:14] | skd5aner: | yea, I'm about to have my first KBR in about 2 months |
| [16:55:09] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 264 seconds) | |
| [16:55:31] | kormoc_afk is now known as kormoc | |
| [16:57:19] | Jordack-Lunch is now known as Jordack | |
| [17:04:00] | stuartm: | of the 20% (arbitrary figure that it is), 15–18% of those only want direct access because of deficiencies in the UI for things like editing channels |
| [17:04:29] | stuartm: | between the setup re-write, the new API etc they should other/better ways to do whatever they want to do |
| [17:05:47] | stuartm: | you don't get Amarok users protesting that they can't fiddle directly with their database, they a) don't need to b) have never been able to |
| [17:06:21] | stuartm: | Amarok 3 might not be the best example because although popular it has one of the worst UIs I have ever seen |
| [17:13:28] | jams: | amarok3 is a great example of messing up a good program. Amarok3 for me is unresponsive and likes to thrash and crash. |
| [17:15:22] | iamlindoro: | With the above said, we were victims to similar attacks in the MythUI port, all you have to do is sub out the program name-- it took time to recover from such a major change, which was partially user muscle memory and partially us fixing the inevitable bugs and incomplete bits |
| [17:15:33] | iamlindoro: | Maybe amarok 4 will kick ass ;) |
| [17:18:29] | jams: | right as you said bugs have been fixed...amarok3 not so much. |
| [17:34:47] | wagnerrp: | is that 60MB resident, or 60MB including all the shared libs? |
| [17:35:15] | wagnerrp: | besides which, if people are running the mysql database internally, most people wont otherwise need to run mysqld at all |
| [17:35:26] | wagnerrp: | and those that do will probably have hardware that can spare the 60MB |
| [17:37:17] | skd5aner: | I'm one that will still need to run MySQL for other reason on the same hardware – all I care about is that it won't cause resource contentions and will play nicely on the same system |
| [17:37:22] | iamlindoro: | Kind of puts the 12 MB worth of frontend they refuse to install in perspective |
| [17:39:05] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has quit (Quit: Leaving) | |
| [17:58:56] | sphery: | not to mention the 9MB worth of X libs... though I thought stuartm was saying 60MB of source code for the libmysqld stuff |
| [18:02:32] | stuartm: | wagnerrp: I was talking disk-space, not memory requirements |
| [18:03:54] | wagnerrp: | oh |
| [18:06:17] | stuartm: | and it seems the disk-space I was remembering was compiled size, not quite sure what the source-code size is since I've not establised what bits we need and what bits we don't, but it should be considerably less than 60MB |
| [18:07:10] | stuartm: | the total mysql source tarball is 200MB uncompressed but it includes documentation and test apps etc which consume the bulk of that |
| [18:09:56] | stuartm: | we can save on space by only including/building the bits we need, e.g. engines |
| [18:10:16] | andreax (andreax!~andreaz@p57B944FE.dip.t-dialin.net) has quit (Ping timeout: 246 seconds) | |
| [18:10:55] | stuartm: | so it shouldn't be too bad, rss might actually be lower than the standalone server for that reason alone |
| [18:11:45] | andreax (andreax!~andreaz@p57B92AA9.dip.t-dialin.net) has joined #mythtv | |
| [18:37:47] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:12:12] | gigem (gigem!~david@host103.16.intrusion.com) has joined #mythtv | |
| [19:12:12] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [19:12:12] | gigem (gigem!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [19:22:46] | sailerboy (sailerboy!~sailerboy@ipv61.sailerboy.net) has joined #mythtv | |
| [20:02:52] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [20:08:56] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Ping timeout: 248 seconds) | |
| [20:16:47] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit () | |
| [20:16:53] | mosburn (mosburn!~mosburn@67-41-146-194.hlrn.qwest.net) has quit (Ping timeout: 276 seconds) | |
| [20:19:50] | mosburn (mosburn!~mosburn@67-41-146-194.hlrn.qwest.net) has joined #mythtv | |
| [20:24:19] | weta is now known as weta_back7pmEDT | |
| [20:25:34] | mosburn (mosburn!~mosburn@67-41-146-194.hlrn.qwest.net) has quit (Ping timeout: 246 seconds) | |
| [20:25:39] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [20:34:41] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [20:41:43] | mosburn (mosburn!~mosburn@67-41-146-194.hlrn.qwest.net) has joined #mythtv | |
| [20:44:52] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has joined #mythtv | |
| [20:51:06] | Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv | |
| [21:10:56] | skd5aner: | k – need some newb help please... I'd like to submit a patch to several files I've updated for mythweb, what's *simplest* way to submit those without creating a git account and all the jazz |
| [21:11:12] | skd5aner: | er, all that jazz |
| [21:12:23] | skd5aner: | I should clarify, what's the easiest way to create the patches and then submit them |
| [21:16:30] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has quit (Read error: Operation timed out) | |
| [21:23:09] | Captain_Murdoch: | you don't need a git account to submit a patch. just "git diff > /tmp/my_new_mythweb_patch.diff" in your working tree then upload that diff file. |
| [21:23:37] | Captain_Murdoch: | you do need a git checkout, but don't need a git login to have a checkout. |
| [21:24:20] | sphery: | skd5aner: You don't need a github account to clone the repo from github (use the public/anonymous URIs--the ones we mention mentioned on the http://code.mythtv.org/trac/ page). Then just submit patches to our Trac. |
| [21:24:36] | sphery: | (was most of the way through typing that when Captain_Murdoch replied, but I didn't feel like clearing it :) |
| [21:25:06] | skd5aner: | ok, let me give it a go :) |
| [21:25:18] | ** Captain_Murdoch falls off his chair out of shock that he beat sphery to the semi-answer. :) ** | |
| [21:25:39] | Captain_Murdoch: | those 2 years of typing in high school must have paid off. |
| [21:26:19] | sphery: | Heh, I'm known as the slow one in #mythtv-users--wagnerrp and iamlindoro always answer before me. Plus, tired after a run. :) |
| [21:26:24] | skd5aner: | hmmm, it creates an empty .diff file |
| [21:26:47] | skd5aner: | ahh... hang on a sec... |
| [21:26:57] | Captain_Murdoch: | skd5aner, 'git status' will show you if any files have changes in them or if there are any new files not under git control. |
| [21:26:59] | skd5aner: | nope – thought I might have done something else... |
| [21:27:08] | sphery: | skd5aner: did you commit changes? if so, you'll need: git diff origin/master HEAD > wherever |
| [21:27:36] | skd5aner: | nope – this is the stuff I know 0 about – dumb user trying to contribute some trivial changes |
| [21:28:01] | skd5aner: | and I'm doing it against 0.24-fixes branch, but these shouldn't have changed to what's in master |
| [21:28:44] | skd5aner: | so, here's what I've done... git clone -b fixes/0.24 git://github.com/MythTV/mythweb.git |
| [21:28:50] | skd5aner: | then I've edited some files in there – that's it |
| [21:29:00] | sphery: | let's switch over to #mythtv-users, so we can do detailed checks |
| [21:29:05] | skd5aner: | ok |
| [21:39:26] | stuartm: | does anyone have a link to those iOS icons that Robert mentioned on the list just now? |
| [21:40:20] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.) | |
| [21:53:33] | gigem: | regarding the db changes, you guys are plotting, i've no problem with making things easier for the user, but i do have a couple of concerns from a (well, part-time) developer's point of view. |
| [21:53:38] | gigem: | first, will there still be some form of sql cli available to developers, preferably without having to stop the master backend first? surely, you guys don't intend for everyone to write c++ code we need to debug, check, repair, etc. things in the database. |
| [21:53:43] | gigem: | second, i really, really, really hope the backend --testsched function can be maintained. it's extremely useful for me to be able to test many changes without having to start/restart a real backend and extract logs. it's also very handy to ask a user to run it when the cause of a scheduling issue isn't obvious. |
| [21:54:03] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has quit (Quit: Ex-Chat) | |
| [21:55:55] | mosburn (mosburn!~mosburn@67-41-146-194.hlrn.qwest.net) has quit (Quit: Leaving) | |
| [21:56:04] | sphery: | gigem: if we do go to embedded mysql, you can get still open the files using mysqld and attach a mysql client to the db... however, you wouldn't do that when the embedded db has the database open |
| [21:59:38] | gigem: | sphery: that's why i'm asking. i used sqlite a while back on something for work, and although it some basic support for multiple processes acessing the database at the same time, it didn't work that well, imo. with myth, i'd really hate to have to shutdown the master backedn or dataserver in order to query the db via a cli. i guess that puts me in the dedicated as opposed to embedded server camp. |
| [22:06:20] | sphery: | As far as the writing C++ goes, if it's just a QUERY_SQL on the protocol, then you could use perl or python bindings (where python bindings would give you full readline capabilities) or, I would assume, the web API, to submit the queries--and you could (or wagnerrp probably would) create a nice development client for doing so. I had a more expansive plan, but it still wouldn't require writing C++ code to get data from the DB--would basically ... |
| [22:06:26] | sphery: | ... just consolidate all SQL into a text file(s) and use some code generators--but would allow direct access of any and all db data, too. |
| [22:07:18] | sphery: | and, yeah, whatever we do will support all in-mythtv use cases--including testsched |
| [22:08:28] | sphery: | I have a feeling, though, I'll need to actually demo my approach to get support for it--which means will need a working implementation, so it won't happen for a while. |
| [22:09:22] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [22:11:06] | wagnerrp: | sphery: i dont think the existing serialization in the protocol would be sufficient for properly handling SQL |
| [22:12:47] | wagnerrp: | im certainly not keen on relying on clients to manage type safety and the like |
| [22:13:23] | sphery: | wagnerrp: I agree, which is why I planned to do the embedded DB part last (and, initially, as an option configuration--with mysqld also supported) |
| [22:13:49] | wagnerrp: | im talking about a QUERY_SQL command on the protocol |
| [22:14:03] | sphery: | my approach would have used protobuf, and wouldn't allow any QUERY_SQL at all |
| [22:14:27] | gigem: | sphery: prolly. fwiw, i like the slow, deliverate, systematic (my words) approch i think you or Captain_Murdoch suggested. the do everything at once way leaves too much room for an "oh, sh*t! i didn't think of that. now, how are we going to fix it?" momemnt. |
| [22:14:37] | wagnerrp: | the problem with protobuf is it is statically defined |
| [22:14:41] | wagnerrp: | no dynamic serialization |
| [22:16:17] | sphery: | wagnerrp: and dynamic access is the cause of most of our data integrity problems :) I.e. clients or programs doing things that they think they should--even if it's not something we want to allow... But that's just my opinion. |
| [22:21:31] | stuartm: | gigem: we have been doing this by the extremely slow approach, it's at least 6 years in the making ;) |
| [22:22:54] | stuartm: | and with the complexity of some proposals I really don't see it ever happening unless someone takes unilateral action |
| [22:24:57] | stuartm: | there really isn't anything too complicated about taking the initial step of having the backend deal directly with an embedded database, that's the easy bit relatively speaking (we have to import some mysql code and build our own QT plugin, but that's not hard it's just ugly) |
| [22:26:46] | stuartm: | efficiently allowing frontend clients and slave backends to access the database is a little harder, but until I try I really don't know how hard and if I achieve nothing else except answering these sorts of questions we'll at least have made more progress than we've made in years |
| [22:30:26] | stuartm: | all this interests proves that I should have followed my first instinct and kept quiet until I had a working patch :) |
| [22:30:28] | gigem: | stuartm: which is why i like sphery's approach – chenage the frontends (and slave backends) first. then when you are abosulutely sure they don't need direct db access, then you can make the next change. |
| [22:31:43] | stuartm: | gigem: even with the best efforts of everyone that would likely take months, I've lost all faith that it will happen unless we force the issue |
| [22:34:18] | sphery: | yeah, my approach is a very slow approach--but since only the process that's running the embedded DB will have access to the DB (and no connections can be made from other processes--it's not a multi-user or client/server database), we /have/ to convert all MySQL access (meaning in remote backends and all frontends and all plugins and all 3rd party clients) to use some non-SQL approach to get data, we kind of have to do the other conversions ... |
| [22:34:20] | stuartm: | I really don't know that it's impossible to allow the remote clients access in an efficient manner with the minimum of new code, I don't think anyone knows that for a certainty, most of the talk about eliminating sql usage in remote clients has to do with data integrity and nothing really to do with embedding the database |
| [22:34:24] | sphery: | ... "first", too |
| [22:35:29] | sphery: | that said, we can do a quick "just get it done" approach, then fix it later to do it with a safer approach, at making a data server process, but that would mean 2x the effort for external projects (adapting to the 2 different data server approaches) and even extra work for us |
| [22:35:58] | stuartm: | sphery: we won't 'have' to ... those clients aren't even dealing with directly with the server anyway, they interface through the mysql client on the local machine which utilises the mysql internal protocol to send the SQL to the server |
| [22:37:32] | stuartm: | and from our POV it's a tiny change made to our existing database wrapper (which itself is wrapping a QT wrapper btw) to treat local/remote differently |
| [22:37:48] | sphery: | right, so you rewrite Qt's MySQL driver to work with your own protocol that passes SQL commands for execution elsewhere, then passes back data (and handles all buffering, caching, etc.), then we rip it out later if we disallow direct SQL from clients |
| [22:37:51] | stuartm: | nothing would need to change in plugins or the frontend code, only in the wrapper |
| [22:38:22] | stuartm: | sphery: I wouldn't do it at the QT level, I'd do it in the MythDB wrapper |
| [22:38:22] | sphery: | (rewrite meaning re-implement--you make your own replacement for the MySQL driver and Qt SQL support that currently provides all that functionality) |
| [22:38:43] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has quit (Ping timeout: 246 seconds) | |
| [22:38:46] | sphery: | right... still need the functionality, though--so it becomes some we provide, instead of using what Qt provides |
| [22:38:56] | kwmonroe (kwmonroe!~kwmonroe@cpe-70-113-204-146.austin.res.rr.com) has joined #mythtv | |
| [22:39:00] | stuartm: | we don't need to replace the driver, we just need to rebuild it to link libmysqld on the master backend |
| [22:39:20] | sphery: | that said, if you can make it work, I'm all for getting rid of the requirement for users to set up and secure (and unsecure--allow access to) mysqld just to use mythtv |
| [22:39:28] | stuartm: | same code, built with a different arg |
| [22:40:07] | sphery: | stuartm: I mean all the rest of the stuff... the passing of data part of the SQL implementation |
| [22:40:28] | stuartm: | sphery: you're lost me |
| [22:40:33] | stuartm: | you've |
| [22:41:03] | stuartm: | this is really pretty simple, I'm not sure how you're managing to make it sound complicated |
| [22:41:35] | stuartm: | or somehow arriving at conclusions such as "2x the effort" |
| [22:41:53] | sphery: | you end up creating a data server that is, in effect, the same capabilities as the Qt SQL stuff, but unless you're trying to serialize QSqlQuery and pass it over the network somehow, you have to handle all the functionality the QSqlQuery provides for the out-of-process stuff |
| [22:42:18] | stuartm: | wtf? |
| [22:42:56] | sphery: | anyway, maybe it is much easier than I thought... it just seems to me that you're going to have to implement a lot of functionality for the switch |
| [22:42:58] | stuartm: | you know what? you've talked me out of working on it |
| [22:43:07] | sphery: | that wasn't my intention |
| [22:43:22] | wagnerrp: | sphery: so youre proposing a protobuf datatype for each and every desired query |
| [22:44:07] | sphery: | stuartm: I really do want you to be excited about working on some part of MythTV... It's just that I think this will require a lot more foundational changes than you thought. I'd /love/ for you to prove me wrong, though. |
| [22:44:30] | wagnerrp: | sphery: stuartm is just talking about embeddeding a database, and using it directly as a database, listening on some port |
| [22:44:47] | wagnerrp: | and the clients accessing the now embedded database over SQL protocol, just as before |
| [22:44:47] | sphery: | wagnerrp: embedded mysql is not a network database |
| [22:44:48] | stuartm: | my own stupid fault for mentioning it, I've said time and time again that submitting something for discussion is the best way to kill an open source project dead and yet I keep repeating the mistake |
| [22:45:07] | wagnerrp: | sphery: so that wouldnt even be an option? |
| [22:46:01] | stuartm: | wagnerrp: of course it's an option, all that happens is that the MBE actually executes the queries and returns the result sets |
| [22:46:29] | wagnerrp: | stuartm: yes, but our qstringlist-based protocol is not set up to handle such result sets |
| [22:46:46] | sphery: | http://dev.mysql.com/doc/refman/5.1/en/libmys . . . ictions.html |
| [22:46:55] | sphery: | You cannot connect to an embedded server from an outside process with sockets or TCP/IP. However, you can connect to an intermediate application, which in turn can connect to an embedded server on the behalf of a remote client or outside process. |
| [22:47:00] | sphery: | that's all I'm talking about |
| [22:47:32] | stuartm: | wagnerrp: I believed it could be done ... at least I was willing to try |
| [22:47:34] | sphery: | so we need that intermediate application to be able to pass all data back and forth between the master DB and the clients |
| [22:48:21] | wagnerrp: | if we could set up a sever that talked SQL, then that would be great |
| [22:48:27] | wagnerrp: | i just dont know how easy that would be |
| [22:48:40] | sphery: | at least that was my understanding... but if I'm wrong, that's great--and it will make the switch much easier |
| [22:48:56] | wagnerrp: | and if we cant do that, and people would have to write their own protocol client to handle it |
| [22:48:58] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [22:49:06] | wagnerrp: | im concerned about safety issues with that |
| [22:49:14] | sphery: | also, this may allow you to do what you were planning: Some of these limitations can be changed by editing the mysql_embed.h include file and recompiling MySQL. |
| [22:49:42] | sphery: | I just didn't really look into that since I do want to prevent direct SQL access by clients |
| [22:50:26] | wagnerrp: | the good thing about direct sql access is that clients (at leas should be) access it through a sane library |
| [22:50:45] | wagnerrp: | which is supposed to enforce proper typing, string safety, and the like |
| [22:51:19] | wagnerrp: | if we drop mysql protocol for our own similar protocol for accessing the now-embedded database |
| [22:51:24] | wagnerrp: | all that is gone |
| [22:51:37] | wagnerrp: | and were going to end up with users running their own likely broken interfaces to it |
| [22:51:59] | wagnerrp: | back to the whole issue of 3rd party protocol libraries bypassing the version checks |
| [22:52:01] | stuartm: | yep, because the server can't do any of that |
| [22:52:32] | sphery: | was about to say, "at least it requires some knowledge on their part," then realized that actually people will post scripts and programs that they can just download and run |
| [22:52:36] | j-rod is now known as j-rod|afk | |
| [22:52:51] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Screw it) | |
| [23:00:57] | sphery: | That wasn't my intention. :( And I would like to publicly apologize (and will apologize directly to stuartm, too). I was digging deeper into details than was appropriate at this point, and it's likely that stuartm has a plan that would have started the process of allowing a conversion. |
| [23:01:23] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [23:03:38] | wagnerrp: | as much as i would like to just make a clean break |
| [23:03:55] | wagnerrp: | i think its too much to bite off at once, at least when third party tools are concerned |
| [23:04:54] | wagnerrp: | if it were just our own internal code we had to worry about, we could do all the testing needed before releasing |
| [23:12:48] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [23:21:33] | dekarl (dekarl!~dekarl@e180143218.adsl.alicedsl.de) has quit (Ping timeout: 260 seconds) | |
| [23:21:41] | dekarl (dekarl!~dekarl@e180142077.adsl.alicedsl.de) has joined #mythtv | |
| [23:29:19] | sphery: | Oh, and I want to publically mention that--even though it may seem like I was saying that my plan was better than stuartm's plan (or that his was a quick, but incorrect plan, that would have to be reworked later), that's not what I meant. He was attempting to solve a different problem (simplify initial DB setup) than I want to solve (out-of-date clients wreaking havoc on the data in the database), and all I meant was that I would still have to ... |
| [23:29:25] | sphery: | ... solve my problem separately. (But I didn't say so clearly.) |
| [23:32:23] | weta_back7pmEDT is now known as weta | |
| [23:33:23] | Gene425 (Gene425!~textual@64.134.134.69) has joined #mythtv | |
| [23:34:22] | Gene425 (Gene425!~textual@64.134.134.69) has quit (Remote host closed the connection) | |
| [23:34:42] | wagnerrp: | is there any good reason were spawning off a new thread for each new file we delete? |
| [23:35:47] | wagnerrp: | i understand the needed for a threaded delete, so were not sitting waiting on a slow delete |
| [23:36:05] | wagnerrp: | but theres a mutex locking deletes to one file at a time, regardless of how many threads are open |
| [23:37:01] | wagnerrp: | seems like it would be better to just use one persistent thread, that we can throw files at for deletion |
| [23:37:37] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has quit (Read error: Connection reset by peer) | |
| [23:38:31] | sphery: | as long as we open the file and delete it immediately, then let the one thread truncate files in order, that would work fine |
| [23:38:50] | sphery: | just have to make sure we delete files immediately (and, for slow deletes, that means opening them first) |
| [23:39:06] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has joined #mythtv | |
| [23:39:42] | abqjp (abqjp!~abqjp@97-119-174-22.albq.qwest.net) has quit (Quit: abqjp) | |
| [23:55:48] | wagnerrp: | slow deletes is a per-host setting, so a single process is either going to delete now, or delete slowly |
| [23:56:03] | wagnerrp: | there is only ever going to be one type of delete |
| [23:56:20] | wagnerrp: | or are you talking about things like thumbnails, files under a couple MB, should be deleted immediately? |
| [23:56:28] | wagnerrp: | regardless of the setting |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.