| Monday, October 21st, 2013, 00:12 UTC | ||
| [00:12:48] | stichnot: | It's kind of challenging to search tickets in trac, so is anyone aware of tickets reporting that switching channels/inputs during Live TV doesn't respect the live TV order set up in the Input Connections screen? |
| [00:52:49] | rsiebert (rsiebert!~quassel@g229053174.adsl.alicedsl.de) has joined #mythtv | |
| [00:55:50] | rsiebert_ (rsiebert_!~quassel@g224251082.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds) | |
| [00:57:10] | aarcane_ (aarcane_!~aarcane@99-42-64-115.lightspeed.irvnca.sbcglobal.net) has quit (Read error: Connection reset by peer) | |
| [00:59:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [01:07:32] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [01:20:59] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 268 seconds) | |
| [01:32:37] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [01:36:16] | dblain: | stuartm: sorry I haven't responded. Ended up being a very busy weekend. I've been reading the scroll back... Do you have any outstanding questions for me? It seems you were able to resolve the ones I've see so far. |
| [02:11:05] | nyloc (nyloc!~quassel@p3EE2CC6B.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:15:15] | _nyloc_ (_nyloc_!~quassel@p5B26F5CE.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds) | |
| [02:19:48] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Operation timed out) | |
| [02:34:59] | sraue_ (sraue_!~stephan@77-239-33-225.dyn.cable.fcom.ch) has joined #mythtv | |
| [02:35:39] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds) | |
| [02:36:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:25:26] | aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 248 seconds) | |
| [03:25:26] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (Ping timeout: 248 seconds) | |
| [03:25:26] | poptix (poptix!poptix@precious.net) has quit (Ping timeout: 248 seconds) | |
| [03:25:42] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [03:26:09] | poptix (poptix!poptix@poptix.net) has joined #mythtv | |
| [03:38:27] | aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [03:44:16] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:45:15] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:05:27] | stoffel (stoffel!~quassel@pD9E41EB4.dip0.t-ipconnect.de) has joined #mythtv | |
| [04:12:10] | toeb (toeb!~toeb@HSI-KBW-078-042-206-116.hsi3.kabel-badenwuerttemberg.de) has quit (Ping timeout: 256 seconds) | |
| [04:22:03] | stoffel (stoffel!~quassel@pD9E41EB4.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [05:56:56] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv | |
| [06:03:59] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:05:27] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:23:30] | joe____ (joe____!~bob@64.73.32.135) has quit (Read error: Connection reset by peer) | |
| [06:23:46] | joe____ (joe____!~bob@64.73.32.135) has joined #mythtv | |
| [06:58:22] | dgeary2 (dgeary2!~debian@pa49-187-82-109.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [07:02:11] | dgeary2 (dgeary2!~debian@pa49-187-82-109.pa.nsw.optusnet.com.au) has quit (Client Quit) | |
| [07:20:56] | doev (doev!~doev@p4FD427E3.dip0.t-ipconnect.de) has joined #mythtv | |
| [07:35:58] | robink (robink!~quassel@unaffilated/robink) has quit (Quit: No Ping reply in 180 seconds.) | |
| [07:36:26] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [07:44:38] | sraue_ is now known as sraue | |
| [07:44:47] | sraue (sraue!~stephan@77-239-33-225.dyn.cable.fcom.ch) has quit (Changing host) | |
| [07:44:48] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [08:06:11] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [08:51:25] | stuartm: | dblain: I think I managed to figure everything out, thanks :) |
| [08:52:38] | stuarta: | morning |
| [08:52:56] | stuartm: | morning |
| [09:13:40] | stuartm: | dblain: in fact the only thing I haven't figured out is where we're failing to catch those throw()s that end up bringing down the backend |
| [09:22:13] | stuarta: | stuartm: can't gdb catch it for you? |
| [09:23:35] | stuartm: | stuarta: yeah it can, that wasn't the type of catch I meant :) |
| [09:24:10] | stuartm: | needs a try {} catch {} somewhere |
| [09:25:09] | stuartm: | I know exactly which line is triggering the problem, I just can't remove it because it's an integral part of the way the services stuff works |
| [09:27:02] | stuarta: | it's the caller of the function that throws the exception you are missin? |
| [09:27:11] | stuartm: | it could, perhaps be substituted in time with a couple of global error variables (error, errorstring) but that's not something I want to start working on atm |
| [09:27:53] | stuartm: | stuarta: there is a signal/slot or similar involved that is hiding the caller, yes |
| [09:28:42] | stuartm: | and it could even be in QT code, in that respect gdb isn't helping |
| [09:36:25] | stuartm: | frustratingly I still can't easily have QTScript parse an ISO datetime string, it seems it's supported in ECMA Script v5 but not in QTScript until QT 5.0 |
| [09:52:35] | dekarl (dekarl!~dekarl@p4FCEE8FB.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:55:07] | dekarl1 (dekarl1!~dekarl@p4FCEE8A7.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [10:06:10] | joe____ (joe____!~bob@64.73.32.135) has quit (Read error: Connection reset by peer) | |
| [10:06:27] | joe____ (joe____!~bob@64.73.32.135) has joined #mythtv | |
| [10:25:37] | stuartm: | dblain: I know when you implement some of the services stuff you had in mind that it might one day replace the existing classes which do the same job and for that reason I was wondering if you objected to making the Get/PutSetting methods wrappers instead of operating directly on the database? The current services implementation doesn't support overrides or the settings cache |
| [11:02:45] | stuarta: | stuartm: maybe drop your findings in an email so we can all see where you have got to? (or a pastebin) |
| [11:06:35] | stuartm: | stuarta: for the throw/crash issue? |
| [11:06:39] | stuarta: | yeah |
| [11:06:59] | stuarta: | maybe its one of those that'll benefit from many people looking at it |
| [11:18:48] | stuartm: | stuarta: http://pastebin.com/ycxyeCev |
| [11:20:55] | ** stuarta adds to the list :) ** | |
| [11:25:49] | stuarta: | interesting |
| [11:28:05] | stuartm: | thanks |
| [11:30:33] | stuarta: | i'll try to take a look tonight if i can, slammed today |
| [11:52:03] | doev (doev!~doev@p4FD427E3.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [11:52:52] | doev (doev!~doev@p4FD40F7E.dip0.t-ipconnect.de) has joined #mythtv | |
| [12:22:13] | dekarl (dekarl!~dekarl@p4FCEE8FB.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [13:17:28] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:32:52] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [13:37:42] | danielk22 (danielk22!~danielk@exchange.wgen.net) has quit (Client Quit) | |
| [13:45:42] | danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv | |
| [13:45:43] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [14:17:07] | nvzn (nvzn!~nvzn@unaffiliated/nvzn) has quit (Read error: Operation timed out) | |
| [14:32:27] | gigem: | stichnot: With your live TV from EPG change, we should probably get rid of the WatchTVGuide setting. |
| [14:33:03] | danielk221 (danielk221!~danielk@exchange.wgen.net) has left #mythtv () | |
| [14:47:18] | tafypz (tafypz!c63a11ed@gateway/web/freenode/ip.198.58.17.237) has joined #mythtv | |
| [14:53:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [14:54:59] | tafypz: | Hi guys, I have done a proof of concept for bringing raw livetv through a rest interface (right now written in java using the myth protocol) |
| [14:55:00] | tafypz: | I have a need for it, however I do not know if other are interested in it... If there is interest and this is something the devs would be opened to add to the services api; I was thinking about creating a patch to add it to the Content or Dvr endpoints Right now to get livetv via http all needs to be done is issuing a GET request to http://<HOST:PORT>/Content/LiveTv?channum=X |
| [14:59:38] | toeb (toeb!~toeb@HSI-KBW-134-3-100-205.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [15:08:22] | dblain: | stuartm: Testing the exception in your foo.qsp example... |
| [15:09:46] | dblain: | I'm running Qt5.1, but if I force a throw in guide.cpp:51, it's caught by serverSideScripting.cpp:205 |
| [15:10:08] | stuartm: | strange, it's not caught here :( |
| [15:10:25] | dblain: | It works as I designed it. When I created it years ago, I know I tested with Qt 4.8 |
| [15:10:54] | dblain: | Do you know if it's hitting the Throw statement or is QDateTime doing the throw? |
| [15:12:02] | stuartm: | it's the throw statement |
| [15:12:11] | stuartm: | let me pastebin the backtrace |
| [15:13:04] | dblain: | okay... granted I tested both time in windows. I wonder if gcc exception handling is showing different behavior |
| [15:13:25] | ** dblain goes and try to reproduce in linux ** | |
| [15:15:04] | stuartm: | http://pastebin.com/bGhdiB63 |
| [15:22:07] | dblain: | stuartm: well, it crashes for me in linux as well. I'll see if I can find a solution |
| [15:31:18] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [15:32:05] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [15:50:34] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [15:52:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:55:10] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [16:07:04] | stuartm: | so having got this guide done and working well, I then add a menu entry for it and several bits break :/ |
| [16:08:36] | stuartm: | fixed all but one issue, but something about the way it loads the pages into index.html instead of using frames is throwing off my position calculations for the 'popup' layers |
| [16:13:47] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [16:14:12] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [16:50:27] | doev (doev!~doev@p4FD40F7E.dip0.t-ipconnect.de) has quit (Quit: Verlassend) | |
| [16:57:47] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:26:21] | stichnot: | gigem: As dismayed as I was when I tried to follow all the code paths using WatchTVGuide, I don't think my change in itself is enough to remove that setting. I'm assuming that you're thinking it would be enough for the WatchTVGuide-using user to remap their remote button for Live TV to Program Guide (assuming they don't have buttons for both actions) |
| [17:27:50] | stichnot: | One problem is that in themes/defaultmenu/mainmenu.xml, Live TV is on the first page, whereas navigating to the guide requires Manage Recordings > Schedule Recordings > Program Guide |
| [17:28:59] | dekarl (dekarl!~dekarl@p4FE8590C.dip0.t-ipconnect.de) has joined #mythtv | |
| [17:29:19] | stichnot: | and probably a few minor things, like making sure the Program Guide starts up with the last Live TV channel highlighted |
| [17:30:35] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv | |
| [17:31:18] | stichnot: | To be clear, I'm also in favor of removing that setting, but it will almost certainly greatly annoy a small subset of users, so we would need to be sure we've identified all the issues. |
| [17:32:02] | stichnot: | sphery, please comment :) |
| [17:52:54] | gigem: | stichnot: I just want to get rid of another superfluous setting. Really, how hard is to press the guide button yourself after entering live TV. As such, I wouldn't really care if any users complain! :) FWIW, I can see promoting Program Guide out of Manage Recordings for the DVR or another more TV-centric menu theme. |
| [17:54:35] | tafypz (tafypz!c63a11ed@gateway/web/freenode/ip.198.58.17.237) has left #mythtv () | |
| [17:58:25] | stichnot: | gigem: I agree, and I would add that this is a setting that seems much more intrusive in the code than most superfluous settings. |
| [17:58:39] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [17:59:49] | stichnot: | It's not hard to press the guide button, but if your remote lacks a guide button, and you have to press 5 buttons instead of 2, I would understand being annoyed. |
| [18:01:08] | stichnot: | On a related note, when you enter the program guide at the top level (i.e. not from within Live TV), I don't really understand the division/replication of functionality between the SELECT menu and the MENU menu. |
| [18:02:32] | stichnot: | I added the "Watch This Channel" only to the MENU menu because the SELECT menu can be accessed from other places in the UI where it wouldn't be appropriate to start watching the channel in Live TV. |
| [18:26:45] | gigem: | stichnot: Wasn't it you who added the ability to customize the OSD menu? No Guide button problem solved. I share your confusion regarding SELECT and MENU in the EPG. In fact, I had a long forgotten keybinding I'd added because of it that caused me some grief recently. I suppose the desired/expected behavior should depend some on context. My Mom's old FIOS DVR worked that way. Enter the EPG from live TV |
| [18:26:47] | gigem: | and SELECT changed channels. Enter the EPG from Schedule Recordings and SELECT brought up the recording options. |
| [18:38:04] | dblain: | stuartm: Even though the calls to our service slots should be direct, the exceptions aren't being unwound correctly in linux. Even though it may be possible to fix this with compiler/linker options, it doesn't seem worth the trouble (that and other devs hate exceptions). |
| [18:38:56] | dblain: | So I'm going to refactor the code to log the details of the error (msg of throw), and then just return a negative result (null for pointers, false for bool, etc ) |
| [18:39:33] | dblain: | I'm open to suggestions if there is a better way. |
| [19:40:28] | sphery: | stichnot / gigem : I'm all for removing the setting (big surprise, right? :). As far as SELECT vs MENU, the (original) distinction is that SELECT displays a "right-click"/context menu of choices that operate on a particular (selected/highlighted) item, whereas MENU should display options related to the "screen"/area (guide) as a whole--things that don't require selecting a specific item. |
| [19:41:31] | sphery: | this distinction got borked by users saying, "MythTV shouldn't require 2 menu buttons, since no other application on earth does," (after all, no one else has right-click menus, I suppose) and the changes in Watch Recordings |
| [19:52:04] | stichnot: | sphery: I expect two menus when I use a mouse with 2 buttons, but I haven't seen a tendency for remote control UIs to provide two menus. Hence my own internal confusion over multiple menus. |
| [19:54:45] | dekarl: | does that work with a remote? http://ars.userfriendly.org/cartoons/?id=19980713 |
| [19:56:34] | stichnot: | Also, in today's computer/mouse UIs, I see 3 types of actions: left-click invokes an immediate action, right-click brings up a secondary, context-specific menu, and left-clicking in the menu bar brings up the main, complete menu. It sounds like you're expecting SELECT to be a combination of left and right clicking, and MENU to be like the menu bar. |
| [19:57:51] | jpharvey_ (jpharvey_!~jpharvey@host109-148-239-68.range109-148.btcentralplus.com) has quit (Remote host closed the connection) | |
| [19:58:35] | stichnot: | Traditional remote control buttons don't map so well onto the computer/mouse model. You can count on having SELECT, and often MENU, but a third button isn't so clear. Maybe INFO? (which is used like a third button in Video Gallery) |
| [19:59:54] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [20:01:59] | dekarl: | stichnot: you did not follow the link, did you? ;) |
| [20:02:05] | sphery: | stichnot: originally in mythtv SELECT was the equivalent of left mouse, but where it wasn't clear what action to take, it would bring up a menu of actions |
| [20:02:28] | sphery: | (left mouse meaning immediate action) |
| [20:02:28] | stichnot: | dekarl: yes, after I posted :) |
| [20:03:25] | stichnot: | sphery: that makes sense |
| [20:03:26] | sphery: | INFO should just give you information on an item, and shouldn't perform any actions, ideally |
| [20:04:38] | sphery: | stichnot: at this point, though, you can probably change SELECT/MENU to work however you like... I'd say that having "Watch this channel" on MENU makes sense even from the original distinction because it doesn't operate on the currently-selected show, but on the channel (regardless of how far in the past/future listings they are) |
| [20:05:38] | sphery: | it seems users, now, prefer one menu button with multiple menus that come up so that I can say, "Press MENU (once or twice until you see the right options), then select ..." |
| [20:06:05] | sphery: | rather than having quick-access to either "page-wide" or item-specific actions |
| [20:06:44] | sphery: | but eventually we'll have to make things more consistent--Video Library still uses the original distinction, but Watch Recordings changed it |
| [20:06:54] | stichnot: | I kind of prefer the single-button multi-state approach, except that it's hard to discover states beyond the first state |
| [20:07:47] | sphery: | I hate having to move the cursor from the show to the group to get group-specific options in "one button press" (because now that I've moved, it's 2) or having to hit the button 2 times to get those group options |
| [20:07:53] | sphery: | but then again, I don't have a 3-button remote |
| [20:09:09] | sphery: | oh, and I actually use LIRC rather than feeling like I can only do whatever the developer who wrote the "pretend like this remote control is actually a keyboard" thought that the "checkmark" button on my remote should do |
| [20:10:03] | joki (joki!~joki@p54861437.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [20:10:18] | sphery: | anyway, though I'm happier with the original implementation, I don't think we could ever go back to it, so I won't argue if people change it (as long as eventually we make things consistent throughout :) |
| [20:11:15] | stichnot: | But as to the original question – removing the WatchTVGuide setting – it would be good to figure out the best way to tweak the UI so that it minimizes the extra navigation for people who like the setting. |
| [20:12:12] | sphery: | yeah, I agree there will be complaints |
| [20:13:04] | stichnot: | Bringing Program Guide into mainmenu.xml; making the guide start up on the last LiveTV channel (maybe with a shortcut to move to the first channel) |
| [20:13:28] | sphery: | I'd be ok with moving Program Guide to the top level menu (in defaultmenu) along with Watch TV and then users can select the one they want |
| [20:13:44] | sphery: | or users who use jump points can simply map the one they want |
| [20:14:21] | stichnot: | Yeah, I figure if they have only the LiveTV button on their remote, they can just remap it to Program Guide |
| [20:14:52] | stichnot: | then it's MENU-SELECT to close the guide and watch that channel, versus ESCAPE before |
| [20:14:56] | sphery: | so the only big difference, then, would be that when people start the guide, Live TV isn't playing in the background/underneath it (which, in theory, should be fine since the whole purpose of starting in the guide is to select what they actually care to watch, rather than what was on last) |
| [20:16:08] | toeb (toeb!~toeb@HSI-KBW-134-3-100-205.hsi14.kabel-badenwuerttemberg.de) has quit (Read error: Operation timed out) | |
| [20:16:20] | joki (joki!~joki@p54862665.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:16:37] | stichnot: | Another difference to consider is the long-wait/guide/LiveTV experience versus guide/long-wait/LiveTV, but I expect seeing the guide quickly should be as good or better than before |
| [20:17:37] | sphery: | so, in the in-OSD guide, when hitting SELECT (space/enter), we change to the selected channel if the selected show is in progress or starts within 15 minutes, or otherwise bring up the scheduler editor (see, under EPG at http://www.mythtv.org/wiki/MythTV-HOWTO#Keyboard_commands ) |
| [20:18:25] | sphery: | we could modify the non-OSD guide to do similar--so that if they actually select an in-progress or soon-to-start(? or maybe not soon-to-start?) show we just go there in Live TV |
| [20:18:41] | stichnot: | I thought that "change to the selected channel behavior" was behind another setting, or did that get removed along the way? |
| [20:18:46] | sphery: | and if they select any other show (past/future), we bring up the editor |
| [20:19:04] | sphery: | there was a setting to set the 15min... |
| [20:19:45] | sphery: | SelChangeRecThreshold -> Record threshold = Pressing SELECT on a show that is at least this many minutes into the future will schedule a recording. (default 16) |
| [20:20:00] | stichnot: | ok |
| [20:20:18] | sphery: | which makes it "within 15min, inclusive", but I don't remember a setting to say whether or not that was enabled |
| [20:20:33] | sphery: | though setting the threshold to 0 would, effectively, disable it, it seems... |
| [20:21:25] | stichnot: | I could be thinking of the setting that controls the SELECT behavior when you do CHANUP/CHANDOWN in live TV (iirc) |
| [20:21:58] | sphery: | I'd think you could piggy back off that and if you want to do the "soon-to-start" shows, use the same value and let the users disable it with 0min (so they have to use MENU|Watch channel...) |
| [20:22:05] | sphery: | ah, yeah, there is that one |
| [20:22:44] | sphery: | although I may have removed it... |
| [20:22:52] | stichnot: | The one thing I don't like about the context-sensitive SELECT action is that if you pressed SELECT but didn't mean to start Live TV on that channel, you may have to wait ~10 seconds before Live TV starts and you can go back and do what you meant |
| [20:23:34] | sphery: | that is true... may not be appropriate because of the high-cost consequences |
| [20:23:50] | stichnot: | but of course that is currently the case in the in-OSD EPG |
| [20:24:36] | stichnot: | except that if you're already watching Live TV, you should already be accustomed to high-cost actions like changing channels |
| [20:24:51] | sphery: | true |
| [20:25:00] | stichnot: | whereas if you start the EPG from the top level, you're still used to a snappy UI |
| [20:25:24] | sphery: | I'll argue whichever approach you choose--I trust your decisions on what works well for Live TV much better than mine :) |
| [20:25:46] | stichnot: | thanks :) |
| [20:26:21] | stichnot: | I'm channeling for the in-laws who are making an extended visit soon :) |
| [20:27:05] | stichnot: | but since I've saved 100+ recordings for them since their last visit, hopefully live TV won't be needed at all... |
| [20:30:45] | stichnot: | So, given the lack of objections here, I will try to make some high-level UI changes targeted to LiveTV-with-EPG users with few remote control buttons, then remove the setting and evaluate unexpected user experience reports that come up. |
| [20:31:24] | sphery: | Hehe, who knows. My parents visited one time and I had some work to do and I left them to watch Live TV and when I came back about 10min later, I saw they were watching the last 20min of an episode of CSI--even though I had every CSI ever broadcast recorded in Watch Recordings (I hadn't started watching the series, yet, at that time) |
| [20:35:11] | stichnot: | that's just sad :) |
| [20:36:06] | sphery: | yeah, though I'll admit that looking through my list of recordings would have been a daunting prospect for someone who just wanted to watch/listen to whatever |
| [20:41:46] | Guest85778 (Guest85778!~neon@bzq-79-180-207-250.red.bezeqint.net) has quit (Ping timeout: 246 seconds) | |
| [20:48:48] | stichnot: | For the plan, also I'll look into gigem's suggestion of making it faster to bring up the EPG during live TV, for people who really want to start up live TV and then see the guide quickly, and don't have a Guide button |
| [20:55:59] | Guest85778 (Guest85778!~neon@109.65.184.99) has joined #mythtv | |
| [20:58:29] | jpharvey (jpharvey!~jpharvey@host109-148-239-68.range109-148.btcentralplus.com) has joined #mythtv | |
| [21:03:27] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:07:40] | danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv () | |
| [21:10:07] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:30:47] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:33:02] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 240 seconds) | |
| [21:52:31] | gigem: | sphery, stichnot: It looks like you guys touched on most of the historical issues concerning SELECT/MENU while I was away. I said "looks like" because I got tired of reading and skipped ahead. Here's my two key points on the issue. One, we have historically been inconsistent in the handling of SELECT/MENU (and INFO) which has lead to the confusion. Two (IMO), SELECT should bring up a menu with quick |
| [21:52:32] | gigem: | access to the most common actions for the currently highlighted item and one option access more, less frequently used actions via sub menus; MENU should bring up a menu to access any other actions relevant to the current screen. |
| [22:09:11] | clever (clever!~clever@nwcsnbsc00w-142167021018.dhcp-dynamic.FibreOp.nb.bellaliant.net) has quit (Ping timeout: 260 seconds) | |
| [22:13:59] | skd5aner: | stichnot: #10967 ;) |
| [22:13:59] | ** MythLogBot http://code.mythtv.org/trac/ticket/10967 ** | |
| [22:20:55] | dekarl: | wagnerrp: just a heads up wrt inetref... http://www.themoviedb.org/account/TheTVDB%20Bot |
| [22:21:41] | wagnerrp: | 9M changes? |
| [22:21:52] | wagnerrp: | well it's been around for almost three years |
| [22:22:07] | dekarl: | they are pulling in the whole thetvdb into themoviedb or so it appears |
| [22:22:25] | wagnerrp: | how are they dealing with id conflicts? |
| [22:22:37] | wagnerrp: | just spawn a new, independent id for any new shows? |
| [22:24:06] | dekarl: | seems to be a new unrelated id starting a 1 |
| [22:30:42] | skd5aner: | stichnot, sphery: IMHO, instead of trying to figure out a situation that works for most remotes – just use the MCE remote model. It aligns nicely to most commercial DVR remotes anyway, and I would assume that today most people are using them for mythtv |
| [22:31:53] | skd5aner: | if someone isn't using a remote that has an info button, then sure – find a way that they can use it without one, but assume that most people could map the equivalent of core buttons like "menu, info, select/ok, etc" |
| [22:33:59] | stichnot: | skd5aner: My mindset comes from the TiVo remote, which is very close in number/type of buttons to the MCE remote |
| [22:34:10] | skd5aner: | gotcha |
| [22:34:24] | skd5aner: | stichnot: did you see that ticket I posted for you above? I think that's what you were looking for, correct? |
| [22:34:26] | stichnot: | but for fun, I think about making a 5-button remote usable |
| [22:34:48] | stichnot: | skd5aner: awesome, thanks, don't know how I missed that |
| [22:35:20] | stichnot: | I think I fixed it in 0.27 – can you verify? |
| [22:35:25] | skd5aner: | oh no, you've come down with a bad case of SteveJobariaha! 5 buttons is enough to rule the world! |
| [22:35:54] | skd5aner: | stichnot: hehe – no problem, if there's a potential live TV related bug, just search "skd5aner" – I may have already submitted it years ago – lol :D |
| [22:36:35] | skd5aner: | stichnot: I can probably test it against 0.27-fixes – did you already commit a fix to the branch? |
| [22:37:29] | stichnot: | yes, I committed it about 8 hours ago |
| [22:42:45] | stichnot: | I would go crazy with only 5 buttons, but it's useful to think about that extreme case in a design |
| [22:43:07] | skd5aner: | stichnot, sphery: I will say, I will likely be a user who would be confused if launched live tv (in to the program guide) and the "esc/exit" button didn't just close the EPG and allow me to watch livetv... going through the menu to get out of the epg seems very unintuitive |
| [22:44:06] | skd5aner: | and, every commercial DVR/STB I know of still allows a live-video preview in the EPG while browsing for a channel |
| [22:47:32] | skd5aner: | stichnot: honestly, I'm greatful you are looking at live tv through the "I have guests coming" lens... although we do use Live TV in my house nearly daily, it seems that anytime we have guests staying with us, it's clear to see the behaviors trip them up that I'm accustomed to just working around |
| [22:48:04] | skd5aner: | stichnot: Since I guess I'm sort of a power user of Live TV, I'm happy to provide input, feedback, and testing if you open for it |
| [22:48:39] | skd5aner: | I'll pull that latest, compile, and test a little later this evening and let you know about your order fix |
| [22:52:50] | stichnot: | skd5aner: the discussion earlier was about removing the option to automatically bring up the EPG whenever you enter Live TV |
| [22:53:15] | stichnot: | Without it, you have two options. 1) start Live TV and then press your Guide button |
| [22:53:57] | stichnot: | 2) start the EPG at the top level (without the live preview), then Menu > Watch This Channel to start Live TV (without the guide initially displayed) |
| [22:54:59] | stichnot: | In case 1, ESCAPE would just bring you back to full-screen Live TV, and in case 2 ESCAPE would bring you back to wherever you were before |
| [22:55:36] | skd5aner: | I see – I wonder how many people would use case 2 to begin with, I'd imagine very little |
| [22:55:58] | stichnot: | me, for one... |
| [22:56:35] | stichnot: | I want to search the guide for something, then start watching it, not start live TV at some random channel and then find what I want |
| [22:57:03] | stichnot: | since changing channels can take ~10 seconds, I'd rather not do it twice |
| [22:57:07] | skd5aner: | I think I turned off the setting to go in to the EPG when launching livetv because it actually seeemed to slow it down and cause other issues a few releases ago |
| [22:58:05] | stichnot: | also, in the earlier days, Live TV was much less reliable, and I couldn't be sure the session/frontend/backend would survive 2 channel changes |
| [22:58:16] | stichnot: | though I find it far more reliable these days |
| [22:58:25] | skd5aner: | I will say that, I do use the EPG while in Live TV frequently... and my most frustrating experience with MythTV at this point, which I think severly lacks compared to commercial DVR/STB projects, is the response of navigating the epg AND the fact that it causes the video to freeze between key presses |
| [22:58:53] | skd5aner: | fix that, and my last actual "complaint" will be wiped off the list :D |
| [22:58:55] | skd5aner: | heh |
| [22:59:23] | stichnot: | that's 4th on my list right now :) |
| [22:59:52] | skd5aner: | I'll buy you a 6 pack of whatever you want if you fix that |
| [22:59:56] | skd5aner: | no joke |
| [23:00:03] | stichnot: | #11020 |
| [23:00:03] | ** MythLogBot http://code.mythtv.org/trac/ticket/11020 ** | |
| [23:00:11] | stichnot: | thanks :) |
| [23:00:55] | stichnot: | that ticket is just a reference/placeholder, I wouldn't actually use the patch provided |
| [23:01:26] | skd5aner: | gotcha |
| [23:01:53] | stichnot: | Compared to commercial DVRs, I think channel changing in Live TV takes much longer in MythTV, but I honestly have no idea what to do about it |
| [23:02:19] | skd5aner: | so, I suppose... I don't care if live TV launches directly in to the EPG... I could be ok with that going away... |
| [23:02:53] | stuartm: | stichnot: it's not one single thing, but lots and lots of little things that just add up |
| [23:03:14] | skd5aner: | the only slow channel changing for me is between channel changes in the hd-pvr |
| [23:03:44] | skd5aner: | which, I understand is really a limitation of the device itself and stabilization of the STB it records from between channel changes |
| [23:03:52] | skd5aner: | so – imho, that's as good as it's going to get |
| [23:04:02] | stuartm: | e.g. the number of queries on the db needs to come down – we get lots of fragments of information from the same table in different queries |
| [23:04:07] | stichnot: | even the hdhr is slower than I think it ought to be |
| [23:05:03] | stichnot: | stuartm: yeah, I've seen that, also just in mythfrontend startup |
| [23:05:20] | stuartm: | and stuff like the creation of the RecordingProfile object is slower than it should be and it's done twice (or was, haven't looked at it for a couple of years) |
| [23:06:52] | skd5aner: | stichnot: feel free to take ownership of #10967... I'm sure gigem won't mind :) |
| [23:06:52] | ** MythLogBot http://code.mythtv.org/trac/ticket/10967 ** | |
| [23:07:22] | stuartm: | eliminating queries was one of the reasons I first created the ChannelInfo class, so that we could load up all the information for a channel once (probably all channels in a list) then just keep re-using that data instead of the mess that is ChannelUtil |
| [23:08:24] | skd5aner: | hey guys, just want to take the oppotunity to say thanks again... I love seeing all the work you guys put in to the project. |
| [23:08:27] | stuartm: | it's work like that which might help to make a modest improvement to channel change times – it's not glamorous, but ... |
| [23:09:07] | skd5aner: | stuartm: over the years, modest changes each release have added up to SECONDS.... you know how easy it is to perceive even a second improvement between channel changes?! |
| [23:11:32] | stuartm: | skd5aner: I wouldn't even be proposing it it I didn't think it was worth doing :) |
| [23:11:57] | skd5aner: | i know – just affirming :) |
| [23:13:36] | stuartm: | I mean there are other benefits besides speed too, classes like ChannelInfo and RecRule (and ProgramInfo which inspired them) reduce the overall code duplication and consolidate all the related code in one place making it easier to maintain |
| [23:15:38] | stuartm: | ProgramInfo has become a bit of a mess, it stores stuff like callsign, channel name – which it has no good reason to do, it would be better if it stored a pointer to a ChannelInfo object instead |
| [23:16:07] | stuartm: | less code, fewer queries, better overall design |
| [23:17:56] | skd5aner: | what causes the blocking though between channel changes? it's like it can only do one thing at a time, navigate the EPG OR show the livetv playback – not both |
| [23:18:37] | skd5aner: | is it inefficiencies in lookups that cause it, or is it the framework that won't allow it to play nicely together? |
| [23:19:19] | stichnot: | skd5aner: are you asking about navigating between channel rows in the EPG, or actually tuning in a different channel? |
| [23:20:55] | stichnot: | for the former, it does a DB query (probably more than one, inappropriately) to see if the channel is currently tunable or not so that the formatting can be changed to indicate that. This blocks the UI thread, which includes video playback |
| [23:21:49] | stichnot: | It could do this by a protocol message to the backend, and/or put the query in a different thread and delay the state update. |
| [23:22:10] | stuartm: | skd5aner: it's network related, as you move through the guide we're re-querying the state of all the tuners to show which channels in the guide are tunable – it's extremely inefficient and that jump in traffic over the protocol causes a lag in video packets |
| [23:23:18] | stuartm: | stichnot: I prefer caching the state on first entering the guide, then passively listening for MythEvent messages which inform us of any state changes |
| [23:23:55] | stuartm: | it's the model we're adopting everywhere else, playback box/watch recordings is the best example |
| [23:24:36] | stuartm: | we don't poll for any changes there, the backend sends out events which we listen for and update the screen (and caches) as needed |
| [23:24:55] | stichnot: | yeah, even better. Do these events currently exist? |
| [23:25:21] | stichnot: | I mean the specific ones that indicate tuner availability change |
| [23:25:57] | stuartm: | stichnot: I don't know if any specifically for tuner/channel status exist, but it's pretty much a one-liner once you find the appropriate place to send them |
| [23:27:31] | stuartm: | handling is a few more lines, but overall it's a fairly easy solution which makes it even better than something like putting the checks into another thread |
| [23:29:22] | stuartm: | I'd be happy to put the work in |
| [23:30:52] | stuartm: | I believe the hardest part really is just figuring out where those events should be sent from as I don't know the recorder side of things very well |
| [23:31:09] | stichnot: | yeah, I've implemented that pattern before, was just wondering if it's already there in this case :) |
| [23:31:43] | skd5aner: | stichnot: sorry, the formmer (navigating between rows in the EPG while LiveTV is playing back) |
| [23:31:50] | stuartm: | I did suggest in a conversation with stuarta and gigem the other day creating a BackendContext class which would keep track of stuff like tuner status – that would be the obvious place for the event to ultimately be sent from |
| [23:32:31] | stichnot: | In this case, it doesn't matter so much if you get it exactly right since the backend will ultimately decide whether you get to make that channel change |
| [23:33:45] | stuartm: | the backend shutdown code regularly checks the tuner status too and again it's very slow (contributes to some deadlocks), so caching that information in one single location is a win-win |
| [23:35:06] | stuartm: | I only wish that I had more time :) |
| [23:35:58] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [23:37:14] | stuartm: | btw one of the reasons it's so slow is that we check the availability of every virtual tuner! |
| [23:38:09] | stuartm: | most of the time we're only concerned with whether the physical tuner is available to tune a channel |
| [23:39:36] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds) | |
| [23:44:28] | skd5aner: | stuartm: random question for you... given that you are trying to do the whole mythweb integration piece, do you think mythweb as we know it will surive in a deprecated state for one more release or go away entirely? |
| [23:49:46] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [23:54:27] | stichnot: | I'm not sure why current mythweb would have to go away suddenly, seems at worst it would slowly rot away |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.