| Tuesday, June 17th, 2014, 00:00 UTC | ||
| [00:00:14] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:08:15] | MythBuild: | build #2087 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2087 |
| [00:08:18] | MythBuild: | build #1776 of master-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1776 |
| [00:09:03] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [00:18:16] | MythBuild: | build #1757 of master-ubuntu-current-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1757 |
| [00:21:20] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has joined #mythtv | |
| [00:21:20] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [00:21:20] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has quit (Changing host) | |
| [00:28:24] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:32:54] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [00:41:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [00:57:01] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [01:00:17] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [01:13:39] | acle (acle!~tb@seattle-nat.cray.com) has joined #mythtv | |
| [01:23:46] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-)) | |
| [01:42:42] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [01:54:54] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:11:51] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:11:56] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [02:11:56] | peper03_ is now known as peper03 | |
| [02:16:25] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:43:47] | arescorpio (arescorpio!~arescorpi@86-237-16-190.fibertel.com.ar) has quit (Read error: Connection reset by peer) | |
| [02:47:30] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-)) | |
| [03:11:02] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [03:12:25] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:17:34] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [05:16:41] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [05:16:54] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [05:16:54] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [05:40:22] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [06:07:33] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:15:31] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:19:59] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [08:06:36] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 260 seconds) | |
| [08:08:56] | amessina (amessina!~amessina@50-196-241-78-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [08:16:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (*.net *.split) | |
| [08:16:35] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (*.net *.split) | |
| [08:16:35] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (*.net *.split) | |
| [08:16:36] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (*.net *.split) | |
| [08:16:36] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (*.net *.split) | |
| [08:16:37] | zentec (zentec!~zentec@71.82.202.47) has quit (*.net *.split) | |
| [08:16:37] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has quit (*.net *.split) | |
| [08:16:37] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has quit (*.net *.split) | |
| [08:16:37] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (*.net *.split) | |
| [08:16:37] | dekarl (dekarl!~dekarl@p4FE85AF0.dip0.t-ipconnect.de) has quit (*.net *.split) | |
| [08:16:39] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (*.net *.split) | |
| [08:16:39] | xris (xris!~xris@mythtv/developer/xris) has quit (*.net *.split) | |
| [08:16:39] | poptix (poptix!poptix@poptix.net) has quit (*.net *.split) | |
| [08:16:39] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (*.net *.split) | |
| [08:16:39] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has quit (*.net *.split) | |
| [08:16:40] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split) | |
| [08:16:40] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (*.net *.split) | |
| [08:16:40] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has quit (*.net *.split) | |
| [08:16:42] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:c457:ef1d:60fd:2177) has quit (*.net *.split) | |
| [08:16:42] | nephyrin (nephyrin!~neph@2620:101:80fc:224:7a2b:cbff:fe9e:2e67) has quit (*.net *.split) | |
| [08:16:42] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split) | |
| [08:16:42] | robink (robink!~quassel@unaffilated/robink) has quit (*.net *.split) | |
| [08:16:43] | ryan_turner|MTW (ryan_turner|MTW!Ryan@2600:3c01::f03c:91ff:fe69:f4ab) has quit (*.net *.split) | |
| [08:16:43] | tgm4883 (tgm4883!uid23806@gateway/web/irccloud.com/x-hmczmnnvchouefrt) has quit (*.net *.split) | |
| [08:16:44] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (*.net *.split) | |
| [08:20:44] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [08:20:44] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:20:44] | zentec (zentec!~zentec@71.82.202.47) has joined #mythtv | |
| [08:20:44] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [08:20:44] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has joined #mythtv | |
| [08:20:44] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [08:20:44] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [08:20:44] | dekarl (dekarl!~dekarl@p4FE85AF0.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:20:44] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [08:20:44] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [08:20:44] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [08:20:44] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [08:20:44] | poptix (poptix!poptix@poptix.net) has joined #mythtv | |
| [08:20:44] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv | |
| [08:20:44] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has joined #mythtv | |
| [08:20:44] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [08:20:44] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [08:20:44] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has joined #mythtv | |
| [08:21:11] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:c457:ef1d:60fd:2177) has joined #mythtv | |
| [08:21:11] | nephyrin (nephyrin!~neph@2620:101:80fc:224:7a2b:cbff:fe9e:2e67) has joined #mythtv | |
| [08:21:11] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [08:21:11] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [08:21:11] | ryan_turner|MTW (ryan_turner|MTW!Ryan@2600:3c01::f03c:91ff:fe69:f4ab) has joined #mythtv | |
| [08:21:11] | tgm4883 (tgm4883!uid23806@gateway/web/irccloud.com/x-hmczmnnvchouefrt) has joined #mythtv | |
| [08:21:11] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
| [08:22:10] | robink (robink!~quassel@unaffilated/robink) has quit (Max SendQ exceeded) | |
| [08:28:11] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [08:33:19] | robink (robink!~quassel@unaffilated/robink) has quit (*.net *.split) | |
| [08:33:20] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (*.net *.split) | |
| [08:33:20] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (*.net *.split) | |
| [08:33:20] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (*.net *.split) | |
| [08:33:20] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (*.net *.split) | |
| [08:33:21] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (*.net *.split) | |
| [08:33:21] | zentec (zentec!~zentec@71.82.202.47) has quit (*.net *.split) | |
| [08:33:21] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has quit (*.net *.split) | |
| [08:33:22] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has quit (*.net *.split) | |
| [08:33:22] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (*.net *.split) | |
| [08:33:22] | dekarl (dekarl!~dekarl@p4FE85AF0.dip0.t-ipconnect.de) has quit (*.net *.split) | |
| [08:33:23] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (*.net *.split) | |
| [08:33:23] | xris (xris!~xris@mythtv/developer/xris) has quit (*.net *.split) | |
| [08:33:23] | poptix (poptix!poptix@poptix.net) has quit (*.net *.split) | |
| [08:33:24] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (*.net *.split) | |
| [08:33:24] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has quit (*.net *.split) | |
| [08:33:24] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split) | |
| [08:33:24] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (*.net *.split) | |
| [08:33:25] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has quit (*.net *.split) | |
| [08:36:40] | dekarl (dekarl!~dekarl@p4FE85043.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:44:05] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [08:44:05] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [08:44:05] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:44:05] | zentec (zentec!~zentec@71.82.202.47) has joined #mythtv | |
| [08:44:06] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [08:44:06] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has joined #mythtv | |
| [08:44:06] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [08:44:06] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [08:44:06] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [08:44:06] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [08:44:06] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [08:44:06] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [08:44:06] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [08:44:06] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has joined #mythtv | |
| [08:44:06] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [08:44:06] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has joined #mythtv | |
| [08:44:06] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv | |
| [08:44:06] | poptix (poptix!poptix@poptix.net) has joined #mythtv | |
| [08:46:24] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [08:57:28] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Remote host closed the connection) | |
| [08:59:07] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Ping timeout: 255 seconds) | |
| [09:00:37] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [09:01:21] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 240 seconds) | |
| [09:03:15] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [09:06:53] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:15:23] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [09:22:02] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:24:38] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 244 seconds) | |
| [09:24:39] | jya_ is now known as jya | |
| [09:25:22] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:25:27] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [09:25:27] | jya_ is now known as jya | |
| [09:55:12] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [09:58:13] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 244 seconds) | |
| [10:34:34] | stuarta: | well that's mysql replication fixed again. i'm now replicating alcor's mysql to my server so we have an online backup |
| [11:27:31] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:27:42] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 245 seconds) | |
| [11:27:42] | jya_ is now known as jya | |
| [12:55:14] | dblain: | stuartm: In researching the throw issue, I came across this – http://stackoverflow.com/questions/3609940/ha . . . -to-qtscript |
| [12:56:12] | dblain: | I was going to try and add execption handlers to the mythbackend\services – Scriptible classes that we have and then have it create the QtScript error/exception. |
| [12:56:22] | dekarl: | stuartm, mind to close https://github.com/MythTV/mythtv/pull/30 after https://code.mythtv.org/trac/changeset/bb8c24 . . . b4f66/mythtv ? |
| [12:58:19] | dblain: | stuartm: I've been rebuilding my dev environment, then had a conference I needed to attend for a few days, so I haven't had time to test this approach. |
| [13:00:19] | dblain: | As for QScriptEngine being thread safe. I tried to be thread-safe with all the code for the backend http server, and would need to review how I implemented (memory not as good as it used to be), but it's definitly possible that I didn't create a new instance of the engine for each thread. |
| [13:01:24] | dblain: | (I also just read a Qt Bug that says there is an error in sharing QScriptProgram instances even though the evaluate method takes a const reference. So that may add to the problem your are seeing. |
| [13:02:19] | dekarl: | stuartm, this also appears to have long been commited https://github.com/MythTV/mythtv/pull/36 https://code.mythtv.org/trac/changeset/2c20e7 . . . bd570/mythtv |
| [13:07:32] | dekarl: | stuartm, this has a comment that its been fixed https://github.com/MythTV/mythtv/pull/67 |
| [13:16:01] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [13:21:51] | stuartm: | dblain: it was definitely one instance, for now I just extended the existing locking around all uses of QScriptEngine which I believe has fixed the issue, but you might prefer another approach |
| [13:23:15] | stuartm: | I think you mentioned that stackoverflow fix before, just slipped my mind, will give it a go |
| [13:42:31] | jya1 (jya1!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has joined #mythtv | |
| [13:42:56] | jya1: | found out why opengl2 painter doesn't work with vdpau |
| [13:43:05] | stuarta: | \o/ |
| [13:43:31] | jya1: | got involved in an unrelated discussion on the libva mailing list with some intel engineers |
| [13:43:53] | jya1: | xbmc folks got involved too (as the answer to my question was of interest for them) |
| [13:44:14] | stuarta: | that can be productive when you get to speak with the engineers |
| [13:44:46] | jya1: | turned out, how we (and xbmc too) are drawing the decoded frame, in the openGL surface is actually not the proper way to do that |
| [13:45:13] | jya1: | and that there's actually no proper openGL implementation in libva |
| [13:45:25] | ** stuarta is find the mailing list archives ** | |
| [13:45:36] | stuarta: | well that sucks then |
| [13:45:43] | jya1: | it works with intel, but not vdpau backend or amd |
| [13:45:51] | jya1: | and it "sorta" works pretty much |
| [13:46:09] | jya1: | xbmc were fast, they have already made an implementation for it |
| [13:46:33] | jya1: | me, I'm still working on squeezing the last cycles in the SSE code |
| [13:46:49] | stuarta: | they are always fast |
| [13:47:15] | jya1: | actually, instead of copying the texture in OpenGL surface |
| [13:47:34] | jya1: | instead, you copy into an X buffer |
| [13:47:56] | jya1: | it's even simplier to implement, and will work with qt painter |
| [13:48:18] | stuarta: | ooo nice |
| [13:48:26] | jya1: | and intel have already submitted patches to fixes my performance issue (it's a bug in their code) |
| [13:48:37] | stuarta: | ooo nice x2 |
| [13:48:55] | jya1: | funny also on who read libva-devel |
| [13:49:40] | jya1: | I made a comment on how we didn't support XVBA, but only VAAPI and VDPAU, and that amd's OSS drivers got almost just as good as nvidia's driver |
| [13:50:00] | jya1: | 10 minutes later, email from AMD's asking what was missing, and what could be changed |
| [13:53:44] | ** stuarta is reading that now ** | |
| [13:54:44] | stuarta: | graphics is such a black art |
| [13:57:55] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [13:57:56] | jya1: | what would cause a "failed to get upgrade lock"? |
| [13:58:52] | jya1: | when I start mythtv-setup, i get hundreds of "Waiting for database schema upgrade lock" |
| [14:00:21] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [14:02:06] | stuartm: | is the backend or frontend running? |
| [14:02:17] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Ping timeout: 245 seconds) | |
| [14:02:17] | jya1: | backend isn't running |
| [14:02:51] | jya1: | and frontend is running as another user, and connected to a different DB/Backend on another host |
| [14:03:11] | stuartm: | that was my one idea |
| [14:03:52] | jya1: | restarting mysql fixed it |
| [14:04:04] | jya1: | it's a very puzzling action |
| [14:04:26] | jya1: | when i start it via X, it shows a black screen for over 2 minutes |
| [14:04:42] | jya1: | can't swap application, can't see what's going on |
| [14:05:04] | jya1: | until mythtv-setup dies that it couldn't get a lock |
| [14:05:09] | stuartm: | is it possible that a process, backend or mythtv-setup started, obtained the lock to do the upgrade but was then aborted before it could release the lock? |
| [14:05:52] | stuarta: | okay, something did a "LOCK TABLE..." then |
| [14:06:01] | stuarta: | restarting mysql releases the lock |
| [14:06:03] | stuartm: | I don't think a schema level lock is released even if the db connection is closed |
| [14:06:36] | stuartm: | s/schema/table/ |
| [14:07:04] | stuartm: | sphery: ^^ |
| [14:10:37] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 245 seconds) | |
| [14:12:46] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [14:18:07] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [14:26:11] | jya1: | oh well... my carefully crafted new SSE code, turned out to be slower than a plain memcpy when used with our vaapi code |
| [14:26:44] | jya1: | weird, when used in VLC, I improved the time to process a frame from 0.97ms to 0.80ms |
| [14:27:31] | jya1: | maybe it's only better for bigger frames, as PIP works only on recordings, all i have are SD |
| [14:27:45] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [14:28:53] | gigem: | stuartm: The recording filters don't work that way. They are only designed to limit matching programs after the base criteria is met. If the base criteria is changed to only match title, then other titles with the same seriesid will never match. I'm not opposed to adding a 'This title' filter, but I wonder if would be used enough to warrant it. The filters were never intended to completely replace custom |
| [14:28:55] | gigem: | rules. They're there to cover the most common cases. |
| [14:32:09] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Client Quit) | |
| [14:32:44] | stuartm: | gigem: ah of course |
| [14:34:38] | jya1 (jya1!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has quit (Ping timeout: 244 seconds) | |
| [14:35:54] | gigem: | stuartm: What would you consider an 'identical' recording rule? |
| [14:37:35] | stuartm: | gigem: one where all elements are identical, carbon copy of another, thinking only of the case where for whatever reason a client of the Services API submits the same identical POST to AddScheduleRecord |
| [14:39:03] | stuartm: | e.g. a user manages to double click instead of single click 'record' in the web frontend or similar |
| [14:40:19] | stuartm: | we can try to mitigate the foreseeable causes in the WebFrontend but from a data integrity standpoint it might be good to have a safeguard on the server side so that all clients of the API benefit |
| [14:46:39] | dekarl: | Should I add some LUA integration for EIT Fixups so our users can inject scripts that remove seriesid when they hurt more then they help? |
| [14:47:20] | dekarl: | been thinking about something like that for some time, but I can't come up with a nice design that allows sharing and updating of these scripts. (think shared ad-blocker lists) |
| [14:47:59] | stuarta: | more stuff for services? but what we really need is the crowd approved stuff to work there |
| [14:48:02] | stuartm: | dekarl: might as well use the existing scripting engine we have now? |
| [14:48:16] | stuartm: | ^^ |
| [14:48:55] | stuarta: | for icons, which we could then re-use for fixups |
| [14:49:35] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has joined #mythtv | |
| [14:52:39] | dekarl: | stuart[am], I think we need lots more services stuff and yes, crowd sourced/approved. best to do it in a musicbrainz editor style and integrated it into an atlas style headend ... but ENOTIME ;) |
| [14:52:39] | stuartm: | not that JS is especially fast for regexp, but then why lua, why not python, ruby, perl, bash, ada etc. Better IMHO if we're going to do it to try and consolidate on one of those to keep things simple to maintain |
| [14:53:01] | dekarl: | LUA because it does not add so many dependencies |
| [14:53:21] | stuarta: | dekarl: sadly we need the infrastructure in place first |
| [14:53:39] | dekarl: | but I doe agree on the "don't add yet another scripting language" part. |
| [14:53:51] | ** stuarta wonders if this is something we could leverage openshift cloud instances for ** | |
| [14:54:19] | stuartm: | JS adds none at all fwiw, can hook directly to C++ code too and a lot of the parts are already present – I was thinking about using it for plugins just last night |
| [14:55:07] | dekarl: | hmm, I like the "make it easy to write a plugin for mythtv with your xbmc plugin skills" concept that someone mentioned some time ago |
| [14:55:29] | dekarl: | I think that would be python then |
| [14:56:57] | stuartm: | if we used python then we'll need a python <> scripting API layer |
| [15:01:25] | sphery: | dekarl (and gigem): speaking of seriesid, did Angela's statement, "Also the seriesid is maintained different depending on the channel, keeping it simple, just based on the title seems to be the best for me," imply that we're not taking defaultauthority into account for seriesid in recording rules or just that defaultauthority is missing from the database/data? |
| [15:01:30] | gigem: | stuartm: I understand the use case. Let me rephrase my question, how much identical is enough? For example, is title, chanid, starttime and type enough? Is the services backend processing multithreaded? If so, there could be race conditions trying to perform such a check, but a modest, unique constraint on the recorded table would solve that. |
| [15:02:08] | stuartm: | sphery: could be the latter, we should be ignoring the seriesid entirely if there is no default authority |
| [15:02:10] | stuartm: | stuarta: ^^ |
| [15:03:17] | sphery: | stuartm: Is defaultauthority per listings provider? Do EIT users get different values per channel? |
| [15:03:44] | gigem: | sphery: Those could be issues. I haven't had time to follow up with Angela yet. I was also hoping dekarl could shed some light on how seriesid gets determine from EIT in Germany. |
| [15:03:45] | sphery: | if so, we should probably ignore seriesid when defaultauthority is missing or when it differs |
| [15:04:00] | stuarta: | sphery: with EIT data, it's either per mux (if all channels have the same value) or per channel |
| [15:04:09] | sphery: | ah, ok |
| [15:04:10] | dekarl: | sphery: I understood it as "each broadcaster has a different craplevel" ;) |
| [15:04:27] | stuarta: | the default_authority+series_id = actual series_id |
| [15:04:34] | stuarta: | same for program id |
| [15:05:06] | stuarta: | dekarl: if i had a dollar for every broadcasters crap level..... |
| [15:05:43] | ** stuarta wanders off to make a cuppa ** | |
| [15:06:00] | gigem: | AIUI, we include the authority when we have one in programid. Do we do that for seriesid too? |
| [15:06:00] | stuartm: | gigem: Services API is multi-threaded, I was only envisioning the case where everything was identical, but yes maybe chanid/starttime/title/type is even better and covers more possibilities than the one I was describing. A DB constraint would seem to be the easiest and most foolproof solution |
| [15:07:25] | gigem: | stuartm: I added it to my (hopefully, short-term) TODO list. |
| [15:07:31] | sphery: | stuarta: So it sounds like the defaultauthority should be taken into account in seriesid comparisons (as it's part of the value inserted into the seriesid field, right?). |
| [15:08:07] | stuartm: | we do include the DA with seriesid, I'm just not sure without checking whether we ignore the series/program ids if the DA is empty/null |
| [15:08:56] | stuartm: | e.g. www.questtv.co.uk/s9035 www.sky.com/g_skyb1233657 www.nhk.or.jp/nhkworld/9929 |
| [15:09:00] | sphery: | yeah, wasn't there a time when it was common for users to have no da (broken channel scanner or something like that)? |
| [15:09:06] | stuartm: | pulled from my program table for series id |
| [15:09:57] | sphery: | perhaps the channels, etc. were put in place back then and da is missing still? |
| [15:10:23] | stuartm: | sphery: there was a time before we even extracted/stored the DA, so potentially users who haven't rescanned in a very long time won't have it – we also weren't looking at every table that could include the DA for a while, missing the DA stored in the BAT for some networks |
| [15:10:37] | gigem: | The other strange thing about Angela's case is that the match seems to show up out of nowhere, as if a seriesid gets added or changed at the last minute. |
| [15:11:10] | sphery: | yeah, and I didn't think we were even using now/next data, even for users with EIT enabled |
| [15:11:36] | sphery: | Angela said it often has no seriesid in normal data, but it appears with now/next |
| [15:11:41] | stuartm: | gigem: that could happen with EIT, there are both long term and short term event streams, the latter sometimes carries more information but those only extend a couple of hours into the future |
| [15:11:58] | stuartm: | sphery: we are using it |
| [15:12:14] | sphery: | ah, ok, so that probably does explain that |
| [15:13:15] | gigem: | stuartm: Yes, that would explain it. |
| [15:13:17] | sphery: | so would it be worth asking when the last rescan was done and possibly suggesting a new rescan (to get DA)? |
| [15:13:44] | sphery: | I guess maybe even just checking if DA is in DB would be an easier start |
| [15:14:08] | stuartm: | a lot of broadcasters choose to save bandwidth by not including all the program information in the 'normal' events, only the near-term updates |
| [15:14:37] | stuarta: | sphery: it should already be in the seriesid |
| [15:14:43] | stuartm: | sphery: I'd start by getting a sample of the programid/seriesid and DA columns from the channel and dtv_multiplex tables |
| [15:15:14] | stuartm: | stuarta: but do we only insert the seriesid if the DA is present? |
| [15:15:32] | stuartm: | that's the bit I'm not sure about – I was about to check |
| [15:15:32] | stuarta: | no idea |
| [15:15:38] | stuarta: | i'd have to check too |
| [15:15:41] | sphery: | yeah, seems that would be a good idea |
| [15:15:52] | sphery: | as otherwise, it's likely to overlap |
| [15:19:01] | dekarl: | gigem, yes, we do it for both https://code.mythtv.org/cgit/mythtv/tree/myth . . . xup.cpp#n250 |
| [15:19:16] | stuartm: | ln 290, eitfixup.cpp // no authority, not a valid CRID, return empty |
| [15:19:24] | stuarta: | \o/ |
| [15:23:24] | gigem: | I'll ask Angela what she has in her database, and we can go from there. |
| [15:24:54] | gigem: | If we're through with that issue for the moment, I have another. Does anyone have an opinion on fixing #12175 in fixes/0.27? I can't do an official schema update like I did for master. About the best I can do is add a conditional update at every backend/scheduler startup. |
| [15:24:54] | ** MythLogBot http://code.mythtv.org/trac/ticket/12175 ** | |
| [15:26:22] | stuartm: | note, that there is an earlier check that might cause it to return an invalid series id if the crid is missing a leading '/' |
| [15:26:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [15:27:11] | stuartm: | gigem: sounds good |
| [15:39:07] | dekarl: | stuarta, what do you mean by "long term and short term event streams"? EIT schedule and EIT present/following? |
| [15:39:45] | stuarta: | dekarl: yeah if i said that, that would be what i mean |
| [15:40:00] | dekarl: | I see a difference between EIT Schedule for close and far events, but that's within the same stream, just a different 3hour subtable |
| [15:40:52] | stuarta: | we trust the data from the table with the lowest id best. ie p/f data |
| [15:40:53] | dekarl: | stuarta, meh, stuartm said that... |
| [15:40:59] | stuarta: | :) |
| [15:42:16] | stuartm: | dekarl: yes that's what I meant, was trying to express it in simple terms for those not familiar with the proper names |
| [15:42:52] | stuartm: | and yes, there may be last minute updates in the regular data too |
| [15:44:16] | stuartm: | different broadcasters (or networks) have different approaches to save space – Freesat uses compression, which I'm not sure is actually in the spec at all |
| [15:44:56] | stuarta: | they would get around that with an implementation guide (can't remember the proper term) |
| [15:45:24] | stuarta: | there's one for uk dvb-t |
| [15:46:06] | stuartm: | yay for specs that let you extend the spec at will :) |
| [15:47:04] | stuarta: | they more clear up the ambiguities in the spec |
| [15:47:30] | stuarta: | found the one for dvb-t2 |
| [15:47:35] | stuarta: | http://www.etsi.org/deliver/etsi_ts/102800_10 . . . v010201p.pdf |
| [15:59:32] | stuarta: | sheesh, lots of reading here http://www.oipf.tv/specifications |
| [16:10:08] | dekarl: | stuartm, IIUIC freesat uses content encryption due to some requirenment... the encryption is huffman compression with a table that needs to be licensed |
| [16:11:53] | dekarl: | stuartm, I see. Its confusing with all the different ways to save bandwidth, e.g. only using the short_event_descriptor for stuff more then 3 days out, the moving its contents into the extended_event_descriptor and writin something else in the short event... Fiddling with the repetition rates so programmes that are weeks in the future are only announced every 5 minutes or so |
| [16:13:15] | stuartm: | it's not encryption, it's just compression |
| [16:13:47] | stuartm: | just compression that uses a custom compression table which they don't share openly |
| [16:16:42] | stuartm: | legally they can't use encryption, though they might like to just to stop pay tv providers like Sky from benefiting from their free services – Sky boxes can receive the free channels and Sky don't exactly advertise that these channels are free so many customers might have the mistaken impression that they are part of the package their are paying for |
| [16:18:30] | stuartm: | s/their/they're/ |
| [16:24:43] | ** stuarta heads home ** | |
| [16:25:43] | dekarl: | stuartm, I don't find an explicit reference right now, only http://www.broadbandtvnews.com/2009/11/17/huf . . . -on-freesat/ "In the case of Freesat, Huffman ensures that only approved manufacturers gain access to the SI (Service Information), differentiating them from standard free-to-air receivers in the market." |
| [16:26:30] | dekarl: | Also the reference to irish Sat4Free having to encrypt their channels due to licensing, but having the UK channels in the clear sounds very similar to the situation between germany vs. austria/switzerland |
| [16:27:20] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [16:32:06] | stuartm: | dekarl: yeah, there's no question that it serves as some degree of protection, but if that was really the driving factor they could just have used real encryption for the EIT or buried it in a private stream that shifted periodically so that STBs didn't know where to find it |
| [16:32:46] | stuartm: | and the huffman tables didn't prove too hard for one clever user to reverse engineer from the raw data |
| [16:34:11] | stuartm: | some time back we chatted with a BBC guy about it and he was clear that first and foremost it was about saving bandwidth, any content protection that it offered was just a bonus |
| [16:36:22] | rsiebert (rsiebert!~quassel@f052169169.adsl.alicedsl.de) has joined #mythtv | |
| [16:37:26] | dekarl: | stuartm I guess that's the difference between the engineer vs. sales guy view :) |
| [16:37:43] | stuartm: | of course a BBC/Freesat rep trying to convince STB makers to join the group and help to fund freesat operations might lead with 'content protection', but content protection was specifically one of the things that Freesat was in direct opposition to |
| [16:38:13] | stuartm: | not just 'Free' but 'Free to Air' |
| [16:42:06] | stuartm: | licensing issues arise with satellite because unlike terrestrial it's harder to prevent people outside the licensed area receiving the signal, that's why Freesat has been moving more and more of their content to new satellites which have a tighter spot beam over the UK |
| [16:43:20] | stuartm: | Ireland have a FTA terrestrial service, Soarview, I guess their satellite service was unable to afford space on a satellite with an Ireland only spot beam |
| [16:47:49] | dekarl: | exactly, if you want to license for 10 million viewers but 100 million viewers that speak the language receive the beam, then you either need deep pockets or content protection |
| [16:48:40] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has quit (Quit: Lost terminal) | |
| [17:06:21] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:34:40] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [17:37:59] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [17:38:46] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [17:39:13] | jpabq (jpabq!~quassel@97-123-207-7.albq.qwest.net) has joined #mythtv | |
| [17:39:14] | jpabq (jpabq!~quassel@97-123-207-7.albq.qwest.net) has quit (Changing host) | |
| [17:39:14] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [17:49:30] | kormoc: | stuartm, I poked at your fix last night, looks like it solved the crash |
| [18:13:17] | unforgiven512 (unforgiven512!~unforgive@oxymorphone.unforgivendevelopment.com) has quit (Quit: ZNC - http://znc.in) | |
| [18:14:50] | unforgiven512 (unforgiven512!~unforgive@oxymorphone.unforgivendevelopment.com) has joined #mythtv | |
| [18:25:08] | dekarl: | rsiebert: I'd love to see us use pull requests and connect our buildbot to the pull requests, too. Basically hooking a "try scheduler" into the pull requests (similar to https://github.com/buildbot/buildbot/pull/516 for commits) |
| [19:28:39] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [19:53:49] | stuartm: | how long did the latest schema update take for most people? I can't tell if the backend has hung or if it's just taking a really long time |
| [19:55:40] | stuartm: | and by long I mean it's been 10 minutes already |
| [19:56:22] | stuartm: | and I don't have many recording rules compared to some |
| [19:57:17] | stuartm: | hmm, schema update just does a replace into for two rows in recordfilter ... something is definitely broken ... |
| [20:00:38] | stuartm: | gigem: so I'm not sure exactly what's going wrong, but the backend keeps hanging on startup after doing the schema backup but before performing the actual upgrade |
| [20:00:40] | caelor: | for the event hooks, should %FILE% return just the base filename of the file, or including a full path? |
| [20:01:45] | caelor: | I'm not sure if I need %DIR%/%FILE%, or just %FILE% – the example for %DIR% in http://www.mythtv.org/wiki/MythTV_System_Events doesn't look especially like a directory.. |
| [20:03:04] | caelor: | also, is the "recording finished" hook (and other recording % hooks) global, or per sbe? |
| [20:05:41] | xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 264 seconds) | |
| [20:06:09] | stuartm: | gigem: nm, user error (sort of) |
| [20:06:27] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [20:06:33] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [20:06:33] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [20:07:12] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [20:10:18] | gigem: | stuartm: Okay. You don't have to share if you don't want to. FWIW, I usually run my development backend in the foreground and always wonder why it seems to get hung before I remember I need to answer 'yes' to the upgrade prompt that gets lost in the logs. |
| [20:16:40] | stuartm: | that's what happened, I saw the prompt but since it appeared back in the logs before the 'backup complete' line, I assumed it had continued without requiring input |
| [20:18:11] | stuartm: | tbh, if we're going to prompt it needs to be the last thing appearing on the console, there shouldn't be any output after that |
| [20:18:49] | gigem: | sphery: ^^^ |
| [20:19:12] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (*.net *.split) | |
| [20:19:13] | zentec (zentec!~zentec@71.82.202.47) has quit (*.net *.split) | |
| [20:19:13] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has quit (*.net *.split) | |
| [20:19:15] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (*.net *.split) | |
| [20:19:15] | poptix (poptix!poptix@poptix.net) has quit (*.net *.split) | |
| [20:19:15] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (*.net *.split) | |
| [20:19:16] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has quit (*.net *.split) | |
| [20:19:16] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split) | |
| [20:19:16] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (*.net *.split) | |
| [20:19:17] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has quit (*.net *.split) | |
| [20:20:11] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [20:20:12] | zentec (zentec!~zentec@71.82.202.47) has joined #mythtv | |
| [20:20:12] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has joined #mythtv | |
| [20:20:12] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [20:20:12] | poptix (poptix!poptix@poptix.net) has joined #mythtv | |
| [20:20:12] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv | |
| [20:20:12] | eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has joined #mythtv | |
| [20:20:12] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [20:20:12] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has joined #mythtv | |
| [20:20:12] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [20:24:43] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (*.net *.split) | |
| [20:24:43] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has quit (*.net *.split) | |
| [20:24:44] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (*.net *.split) | |
| [20:24:44] | robink (robink!~quassel@unaffilated/robink) has quit (*.net *.split) | |
| [20:24:44] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (*.net *.split) | |
| [20:24:45] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (*.net *.split) | |
| [20:25:33] | stuartm: | wouldn't hurt to also have it repeat the prompt and/or time out with a error along the lines of "Timed out waiting for user to approve schema upgrade" |
| [20:27:32] | sphery: | My personal preference would be to remove the DB upgrade capability from the backend and require users to run mythtv-setup (which has a GUI) to do the upgrade. |
| [20:28:13] | sphery: | and to make things easier for packagers, we could also provide a mythutil option for doing DB upgrade, with some kind of --no-prompt option available |
| [20:28:35] | kormoc: | ^^ agree |
| [20:28:36] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [20:30:40] | caelor: | how long do deleted recordings stay in the "deleted" group before being removed from disk? |
| [20:31:25] | sphery: | caelor: there's a setting allowing 1–365 days or 0 = "until space is needed" |
| [20:32:27] | caelor: | ah ok. Is there any way to force it to occur on a one off basis? |
| [20:32:36] | sphery: | "Time to retain deleted recordings (days)" in frontend setup, under General Settings |
| [20:32:52] | sphery: | You can delete a show from Deleted recording group and it is removed immediately |
| [20:32:58] | sphery: | (like the Windows recycle bin) |
| [20:33:33] | caelor: | ok thanks. |
| [20:34:47] | sphery: | Or if you want to get rid of them all, in Watch Recordings, MENU|Change Group Filter, then select Deleted, then MENU|Add Group to Playlist, then MENU|Playlist Option|Delete, or https://code.mythtv.org/cgit/mythtv/tree/myth . . . _recgroup.pl |
| [20:36:35] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [20:36:35] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [20:36:35] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [20:36:35] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [20:36:35] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [20:38:50] | caelor: | thanks. Is there an override you can pass to mythfrontend to tell it to use a different identifier? The --help didn't mention one, which surprised me |
| [20:42:01] | dekarl: | sphery: caelor: 0 = quickly (5–20 minutes), -1 = when space is needed according to the infobox of that setting |
| [20:42:41] | caelor: | cheers – now I look, and it's cleared it out, so I must have it set to 0. |
| [20:43:45] | caelor: | dekarl (and anyone else who wants to check) – http://pastebin.com/ew1QK6Tf is a script to move recordings from sbe to mbe on post record |
| [20:44:01] | caelor: | if you guys are happy it meets standards, I'll put it on the wiki |
| [20:44:32] | dekarl: | caelor, nice that its working, sad as I had an issue with recordings not being deleted that I can't reproduce :/ |
| [20:46:57] | caelor: | I wasn't sure if it would, because the file was owned by the mythtv-sbe user, and was mode 644, in a directory owned by the mythtv user (that mbe runs as) |
| [20:48:29] | dekarl: | caelor: looks like you need a different use with a config.xml that overrides the hostname (judging from the command line parser's code and http://www.mythtv.org/wiki/Running_MythTV_Dual_Headed ) |
| [20:48:40] | dekarl: | s/different use/different user/ |
| [20:49:13] | caelor: | pleasantly, it did though. So I think the only issue I can see with my bash script is cleaning up the thumbnails that are created alongside the recording. I could wildcard the filename, but given copying is potential non-instantaneous, there's a likelihood for a race condition leaving orphaned files |
| [20:50:03] | caelor: | hence the wildcard unlink (which I dislike – it feels like a sledgehammer) |
| [20:51:54] | dekarl: | hmm, could just rsync %FILE%* over to the MBE, so nothing gets lost. even when it matches an unrelated file it is still there |
| [20:52:49] | caelor: | but the file list will be created when the script first runs. If you're triggering off a post-record hook, then the script is likely to run ahead of any thumbnail creation, and hence they'll not be included in the file list |
| [20:53:18] | caelor: | assuming thumbnail creation is asynchronous to the event hooks |
| [20:54:00] | caelor: | I could sleep 10s when the script runs, but delays are at best workarounds for race conditions |
| [20:55:02] | dekarl: | we can fix those bugs. (thumbnails can be generated once the thumbnail generation time has been reached. I don't like the "on demand" generation of the frame from the video. Makes for lots of black images when looking at a dozen new recordings in mythweb) |
| [20:56:00] | caelor: | ok. I'll leave it as-is for now (just copying the video, and unlinking video and video.* after it completes) – thumbnails can be recreated on MBE |
| [20:58:32] | dekarl: | yes, leave it as is. That can be revisited once we actually track these files in the database. |
| [21:05:54] | dekarl: | ohh my, "warning, usage of deprecated type" in the buildbot looking up the commit that deprecated it says "deprecate unused stuff"... and the doxygen comment that could tell what it was good for when it was not deprecated got lost earlier due to a copy'n'paste mistake when shuffling stuff around... |
| [21:05:54] | dekarl: | re "mpeg2fix.cpp(1185): warning #1478: member "AVFrame::type" was declared deprecated" |
| [21:11:31] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [21:18:51] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:19:44] | caelor: | ok, wiki page created: http://www.mythtv.org/wiki/MoveRecording.sh |
| [21:20:09] | caelor: | arguably should be "move_recording.sh", but I was unsure of the constraints on wiki page naming |
| [21:23:28] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:41:31] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:c457:ef1d:60fd:2177) has quit (Ping timeout: 240 seconds) | |
| [21:52:29] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (Ping timeout: 264 seconds) | |
| [22:03:18] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:e179:4c6d:bc2a:b525) has joined #mythtv | |
| [22:04:12] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv | |
| [22:14:04] | jpabq: | sphery: I believe that "Time to retain deleted recordings (days)" should be backend option, not a frontend one. I don't tweak it very often, but I always look for it in mythtv-setup and end up having to to a search to discover that it is in the frontend settings. |
| [22:16:38] | kormoc: | there's a bunch of weird frontend settings, like comm flag stuff |
| [22:19:10] | sphery: | jpabq: though it's a global option, it's one that doesn't require shutting down mythbackend to change... that used to be the difference between setting in frontend settings editor and settings in mythtv-setup General... Recently some have begun moving "doesn't require shutting down backend" global settings into mythtv-setup, which we tell users to shut down all backends/frontends when running |
| [22:20:05] | sphery: | personally, I like the idea of all "doesn't require shutting down mythbackend" settings being easily available through the often already-running mythfrontends I have scattered around the network |
| [22:21:12] | sphery: | not to mention mythtv-setup General settings is pretty huge for a single settings wizard (i.e. it's in one of the thousand screens of General in mythtv-setup) |
| [22:21:49] | sphery: | just because they're in the frontend settings editor doesn't mean they're "frontend" settings :) |
| [22:22:13] | kormoc: | I don't run any frontends and don't intend to, so it's odd to require on to just set stuff :) |
| [22:28:33] | caelor: | WebFrontend would then seem to be an appropriate place to change settings that don't require a backend restart, wouldn't it? |
| [22:30:04] | caelor: | is the hostname value for a recording used to determine where to generate thumbnails/previews? I'm seeing them generated on the SBE even after moving the recording to MBE. I guess it would make sense... |
| [22:31:17] | jpabq: | caelor: I agree. I think most (if not all) of the backend settings would be good via a http interface of some sort. sphery has a point about the need to restart mythbackend, though. |
| [22:31:19] | caelor: | unfortunately, I think the only way to update the host for a recording is direct db access – is that so? |
| [22:33:15] | caelor: | yes, although my observation has been that there's generally been a desire to try and reduce the need to restart mbe to apply settings – there's been talk of replacing mythtv-setup with a web based alternative for a long time |
| [22:42:03] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:02:00] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 244 seconds) | |
| [23:31:31] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [23:52:41] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
| [23:52:41] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:52:41] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.