| Monday, April 27th, 2015, 00:19 UTC | ||
| [00:19:44] | rich0 (rich0!~quassel@gentoo/developer/rich0) has quit (Ping timeout: 264 seconds) | |
| [00:23:01] | rich0 (rich0!~quassel@gentoo/developer/rich0) has joined #mythtv | |
| [01:01:14] | andreaz (andreaz!~andre_000@p5DD1506E.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [01:02:08] | andreaz (andreaz!~andre_000@p5DD1506E.dip0.t-ipconnect.de) has joined #mythtv | |
| [01:20:13] | jya (jya!~sid132@2620:101:8016:74::4:84) has quit (Ping timeout: 256 seconds) | |
| [01:20:50] | jya (jya!~sid132@2620:101:8016:74::4:84) has joined #mythtv | |
| [01:59:48] | arescorpio (arescorpio!~arescorpi@218-57-245-190.fibertel.com.ar) has joined #mythtv | |
| [02:19:56] | andreaz (andreaz!~andre_000@p5DD1506E.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:55:02] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 265 seconds) | |
| [02:55:49] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:45:30] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:49:39] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 265 seconds) | |
| [03:51:03] | cfuackers (cfuackers!~cfuackers@82.163.78.62) has joined #mythtv | |
| [03:51:29] | cfuackers (cfuackers!~cfuackers@82.163.78.62) has left #mythtv () | |
| [03:53:45] | stichnot: | Thinking of setting the next MYTH_PROTO_TOKEN to something like (ノಠ益ಠ;)ノ彡┻â”&ac irc;”» |
| [03:58:49] | stichnot: | Do I dare? I'm getting Y2K flashbacks |
| [04:33:58] | arescorpio (arescorpio!~arescorpi@218-57-245-190.fibertel.com.ar) has quit (Quit: Leaving.) | |
| [05:06:55] | clever_: | :D |
| [05:09:10] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [05:20:04] | skd5aner (skd5aner!~skd5aner@195.sub-70-198-68.myvzw.com) has quit (Ping timeout: 255 seconds) | |
| [05:23:16] | skd5aner (skd5aner!~skd5aner@21.sub-70-198-65.myvzw.com) has joined #mythtv | |
| [05:30:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds) | |
| [05:31:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [05:37:49] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [05:40:18] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 256 seconds) | |
| [05:42:04] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [05:43:33] | stichnot (stichnot!~stichnot@adsl-68-125-53-168.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [05:43:33] | stichnot (stichnot!~stichnot@adsl-68-125-53-168.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [05:43:33] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [05:47:40] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [05:50:30] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 256 seconds) | |
| [06:11:12] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:23:02] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 256 seconds) | |
| [06:31:17] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [06:47:03] | stichnot (stichnot!~stichnot@adsl-68-125-53-168.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [06:47:03] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:47:03] | stichnot (stichnot!~stichnot@adsl-68-125-53-168.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [06:47:53] | joki (joki!~joki@p5B36E96A.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds) | |
| [06:54:44] | joki (joki!~joki@p5B36CAB2.dip0.t-ipconnect.de) has joined #mythtv | |
| [07:29:51] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has joined #mythtv | |
| [08:07:17] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has quit (Ping timeout: 248 seconds) | |
| [08:08:01] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has joined #mythtv | |
| [08:19:37] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has quit (Ping timeout: 264 seconds) | |
| [08:20:21] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [08:30:07] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [08:32:02] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [08:40:08] | stuarta: | morning all |
| [08:45:14] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [08:51:10] | warpme: | morning all! |
| [08:57:18] | warpme: | I'm trying to get current master compiled under latest OSX/Xcode. After fixing compilation issues with clang inperfect gcc emulation I got all dependencies compiled. Unfortunatelly current master fails to compile due Qt4->Qt5 changes in Qwidget area. Some functions are now private – some other gone. Particulary it looks like GetWindowBounds function gone in Qt5. Interesting that I can't find any reference for this function in Qt4 docs. Can so |
| [09:02:23] | stuarta: | pastebin the errors you are seeing |
| [09:04:52] | warpme: | stuarta: sure but it is very simple: util-osx.cpp:63:10: error: use of undeclared identifier 'GetWindowBounds' |
| [09:05:05] | warpme: | and util-osx.cpp:61:24: error: use of undeclared identifier 'HIViewGetWindow' |
| [09:06:33] | warpme: | Both are due Qt5 making some function private and remove some others. 2 above functions seems to be removed so some more work is needed within util-osx.cpp to get it working in Qt5 |
| [09:07:25] | warpme: | also videoout_quartz.cpp is usting GetWindowBounds |
| [09:37:06] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [09:40:04] | clever_ is now known as clever | |
| [10:03:35] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [10:21:21] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has joined #mythtv | |
| [10:42:08] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Remote host closed the connection) | |
| [10:48:56] | map7_ (map7_!~map7@two1000979.lnk.telstra.net) has quit (Ping timeout: 252 seconds) | |
| [11:05:43] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [11:10:12] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [11:11:56] | sraue (sraue!~stephan@kodi/staff/sraue) has joined #mythtv | |
| [11:13:24] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 276 seconds) | |
| [11:16:28] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [11:18:58] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 250 seconds) | |
| [11:50:13] | moparisthebest (moparisthebest!~mitb@unaffiliated/moparisthebest) has quit (Ping timeout: 255 seconds) | |
| [11:54:26] | moparisthebest (moparisthebest!~mitb@unaffiliated/moparisthebest) has joined #mythtv | |
| [12:23:47] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [12:26:14] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 244 seconds) | |
| [12:54:22] | Chutt_ (Chutt_!~ijr@2605:a000:1225:65:c457:ef1d:60fd:2177) has quit (Ping timeout: 265 seconds) | |
| [13:03:36] | dmfrey (dmfrey!~dmfrey@208.5.237.2) has joined #mythtv | |
| [13:26:14] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv | |
| [13:44:18] | stichnot: | Are there any kind souls who could test out https://code.mythtv.org/trac/raw-attachment/t . . . .27_v1.patch on fixes/0.27? The goal is to improve Watch Recordings responsiveness while navigating the screen by getting rid of dozens of DB queries each time the selection is changed. |
| [13:47:56] | jheizer_: | skd5aner, I am not using spdif. I've never been able to find a firmware/STB combo of settings that didn't result in massive audio drift. |
| [14:44:57] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [14:45:28] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [14:56:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [14:58:45] | sphery_: | stuarta: FWIW, I was recommending we keep the singleton design for the screensaver stuff and just make the DPMS stuff in a separate, not-inherited-from-ScreenSaverControl class that's just a helper class aggregated into ScreenSaverX11 (or ScreenSaverXScreenSaver, if we want to change the name to be more precise) and ScreenSaverDBus. Then those classes would just create ScreenSaverDPMS in the constructor and make DisableDPMS() and ... |
| [14:58:52] | sphery_: | ... RestoreDPMS() calls on it at appropriate times. |
| [14:59:42] | stuarta: | i'm not convinced that a singleton is possible anymore |
| [15:00:42] | sphery_: | However, if you're saying you want to use the DBus idle-inhibition spec to inform the computer not to do other idle-power-state-stuff--and if the spec actually handles anything other than screensaver/screen blanking--and, therefore, might need xscreensaver control and DBus control, then Singleton wouldn't work |
| [15:01:22] | sphery_: | But if all the idle inhibition spec ever does is handle screen state, and since xscreensaver won't ever support DBus control, we'd never need xscreensaver and DBus control. |
| [15:01:26] | sphery_ is now known as sphery | |
| [15:03:11] | sphery: | I'd think any other "idleness" stuff should be handled without the idle-inhibition spec. For example, CPU freq scaling should be done according to CPU business and HDD spin down according to HDD usage and such. |
| [15:03:32] | stuarta: | from the testing i did, calling dbus, disable the powering down of the screen too |
| [15:05:11] | sphery: | Right. I think if you have a dbus-aware screensaver it will work with the DPMS stuff. Just like even xscreensaver will allow you to specify how long, after the screensaver is activated, until the monitor should power off and such |
| [15:06:03] | sphery: | (actually allows specifying standby, suspend, power off time) |
| [15:06:17] | stuarta: | now, maybe it's because people are using xset s blah, that something else occurs |
| [15:07:00] | stuarta: | my target was the default install of a system, using dbus on that, correctly inhibits screen saving whilst allowing the screen to sleep when its not been called |
| [15:07:48] | sphery: | Yeah, the guy in the thread on -dev is using /only/ X DPMS, via xset and/or X's ServerFlags options BlankTime, SuspendTime, StandbyTime, and OffTime |
| [15:08:01] | stuarta: | i think where issues are now being hit, is "legacy" setups where previously people have installed a screensaver to get it to actually work |
| [15:08:13] | sphery: | Your stuff is perfect for the people using any DBus-aware screensaver |
| [15:08:22] | stuarta: | ie. 95% of users |
| [15:08:33] | sphery: | and I think we only then have to handle X11-DPMS-only and xscreensaver users |
| [15:08:39] | stuarta: | although, stuartm has his system configured the same way as that user does |
| [15:08:41] | jheizer_: | skd5aner, I just upgraded to v0.27.4-51-gbcdaa88 and hd-pvr recording from last night works. |
| [15:08:42] | sphery: | right, the other 5% :) |
| [15:09:15] | sphery: | The dbus stuff won't work on OS X, right? |
| [15:09:21] | stuarta: | doubt it |
| [15:10:09] | stuarta: | but that's another reason to not have a singleton, if your osx qt5 is compiled with qtdbus, then you would automatically lose the screensaver support. that of course assumes that's how the packages are built |
| [15:10:36] | sphery: | yeah, so we could just have X11 systems have a runtime check if xscreensaver is running (which the ScreenSaverX11 currently does with xscreensaver --version , which returns an error exit code if the xscreensaver daemon isn't running) |
| [15:10:46] | sphery: | No, not using the code I showed in that thread |
| [15:11:09] | stuarta: | now ideally, i'd like to not use DPMS if possible, as that is what leaves the system with a disabled DPMS if the frontend crashes |
| [15:11:40] | sphery: | yeah, that's the one that can leave the system in a bad state |
| [15:11:59] | stuarta: | trying to work out what is active is a pain |
| [15:12:27] | sphery: | but it will only ever cause problems for users who use only dpms |
| [15:13:06] | stuarta: | for example, running xset q here on my laptop, where i've not configured dpms via xset, results in "DPMS is Enabled" so it's next to impossible to differentiate between pure dbus users and dpms users |
| [15:13:40] | sphery: | right, we can only tell if xscreensaver control will work |
| [15:14:11] | sphery: | but if dbus works, regardless of what we do to dpms, the dbus-aware screensaver will "fix" it next time it's supposed to standby/suspend/power off |
| [15:14:18] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:14:31] | sphery: | and same thing with xscreensaver |
| [15:14:47] | sphery: | so it's only if the user is using only dpms that dpms state can ever be left in a bad state |
| [15:15:02] | stuarta: | i think i'll make it try dbus then xscreensaver |
| [15:15:15] | sphery: | it has to be the other way |
| [15:15:29] | sphery: | because only xscreensaver can be properly detected |
| [15:15:40] | sphery: | so that's the only one we can know for sure |
| [15:16:05] | sphery: | so check if xscreensaver is running, and if so us xscreensaver + dpms. if not, use dbus + dpms |
| [15:16:17] | stuarta: | still leaves us using dpms |
| [15:16:20] | stichnot: | sphery, stuarta: don't forget the lirc issue :) |
| [15:16:48] | sphery: | true, but the dpms stuff will get fixed by xscreensaver or the dbus-aware screensaver |
| [15:16:48] | stuarta: | stichnot: haven't, dev laptop has been built with the pre-dbus version so i can get a test lirc setup working |
| [15:16:57] | sphery: | so only the users who use only DPMS will ever get bad state |
| [15:17:47] | sphery: | stuarta: and we can still do a singleton with the approach I recommended and not worry about OS X systems with qt-dbus support because of the changes I'm recommending for screensaver.cpp |
| [15:18:02] | sphery: | In http://lists.mythtv.org/pipermail/mythtv-dev/ . . . /074840.html |
| [15:18:15] | sphery: | where we have an outer #if defined(USING_X11) |
| [15:18:31] | sphery: | and inside we have 2 #if defined(USING_DBUS) |
| [15:18:37] | sphery: | one for the if (ScreenSaverX11::IsXScreenSaverRunning()) |
| [15:18:49] | sphery: | and the other for the else ScreenSaverSingleton = new ScreenSaverDBus(); |
| [15:19:18] | sphery: | so we can only use ScreenSaverDBus on systems with USING_X11 (which we both think is correct) |
| [15:19:31] | sphery: | and it's only used if USING_DBUS |
| [15:19:36] | stuarta: | i'll have a think about it while i'm doing it |
| [15:19:48] | sphery: | but it's a runtime-check of whether xscreensaver is running |
| [15:19:56] | stuarta: | yep |
| [15:19:58] | sphery: | and if not we use dbus |
| [15:20:04] | stuarta: | dpms is still the issue |
| [15:20:12] | stuarta: | but can probably work with that |
| [15:21:52] | sphery: | but if we make it a simple little helper class with just a constructor that checks X DPMS state (using the code from ScreenSaverX11Private, like https://code.mythtv.org/cgit/mythtv/tree/myth . . . x11.cpp#n54) and then has DisableDPMS() and RestoreDPMS() functions that we can pepper into ScreenSaverDBus and ScreenSaverXScreenSaver, it would work |
| [15:22:45] | sphery: | basically, make the dpms code reusable through aggregation rather than inheritance |
| [15:23:03] | stuarta: | that is the reason to create a non singleton controller, peppering different methods with calls into the other is not very clean, it's cleaner to have each method in it's own class, and then call the appropriate combination |
| [15:23:15] | FabriceMG (FabriceMG!~Thunderbi@LCaen-656-1-100-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [15:23:45] | sphery: | by pepper into, I meant pepper calls to those methods into |
| [15:24:23] | sphery: | so the 2 different screensavercontrol subclasses would just make DisableDPMS() and RestoreDPMS() calls when appropriate |
| [15:24:36] | stuarta: | i still think it's cleaner to have each class control it's own method with no reference to the other. that's the controllers responsibility (and as a bonus, easier to make different combinations) |
| [15:25:11] | stuarta: | so controller goes, dbus disable, dpms disable etc |
| [15:25:46] | sphery: | yeah, that would work |
| [15:27:06] | sphery: | so basically just keep screensaverx11 as the controller and make screensaverdbus, screensaverxscreensaver, and screensaverdpms as helper classes |
| [15:27:21] | sphery: | ? |
| [15:27:36] | sraue_ (sraue_!~stephan@xd9ba81ab.dyn.telefonica.de) has joined #mythtv | |
| [15:27:53] | stuarta: | no. singleton get replaced by the controller |
| [15:28:40] | sphery: | sounds good |
| [15:28:54] | stuarta: | the singleton is really dual purpose at the moment, it's both the base class and the controller |
| [15:29:19] | sphery: | yeah |
| [15:30:26] | sphery: | I was mainly thinking we'd want to keep the changes minor/less work, but if you're willing to do the extra work, that's great |
| [15:31:09] | sraue (sraue!~stephan@kodi/staff/sraue) has quit (Ping timeout: 264 seconds) | |
| [15:31:16] | stuarta: | there is minor, and there is gross hack ;-) |
| [15:31:52] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Read error: Connection timed out) | |
| [15:32:32] | sphery: | well, I'd say it's not a gross hack--it's barely different from what's there now |
| [15:32:45] | sphery: | unless, of course, the existing code is a gross hack :) |
| [15:33:09] | stuarta: | not quite |
| [15:33:18] | sphery: | (but then again, I'd also think that screensaver control isn't something warranting a grand design in a DVR program) |
| [15:33:28] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [15:34:06] | stuarta: | you would hope not |
| [16:16:04] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [16:23:25] | stichnot (stichnot!stichnot@nat/google/x-znnopmazubmqlgwf) has joined #mythtv | |
| [16:23:25] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:23:25] | stichnot (stichnot!stichnot@nat/google/x-znnopmazubmqlgwf) has quit (Changing host) | |
| [16:23:44] | tstorm (tstorm!~tstorm@50-76-62-217-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [16:26:37] | SteveGoodey (SteveGoodey!~steve@host86-160-175-76.range86-160.btcentralplus.com) has joined #mythtv | |
| [16:33:58] | sraue__ (sraue__!~stephan@x4d05f5f1.dyn.telefonica.de) has joined #mythtv | |
| [16:36:56] | sraue_ (sraue_!~stephan@xd9ba81ab.dyn.telefonica.de) has quit (Ping timeout: 240 seconds) | |
| [16:41:24] | sraue_ (sraue_!~stephan@x4d065f93.dyn.telefonica.de) has joined #mythtv | |
| [16:44:33] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [16:44:55] | sraue__ (sraue__!~stephan@x4d05f5f1.dyn.telefonica.de) has quit (Ping timeout: 265 seconds) | |
| [16:52:44] | jwhite__ is now known as jwhite | |
| [16:53:58] | gigem: | stichnot: I can possibly try that patch tonight. Honestly, though, I haven't noticed any sluggishness before, so I'm not sure I'll be able to tell any difference. |
| [16:54:51] | stichnot: | gigem: thanks. Are you by chance using a combined fe/be? |
| [16:58:20] | stichnot: | I was getting really laggy behavior when scrolling through the listings (either one at a time or a page at a time), on a fast frontend with a slow network, and on a slow frontend with a fast network. I assume DB queries in the UI thread on a combined fe/be won't be noticeable. |
| [17:01:24] | stichnot: | and I've been experiencing it for probably close to a year before I got around to digging into it. And in the meantime casting false aspersions on preview image generation/loading. :) |
| [17:03:48] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving) | |
| [17:22:06] | Steve-Goodey (Steve-Goodey!~steve@host109-159-59-229.range109-159.btcentralplus.com) has joined #mythtv | |
| [17:22:10] | sraue__ (sraue__!~stephan@xd9be242e.dyn.telefonica.de) has joined #mythtv | |
| [17:22:45] | SteveGoodey (SteveGoodey!~steve@host86-160-175-76.range86-160.btcentralplus.com) has quit (Ping timeout: 264 seconds) | |
| [17:24:28] | dekarl: | stuarta, re PID 0x1fff i think the change was a no-op and we may need something like the fix titled "don't remove unwanted PIDs from the PMT only, but also remove the actual stream data". but ran out of time when tryingto understand the code |
| [17:25:45] | sraue_ (sraue_!~stephan@x4d065f93.dyn.telefonica.de) has quit (Ping timeout: 264 seconds) | |
| [17:31:12] | gigem: | stichnot: I have a fast backend, fast network and moderately slow to moderate frontends. |
| [17:54:16] | stichnot: | gigem: interesting, I wonder if there's a theme component as well? When I run mythfrontend -v database, before the patch I would see a ton of jobqueue queries every time the selection changed, which was responsible for the sluggishness. |
| [17:55:01] | skd5aner (skd5aner!~skd5aner@21.sub-70-198-65.myvzw.com) has quit (Ping timeout: 264 seconds) | |
| [17:55:49] | skd5aner (skd5aner!~skd5aner@21.sub-70-198-65.myvzw.com) has joined #mythtv | |
| [18:07:06] | stichnot: | btw gigem: I haven't started investigating yet, but I just noticed that since about 10 days ago, preroll is never happening for HD-PVR recordings (even isolated recording not adjacent to any other recordings), but basically always happening for HDHR recordings. I have no idea how any commit during that period could have caused this. Is it possible I messed up my settings somehow? |
| [18:07:34] | stichnot: | (just wondering if this rings a bell) |
| [18:10:56] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 240 seconds) | |
| [18:13:50] | natanojl: | stichnot: I'll test the patch |
| [18:16:41] | stichnot: | natanojl: thanks! Do you see the sluggishness on 0.27? |
| [18:18:35] | natanojl: | stichnot: yes |
| [18:20:28] | peper03: | stichnot: I've just compiled it here too. I haven't noticed any sluggishness but looking at the database queries with -v database --loglevel=debug shows a single query now |
| [18:21:33] | peper03: | It might be a stupid question but why is the job status of every visible recording queried when moving from one recording to another? |
| [18:22:02] | natanojl: | stichnot: I told you about #8962, didn't I ;) |
| [18:22:02] | ** MythLogBot http://code.mythtv.org/trac/ticket/8962 ** | |
| [18:24:55] | peper03: | stichnot: I seem to get some flicker now when the list of recordings is shown. |
| [18:25:16] | stichnot: | natanojl: yep, but I wasn't sure whether you were running master or 0.27 |
| [18:26:54] | stichnot: | peper03: I think it was so the commflag/transcode status of every item on screen could be mostly kept up to date |
| [18:26:58] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Read error: Connection timed out) | |
| [18:27:19] | stichnot: | since that status is automatically pushed when the jobqueue changes |
| [18:27:58] | stichnot: | peper03: can you describe the flicker? and how it's different from before? |
| [18:28:26] | peper03: | stichnot: Ah, whether that is useful would be theme-dependent then. At least the Mythbuntu theme only shows the commflag/transcode status of the currently selected recording. |
| [18:29:25] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [18:30:08] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [18:31:11] | peper03: | stichnot: When I enter 'Watch Recordings' with your patch the list of titles flickers once or twice. Without the patch there is no flicker. |
| [18:32:35] | peper03: | It is particularly noticeable with debug database logging enabled (probably because the logging slows things down a bit). The list of titles flickers visibly several times. |
| [18:33:44] | natanojl: | stichnot: Ok. Production system runs 0.27. I usually develop on combined BE/FE but last time I tried on a separate FE on master using WLAN it was slow as well |
| [18:38:10] | peper03: | stichnot: Looks like there's some caching involved too. If I exit the Watch Recordings screen and go straight back in again, I don't see any flicker. If I exit and wait a few seconds, there's flicker. |
| [18:39:00] | peper03: | But not always the same amount. Could also be down to network traffic but there's not much happening on my network at the moment and the backend is idle. |
| [18:53:58] | jpabq_ (jpabq_!~quassel@75-161-23-131.albq.qwest.net) has joined #mythtv | |
| [18:54:15] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 276 seconds) | |
| [18:56:38] | gigem: | stichnot: Regarding your preroll problem, the only thing I can think of that would prevent preroll is if another input in the same group is busy. Check your inputgroup table to see anything looks strange there. |
| [19:04:06] | sraue__ is now known as sraue | |
| [19:04:14] | sraue (sraue!~stephan@xd9be242e.dyn.telefonica.de) has quit (Changing host) | |
| [19:04:14] | sraue (sraue!~stephan@kodi/staff/sraue) has joined #mythtv | |
| [19:17:37] | andreaz (andreaz!~andre_000@p5DD1506E.dip0.t-ipconnect.de) has joined #mythtv | |
| [19:38:09] | jpabq_ (jpabq_!~quassel@75-161-23-131.albq.qwest.net) has quit (Ping timeout: 245 seconds) | |
| [19:38:43] | stichnot: | gigem: thanks – it's possible I was messing around with the settings for my PVR-150 which is in the same input group but is normally supposed to be disabled (used only for extracting closed captions) |
| [19:38:47] | jpabq (jpabq!~quassel@75-161-23-131.albq.qwest.net) has joined #mythtv | |
| [19:38:47] | jpabq (jpabq!~quassel@75-161-23-131.albq.qwest.net) has quit (Changing host) | |
| [19:38:47] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [19:38:51] | tstorm (tstorm!~tstorm@50-76-62-217-ip-static.hfc.comcastbusiness.net) has quit (Quit: tstorm) | |
| [19:45:43] | stichnot: | peper03: I've grown used to that kind of flicker happening quite frequently, but assumed it was an artifact of an underpowered frontend. What happens is that any time something changes in the ProgramInfo, like the file size changes for an in-progress recording, or another frontend sets a bookmark, the Watch Recordings entry gets redrawn. When that happens, I always see a flicker. |
| [19:46:11] | stichnot: | But I'm trying to figure out why this particular patch would change that behavior for the worse. |
| [19:55:55] | stuartm: | great to see it so busy in here |
| [19:56:23] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Read error: Connection timed out) | |
| [19:56:50] | stuartm: | ironic that I'm suddenly so busy just as everyone else has more free time available |
| [19:58:07] | stuartm: | stichnot: the flicker you see, is that with opengl? |
| [19:59:52] | stichnot: | stuartm: I'm not sure, but I think it's Qt. I know so little about Qt vs OpenGL that I just randomly hit buttons until things start working again. |
| [19:59:53] | stuartm: | a few years ago I started adding clipping support to the opengl painter, but Isaac didn't seem to feel it was necessary given the speed at which most GPUs can redraw the whole screen so ultimately the clipping support only went into the QT painter |
| [20:00:36] | stuartm: | I might revisit that decision, since the clipping support couldn't do any harm and might help on lower power frontends |
| [20:01:45] | stichnot: | stuartm: When the screen gets redrawn, there's nothing like double buffering going on, right? So on a slow frontend, you could see the erasing plus drawing of individual elements as a flicker? |
| [20:01:54] | stuartm: | not sure whether it's worthwhile investing time in the QT painter since opengl/opengl ES support is nearly universal now |
| [20:03:02] | stichnot: | again I know nothing about Qt vs OpenGL, but generally my OpenGL experience is pretty bad and I end up solving things by switching to Qt |
| [20:03:09] | stuartm: | it's been a while, but QT should handle the double buffering itself and I can't remember what the GL painter does |
| [20:03:34] | stichnot: | oh, Qt would do double buffering as part of the event loop? |
| [20:04:27] | stuartm: | there's more wrong with the QT painter than there is with the GL painter, except that performance on systems with lousy or no hardware GL support is worse |
| [20:04:56] | stichnot: | anyway, if it helps, tonight I can try to gather more data (and fewer guesses) about my OpenGL woes on my ION-1 machines |
| [20:05:42] | stuartm: | if clipping support was added to the GL painter it would help things, and it's not that difficult, the hooks are already there in the painter but they are just ignored |
| [20:09:09] | stuartm: | improving the opengl performance is one of the things I've wanted to tackle for a while, mostly because I'd like to improve my knowledge of opengl, but also because it's one of the things we need to do if mythfrontend is going to stay relevant with embedded devices |
| [20:12:15] | natanojl: | stichnot: I started two commercial flagging jobs and the two recordings got the jobstate correctly set to commflagging in the list. However, three additional recordings also got their jobstate set to commflagging. |
| [20:13:38] | stichnot: | natanojl: yikes, that is surely a problem in master as well |
| [20:16:36] | stichnot: | I'll check tonight, but in the meantime, did you notice anything interesting about the 3 recordings with bad state? e.g. they were the only 3 on screen besides the two commflagging entries plus the highlighted entry, or they all shared a chanid with one of the commflagging entries, or ... ? |
| [20:17:25] | natanojl: | stuartm: Even if we drop the QT painter for the normal GUI, I've found it useful for rendering the OSD in MythFlashPlayer if we would switch to QGraphicsWebview and QGraphicsScene |
| [20:17:48] | natanojl: | stichnot: Oh, you could reproduce it? |
| [20:20:14] | stuartm: | natanojl: we may be able to salvage it, or replace it with something that uses the newer APIs in QT 5, I'd like to say I've done my research on those but I've not had the chance |
| [20:20:29] | jpharvey_ (jpharvey_!~jpharvey@host81-159-18-108.range81-159.btcentralplus.com) has quit (Ping timeout: 256 seconds) | |
| [20:20:34] | stichnot: | natanojl: I won't be able to test it until I get home in 5–6 hours |
| [20:21:10] | natanojl: | stichnot: They were the last five in the list and of those five I started the comm flagging for the first and third recording. Four different channels |
| [20:21:24] | jheizer_: | stichnot, FWIW I use opengl on my ion-1 without issue. Though I also think it does flicker now and then. I was thinking more maybe when new shows start recording though. |
| [20:23:18] | stuartm: | stichnot: just in case you're not aware, I want to switch PBB from ProgramInfo to RecordingInfo, the biggest hurdle will be converting, or extending the PI updater |
| [20:24:13] | stuartm: | I've not started yet, but if I do we should try to coordinate so we're not stepping on each other's toes |
| [20:26:42] | stuartm: | one of those refactoring projects I'll probably wish I'd never started, but long overdue |
| [20:33:45] | stichnot: | stuartm: OK. After the dust settles on this pbb/jobqueue stuff, I'll probably be switching back to caption/subtitle/timing fixes. |
| [20:33:55] | jpharvey_ (jpharvey_!~jpharvey@host81-159-18-108.range81-159.btcentralplus.com) has joined #mythtv | |
| [20:34:54] | stuartm: | don't want to put you off working on pbb :) |
| [20:36:58] | stuartm: | it's a monster, not really where I want to be working but I've started this transition from PI to RI and it has to get finished sometime |
| [20:41:52] | stichnot: | heh. My monster pbb project idea is the "Previously Watched Recordings" page which acts kind of like browser history |
| [20:49:35] | dmfrey (dmfrey!~dmfrey@208.5.237.2) has quit (Quit: Ex-Chat) | |
| [20:59:11] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [21:04:28] | jpharvey_ (jpharvey_!~jpharvey@host81-159-18-108.range81-159.btcentralplus.com) has quit (Ping timeout: 265 seconds) | |
| [21:13:24] | tstorm (tstorm!~tstorm@67.169.143.241) has joined #mythtv | |
| [21:15:37] | Warped_ (Warped_!~Warped@108.85.160.119) has joined #mythtv | |
| [21:16:39] | jpharvey_ (jpharvey_!~jpharvey@host81-159-18-108.range81-159.btcentralplus.com) has joined #mythtv | |
| [21:17:00] | Warped (Warped!~Warped@unaffiliated/warped) has quit (Ping timeout: 256 seconds) | |
| [21:19:21] | Warped_ (Warped_!~Warped@108.85.160.119) has quit (Client Quit) | |
| [21:19:36] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 252 seconds) | |
| [21:20:22] | Warped (Warped!~Warped@unaffiliated/warped) has joined #mythtv | |
| [21:28:23] | Steve-Goodey (Steve-Goodey!~steve@host109-159-59-229.range109-159.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:29:03] | amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv | |
| [21:29:37] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit (Quit: I told the doctor I broke my leg in two places. He told me to quit going to those places.) | |
| [21:33:34] | tstorm (tstorm!~tstorm@67.169.143.241) has quit (Ping timeout: 245 seconds) | |
| [21:35:52] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Read error: Connection timed out) | |
| [21:36:20] | tstorm (tstorm!~tstorm@67.169.143.241) has joined #mythtv | |
| [21:37:34] | peper03: | stuartm, stichnot: This machine is currently set to using the QT painter. I don't seem to get the flicker with OpenGL but my card 'only' has 256MB and there were certainly issues in the past with using OpenGL. |
| [21:38:11] | peper03: | But I don't see any flicker without the patch. |
| [21:38:21] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [21:41:22] | tstorm (tstorm!~tstorm@67.169.143.241) has quit (Ping timeout: 256 seconds) | |
| [21:44:44] | tstorm (tstorm!~tstorm@67.169.143.241) has joined #mythtv | |
| [21:59:24] | Tobbe5178 (Tobbe5178!~asdf@2001:2002:51e3:5f22:218b:7e4b:48dd:a31e) has quit (Read error: Connection reset by peer) | |
| [22:26:38] | stichnot: | peper03: I think that sometimes the flicker can come from a redraw triggered by arrival of artwork or preview image, which is fetched in a separate thread. I wonder if the several jobqueue queries were blocking the UI thread long enough for the images to arrive, letting all the redrawing happen in one go and avoiding the flicker? |
| [22:28:11] | peper03: | stichnot: Very possible. The flicker behaviour was certainly not consistent. Sometimes it was barely there, other times very noticeable so it's almost certainly something timing related. |
| [22:30:07] | stichnot: | peper03: you said you're using the mythbuntu theme, right? |
| [22:30:34] | peper03: | stichnot: Yes. |
| [22:31:14] | stichnot: | I'll have to test with that one, if I can ever get theme downloading to work... (it usually fails to download the zip file for reasons unknown) |
| [22:33:06] | tgm4883: | stichnot: you can also download it from git and put it in your themes directory |
| [22:33:14] | tgm4883: | you don't have to use the theme downloader |
| [22:33:23] | stichnot: | ah right, ok |
| [22:34:51] | peper03: | stichnot: I've just tried it with MythCenter-wide and Steppes and don't see any flicker with those. |
| [22:38:17] | stichnot: | peper03: Do you ever notice a similar flicker when the backend starts a new recording? |
| [22:39:18] | peper03: | stichnot: Never noticed it before. |
| [22:39:43] | peper03: | Which of course doesn't mean it doesn't happen |
| [22:43:22] | peper03: | Also, my production box (0.27) is a combined BE/FE, so that could affect it. The tests today have been with the FE on my dev box connecting to the production BE. |
| [22:43:46] | skd5aner: | jheizer_: interesting, it's always worked fine for me on multiple firmware versions and 3 different HD-PVRs. Perhaps it's your STBs feeding it that get fubar??? |
| [22:44:58] | skd5aner: | jheizer_: thank you for testing though! Also, I tried to do an HLS transcode of a blu-ray rip via handbrake, and it has the same issue. I'm beginning to think it's either an h.264 issue, an AC3 audio issue, or both |
| [22:46:20] | skd5aner: | jheizer_: do you have any content that has AC3 audio to try and do an HLS transcode from? |
| [22:48:14] | skd5aner: | or anyone else for that matter? :) |
| [22:49:12] | stichnot: | skd5aner: I always had the same problem where my DISH STB and the AC3 output wouldn't get along, with any firmware version, so I ended up using the stereo output only. It would generally work fine at first, but within 24 hours the drift would permanently set in. |
| [22:52:52] | skd5aner: | odd, I've used it with STBs from multiple providers (sattelite and cable) over the years, and I think maybe 1 time ever did I have a sync issue but I chalked that up to a fluke. Never had Dish though |
| [22:53:32] | skd5aner: | !seen dmfrey |
| [22:53:32] | MythLogBot: | dmfrey was last seen 2 hours 3 minutes 57 seconds ago |
| [23:00:07] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has joined #mythtv | |
| [23:03:34] | Roklobotomy (Roklobotomy!~Roklobsta@ppp118-209-27-146.lns20.mel4.internode.on.net) has quit (Ping timeout: 264 seconds) | |
| [23:16:57] | dmfrey (dmfrey!~dmfrey@65-78-98-83.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [23:30:10] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds) | |
| [23:49:29] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.