| Wednesday, February 29th, 2012, 00:00 UTC | ||
| [00:00:16] | xavierh: | except I would not recommend to modify the default keybinding as a lot of apps rely on it to provide a remote control functionality |
| [00:00:18] | stuartm: | frankster: everyone except X devs would agree :) |
| [00:00:34] | xavierh: | :) |
| [00:00:54] | frankster: | I guess the way forward is redesign a new protocol from the start up but have a mode that encapsulates existing X11 |
| [00:01:25] | xavierh: | frankster: wrong channel :) |
| [00:01:30] | frankster: | hehe |
| [00:02:22] | stuartm: | yeah, you'd actually expect an X extension that sits either side of the protocol and handles translation of keycodes above 255, but no, that doesn't exist for some reason |
| [00:03:40] | frankster: | I presume gnome/kde have got some scheme where they have their own devinput listener to work around X's deficiency? |
| [00:05:14] | stuartm: | http://svn.mythtv.org/trac/ticket/10391 – wtf? How do you end up with hundreds or thousands of tables in the mythconverg database? |
| [00:05:43] | stuartm: | there's a good reason if one were needed why allowing apps direct access to our database is a seriously bad idea |
| [00:07:48] | stuartm: | frankster: maybe, although I'm not aware of one, I find that kde can't see input with keycodes above 255 just the same as everything else |
| [00:08:01] | xavierh: | stuartm: is there a way to override a theme font, I need to use smallbase but chande its color |
| [00:08:05] | xavierh: | ? |
| [00:09:11] | xavierh: | s/chande/change s/smallbase/basesmall |
| [00:09:16] | stuartm: | xavierh: you can use inheritence to create a new font but based on the characteristics of smallbase e.g. <fontdef name="myfont" from="smallbase"><color>#FF0000</color></fontdef> |
| [00:09:47] | wagnerrp: | stuartm: ive probably had every assorted plugin from the last 5 years connected to my database at one time or another |
| [00:09:53] | wagnerrp: | and i think i have just over 100 tables |
| [00:10:18] | xavierh: | stuartm: thanks |
| [00:10:39] | stuartm: | frankster: mythtv can handle input direct from a remote provided it uses keys with a value less than 255, but that rules out many 'media' keys and you need to turn off lirc first because the lirc startup script usually disables devinput |
| [00:10:55] | wagnerrp: | stuartm: yeah, 111 tables, i dont know where hundreds (plural) came from |
| [00:11:20] | wagnerrp: | and have no clue how you could have thousands, unless you started running multiple versions of mythtv on the same database using table name prefixes |
| [00:12:58] | stuartm: | wagnerrp: that's about the same for me, I've ended up with some extras because of the need to create backups while testing a feature |
| [00:13:10] | stuartm: | 121 total |
| [00:14:36] | wagnerrp: | oh! anyone have any desire to make a run at a GSoC project? |
| [00:15:43] | frankster: | well it seems like the most useful thing I can do to handle remotes better is to make a better lirc config generator for the distro i am using(mythbuntu) |
| [00:16:11] | frankster: | cos im not taking a year off work to redesign xkb ;) |
| [00:16:19] | wagnerrp: | stuartm: perhaps something to mention to the mailing list? |
| [00:16:48] | wagnerrp: | i know every year, shortly after the submissions are do, people invariably comment "that would have made a good GSOC project" |
| [00:16:57] | wagnerrp: | due* |
| [00:26:03] | stuartm: | hmm, looking at that thread the problem isn't to do with the number of tables in mythconverg, the suggestion is that the query we're using is looking at the tables from every database |
| [00:28:50] | wagnerrp: | that still raises the question what is someone doing with hundreds of thousands of database tables |
| [00:33:13] | wagnerrp: | sphery: by default, the `mythtv` user should not even have access to those tables to read them |
| [00:33:59] | wagnerrp: | stuartm: ^^^ |
| [00:34:24] | stuartm: | wagnerrp: right, but at least they aren't in mythconverg |
| [00:34:25] | Seeker`: | wagnerrp: but why are we grabbing a list of all table names? |
| [00:34:40] | stuartm: | Seeker`: to check that the tables are all there |
| [00:34:58] | stuartm: | i.e. it's not fubar |
| [00:35:35] | wagnerrp: | actually, it runs through the list of tables and makes sure theyre not crashed |
| [00:36:46] | wagnerrp: | why we dont just use a 'show tables'... i dont know |
| [00:37:07] | wagnerrp: | i suppose to allow filtering by database engine type |
| [00:37:13] | wagnerrp: | we only attempt to repair myisam tables |
| [00:39:03] | xavierh: | new ui for audio settings http://imagebin.org/201309 . I should be ban to touch any theme file :) |
| [00:43:43] | stuartm: | wagnerrp: it's used in a couple of places, one of which is checking that the tables actually exist on startup and if it finds they are all missing, then it starts to create the schema |
| [00:50:29] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq_) | |
| [00:51:15] | noahric (noahric!~noahric@74.125.59.74) has quit (Quit: noahric) | |
| [00:56:00] | sphery: | wagnerrp: haven't read the scrollback, but the problem in #10391 is the user is running mythtv using an excessively-privileged mysql user (i.e. mysql root, likely) |
| [00:56:57] | wagnerrp: | sphery: its more than that, they did something to break their code |
| [00:57:22] | wagnerrp: | as the query in question limits the call to only those tables in the 'DATABASE()' database |
| [00:57:47] | wagnerrp: | unless hes saying its simply that difficult for him to do a search in a table with several hundred thousand entries |
| [00:58:03] | wagnerrp: | of course if his system cant handle a table with several hundred thousand entries |
| [00:58:19] | wagnerrp: | he DEFINITELY shouldnt be running a database server with several hundred thousand tables |
| [00:59:45] | stuartm: | I think the user is just mistaken, he didn't read the query properly and assumed it was the cause of the slow startup he was experiencing |
| [01:00:37] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds) | |
| [01:02:44] | sphery: | wagnerrp: no, it's exactly that: http://code.mythtv.org/trac/ticket/9742 + http://www.gossamer-threads.com/lists/mythtv/users/478260#478260 |
| [01:02:53] | sphery: | plus, we don't even call CheckTables() in startup |
| [01:02:55] | stuartm: | there aren't any indexes on information_schema.tables, but that's not really our concern, as I said when closing the ticket having a resource intensive application sharing the RDBMS with mythtv is unsupported |
| [01:02:59] | sphery: | the user is using an old, broken version of mythtv |
| [01:03:11] | sphery: | i.e. the old, broken one he got for mac os on sf site |
| [01:08:32] | sphery: | we had to remove all the check-tables-on-startup stuff because of people terribly broken MySQL configurations and running master backends + mysql servers on Atom or PogoPlug and similar |
| [01:09:25] | stuartm: | sphery: did you mean to say "hundreds or thousands of recordings"? |
| [01:09:45] | sphery: | hehe, meant tables |
| [01:10:19] | stuartm: | figured you did, at least you can edit the comment |
| [01:10:30] | sphery: | hehe, good approach |
| [01:10:42] | sphery: | can mention that we're not calling CheckTables, that way, too |
| [01:10:54] | sphery: | (and say, "for all practical purposes, a dup") |
| [01:11:02] | stuartm: | sadly not the hundreds of emails which were sent out ... |
| [01:11:16] | sphery: | but at least the record will be right |
| [01:11:32] | sphery: | trying to find the commit that removed checktables call |
| [01:11:44] | stuartm: | I didn't realise the CheckTables behaviour had changed, it was still called on startup when I last looked |
| [01:12:21] | sphery: | I could have sworn I was forced to remove it because it was too slow |
| [01:12:30] | stuartm: | ok, better call it a night before I look at the clock again and find another two hours have passed |
| [01:12:39] | sphery: | (and, really, it shouldn't delay startup, so I /should/ have removed it) |
| [01:12:56] | sphery: | anyway, I /know/ for a fact current 0.24-fixes doesn't call it, so it could only be called in master, if anything |
| [01:12:59] | stuartm: | sphery: well the last time I looked at it was months ago at the very least |
| [01:13:30] | stuartm: | just because it was that when when I last looked doesn't mean it's still like that today ;) |
| [01:14:03] | sphery: | in fact, in 0.24-fixes, DBUtils::CheckStartup() is never called by any code, anywhere... First user in master became the Service API stuff |
| [01:14:46] | sphery: | finding a commit that removes something is so much harder than finding a commit that added something that's there... |
| [01:23:30] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [01:29:00] | sphery: | OK, startup table check was added on Jul 25, 2010 ( https://github.com/MythTV/mythtv/commit/278b7cadb ) and removed Aug 22, 2010 ( https://github.com/MythTV/mythtv/commit/3303e2953 ), and never existed in any released version of MythTV--only pre-0.24 unstable/development code |
| [01:29:02] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120216080748]) | |
| [01:46:17] | gigem: | frankster (and stuartm and anyone else who's interested): it is possible to use a remote without lirc. it's just way more tedious than it should be. you need to create a custom keytable for your remote (see "man ir-keytable") that maps all of the keycodes into input events that Qt can recognize (some subset of event codes <= 255). that's what i do for my imon remote. j-rod can proably explain it all better than me, though. |
| [02:06:04] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [02:06:26] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [02:07:06] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [02:07:06] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [02:07:06] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [02:18:38] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [02:31:21] | Yancho_ (Yancho_!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 240 seconds) | |
| [02:31:51] | sphery: | Maybe after switching to not use .lircrc, we can change so we don't use keyboard keysyms and just use keycodes, instead (which is the equivalent of using /etc/lircd.conf button names). Then again, why not continue farther and just use keyboard scan codes (the equivalent of accessing the device signals directly). After all, I'm sure everyone uses a US 105-key keyboard, right? :) (Just saying that the only reason keyboards--which use the ... |
| [02:31:57] | sphery: | ... same 2-level mapping--seem better is because the distros, etc., do a better job of supporting them by providing appropriate configurations for what you want--likely because there aren't many differences in what people want.) |
| [02:38:12] | wagnerrp: | does the name Lindsay Ward ring a bell with anyone? |
| [03:05:14] | noahric (noahric!~noahric@50.46.147.0) has joined #mythtv | |
| [03:16:32] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [03:18:48] | 50UAAJH0Z (50UAAJH0Z!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Ping timeout: 245 seconds) | |
| [03:22:08] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [03:46:30] | noahric (noahric!~noahric@50.46.147.0) has joined #mythtv | |
| [03:54:41] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [04:06:01] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Ping timeout: 246 seconds) | |
| [04:09:12] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [04:17:02] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [04:20:43] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!) | |
| [04:22:32] | noahric (noahric!~noahric@50.46.147.0) has joined #mythtv | |
| [05:02:16] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Ping timeout: 272 seconds) | |
| [05:05:15] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:20f:eaff:fefc:ba0e) has joined #mythtv | |
| [05:05:16] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:20f:eaff:fefc:ba0e) has quit (Changing host) | |
| [05:05:16] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [05:23:55] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [05:29:31] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [05:46:07] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 246 seconds) | |
| [05:47:55] | Seeker` (Seeker`!~cjo20@host86-145-11-229.range86-145.btcentralplus.com) has joined #mythtv | |
| [05:47:55] | Seeker` (Seeker`!~cjo20@host86-145-11-229.range86-145.btcentralplus.com) has quit (Changing host) | |
| [05:47:55] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [05:49:08] | ThisNewGuy (ThisNewGuy!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has quit (Ping timeout: 260 seconds) | |
| [06:11:32] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [06:12:49] | ThisNewGuy (ThisNewGuy!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has joined #mythtv | |
| [06:39:26] | ThisNewGuy1 (ThisNewGuy1!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has joined #mythtv | |
| [06:41:15] | ThisNewGuy (ThisNewGuy!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has quit (Ping timeout: 260 seconds) | |
| [06:48:29] | ThisNewGuy1 (ThisNewGuy1!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has quit (Ping timeout: 255 seconds) | |
| [06:49:52] | ThisNewGuy (ThisNewGuy!~doug@pool-74-102-15-78.nwrknj.fios.verizon.net) has joined #mythtv | |
| [06:58:51] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [07:43:12] | jwhite (jwhite!jwhite@216.251.189.141) has quit (Read error: Operation timed out) | |
| [07:44:40] | jwhite (jwhite!jwhite@216.251.189.141) has joined #mythtv | |
| [07:45:14] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120215223356]) | |
| [07:50:56] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [07:55:52] | Yancho (Yancho!~mpulis@c171-244.i02-3.onvol.net) has joined #mythtv | |
| [07:55:52] | Yancho (Yancho!~mpulis@c171-244.i02-3.onvol.net) has quit (Changing host) | |
| [07:55:52] | Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv | |
| [07:57:50] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [08:00:30] | jya: | is n--disable-backend |
| [08:00:53] | jya: | oops.. isn't there a way to disable building the backend anymore ? |
| [08:01:55] | wagnerrp: | hasnt been for years |
| [08:02:00] | wagnerrp: | i think that got taken out in 0.22 |
| [08:02:15] | jya: | can't be years… I was compiling 0.24 build without backend on ubuntu |
| [08:02:24] | solars (solars!~solars@clnet-kmu02-090.ikbnet.co.at) has joined #mythtv | |
| [08:02:39] | jya: | just that building the backend makes little sense IMHO on a mac, but it always built it no matter way |
| [08:02:44] | wagnerrp: | maybe you were discarding it, but it was still getting compiled |
| [08:02:58] | jya: | I see a "# disabled due to abuse in Gentoo ebuild" |
| [08:03:04] | jya: | sounds like you :) |
| [08:03:31] | wagnerrp: | hey now! that was before i was even a dev |
| [08:03:35] | wagnerrp: | :P |
| [08:04:03] | jya: | jannau change :) |
| [08:04:23] | jya: | you're right.. been years |
| [08:05:32] | wagnerrp: | [15261] |
| [08:05:32] | MythLogBot: | SVN 15261: (branch master) https://github.com/MythTV/mythtv/commit/02127435 |
| [08:05:34] | jya: | would there be any issue if I was to re-active that ? |
| [08:05:53] | jya: | I mean , I would apply a custom patch in the mac builder only |
| [08:06:08] | wagnerrp: | [10963] |
| [08:06:08] | MythLogBot: | SVN 10963: (branch master) https://github.com/MythTV/mythtv/commit/c574b3f4 |
| [08:09:24] | wagnerrp: | i dont know why you wouldnt want the backend on OSX |
| [08:10:47] | wagnerrp: | i mean its not like the backend adds any dependencies to the mix |
| [08:11:29] | wagnerrp: | and considering mythtv-setup still requires X for the backend, disabling the frontend doesnt remove any dependencies either |
| [08:14:17] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [08:19:32] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [08:20:36] | jya: | wagnerrp: backend is so limited on OS X, I think I only ever read about 2–3 people in total who have used a native mac as backend ever |
| [08:20:47] | jya: | but you're right.. probably not worth disabling |
| [08:21:16] | wagnerrp: | several months back, iamlindoro set up some wizard application to make running an OSX backend with an HDHR Prime very easy |
| [08:21:41] | wagnerrp: | although i dont recall if he actually cleaned it up and released it |
| [08:21:58] | jya: | hdhomerun doesn't compile for me, erroring with missing headers.. |
| [08:22:04] | jya: | I wanted to look after this next |
| [08:37:33] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 245 seconds) | |
| [09:00:06] | stuarta: | osx backend is feasible with network based tuners |
| [09:00:30] | stuarta: | maybe some usb ones too, provided you can find driver support |
| [09:06:10] | wagnerrp: | ive heard it works well with firewire too |
| [09:07:38] | stuarta: | ah yes, that should work too |
| [09:08:05] | stuarta: | forget the usb based ones, we have no interface to use them |
| [09:09:21] | wagnerrp: | supposedly, freebsd will support any USB tuner that has linux drivers |
| [09:09:38] | wagnerrp: | using some userland framework |
| [09:09:47] | wagnerrp: | i wonder how difficult that would be to port to OSX |
| [09:10:19] | stuarta: | i've no idea how they expose the devices, and i'm pretty sure we haven't coded anything for it |
| [09:10:46] | wagnerrp: | presumably they just create the standard DVB device nodes |
| [09:13:03] | stuarta: | if that's so, there's half a chance of it working |
| [09:13:21] | stuarta: | actually since you are the bsd guy, you've more idea than the rest of us :) |
| [09:13:46] | peitolm: | jya: if i can get the backend running on osx, it will give me more horsepower for job runs |
| [09:13:54] | peitolm: | so, i'll use it if it's there :) |
| [09:13:57] | wagnerrp: | ive never used it, just use a HDHR on mine |
| [09:14:26] | jya: | peitolm: you can already build mythback on the mac.. you pass the -backend switch to the build script |
| [09:15:00] | peitolm: | :) i was just bumping your numbers up that's all |
| [09:16:12] | wagnerrp: | peitolm: if you have no intention of recording on a machine, you should not be running a backend on it |
| [09:16:42] | stuarta: | there's a case to be said for a job queue only backend |
| [09:16:53] | wagnerrp: | no, there isnt |
| [09:16:58] | wagnerrp: | thats why we have mythjobqueue |
| [09:17:13] | wagnerrp: | :P |
| [09:18:48] | peitolm: | i seem to recall we've had this arguement before |
| [09:26:18] | stuarta: | i didn't realize we had mythjobqueue |
| [09:27:38] | ** peitolm wonders what else mythbackend controls apart from the recorders and mythjobqueue ** | |
| [09:28:30] | jya: | are we using the phonon framework in myth? |
| [09:29:15] | stuarta: | i don't believe so, we always disabled it in the OSX Qt build |
| [09:31:21] | jya: | ah… |
| [09:31:42] | stuarta: | tho i do wonder if there's anything of use in it to us... |
| [09:31:54] | stuarta: | but given how bad Qt have been with osx support |
| [09:31:58] | jya: | it gets linked automatically when I just parse the framework dependency |
| [09:32:03] | stuarta: | i think i'd steer clear of it |
| [09:32:29] | jya: | rebase crashes when given that many libs to rebase at once, and it crashes on phonon |
| [09:33:02] | jya: | stuarta: well, I can't just ignore it if it's actually linked to a lib… or we have to build Qt ourselves and be back to square 1 |
| [09:34:05] | jya: | how well, if it's not on phonon, rebase crashes nonetheless. |
| [09:34:49] | jya: | there are 65 loaded libs on the MythFrontend exe |
| [09:38:01] | jya: | Allright, I get myth to compile with the 4.8, 4.7 and 4.6 Qt SDK… not so much luck with just the libs package… having issues with the headers.. they aren't locatded in a single include like with the SDK, but within the framework file itself |
| [09:48:43] | stuarta: | yeah, if it gets pulled in there is nothing we can do about it |
| [09:49:10] | stuarta: | well very little |
| [09:53:45] | stuarta: | jya, i wonder if there is a patch we need to apply to the libs only package to make it do the right thing |
| [10:36:12] | xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [11:05:02] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [11:05:50] | mike (mike!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [11:06:16] | mike is now known as Guest75561 | |
| [11:07:05] | stuartm: | peitolm: if you're still wondering it acts as a hub for media, if you had videos on a machine that you want to make available to the frontends, then one way of doing that is to have a tunerless backend on there |
| [11:07:45] | stuartm: | the backend also handles scheduling, but obviously that doesn't apply to a tunerless setup |
| [11:10:44] | xavierh: | gigem: at [01:46:17], It is way better leave keytable as deafult, use lirc without .lircrc and allow mythtv to map key independantly of the keyboard mapping using the remote name + button name |
| [11:38:59] | peitolm: | stuartm: yeah, as far as i know, job queues, media serving, recording, scheduling[1] run on the backend, but couldn't think of anything else |
| [11:39:15] | peitolm: | [1]: but isn't all the scheduling done on the master? |
| [11:43:06] | stuartm: | peitolm: yeah, scheduling is done on the master, but then the question wasn't "what else does a slave backend control?" :) |
| [11:43:56] | stuartm: | in future the master backend will also manage the embedded DB and serve up mythweb |
| [11:44:22] | peitolm: | that's what i thought, but your comment"he backend also handles scheduling, but obviously that doesn't apply to a tunerless setup" could be read that all backends with tuners do scheduling (can we say contention) |
| [11:44:23] | stuartm: | I'm sure there's something else I'm forgetting |
| [11:44:43] | stuartm: | peitolm: not everyone uses mythtv for recording |
| [11:44:57] | stuartm: | sorry, mis-read what you said just now |
| [11:46:14] | stuartm: | peitolm: I was refering to the entire setup, rather than just a single backend – i.e. mythtv without any recording capability |
| [11:48:21] | peitolm: | *nods* |
| [11:49:01] | peitolm: | i'm not playing devil's advocate, just trying to nail down what else the backend does, i'm sure there's something else, but I can't think of it |
| [11:49:13] | peitolm: | comm flag is a job, metadata is a job aiui |
| [11:58:09] | stuarta: | you could in theory split it up into the core (which just handles scheduling of recordings, storage, and client interactions), and make all recorders slaves |
| [12:06:51] | peitolm: | two schools of thought on that one |
| [12:07:47] | peitolm: | fex, if i had a mac mini running osx, that could run all the time, and fireup remote recording boxes as needed |
| [12:31:50] | wagnerrp: | jya, stuarta: phonon gets used for mythbrowser |
| [12:32:31] | stuarta: | i thought it used WebKit |
| [12:32:55] | jya: | wagnerrp: as stuarta mentioned, qt on mac used to be built with -no-phonon |
| [12:33:43] | wagnerrp: | probably a good thing |
| [12:33:53] | wagnerrp: | you miss out on a good half hour of gstreamer crap |
| [12:34:04] | stuarta: | hahahahahaa |
| [12:41:15] | zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv | |
| [12:41:15] | zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host) | |
| [12:41:16] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [12:53:33] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [13:00:00] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 252 seconds) | |
| [13:03:01] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [13:04:58] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [13:05:21] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [13:07:33] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 248 seconds) | |
| [13:07:58] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [13:13:30] | stuartm: | stuarta: splitting out the recording capability of the backend is popular round here, personally I'm not sold, it just seems like obsessive modularisation for the sake of it but I'm in a minority of one |
| [13:16:12] | peitolm: | i wonder if it's because you can't seem to separate out the recorder part in the same way as you can the jobqueue |
| [13:16:39] | stuartm: | segregating the code internally is one thing, but turning mythtv into an assortment of little single pupose applications just makes it seem complicated and I can only imagine how much new users would be confused by it, power users would probably love it but most users aren't power users |
| [13:17:42] | peitolm: | but there's nothing stopping 'mythbackend' from being the way you start 'mythrecorder','mythjobqueue' |
| [13:17:54] | peitolm: | in the same way there's a setting for 'run jobs on this backend' |
| [13:18:45] | stuartm: | peitolm: right, I still think that's unnecessary |
| [13:18:56] | stuartm: | but like I said, I'm pissing in the wind :) |
| [13:20:19] | peitolm: | i'm not saying that it should be 15 different processes, just that i'd like to break the mythbackend==recorder |
| [13:20:20] | stuartm: | it's amusing that while the trend is generally towards simple, monolithic apps nginx vs apache etc we'd move against the current |
| [13:20:39] | stuarta: | the keyword there being simple |
| [13:20:59] | peitolm: | that's becauase nginx does 1 thing, apache 30, mythtv does 30, not 1 |
| [13:21:05] | peitolm: | (grossly simplified) |
| [13:21:11] | stuarta: | but correct |
| [13:21:32] | peitolm: | but what do i know, i'm only a user :) |
| [13:23:13] | stuartm: | ah well, when it eventually happens I'll just fork and merge everything back into one app again |
| [13:23:42] | peitolm: | I don't oppose one app |
| [13:23:56] | peitolm: | but it would be nice to turn off bits and pieces i'm not using |
| [13:24:17] | peitolm: | but i suspect i'm in a vanishingly small minority of users |
| [13:27:41] | stuartm: | we you more or less can do that already, if you don't have jobs enabled there is no jobqueue, no tuners then no scheduler, eit or recording |
| [13:28:23] | peitolm: | last i heard, that last bit wasn't supported |
| [13:31:32] | stuartm: | you can record without a tuner? |
| [13:33:52] | jya: | [24835] |
| [13:33:52] | MythLogBot: | SVN 24835: (branch master) https://github.com/MythTV/mythtv/commit/edae94e0 |
| [13:35:31] | peitolm: | stuartm: I mean running mythbackend without a tuner |
| [13:36:45] | stuartm: | yeah, you can, it runs or did the last time I checked |
| [13:36:59] | peitolm: | o.k. this may have changed in the mean time |
| [13:37:27] | stuartm: | not supported != not a configuration for which we provided user support |
| [13:37:34] | stuartm: | the latter is true, the former is not |
| [13:40:39] | stuartm: | there used to be a hidden frontend arg that allowed it to run even when there was a schema mis-match, what happened to that? |
| [13:41:10] | peitolm: | never heard of that |
| [13:48:58] | stuartm: | right, you weren't supposed to ;) |
| [13:49:12] | peitolm: | :) |
| [13:49:21] | stuartm: | It was to help devs testing db schema updates and that sort of thing |
| [13:49:59] | stuartm: | seems like it might have been removed when argument parsing was refactored :( |
| [13:50:07] | ** peitolm has been battering the db for a while, contrary to the "don't touch the database" ** | |
| [13:55:19] | j-rod|afk is now known as j-rod | |
| [14:04:25] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [14:14:49] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:35:50] | ** Captain_Murdoch still doesn't get how we'll be able to get rid of the old deletion code and still allow immediate deletion from the 'Deleted' group to free up space immediately. ** | |
| [14:41:59] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Read error: Connection reset by peer) | |
| [14:53:05] | Captain_Murdoch: | stuarta, yeah, there are some of us who advocate the master being just a master and even tuners local to the master would be controlled by a slave backend. it simplifies the code inside the master quite a bit if it assumes all tuners are 'remote' and isn't sprinkled with 'if (isLocal())" to act one way or the other if the tuner is local vs remote. to me this makes even more sense if the master is also running an embedded DB se |
| [14:53:06] | Captain_Murdoch: | rver. that would simplify code greatly in the master & slave and make them easier to follow. now, I'm still up on the fence as to breaking out other functionality. theoretically if we truly support tunerless backends, then we could get rid of mythjobqueue and just run a slim tunerless slave. |
| [14:54:32] | Captain_Murdoch: | ditto for a mythmediaserver, if we have a slim tunerless slave or backend plugins, then we could get away with just a master and slave instead of 4+ binaries. |
| [14:54:49] | stuarta: | Captain_Murdoch: exactly |
| [14:57:24] | Captain_Murdoch: | wagnerrp did some work on allowing pluggable command processing which is a step towards backend plugins. not sure where that's at though or if it has been put on the back burner. |
| [14:58:26] | ** Captain_Murdoch resists the urge to say "maybe we can merge that feature back from Torc" everytime he talks about something new or an idea that's been discussed but without enough coding time to accomplish. ** | |
| [15:00:22] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [15:01:34] | stuartm: | Captain_Murdoch: good point, guess I didn't think that all the way through |
| [15:03:17] | Captain_Murdoch: | not sure any of us have. several ways to do it and it's a big enough change where I think it might be good to write up a description of how it would be accomplished. |
| [15:04:47] | stuarta: | surely not a mini project plan |
| [15:04:53] | ** stuarta is astounded! ** | |
| [15:04:56] | stuartm: | if sphery adds a wakeup feature to the auto-expirer then we can still have it deleted there, but just faster still |
| [15:05:35] | stuarta: | we can also please the low power freaks by making all recorders slaves |
| [15:06:16] | stuarta: | then the MBE can be on a low power always on device, and the recorders only come online when required |
| [15:07:54] | xavierh: | Not sure if the db should be only in the master backend, I could see the use to have a slave backend on my laptop which would old the data about the recordings I transfer to it, so I can watch them on holidays |
| [15:08:24] | stuartm: | well a recorder doesn't have to be fast or high power, and you wouldn't be able to use EIT, only xmltv |
| [15:09:03] | stuarta: | xavierh: there's a whole much talked about theory to make a "disconnected frontend" |
| [15:10:38] | xavierh: | stuarta: I am sure there is. Just relaying my wife first complainte when we go to see my family and she get bored :) |
| [15:10:51] | stuarta: | hahaha |
| [15:12:18] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [15:12:24] | xavierh: | That being said, removing all direct access to the db from mythfrontend and using some service API would greatly ease this goal. |
| [15:14:30] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone - http://colloquy.mobi) | |
| [15:21:42] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [15:23:25] | peitolm: | xavierh: if you're a nutter, you could run a local backend, and mysql daemon |
| [15:23:49] | peitolm: | i don't know how spectacularly 2 backends talking to the same db would be |
| [15:24:13] | ** peitolm sticks his hand up at the 'low power freaks' comment ** | |
| [15:24:51] | stuarta: | there's always 1... |
| [15:25:48] | peitolm: | and i'm happy for that to be me :) (today) |
| [15:26:15] | peitolm: | but it's not just the low power freaks |
| [15:26:39] | peitolm: | i'd love to run everything on one box, but it's currently spread across 3 |
| [15:26:50] | stuarta: | hp microservers |
| [15:27:08] | peitolm: | yes, but they don't have the storage |
| [15:27:37] | peitolm: | right now, there isn't 1 box that meets all my requirements |
| [15:27:55] | peitolm: | which is why i have a loft half full of kit |
| [15:27:59] | stuarta: | they can take 4 internal drives, that's 8Tb of raw storage |
| [15:28:03] | peitolm: | 12 |
| [15:28:30] | stuarta: | 2Tb drives is the biggest officially supported atm |
| [15:28:54] | stuarta: | still it's plenty |
| [15:29:01] | stuarta: | although, i still want 3 of them |
| [15:29:22] | stuarta: | 1 as a NAS ~5.5Tb over raid5 |
| [15:29:30] | stuarta: | 1 as a virtualization host |
| [15:29:37] | stuarta: | 1 as my mythtv box |
| [15:30:14] | peitolm: | i currently have 2 boxes in the loft, one solaris box, one linux, plus i have an xserve |
| [15:33:50] | stuartm: | hmm, article on the reg suggests that Suse is pushing btrfs over ext4, even though btrfs was still much slower in the last benchmarks I saw |
| [15:34:08] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [15:34:37] | jams: | suse has never liked ext* |
| [15:35:06] | jams: | don't know why..but ext is often the last choice with them |
| [15:36:43] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [15:38:44] | stuartm: | the results of recentish Phoronix comparisons show that btrfs is order of magnitudes slower unless you disable all the features in which case it's still slower but by a smaller amount |
| [15:39:30] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [15:40:42] | peitolm: | xavierh: i should also through in 'mysql replication,' to that mix as well |
| [15:40:51] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [15:40:51] | stuartm: | anyway, interesting that Suse would go so far as to omit Ext4 |
| [15:41:08] | jya: | anyone has any objection to this change? |
| [15:41:09] | jya: | http://pastebin.com/KPw6FwTZ |
| [15:41:27] | peitolm: | is this sles or ? |
| [15:42:45] | jya: | explanation behind the change. Everywhere we configure LDFLAGS, except that Qt never uses that value, it uses QMAKE_LFLAGS/LFLAGS. as such, no special LD flags you pass to configure, or via the LDFLAGS environment variable is ever used for linking by a makefile generated by Qt. |
| [15:42:48] | stuartm: | peitolm: yeah |
| [15:42:49] | wagnerrp: | Captain_Murdoch: the libmythprotoserver is a functional implementation of that, but it only has a couple protocol handlers at the moment |
| [15:42:50] | Captain_Murdoch: | stuarta, a mini project plan is not unheard of, we've done that a few times in the past. :) the recordedfile schema change has a writeup along that line on the wiki. |
| [15:43:13] | wagnerrp: | a basic status class with LOAD, UPTIME, HOSTNAME, MEMSTATS, and TIME_ZONE |
| [15:43:32] | jya: | the LDFLAGS is only use for compiling ffmpeg. While not a problem for most setup, if you configure linker flags to say link in 32 bits, on a 64 bits machine, compilation will fail |
| [15:43:34] | wagnerrp: | a shell class to be subclassed for connection upstream to the master |
| [15:43:48] | wagnerrp: | and a file server class |
| [15:43:59] | Captain_Murdoch: | stuartm, yeah, auto-waking the auto-expirer could be sufficient. if current recording is in the Deleted group then wakeup, else let it run at it's normal interval or perhaps send an event to trigger a timer to make sure it wakes up in X minutes to do the delete. |
| [15:44:01] | wagnerrp: | basically, the minimal functionality needed to implement mythmediaserver |
| [15:44:41] | Captain_Murdoch: | stuarta, embedding the DB will be fun for the low-power guys. ~1–2 minute scheduler runs... :) |
| [15:44:48] | wagnerrp: | it allows for backend plugins, by adding the ability to hook different handling into the listen server |
| [15:45:09] | wagnerrp: | but theres none of the dynamic module loading to actually implement plugins |
| [15:45:36] | wagnerrp: | its more, the first step of many, by getting away from the monolithic mainserver.cpp |
| [15:45:43] | stuartm: | Captain_Murdoch: I was thinking the latter to force 'quick' deletes, which are now the default to occur at the 5/10 minutes mark and not at the next scheduled run, for 'immediate' deletes we just have that timer fire immediately |
| [15:46:02] | Captain_Murdoch: | stuartm, makes sense. |
| [15:46:27] | stuarta: | jya: does that still build properly on linux with that change, if so i'm happy with it |
| [15:46:33] | Captain_Murdoch: | ok, mini project plan, check! |
| [15:46:35] | jya: | it does. |
| [15:46:41] | jya: | I've compiled on linux already |
| [15:46:49] | Captain_Murdoch: | s/plan/plan done/ |
| [15:46:54] | stuarta: | <mr burns> EXCELLENT! </mr burns> |
| [15:47:07] | jya: | haven't tried cross compilation however… this may not work the same with cross compilation |
| [15:47:11] | jya: | but I've never done it |
| [15:47:37] | stuartm: | wagnerrp: fwiw unless someone beats me to it I do still intend to implement the backend plugin loading, since you're working on the extensible protocol/events stuff we might want to coordinate |
| [15:47:50] | Captain_Murdoch: | wagnerrp, yeah, there's no need to have the 'mythprocessspawner' daemon if we can just dlopen() the right plugins. |
| [15:47:52] | stuartm: | either that or I leave the plugin stuff entirely to you :) |
| [15:47:57] | stuarta: | the only people ridiculous enough to cross compile are the embedded folks, and that's currently an unsupported target arch |
| [15:49:15] | wagnerrp: | stuartm: sure, im planning on migrating the remaining functionality in mainserver.cpp into these pluggable classes for 0.26, and migrating the master backend over to it |
| [15:49:18] | stuartm: | wagnerrp: I wanted to improve the existing plugin api allowing more 'plug in' type behaviour instead of the current 'strap on' plugins we have now |
| [15:49:29] | stuartm: | keep the jokes to yourself |
| [15:49:52] | stuartm: | stuarta: I saw you sniggering, detention after class |
| [15:49:52] | wagnerrp: | i had actually wanted to split the backend in half in the process |
| [15:50:21] | wagnerrp: | the above mentioned master scheduler, and dedicated recorder |
| [15:50:26] | stuarta: | eh, what... |
| [15:50:34] | stuartm: | stuarta: nm, j/k |
| [15:50:39] | wagnerrp: | stuarta: 'strap on' plugins |
| [15:50:52] | ** stuarta decided to snigger after all ** | |
| [15:50:56] | stuarta: | -d+S |
| [15:53:43] | wagnerrp: | Captain_Murdoch, stuartm: i was more of a middle ground between the two camps |
| [15:54:10] | Captain_Murdoch: | wagnerrp, not sure how much thought you've given it, but I'd see the 'dedicated recorder' as a generic slave that loaded plugins as necessary. if (runJobQueue) { dlopen(mythjobqueue.so);} if (hasLocalTuners) { dlopen(mythrecorder.so); } rip out everything but 'master' type functionality from master, including media serving. |
| [15:54:23] | wagnerrp: | if everything is in pluggable classes that can be mixed and matched, i dont see why we couldnt have a plethora of executables, with overlapping functionality |
| [15:55:28] | wagnerrp: | but youre actually suggesting just some basic 'daemon' executable |
| [15:55:31] | Captain_Murdoch: | no reason to have more than 2, or 1 if 'master' status was a command line option. (exluding things like preview gen, commflag, transcode that we want to keep broken out) |
| [15:55:41] | wagnerrp: | that loads modules as necessary depending on how it gets configured in the database? |
| [15:55:54] | Captain_Murdoch: | we alread have the daemon. I'm saying with plugins, we don't need to have hte daemon spawn other daemons. |
| [15:56:42] | stuarta: | and it's dlopen'ing is to painful for various arch's, is easy enough to make it fork/exec |
| [15:56:51] | Captain_Murdoch: | we have mythmaster with the scheduler and DB, and then we have mythslave which dlopen's the plugins it needs. plugins would be things like jobqueue, recording, media serving, etc. |
| [15:56:55] | stuarta: | s/it's/if |
| [15:58:00] | wagnerrp: | that could be interesting |
| [15:58:06] | Captain_Murdoch: | I think I'd prefer 2 apps though, one dedicated master app and one slave app which used plugins. rather than having master functionality like scheduling and DB being plugins. |
| [15:59:36] | Captain_Murdoch: | just thoughts, haven't written things down and revisited to make sure it makes sense weeks later. :) |
| [15:59:55] | wagnerrp: | the dedicated master app would require plugins as well |
| [16:00:04] | wagnerrp: | assuming all database access is to be routed through it |
| [16:00:39] | wagnerrp: | that would mean each plugin would require a pair of libraries, one core, and one database |
| [16:01:08] | wagnerrp: | where the database library would route all necessary calls through services/protocol |
| [16:04:38] | Captain_Murdoch: | master wouldn't necessarily need plugins, you need the DB, why make it a plugin. the scheduler could be required even if not needed/used. |
| [16:05:17] | wagnerrp: | well that depends on how database access is going to be managed |
| [16:05:18] | Captain_Murdoch: | could be pluggable as far as the command processing goes, but wouldn't need to dlopen .so files. |
| [16:05:47] | wagnerrp: | would everything be translated on the server side, or would there be a more traditional sql interface to access |
| [16:06:22] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds) | |
| [16:07:06] | wagnerrp: | i know sphery wanted to switch over to the embedded DB with a clean cut |
| [16:07:16] | Captain_Murdoch: | I think we need to make some form of sql client even if it just passes commands to and gets results from the MBE. |
| [16:07:43] | wagnerrp: | move all current database access performed by the recorders/frontends into protocol or services interfaces |
| [16:07:54] | wagnerrp: | and have no direct database access outside the master backend |
| [16:08:01] | Captain_Murdoch: | right |
| [16:08:02] | stuarta: | then you can change the db to your hearts content |
| [16:11:06] | Captain_Murdoch: | I think we will have to fix things at some point though, and making users dump the internal DB to a file, hand-edit or script-edit, and then reload won't go over well. unless we include the embedded mysql library, we can't control what mysql lib upgrades might break in our DB. |
| [16:11:38] | rsiebert_ (rsiebert_!~quassel@e179132010.adsl.alicedsl.de) has joined #mythtv | |
| [16:12:16] | wagnerrp: | Captain_Murdoch: well it would still be stored in exactly the same manner as a traditional mysql database |
| [16:12:18] | peitolm: | unless the db isn't mysql |
| [16:12:28] | wagnerrp: | you could just stop the master backend |
| [16:12:37] | wagnerrp: | point mysqld at the folder |
| [16:12:38] | Captain_Murdoch: | peitolm, we're not talking about changing engines, just embedding |
| [16:12:42] | rsiebert (rsiebert!~quassel@e179128171.adsl.alicedsl.de) has quit (Read error: No route to host) | |
| [16:12:46] | wagnerrp: | and use any traditional mysql client |
| [16:13:17] | Captain_Murdoch: | wagnerrp, to me that could be worse than just providing our own limited set of SQL commands via mythsqlclient. |
| [16:13:37] | stuartm: | Captain_Murdoch: without a plugin facility in the master how would you handle protocol extensions, the master needs to know about these things to handle them correctly? |
| [16:13:37] | Captain_Murdoch: | attaching our DB to mysqld should be an unsupported operation IMHO. |
| [16:13:39] | wagnerrp: | considering mysqld and mythbackend would be linked to the same libs, they should be compatible |
| [16:14:47] | wagnerrp: | Captain_Murdoch: there is that too, im using a centralized scheduler for the jobqueue rewrite, and it only makes sense that would exist in the master backend |
| [16:14:57] | Captain_Murdoch: | stuartm, I guess it depends on what qualifies as a protocol extension. what kind of things do you envision adding to the master via a plugin? I'm not opposed to them, I was just saying that things like the scheduler and DB wouldn't need to be in .so files, they could be built right in. |
| [16:15:09] | wagnerrp: | theres no reason different plugins might want similar behaviors |
| [16:15:56] | stuartm: | Captain_Murdoch: agreed on that, it complicates it vastly if we still allow an external DB plus it means we lose many benefits, such the ability to tune the 'dbms' and we can't change engines to one unsupported by mysql, that sort of thing |
| [16:17:41] | jya: | anyone building myth via cross compilation ? |
| [16:17:48] | Captain_Murdoch: | wagnerrp, yeah, makes sense. no reason server code has to be in client lib though. common lib (ie, mythtv or similar) could have common code and client code. common code in libmythtv or elsewhere, client/slave plugin in a slave .so. server side could use that lib but reside in another dir and .so. |
| [16:18:09] | Captain_Murdoch: | or we could have one .so for a plugin/feature with two init() methods in it. |
| [16:18:40] | stuartm: | Captain_Murdoch: right, I'm not invisioning turning core backend behaviour into plugins, I'm thinking more along the lines of companions to frontend plugins so that they can have local access to files and that sort of thing – take mythmusic, if we weren't planning to integrate it then we'd still need a way to perform the music scan on the backend itself: scanning across the network would be far too slow and I'm pretty sure taglib wouldn't like |
| [16:18:42] | stuartm: | it anyway |
| [16:19:02] | Captain_Murdoch: | load the plugin on the master does one thing, load it on the slave does another. all master/slave code for that specific feature is compartmentalized into one .so and maybe lib for the FE to use. |
| [16:19:29] | Captain_Murdoch: | stuartm, yeah, totally on board. makes sense. |
| [16:19:50] | wagnerrp: | Captain_Murdoch: wouldnt that make a dedicated master backend host have an unnecessarily high memory usage? if it has to carry around those shared libraries with both sides of the code in them? |
| [16:20:10] | wagnerrp: | or do only the methods it actually uses get loaded into memory? |
| [16:20:37] | Captain_Murdoch: | but some of those might be master plugins and slave plugins depending on the feature. if master doesn't have 'storage' then the mythmusic scan is actually occurring on the slave/media-server |
| [16:21:09] | Captain_Murdoch: | wagnerrp, not resident memory, parts are loaded on demand. |
| [16:21:28] | Captain_Murdoch: | I'm not advocating one lib, it's just an option. |
| [16:21:54] | wagnerrp: | ive never been all that clear on when shared libs actually start consuming physical memory |
| [16:22:06] | Captain_Murdoch: | segmenting code makes it easier to follow, so I'd be for 2 .so files to dlopen. |
| [16:23:30] | Captain_Murdoch: | dlopened lib is memory mapped where possible I believe. |
| [16:23:50] | stuartm: | Captain_Murdoch: right, in that example there might not be a need for a master component, but I'm sure there will be some more creative uses of backend plugins that would need to be on the master, even changing/overriding 'core' master functionality, such as altering scheduling behaviour in some custom fashion |
| [16:24:03] | wagnerrp: | as for scans, id actually prefer such things be managed on the master |
| [16:24:20] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv | |
| [16:24:34] | wagnerrp: | i could see some use for a 'pluggable' scheduler |
| [16:24:59] | wagnerrp: | id still like to see someone actually implement an efficient 'record everything on X channel' |
| [16:25:21] | Captain_Murdoch: | scans can be managed on the master, but will need slave components to do the actual scan and metadata parsing, etc.. that's the reason for a 'master' plugin part and a 'slave' plugin part. |
| [16:25:24] | wagnerrp: | our current scheduler is horribly optimized for that sort of behavior, and it should be since thats completely counter to how its supposed to operate |
| [16:25:37] | wagnerrp: | but there still seem to be plenty of users who want to use it that way |
| [16:34:07] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone - http://colloquy.mobi) | |
| [16:34:43] | Captain_Murdoch: | yeah, maybe that is a reason to have the scheduler pluggable, but that's a slippery slope. we could make users just use patches if they want that level of functionality. scheduler and DB are core, IMHO. easy to shoot yourself in the foot with either. |
| [16:36:20] | Captain_Murdoch: | we have 'record everything on X channel', it's called LiveTV. :) |
| [16:36:55] | stuarta: | cat /dev/dvb/adapter0/demux0 > moo.mpg |
| [16:37:11] | stuarta: | watching it is a little harder |
| [16:37:13] | Captain_Murdoch: | I think you can start that via a mythproto command without having a FE. I think one of the groups working on one of the mobile devices does that. |
| [16:39:05] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [17:05:32] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [17:07:46] | Goga777 (Goga777!~Goga777@2.95.148.172) has joined #mythtv | |
| [17:11:39] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [17:19:07] | solars (solars!~solars@clnet-kmu02-090.ikbnet.co.at) has quit (Read error: Operation timed out) | |
| [17:26:56] | stichnot: | sphery: I marked #10389 as fixed, but did you get a chance to test keyframe-seek mode under 0.24? |
| [17:39:34] | stuartm: | stuarta: http://www.digitalspy.co.uk/tech/news/a368497 . . . onality.html |
| [17:40:03] | stuartm: | what those changes actually are, I don't know yet |
| [17:45:51] | wagnerrp: | Beirdo: after we transition to our own hosted repo, and use github as a mirror |
| [17:46:06] | Beirdo: | aye? |
| [17:46:19] | wagnerrp: | will things like github's pull requests still function? |
| [17:46:36] | wagnerrp: | or will github effectively be read-only? |
| [17:46:40] | Beirdo: | not with a one-button push. |
| [17:46:47] | Beirdo: | yeah, I'll be setting it read-only |
| [17:47:03] | Beirdo: | pull requests DO email out saying how to do it remotely |
| [17:47:07] | Beirdo: | it's really simple :) |
| [17:47:25] | wagnerrp: | yes, but their web UI will no longer function |
| [17:47:30] | Beirdo: | but that essentially is the only thing we lose, and we rarely use it |
| [17:47:38] | Beirdo: | ummm, sure it will |
| [17:47:39] | wagnerrp: | or at least that one button wont |
| [17:47:49] | wagnerrp: | the 'apply' button |
| [17:48:12] | Beirdo: | yeah, well, the button likely won't be there if the user doesn't have commit permissions on github |
| [17:48:46] | Beirdo: | that's such a tiny part of our workflow though |
| [17:48:50] | Beirdo: | and rare |
| [17:49:16] | wagnerrp: | true |
| [17:50:34] | Beirdo: | for instance, the last one we got on mythweb (that kormoc already merged)... the beginning of the email states: |
| [17:50:38] | Beirdo: | You can merge this Pull Request by running: |
| [17:50:38] | Beirdo: | git pull https://github.com/RXM307/mythweb patch-1 |
| [17:51:20] | Beirdo: | we'll survive, I think ;) |
| [17:51:57] | stuartm: | I wasn't even aware of the one button 'pull' thing until very recently anyway |
| [17:52:11] | wagnerrp: | ive maybe used it twice |
| [17:53:28] | stuartm: | heh, fun bug, commentary track on DVD has more channels than the normal audio and we always prefer the track with more channels, so on every chapter transition it changes tracks back to the commentary |
| [17:53:50] | Beirdo: | hehe, ooops |
| [17:54:31] | Beirdo: | anyways, I guess I should head to work. Another day of workstation futzing awaits me |
| [18:01:33] | stuartm: | I can't actually remember why logical track order isn't enough, I don't believe there are any hints for DVD either so perhaps it makes sense to always trust logical ordering for DVD |
| [18:06:59] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [18:07:08] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [18:07:21] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [18:13:34] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [18:13:36] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Remote host closed the connection) | |
| [18:13:49] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [18:23:14] | stichnot: | d'oh! I should know better than to test tickets with my private patches applied |
| [18:34:11] | Malard (Malard!Malard@xbmc/staff/malard) has quit () | |
| [18:35:29] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [18:38:40] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv | |
| [18:41:00] | Malard (Malard!Malard@xbmc/staff/malard) has joined #mythtv | |
| [18:57:41] | solars (solars!~solars@mk089144206150.a1.net) has joined #mythtv | |
| [19:11:32] | Beirdo: | |
| [19:11:37] | Beirdo: | oops, sorry |
| [19:17:36] | stichnot: | can anyone explain the comment and following code at https://github.com/MythTV/mythtv/blob/master/ . . . er.cpp#L4002 ? |
| [19:17:43] | stichnot: | this is the source of the problem in #10389 |
| [19:19:10] | Goga777 (Goga777!~Goga777@2.95.148.172) has quit (Remote host closed the connection) | |
| [19:20:03] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 245 seconds) | |
| [19:21:20] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [19:25:12] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [19:32:55] | sphery: | stichnot: I can guarantee #10389 still exists in 0.24-fixes. What I was going to test is whether recording where I'd seen it on 0.24-fixes showed the same behavior on master (but I didn't expect them to, since I'm sure it was the player and not the recording). I just don't think it's worth debugging 0.24-fixes at this point (as you said in ticket close). |
| [19:33:39] | stichnot: | sphery: I found the problem, see my question/link above. |
| [19:35:15] | Beirdo: | stichnot: which line number? I don't see any comment near line 4002 as in the URL |
| [19:35:21] | sphery: | yeah, I wasn't see^^^ |
| [19:36:47] | stichnot: | Beirdo: there's a 3-line comment starting at line 4002, you're not seeing it? |
| [19:37:12] | Beirdo: | no |
| [19:37:34] | Beirdo: | return videoOutput->GetAdjustFill(); |
| [19:37:39] | Beirdo: | that's 4002 |
| [19:37:55] | stichnot: | it's in MythPlayer::HandleArbSeek() |
| [19:38:22] | Beirdo: | ah. line 3978 |
| [19:39:17] | stichnot: | you're right, it's line 3978 in my file. thanks again github! |
| [19:39:31] | Beirdo: | not sure we're looking at the exact same code if our line numbers are that far off |
| [19:39:34] | Beirdo: | ahh |
| [19:39:43] | sphery: | hehe, you probably have some patches on your local code--but with github's "Denial-of-Service" JavaScript-based UI, I can see why you might skip looking on github... |
| [19:41:05] | sphery: | oh, you did look on github... might be the bug where sometimes the #L1234 gets stuck in the address bar even though it moves your view (I saw that one a few days ago) |
| [19:41:27] | Beirdo: | heh |
| [19:42:10] | sphery: | stichnot: fwiw, though, I have no idea what that comment is about. Perhaps danielk22 has an idea? |
| [19:42:25] | stichnot: | anyway, to step to the left by keyframe, that code asks the decoder to seek 2 frames back but snap to the next keyframe. If I change the "step to the right" code to also use 2 frames (instead of that weird calculation), the bug is fixed. |
| [19:44:42] | stichnot: | in the test file, most keyframes are 24 frames apart, but then there is the odd one that's only 9 frames away. apparently MythPlayer's value of keyframedist is bigger than 9 so it skips past the close keyframe. |
| [19:45:00] | stichnot: | I bet markk knows :) |
| [19:51:34] | danielk22: | stichnot: The original editing code was built around a fixed keyframe distance of either 15 or 12 frames. This looks like a hack to allow it to work with DTV sources where the keyframe distance may not be fixed. |
| [19:52:15] | stichnot: | In any case, I would like to change the fastforward code to be just like the rewind code, i.e. move 2 frames then snap to the next keyframe. This only affects edit mode, and if the user has a weird recording without proper keyframes such that keyframe stepping now moves 2 frames forward instead of 18, we can deal with it then. |
| [19:53:54] | stichnot: | sphery, I don't have a 0.24 setup. If I commit that change to master (assuming it's OK with everyone), would you want to cherry-pick it to 0.24 and test it? or just wait for 0.25? |
| [19:56:34] | sphery: | I'd say just wait... it's really not a big deal once you realize that it's just skipping 2 keyframes forward and you can use left once to hit the skipped one or twice to get back where you were (so those who really care can work around it until 0.25) :) |
| [19:57:01] | sphery: | thanks for looking into it, btw. it had been on my TODO for about 2yrs, now |
| [19:57:35] | sphery: | (which is another reason why waiting a bit over a month for 0.25 seems fine :) |
| [20:43:07] | stichnot: | sphery: OK, I'll just fix for 0.25 and (re)close the ticket. |
| [20:48:08] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 240 seconds) | |
| [21:03:15] | stichnot_ (stichnot_!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [21:05:39] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [21:05:41] | stichnot_ is now known as stichnot | |
| [21:23:04] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [21:25:10] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [21:27:06] | foobum_ (foobum_!~foobum@78-105-15-213.zone3.bethere.co.uk) has quit (Ping timeout: 252 seconds) | |
| [21:35:25] | foobum (foobum!~foobum@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv | |
| [21:37:30] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:39:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 265 seconds) | |
| [21:45:08] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 244 seconds) | |
| [21:49:38] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [21:55:34] | joki (joki!~joki@p54861D78.dip.t-dialin.net) has quit (Ping timeout: 245 seconds) | |
| [21:56:28] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 255 seconds) | |
| [21:57:12] | joki (joki!~joki@p5486305D.dip.t-dialin.net) has joined #mythtv | |
| [21:57:52] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has joined #mythtv | |
| [21:57:52] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has quit (Changing host) | |
| [21:57:52] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [22:07:23] | frankster: | gigem: ah good thinking, though I think configuring a custom keytable is as bad as having to configure lirc (or in fact worse cos it will also change it for every other app as well which may matter depending how you use the remote) |
| [22:28:06] | davide: | frankster: yeah, it's bad but it has the advantage that the keys work with applications that don't support lirc. i used to get annoyed when mythfrontend crashed, not only because of the bug, but because i then had to go get the keyboard and press up then enter. since my remote works in xterm/konsole/gnome-terminal or whatever, i don't have to go get the keyboard anymore. |
| [22:29:38] | davide: | btw, i ran across a new package i hadn't noticed before. debian calls it inputlirc. it's a light-weight, no-configuration-needed replacement for lircd for devinput supported devices. |
| [22:30:43] | solars (solars!~solars@mk089144206150.a1.net) has quit (Quit: WeeChat 0.3.5) | |
| [22:31:58] | stichnot_ (stichnot_!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [22:34:37] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [22:34:38] | stichnot_ is now known as stichnot | |
| [22:36:48] | j-rod is now known as j-rod|afk | |
| [22:52:40] | stichnot: | sphery: One of my private patches duplicates the UNDO/REDO keybindings in the TV Editing context (the original bindings are in the Global context). I need this because my remote doesn't have enough buttons to devote two to undo/redo. There are lots of unused buttons in TV Editing, so I want to use the 7 and 9 buttons for undo and redo. Other people may have the same issue. Since the undo... |
| [22:52:42] | stichnot: | ...stack is new for 0.25, is there something we can do about this before the release? |
| [22:57:53] | stichnot: | One possibility is to add UNDOEDIT/REDOEDIT keybindings to the TV Editing context, and process both UNDO and UNDOEDIT the same, and similar for REDO and REDOEDIT. |
| [22:59:16] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Read error: Connection reset by peer) | |
| [22:59:35] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [23:04:45] | peitolm (peitolm!~moreyc@mandlebrot.random-chaos.org.uk) has quit (Ping timeout: 260 seconds) | |
| [23:15:53] | xavierh_ (xavierh_!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [23:16:03] | Beirdo: | stichnot: wouldn't that be classed a new feature at this point? |
| [23:17:13] | stichnot: | Beirdo: that's part of my question, given that it's a piece of #8901 which is new in 0.25 |
| [23:17:45] | Beirdo: | we are (in my opinion) too close to release to be considering slipping in new features unless they are truly considered crucial. We barely have any time to work out issues in the code we have now :) |
| [23:18:52] | Beirdo: | but, if it's fixing it, that's another story. It just seems rather "new feature" to me. I'm just one voice though :) |
| [23:21:33] | Beirdo: | I guess we'll see what others think :) We are about a month out from what *should* be fully debugged (ha!) release |
| [23:22:26] | Beirdo: | if it is fully debugged, I think it will be a first, but that *is* the goal :) |
| [23:25:02] | stichnot: | My private patch is 2 statements and I've been running it over a year. :) The suggestion I put above would be a couple more lines. But I think sphery has ideas on enhancing keybindings that these two ideas are in conflict with. |
| [23:25:12] | Beirdo: | cool |
| [23:25:35] | Beirdo: | I'm just being over-cautious, I'm sure. :) Carry on! :) |
| [23:25:55] | stichnot: | it's definitely in the grey area between fix and feature, which is why I'm asking |
| [23:25:56] | Beirdo: | I leave you in sphery's fine hands anyways. |
| [23:26:25] | Beirdo: | yeah :) He'd be a better person to comment on it, I was just noticing that we are dancing on the line and all |
| [23:26:45] | stichnot: | can someone send out the sphery-signal? his sphery-senses must be all a-tingle by now |
| [23:27:48] | Beirdo: | He's probably off spending time having a real life for a moment or two. It does happen occasionally, but he'll be back |
| [23:51:14] | frankster: | davide: interesting, i'll check it out |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.