| Friday, June 20th, 2014, 14:07 UTC | ||
| [14:07:53] | peper03: | stuarta: The more I think about it, the more it seems to make sense to enter standby if an idle timeout is set. Does it even make sense to use the standby functionality on anything but a combined system? |
| [14:08:05] | stuartm: | stichnot: all I was proposing for that bit was not to remove the option, just change it's behaviour for programmes in the future – offering to change the channel automatically when they started or popup up a reminder "You wanted to watch Cops @ 21:00, change channel now?" |
| [14:08:33] | stuartm: | peper03: yes, any non-idle frontend can block shutdown of a master backend |
| [14:09:06] | stuartm: | if the goal is to let your master backend shutdown to save power then all frontends need to be configured to go idle |
| [14:10:00] | stuartm: | I was eventually going to add a wakeonlan option for frontends, so they could also wake up the backend when they exited standby |
| [14:11:08] | peper03: | stuartm: I just wanted to mention that. If the backend shuts down, I seem to remember than any connected remote frontends play up. It ends up being very difficult to exit without resorting to killing them from the command line. |
| [14:11:42] | stuartm: | that should no longer be the case |
| [14:11:54] | peper03: | In master or 0.27-fixes already? |
| [14:11:57] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [14:12:08] | stuartm: | 0.27.0 from what I recall |
| [14:13:08] | stuartm: | they'll pop up a warning that they are unable to connect, and you won't be able to use certain features (we should ultimately grey out those from the menus) but it won't become unresponsive |
| [14:14:53] | peper03: | Just tried it. 0.27 frontend running on my development PC connected to my production machine. Entered standby on the FE, shutdown the BE and the FE keeps complaining about not being able to connect to the master backend and is very unresponsive. |
| [14:15:06] | stuartm: | maybe they should be forced into standby when the backend disappears and won't leave it until they are able to reconnect – there is nothing you can really do on a frontend without the backend, all content is streamed via the backend, the database is likely on the same machine as the backend too |
| [14:15:22] | stuartm: | unresponsive how? |
| [14:15:40] | peper03: | It doesn't respond :) |
| [14:16:12] | peper03: | It doesn't re-draw properly. |
| [14:16:20] | peper03: | Everything is extremely sluggish. |
| [14:16:46] | stuartm: | hmm |
| [14:16:51] | peper03: | Ah, now after a minute or two, it's responding again. |
| [14:17:58] | peper03: | But if you try to do something that causes it to try to talk to the backend, it's not a pleasant experience. |
| [14:18:17] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [14:18:26] | stuartm: | doesn't do that here, yes there is the annoyingly persistent popup, but that's why I was suggesting that the frontend 'retreats' into standby where we can suppress the popup and instead include a message on-screen that the backend/database is offline with a "Start the backend" option |
| [14:18:47] | peper03: | That was why I assumed that no-one would use standby on a remote FE if the backend were likely to go to sleep. |
| [14:20:13] | stuartm: | we tried that briefly, people complained that because they forgot to shutdown a frontend the backend stayed running, hence we give them the choice |
| [14:20:36] | stuartm: | but the frontend behaviour in that situation could be better |
| [14:21:21] | stuartm: | I'll whip up something this weekend |
| [14:21:48] | stuartm: | have an idea that's relatively simple but should be an improvement on the current behaviour |
| [14:22:28] | peper03: | In terms of remote FE behaviour when MBE disappears, or exiting to standby? |
| [14:34:41] | stuartm: | the former, but I may just look at the latter while I'm at it, not sure how much time I want to give to that while I've still got a lot to do on the WebFrontend |
| [14:37:14] | peper03: | stuartm: I'm quite happy to do it. I don't think entering standby instead of exiting is going to be hard to implement, it's just trying to work out when that can be done for those that need it without affecting those that don't. |
| [14:38:16] | peper03: | At the moment, though, I can't think of a way to do it automatically based on existing settings/conditions. |
| [14:38:31] | stuartm: | it might be a cop out, but I'd just use the existing 'exit behaviour' setting |
| [14:39:32] | stuarta: | add a new state, that's an idea |
| [14:39:52] | stuartm: | users who want it to go into standby can, those that want it to exit or shutdown can also get their preferred behaviour – we can allow shutdown from standby mode for anyone who wants both options and that's similar to what mythwelcome does now |
| [14:40:24] | stuartm: | I'd also add 'Enter Standby' to the exit menu, cover all the bases |
| [14:40:46] | peper03: | The current setting is to customise the exit menu options. There is no 'exit behaviour' setting (unless I'm missing something). |
| [14:41:08] | peper03: | And unless the key-binding is set correctly, you don't even see the exit menu. |
| [14:43:39] | stuartm: | huh, I was sure there was a setting that let you choose to 'Exit without prompt'/'Show exit menu' |
| [14:43:52] | stuartm: | must have been swept away in one of the setting cleanups |
| [14:45:46] | peper03: | [6e203ec] (https://github.com/MythTV/mythtv/commit/6e203ec) |
| [14:46:08] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [14:49:10] | stuartm: | doh |
| [14:49:37] | stuartm: | sphery: so you know that setting I had you remove? :p |
| [14:49:41] | stuarta: | arse |
| [14:50:43] | stuartm: | peper03: well for now we can start by adding Enter Standby to the menu, then figure out what else we might do |
| [14:51:13] | stuartm: | adding back the setting might appear a bit farcical to outsiders |
| [14:51:50] | stuarta: | no change there then |
| [14:52:33] | peper03: | What about another key binding for 'Main Menu'? Currently, there's 'EXIT' and 'EXITPROMPT'. What about 'ENTERSTANDBY'? There is already a jumppoint for that, but that's not ideal for this scenario. |
| [14:53:31] | ** stuartm is going AFK for a bit ** | |
| [14:54:08] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [15:01:46] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [15:05:25] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Client Quit) | |
| [15:25:07] | gigem: | stichnot, et al: Here are my thoughts on the EPG SELECT issue. I've long felt that, by default, SELECT should bring up a 'smallish,' context sensitive menu listing the most common actions relating to the currently highlighted 'thing'. The last item on that menu could lead to a longer, perhaps nested, menu of all reasonable actions that could be taken on 'thing.' For example, in the live TV EPG, the first |
| [15:25:08] | gigem: | menu item could be 'Watch this channel', followed by the other recording options offered in the non-live TV EPG. |
| [15:25:10] | gigem: | Note that the context sensitive menu action could be overridden by key bindings. In addition, other common actions could still be accessible via key bindings. For example, in the live TV EPG, PLAY might be a good choice for a 'Watch this channel' action and the user could change SELECT to do that if s/he wanted. To be done well, though, this would all most likely require more fine-grained key binding |
| [15:25:12] | gigem: | contexts. IMO, 'TV Frontend' is way too broad. |
| [16:05:19] | Cougar (Cougar!~cougar@2a03:5880:104:10:a1d4:d4b5:86fb:b4c4) has joined #mythtv | |
| [16:49:29] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [16:50:17] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:02:15] | sphery: | stuartm: If you're talking about entering standby versus exiting, it should be done as an action/key binding, not as a setting |
| [17:02:15] | acle (acle!~tb@or-71-53-74-177.dhcp.embarqhsd.net) has quit (Ping timeout: 244 seconds) | |
| [17:03:14] | sphery: | stuartm: that way, users can hit power to exit with prompt or exit without prompt or enter standby (and, while you're at it, you could add an action for power off, and then they could hit power to shut down) |
| [17:04:25] | sphery: | basically they choose the action they want associated with the power button through key bindings, and users can even do things like power = power off, stop = exit no prompt, pause = standby/sleep |
| [17:04:44] | sphery: | (since they're all in the Main Menu context, they won't conflict with TV Playback actions) |
| [17:08:50] | sphery: | and, yeah, I agree with gigem that our current contexts are too broad and could be split up a bit--the only down side is more complexity in customizing/mapping/finding key bindings. I still want to eventually have key binding themes--basically add code to read in and write out key bindings (in some XML format, similar to how we do UI/OSD/Menu themes), so that users can easily try new ones, share them (among their own systems or among all ... |
| [17:08:56] | sphery: | ... users), and--ideally--find new ones (designed for their particular remote and the number of buttons it has available) through an extension to the theme downloader |
| [17:09:49] | sphery: | I think that would be enough of a benefit to allow the additional complexity of more-fine-grained contexts without causing additional problems/confusion for the majority of users. |
| [17:10:37] | sphery: | (that said, since the majority probably just use default key bindings, we can probably add new contexts without too many issues even without simplifying mapping/customization) |
| [17:14:59] | stuartm: | sphery: at once too broad and too narrow, e.g. tv playback controls such as PLAY/STOP/PAUSE/FFWD et al should just be playback controls and apply to internet video, music etc |
| [17:26:15] | 77CAAE594 (77CAAE594!~RedPengui@207-255-52-248-dhcp.jst.pa.atlanticbb.net) has quit (Ping timeout: 255 seconds) | |
| [17:26:22] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [17:26:27] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [17:27:59] | RedPenguin (RedPenguin!~RedPengui@207-255-52-248-dhcp.jst.pa.atlanticbb.net) has joined #mythtv | |
| [18:03:07] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Ping timeout: 272 seconds) | |
| [18:45:29] | peper03: | Ok, adding a new key binding to enter standby from the main menu is easy enough but there are some settings that need the frontend to be restarted to take effect. If neither EXIT nor EXITPROMPT are bound, there's no way to exit the frontend. |
| [18:45:40] | peper03: | Add 'Exit' to the system menu? |
| [19:07:33] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [19:15:38] | caelor: | stuartm at the risk of additional conceptual complexity, that could be handled by having overlapping contexts, rather than contexts being mutually exclusive |
| [19:15:41] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [19:17:28] | caelor: | some measure of context priority would be needed to handle conflicts (although the mini-context menu might be appropriate in some instances where action is ambiguous due to overlapping contexts) |
| [19:20:59] | caelor: | I'd like to think that in the majority of cases, having consistent key bindings when "playing media" context is active should outweigh the times that "ok" could apply to multiple actions |
| [19:38:48] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [20:14:43] | sphery: | stuartm: hehe, I stand corrected--that's definitely true |
| [20:51:27] | jpharvey_ (jpharvey_!~jpharvey@host109-145-24-102.range109-145.btcentralplus.com) has quit (Ping timeout: 245 seconds) | |
| [21:04:20] | jpharvey_ (jpharvey_!~jpharvey@host86-152-2-34.range86-152.btcentralplus.com) has joined #mythtv | |
| [21:35:35] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:36:21] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:31:33] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [22:33:57] | arescorpio (arescorpio!~arescorpi@14-57-245-190.fibertel.com.ar) has joined #mythtv | |
| [23:14:02] | arescorpio (arescorpio!~arescorpi@14-57-245-190.fibertel.com.ar) has quit (Excess Flood) | |
| [23:40:11] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:45:21] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [23:52:48] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| Saturday, June 21st, 2014 | ||
| [00:08:25] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:19:07] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:22:42] | Warped_ (Warped_!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [00:22:43] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Ping timeout: 240 seconds) | |
| [00:22:59] | Warped_ (Warped_!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Client Quit) | |
| [00:26:27] | rsiebert (rsiebert!~quassel@e179165030.adsl.alicedsl.de) has joined #mythtv | |
| [00:27:27] | rsiebert_ (rsiebert_!~quassel@f052164011.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds) | |
| [00:37:04] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [00:40:30] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [00:41:03] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [01:26:41] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [01:32:05] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [01:40:29] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [01:50:15] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Remote host closed the connection) | |
| [01:54:45] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [01:58:58] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Remote host closed the connection) | |
| [02:07:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [02:08:09] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [02:08:18] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:08:18] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [02:20:28] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [02:40:32] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [03:05:58] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 240 seconds) | |
| [03:07:26] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:09:24] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:31:32] | arescorpio (arescorpio!~arescorpi@14-57-245-190.fibertel.com.ar) has joined #mythtv | |
| [04:02:53] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:04:17] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:24:26] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 264 seconds) | |
| [04:37:54] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [05:28:47] | arescorpio (arescorpio!~arescorpi@14-57-245-190.fibertel.com.ar) has quit (Excess Flood) | |
| [06:29:31] | stichnot (stichnot!~stichnot@adsl-69-105-238-26.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [06:29:32] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:29:32] | stichnot (stichnot!~stichnot@adsl-69-105-238-26.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [06:49:18] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [06:54:44] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [06:56:35] | warpme: | jya: quick question about VAAPI in current master: is PIP working OK for You?. In my test system it always gives green PIP box. Here is log from frontend: http://pastebin.com/LDTQqiMr |
| [07:13:58] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Remote host closed the connection) | |
| [07:32:30] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [07:53:16] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:04:48] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 260 seconds) | |
| [08:07:22] | amessina (amessina!~amessina@50-196-241-78-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [08:11:01] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has left #mythtv ("http://quassel-irc.org - Chat comfortably. Anywhere.") | |
| [08:15:54] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [08:32:42] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [08:39:01] | dekarl1 (dekarl1!~dekarl@p4FE84256.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:39:45] | dekarl (dekarl!~dekarl@p4FCEE9D0.dip0.t-ipconnect.de) has quit (Ping timeout: 255 seconds) | |
| [09:12:06] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:19:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 255 seconds) | |
| [09:20:59] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [09:22:39] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [09:27:08] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:50:32] | joki (joki!~joki@p5486381F.dip0.t-ipconnect.de) has joined #mythtv | |
| [10:54:01] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [11:39:17] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Ping timeout: 264 seconds) | |
| [11:42:40] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:7025:3e4b:5575:dc4) has joined #mythtv | |
| [11:42:43] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:7025:3e4b:5575:dc4) has quit (Changing host) | |
| [11:42:43] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [11:44:10] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [11:52:33] | dekarl1 is now known as dekarl | |
| [13:13:57] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [13:14:33] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [13:16:14] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [13:31:30] | amessina (amessina!~amessina@50-196-241-78-static.hfc.comcastbusiness.net) has quit (Quit: Konversation terminated!) | |
| [13:37:36] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.