| Sunday, June 8th, 2014, 00:18 UTC | ||
| [00:18:23] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [00:20:41] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 264 seconds) | |
| [00:24:24] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has quit (Remote host closed the connection) | |
| [00:29:08] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [01:21:06] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [01:21:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [01:21:06] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [01:21:09] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.3) | |
| [01:22:23] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:36:02] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds) | |
| [01:40:02] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:22:18] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds) | |
| [02:23:26] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:18:17] | jya: | wagnerrp: is a slave backend expected to be able to work if the master is down? |
| [03:18:46] | wagnerrp: | nope |
| [03:19:08] | jya: | so it can’t scheduled recordings and stuff like that |
| [03:19:16] | wagnerrp: | i don't believe so |
| [03:19:38] | wagnerrp: | the frontend won't operate without a master either. it will just sit there and complain |
| [03:20:23] | jya: | i was thinking of changing the way we resolve names and how a backend is being identified. Rather than using hostname. The first time a backend is started, it generates a unique UUID and use that uuid across. Whenever a frontend need to access that particular backend, it goes via the master backend to do so |
| [03:20:27] | wagnerrp: | i'm writing up some protocol updates that will allow backends to report and frontends to query addresses through the master |
| [03:20:46] | jya: | that way you can easily migrate a backend from one host to another, no lost of settings, they carry through etc |
| [03:21:08] | jya: | as all the name resolution and IP retrieval is now done via a getter, it can be made fully transparent to the existing code |
| [03:21:40] | wagnerrp: | there may be existing UUIDs available from smolt |
| [03:21:54] | jya: | yeah, not going to use smolt, it only works on linux |
| [03:22:03] | wagnerrp: | actually, there are already ones available from all the UPNP stuff |
| [03:22:05] | jya: | i’ve given up attempting to port that to mac |
| [03:22:19] | wagnerrp: | each config.xml should have one already |
| [03:22:33] | jya: | well, even better. the uuid will be written to config.xml, so even if the database can’t be connected etc.. the backend know its uuid |
| [03:22:38] | wagnerrp: | the MediaRenderer tag |
| [03:22:48] | jya: | could use that sure. |
| [03:23:09] | jya: | but my plans would have been made difficult if a slave backend could work on its own without a master. |
| [03:23:16] | jya: | as who do you query then? |
| [03:23:17] | wagnerrp: | although i'm not sure if those are generated globally, or only on systems that would have run a frontend |
| [03:24:01] | wagnerrp: | i believe they will continue to record whatever they were recording, waiting for the master to come back online |
| [03:24:05] | wagnerrp: | i'm not sure on that one |
| [03:24:14] | jya: | I’m going to backport all my changes related to the IPv6 fix to devel/027candidates… it’s pretty big as for that to work and work with grand-fathered config I need the whole lot |
| [03:24:20] | wagnerrp: | but a slave backend really has almost no smarts at all |
| [03:24:58] | jya: | the other thing I wanted to ask.. The idea of the libmythproto server is great. It would have been ideal if we had use that instead of mythbackend’s own code |
| [03:25:19] | jya: | but seeing there’s been no progress on this for a while, the mythmediaserver hasn’t taken off |
| [03:25:28] | wagnerrp: | that was the end goal, to break apart the bits of mainserver into libmythproto |
| [03:25:41] | jya: | it becomes difficult and error-prone to maintain both code. espeically as there’s no way to test mythmediaserver alone |
| [03:25:45] | jya: | so shouldn’t we just drop it? |
| [03:25:53] | wagnerrp: | however the development of the services api at around the same time threw some uncertainty into the mix |
| [03:25:57] | wagnerrp: | so my work on it stalled |
| [03:26:04] | jya: | it’s unfortunate... |
| [03:26:11] | wagnerrp: | there was question whether the internal protocol would remain at all |
| [03:26:15] | jya: | i really think it should have been the way to do things |
| [03:26:24] | wagnerrp: | or we would switch to dbl ain's serializer for everything |
| [03:26:52] | jya: | but, the fact is that we use mythbackend, and it’s probably easier to make the existing mythbackend works in a cut-down fashion, than bring mythmediaserver up to date |
| [03:26:52] | wagnerrp: | the original intention was that it would allow the backend to be more modular |
| [03:27:05] | wagnerrp: | both to allow the master backend functionality be broken away from the server |
| [03:27:27] | wagnerrp: | and to allow backend plugins for direct access to the database for when we switch to the internal database and remove external sql access |
| [03:27:57] | jya: | i just went over libmythproto in the past few days again, as I was upgrading the myth protocol… but I hate those blind changes, where I can’t test. I could for all I see, just brake something and it will be carried forward for years |
| [03:28:02] | wagnerrp: | mythmediaserver was basically supposed to be running shared file server code with the backend |
| [03:28:13] | jya: | yeah.. I got that |
| [03:28:39] | jya: | the other thing I’m hoping to do, is not have any frontend access the database directly, and instead via the master backend. |
| [03:29:02] | jya: | that will give us longer term approach and much easier way to change database, including using an embedded one |
| [03:29:23] | wagnerrp: | right, and that requires backend plugins to match the frontend plugins |
| [03:31:13] | jya: | what I’d love to see, in the long term, and I’m fairly certain that’s the aim of everyone: |
| [03:31:38] | jya: | You install mythbackend, you run it. It tells you where it can be configured. You access the web site there. |
| [03:31:53] | jya: | you start the frontend, it finds the backend, or give you the choice of the one it can access |
| [03:31:56] | jya: | and there you go |
| [03:32:25] | jya: | no config, no database username/password , security settings, mysql not listening to the right port/IP etc |
| [03:32:38] | jya: | whatever makes myth so damn complicated to setup |
| [03:34:17] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:34:17] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:34:17] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:36:41] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [03:37:49] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:41:31] | jya: | wagnerrp: so are you okay to drop libmythprotoserver and focus on only one server? |
| [03:42:29] | wagnerrp: | i'd rather drop mainserver.cpp and focus on libmythproto |
| [03:43:01] | wagnerrp: | but, disabling libmythproto until i get a chance to get back to it would be fine |
| [03:44:00] | wagnerrp: | i fly back on the 18th, and then am pretty much finished traveling until october |
| [03:44:36] | wagnerrp: | i can bring libmythproto up to date and break everything out of mainserver then |
| [03:45:01] | jya: | wagnerrp: I think I have libmythproto up to date with all the recent changes |
| [03:45:22] | jya: | though I haven’t checked with the recent mythmusic protocol change |
| [03:46:58] | wagnerrp: | i do want to redo how commands are stored in it |
| [03:47:08] | jya: | what commands? |
| [03:47:22] | wagnerrp: | the individual query strings, and their mapped functions |
| [03:48:02] | wagnerrp: | right now, queries are handed off to modules, and modules check the functions they handle individually |
| [03:48:16] | wagnerrp: | i want to move that into one big list, and have the list auto-optimize based off how frequently they're used |
| [03:48:46] | jya: | how do you intend to “auto-optimize” ? |
| [03:49:07] | wagnerrp: | store a use counter, periodically sort based off that counter |
| [03:49:27] | jya: | should be a nice table hash.. rather than the 1000s lines-long if (command == “blah”) else if (….) |
| [03:49:41] | jya: | then no need to worry about sorting things. |
| [03:49:52] | jya: | it’s always fast |
| [03:50:09] | jya: | would make it much easier to maintain too |
| [03:50:14] | wagnerrp: | there are going to be some that need to be reworked then |
| [03:50:36] | jya: | yes… |
| [03:50:36] | wagnerrp: | cases where one function handles multiple queries |
| [03:51:03] | jya: | IMHO, it should be modular. A module registering what command they can handle |
| [03:51:15] | jya: | (would make that easier to have backend plugin in the future too) |
| [03:51:18] | wagnerrp: | at the moment, the module just registers itself |
| [03:51:58] | jya: | from what I’ve seen, it’s more like we have a module, but the main protocol command list, is just added to that massive if else if else.. business |
| [03:52:40] | wagnerrp: | IIRC, i broke it up into a bunch of small if/elseif/else blocks within each module |
| [03:53:02] | wagnerrp: | the query would go into one module, see if the module wanted to handle it, and if not, move on to the next |
| [03:54:07] | jya: | yeah, but that’s less that optimal approach.. you still make unecessary checks. if you have a global registrated based command. with a module registering what command they support, you know before hand which module the query will be forwarded to |
| [03:54:25] | jya: | no loop, nothing |
| [03:54:50] | jya: | except if there’s the case where two modules could handle the same query… but that will fail elsewhere anyway |
| [03:56:50] | jya: | anyhow.. that’s later. can be an optimization done later. But before have the proper architecture to start with than taking the usual myth way of doing things with a series of if/else and loops trying everything |
| [04:01:41] | jya: | wagnerrp: one thing in your alley, would be to upgrade the python bindings, so they can properly handle BackendServerIP6 when it contains a scopeId |
| [04:02:10] | wagnerrp: | yeah. i've still got that trac email marked as unread so i remember to do so |
| [04:02:28] | jya: | i handled that in mythcorecontext, by dropping the scopeId completely, and then going through all interfaces trying to find one that do connect |
| [04:02:53] | wagnerrp: | are you just trying them sequentially until one connects? |
| [04:03:03] | jya: | could maybe add a myth protocol or API and ask the backend to do it |
| [04:03:24] | jya: | wagnerrp: I only do so for link-local address, start with the main interface, and then try them all yes |
| [04:03:43] | wagnerrp: | ok, i wasn't sure if there were any more intelligent way to do it |
| [04:03:44] | jya: | I cache the result because it will time-out if you try to connect using an interface that is not good |
| [04:03:52] | jya: | I can’t think of any. |
| [04:04:11] | jya: | the link-local ipv6 address, all those interfaces have one, and they are all on the same subnet |
| [04:04:18] | wagnerrp: | right |
| [04:04:19] | jya: | so there’s no smart way to do it. |
| [04:04:48] | jya: | I’ve seen projects handling it differently because they don’t use a store settings |
| [04:05:05] | jya: | instead they use Bonjour/Zeroconf, and see which interface the service is found on |
| [04:05:11] | wagnerrp: | can you connect without providing any scope, and expect the system's arp cache will recognize the correct interface to use? |
| [04:05:13] | jya: | that’s a much quicker way to do it |
| [04:05:17] | wagnerrp: | or does it require scope? |
| [04:05:20] | jya: | wagnerrp: nope |
| [04:05:39] | jya: | if you try to connect to a link-local IPv6 address, without a scopeId , it will fail with an error |
| [04:06:10] | jya: | likeL telnet: connect to address fe80::f66d:4ff:fe02:5ee7: No route to host |
| [04:06:18] | jya: | Qt connect gives another error |
| [04:06:52] | wagnerrp: | because the socket library knows that prefix should always be used with a scope |
| [04:07:14] | jya: | yes, that’s the case for link-local addresses. |
| [04:07:28] | jya: | for other type of addresses, simply removing the scopeId is all that is required |
| [04:07:35] | jya: | routing table will know what to do there |
| [04:08:08] | wagnerrp: | we could assume it's the same scope as the master backend |
| [04:08:29] | jya: | you could try that first (I thought about it) |
| [04:08:50] | jya: | but then, not even within linux that would always work |
| [04:09:01] | jya: | like my ubuntu wireless inteface is wlan0 |
| [04:09:28] | jya: | so you read BackendServerIP6, which was determined and set on the backend so has a scope id of eth0 |
| [04:09:37] | jya: | there’s no eth0 on the wireless frontend |
| [04:09:51] | jya: | so you have to go through the list of all interfaces anyway |
| [04:10:19] | wagnerrp: | i mean... the frontend connects to the master backend and figures out what interface that is on. for any subsequent connections, it assumes they are going to occur on the same interface |
| [04:10:26] | jya: | and linux: ethX, mac: enX, FreeBSD depends on the driver name etc... |
| [04:10:37] | jya: | oh, I have just that |
| [04:10:47] | jya: | as I wrote, I cache the scopeId for that particular IP |
| [04:10:48] | wagnerrp: | ok |
| [04:11:07] | jya: | when there’s another atttempt to connect to that address, the scopeId is checked in the cache, and use |
| [04:11:08] | wagnerrp: | but do you use that for new IPs as wellor start fresh? |
| [04:11:29] | jya: | the cache is in memory, it gets cleared after each restart |
| [04:11:58] | jya: | I’ve put a 5s timeout on the search, that’s less long than this stupid DBus erroring before the frontend starting |
| [04:12:20] | jya: | wagnerrp: the problem only occurs for link-local address |
| [04:12:49] | jya: | there’s typically only one link-local address to resolve, the one the backend is listening on |
| [04:12:57] | wagnerrp: | i'm talking about the case for slave backends |
| [04:13:00] | jya: | so there’s only need for one query |
| [04:13:36] | jya: | well, if the frontend attempts to connect to a slave backend via a link-local address, same deal: the scope is search via trying all interfaces, the result is cached. |
| [04:13:44] | jya: | in the future, the cached scopeId is used |
| [04:14:18] | jya: | there’s no handling about the scopeId changing part-way though… but I fgured this is a very unlikely case, and nothing would work anyway |
| [04:15:08] | jya: | there’s no universal/accepted method to determine what the scopeId should be. |
| [04:15:25] | jya: | typically, you never use link-locla addresses other than via Bonjour type service |
| [04:15:46] | jya: | in which case, bonjour knows what interface the service is on and you use that information |
| [04:16:04] | jya: | but we let it use link-local address, so had to find a way to do so |
| [04:16:36] | jya: | googling scopeId, connection error, returns a massive amount of bug reports on project facing the exact same issue |
| [04:16:53] | ** jya going to walk the dog ** | |
| [05:24:15] | jya: | wagnerrp: sorry, was ordered to walk the dog by superior authority |
| [05:55:26] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [05:55:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [05:55:26] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [06:00:29] | lomion0815 (lomion0815!~markus@212-88-1-189.adsl.highway.telekom.at) has joined #mythtv | |
| [06:17:43] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [06:34:09] | rsiebert_ (rsiebert_!~quassel@f052128046.adsl.alicedsl.de) has joined #mythtv | |
| [06:37:11] | rsiebert (rsiebert!~quassel@g224251249.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [06:55:31] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 252 seconds) | |
| [07:21:19] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [07:21:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [07:21:19] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [08:01:30] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [08:04:52] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Remote host closed the connection) | |
| [08:05:17] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:06:30] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [08:24:15] | Weaselweb (Weaselweb!~quassel@77-64-221-251.dynamic.primacom.net) has joined #mythtv | |
| [08:29:32] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [08:36:36] | jya1 (jya1!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has joined #mythtv | |
| [08:37:18] | jya1: | anyone with OpenGL knowledge ? |
| [08:37:24] | jya1: | i'm so out of my breath here |
| [09:11:55] | paul-h (paul-h!~Paul@2.221.230.194) has joined #mythtv | |
| [09:15:55] | paul-h: | Anyone else notice the titles of some programs from the radio times EPG feed is being corrupted somehow like the next program on BBC2 is shown as '136,' |
| [09:19:52] | dekarl1: | paul-h: the feed has "Saturday Kitchen Best Bites~136, series 1" |
| [09:19:55] | dekarl1 is now known as dekarl | |
| [09:20:44] | paul-h: | Yeah just looking at that. So does that mean it's our parsing that messed up? |
| [09:26:12] | dekarl: | the xmltv output looks good, proper Title + Episode Number (that gets turned into episode title by mythtv's code) |
| [09:28:40] | dekarl: | http://paste.ubuntu.com/7612166/ |
| [09:40:50] | stuartm: | paul-h: it's OK here, seems as though it's parsed the feed incorrectly in your case |
| [09:41:02] | stuartm: | 136 is the episode number |
| [09:41:15] | dekarl: | hmm, I'm not seeing the last part (turning the episode number into a subtitle) in mythtv's code. that's in nonametv's code :/ |
| [09:41:24] | stuartm: | paul-h: not our parsing, the xmltv grabber, which version are you running? |
| [09:42:00] | stuartm: | dekarl: we don't put the number in the subtitle in MythTV |
| [09:42:12] | stuartm: | it gets put in the episode column |
| [09:42:13] | dekarl: | stuartm -^ yes :) |
| [09:42:39] | paul-h: | looks like 0.5.57 |
| [09:43:36] | stuartm: | 0.5.63 here |
| [09:44:27] | stuartm: | might try installing the latest from xmltv.org |
| [09:45:21] | paul-h: | It is xmltv this is what I get for that program in the xml http://pastebin.com/UyU4fuEZ |
| [09:45:22] | stuartm: | although the feed format hasn't changed in ten years, so I've no idea why any grabber version would be messing up |
| [09:46:29] | paul-h: | Getting lots of these when running the grabber 'Use of uninitialized value $episode in uc at /usr/bin/tv_grab_uk_rt line 3025.' |
| [09:46:33] | dekarl: | stuartm, the upstream data "fixup potential" has "evolved"... leading to some fixes in Nick's code in the last four years (hint move to new content pipeline) |
| [09:46:41] | stuartm: | odd that it would mess up only the title, if it was shifting the episode number into the title field you'd expect everything else to be shifted |
| [09:48:57] | joki (joki!~joki@p54861371.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds) | |
| [09:50:13] | paul-h: | According to Gentoo 0.5.57 is the latest available |
| [09:50:14] | dekarl: | might be missing this or similar fixes http://xmltv.cvs.sourceforge.net/viewvc/xmltv . . . amp;r2=1.360 |
| [09:50:16] | stuartm: | dekarl: the need to get a personal key for the atlas feed is a pain |
| [09:50:39] | dekarl: | nobody cared enough to write an updated xmltv export ;) |
| [09:50:42] | dekarl: | gtg |
| [09:51:18] | stuartm: | I need to compare the direct feed against the atlas feed, not going to switch as long as there is information missing from the atlas feed (which was the case last time I checked) |
| [09:52:25] | stuartm: | paul-h: 0.5.65 is the latest from xmltv.org, so Gentoo is quite a bit behind |
| [09:54:46] | dekarl1 (dekarl1!~dekarl@p4FCEE448.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:54:50] | paul-h: | There is an overlay with xmltv-0.5.63.2 I'll try that |
| [09:54:50] | jya1 (jya1!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has quit (Read error: Connection reset by peer) | |
| [09:55:13] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [09:55:30] | stuartm: | wow, 5.57 is really, really old – Apr 2010 |
| [09:55:56] | stuartm: | think someone at Gentoo needs a prodding |
| [09:56:09] | joki (joki!~joki@p54861597.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:57:23] | dekarl (dekarl!~dekarl@p4FCEE32E.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [10:09:48] | paul-h: | stuartm: the funny things is 0.5.57 is considered unstable by gentoo most people who use stable will get 0.55.0 which I would guess is really ancient |
| [10:11:22] | paul-h: | Updating to 0.5.63 looks to have fixed it |
| [10:12:28] | paul-h: | Now what's the best way to reload the program data in the DB to get the fixed version? |
| [10:14:42] | stuartm: | re-running mfdb will update any programs with mis-matching times/title/subtitle/description but if you want to be sure to update everything then DELETE FROM program WHERE starttime > NOW(); |
| [10:15:23] | stuartm: | you could use TRUNCATE but then you lose the historical data for the last two weeks, and personally I find that occasionally useful |
| [10:25:37] | paul-h: | thanks re-running mfdb seems to have updated the titles |
| [10:55:10] | paul-h: | Do we know if playback of encrypted ISOs via a storage group is supposed to work? |
| [10:59:00] | paul-h: | stuartm: I thought you committed a patch to do that but maybe it only works for VIDEO_TS directories not ISOs? |
| [11:01:34] | stuartm: | I thought it worked for ISOs, but I was never able to test personally so I relied on feedback from others |
| [11:04:05] | paul-h: | peper03: Do you know if it works? |
| [11:04:44] | stuartm: | I don't see why it shouldn't work for one and not the other |
| [11:08:52] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:19:29] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:20:04] | jmusits_ (jmusits_!~jmusits@cpe-67-246-61-237.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [11:59:36] | paul-h: | stuartm: I think some of your recent changes have broken the channel editor in the webfrontend. It's now not showing any channels at all |
| [12:01:38] | paul-h: | I was just looking at what broke the sorting by channel number so updated to make sure it hadn't already been fixed but now get no channels at all |
| [12:05:07] | paul-h: | Don't know if it's just me but I find really annoying when you refresh the page you get always get dumped back to the last 10 recordings page :( |
| [12:08:06] | paul-h: | Also I don't think you can bookmark a page to jump straight to that page. So you can't bookmark the 'Program Guide' and jump straight to that page within the webfrontend for example |
| [12:09:40] | paul-h: | And we both know that should be 'Programme Guide' :) |
| [12:34:54] | stuartm: | paul-h: I was expecting that might happen, will take a look |
| [12:35:32] | stuartm: | paul-h: I'll be fixing that behaviour, the way we load pages atm is a bit, er, wrong |
| [12:36:55] | stuartm: | I need to add support to the server for inclusions first |
| [13:30:29] | stuartm: | paul-h: I'll add correct channum sorting |
| [14:14:30] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [14:31:27] | peper03: | paul-h: To be honest, I've never tried it. If I remember correctly, it doesn't affect combined systems (which is all I've got), and I'm pretty sure whatever ISOs I have are already unencrypted. VIDEO_TS directories are already unencrypted, though. It'll only help with ISOs. |
| [14:32:42] | peper03: | Our DVD navigation and playback code is oblivious to whether the source data was encrypted or not. |
| [14:40:22] | stuartm: | VIDEO_TS directories copied directly from the disc won't be decrypted? |
| [14:48:40] | peper03: | stuartm: It's been a long time since I tried that but the CSS encryption should stop you copying the directory at all. The last time I remember trying it, I found you could sometimes get the first .IFO file but copying would fail on the first VOB. |
| [14:50:03] | peper03: | CSS encrypts at the sector level, if I remember correctly. |
| [14:59:37] | stuartm: | really? Never knew that |
| [15:00:55] | stuartm: | just thought that I may be able to test ISOs on my production frontend, but I'll need to update the laptop first so it probably won't be today |
| [15:11:59] | wagnerrp: | why do people keep wanting to use mythtv as a video capture application?> |
| [15:13:07] | peper03: | stuartm: You can get an encrypted ISO with 'dd'. If everything's local and libdvdcss is installed, everything works fine. It doesn't matter whether you're reading from an image or directly from a drive. |
| [15:13:42] | wagnerrp: | peper03: that's not always true |
| [15:13:58] | peper03: | I never really looked at the patch to support remote encrypted images in detail but I think it just fed it through libdvdcss on the backend. |
| [15:14:04] | stuartm: | peper03: yeah I know, but to properly test the remote playback via storage groups I really need to be remote |
| [15:14:05] | wagnerrp: | on some intentionally damaged discs, dd will stall trying to exhaustively recover damaged sectors |
| [15:14:50] | stuartm: | iirc I did do a local test by forcing the backend to stream instead of reading the local file, but that's not a foolproof method |
| [15:15:21] | stuartm: | peper03: that's all it does, it decrypts the data before sending it on to the frontend for playback |
| [15:15:32] | stuartm: | well, that's what it should be doing |
| [15:15:51] | peper03: | wagnerrp: Yes, you're right. I wasn't thinking of those. They mess up the internal sector table (or however it's stored) so that non-existant sectors are referenced, or the same physical sector is referenced multiple times, and other nastiness. |
| [15:16:10] | stuartm: | paul-h: can I assume from what you were saying earlier that remote streaming of encrypted ISOs isn't work for you? |
| [15:16:17] | laga (laga!~laga@h1626373.stratoserver.net) has quit (*.net *.split) | |
| [15:16:17] | clever (clever!~clever@nwcsnbsc00w-142163138075.dhcp-dynamic.FibreOp.nb.bellaliant.net) has quit (*.net *.split) | |
| [15:16:24] | laga (laga!~laga@h1626373.stratoserver.net) has joined #mythtv | |
| [15:16:34] | clever (clever!~clever@nwcsnbsc00w-142163138075.dhcp-dynamic.FibreOp.nb.bellaliant.net) has joined #mythtv | |
| [15:18:11] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [15:18:11] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:18:11] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [15:19:55] | toeb (toeb!~toeb@HSI-KBW-37-49-118-13.hsi14.kabel-badenwuerttemberg.de) has quit (Quit: leaving) | |
| [15:22:23] | peper03: | stuartm: Sorry, you said 'production frontend'. I assumed you meant they would be local to the frontend. Creating an image from a 'standard' DVD (i.e. no Disney/Pixar type disc with additional copy protection) should work fine, I assume. |
| [15:23:32] | stuartm: | peper03: meant my production system, not specifically my production frontend alone |
| [15:25:23] | stuartm: | was thinking about the fact that I have a laptop which has in the past had the frontend installed and configured to use my production backend, hasn't actually been used in a while and I think it's still running 0.26 so I'll need to update the packages first |
| [15:31:15] | peper03: | I think the only thing I could do would be to run a 0.28 frontend on my production box and point it at my dev backend (and hope no configuration stuff gets screwed up on the production box!) |
| [15:32:34] | peper03: | Or maybe try the frontend in a VM? Not sure how much pain that would be... |
| [15:33:31] | stuartm: | paul-h: so I've fixed the sorting of Channels as they come from the Services API, but the channel editor is then messing that up by applying it's own broken sorting method to the results |
| [15:34:48] | stuartm: | for a typical UK setup they will probably appear correct though, it's only a problem if you're using channel numbers in the format 1.3 etc |
| [15:35:12] | paul-h: | stuartm: I've not looked at what's happening in detail but playback of many DVD's does seem to be broken after switch to use storage groups only |
| [15:35:27] | paul-h: | The sorting can't be any worse than it was |
| [15:39:01] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [15:41:38] | paul-h: | stuartm: that looks a lot better the sorting wasn't working at all for the channel number column |
| [15:42:37] | paul-h: | Doesn't look like the XMLTVID column is being populated now though |
| [15:43:19] | stuartm: | paul-h: just pushed a fix for that |
| [15:56:49] | stuartm: | we could use some unit testing of the services API, but it can't be done using the existing test harness as it's all higher level than that – we need to pull information from a test database full of specially crafted entries |
| [15:58:56] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has quit (Remote host closed the connection) | |
| [15:59:56] | paul-h: | stuartm: Still not seeing the xmltvid's |
| [16:01:32] | stuartm: | paul-h: try forcing the browser to reload the page, failing that clear the browser cache and restart it |
| [16:01:48] | stuartm: | some browsers are very aggressive in their caching of js/css |
| [16:02:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [16:03:47] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [16:16:59] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Quit: Leaving) | |
| [16:37:27] | stichnot: | jya: iirc, some of the myth proto commands are matched using a prefix test, so that would have to be fixed before using a hash table approach (but I could be misremembering) |
| [16:38:00] | stichnot: | I know that's the case for some of the actions during playback, though those aren't myth proto commands |
| [16:46:26] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.3) | |
| [16:47:34] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:05:58] | stichnot: | jya: should https://github.com/MythTV/mythtv/commit/e63ca . . . 837a0040283c be a 0.27 candidate, given that it has a new translation string? |
| [17:59:56] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [18:18:17] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [19:17:29] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds) | |
| [19:24:43] | stuartm: | stumbled across a reference in some QT documentation to the fact that setting 'ForwardOnly' for queries can significantly speed up iterating over query results and uses less memory, but we're only using it in one place – some checks suggest we're never iterating/seeking backwards in result sets so I'm thinking the easiest way to benefit is to always enable it in MSqlQuery::prepare() – thoughts? |
| [19:27:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds) | |
| [19:33:01] | kormoc: | I don't believe mysql supports forward only cursors on the server side |
| [19:33:49] | stuartm: | well this is what I was trying to find out, but I've had no luck so far, but I did find a number of people using the option with mysql databases |
| [19:34:01] | stuartm: | either way, it couldn't do any harm |
| [19:34:38] | kormoc: | ahh, so I'm slightly wrong, https://dev.mysql.com/doc/refman/5.0/en/cursor-restrictions.html |
| [19:34:42] | kormoc: | "Cursors are nonscrollable" |
| [19:34:49] | kormoc: | so they're just forward only by default |
| [19:36:03] | kormoc: | yeah, I wonder if in the QT code it moves from client side cursors to server side cursors, which might have a performance impact |
| [19:36:08] | stuartm: | ah, so the driver would have to perform the caching to support reverse iteration |
| [19:36:16] | kormoc: | yeah |
| [19:36:24] | stuartm: | so there should be a benefit |
| [19:36:32] | kormoc: | seems like it |
| [19:37:13] | stuartm: | since the QT docs make no mention of previous() etc being unavailable with mysql they must be supporting it client side at some cost |
| [19:37:59] | kormoc: | Moving to server side cursors also has the benefit that the data transfer amount might be decreased if the whole result set isn't iterated over |
| [19:38:03] | stuartm: | ok, well I've posted to the -developer list to get more opinions on making this a global change instead of individually updating dozens (hundreds) of queries |
| [19:38:56] | stuartm: | the benefits will be limited on small result sets, but if we still figure it's worth including those then that hundreds figure comes into play |
| [19:40:56] | kormoc: | you might see negative impact if people have their mysql server not local and potentially adding a extra round trip per row requested |
| [19:51:20] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [19:51:30] | stuartm: | gigem: might be interesting to see the results on the scheduler since that is at least one series of queries which are already benchmarked |
| [20:05:59] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:16:42] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [20:16:42] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [20:16:42] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [20:17:30] | stichnot: | stuartm: Another thing practical to measure is mythfrontend startup time. |
| [20:22:37] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:23:26] | lomion0815 (lomion0815!~markus@212-88-1-189.adsl.highway.telekom.at) has quit (Remote host closed the connection) | |
| [20:27:38] | stuarta: | evening all |
| [20:29:50] | Weaselweb (Weaselweb!~quassel@77-64-221-251.dynamic.primacom.net) has quit (Remote host closed the connection) | |
| [20:35:13] | stuartm: | stichnot: maybe, but there are not big results sets involved when starting the frontend so I'd expect the impact to be small, the scheduler, livetv, the search list screens and pbb though all involve larger sets of data |
| [20:35:22] | stuartm: | stuarta: good evening |
| [20:37:01] | stuarta: | you've been busy i see :) |
| [20:37:59] | stuartm: | fwiw, I've enabled it for ProgramInfo::LoadFromProgram() which is used in the guide and the search list screens among others, it would be entirely subjective but if any of those seem to load faster in master ... |
| [20:38:40] | stuarta: | stuartm: does it help for the guide in the backend webserver too? |
| [20:38:53] | stuartm: | stuarta: yes |
| [20:38:56] | stuarta: | :) |
| [20:39:46] | stuartm: | although there since I've had to add a second query to determine the total number of available records that will offset some, if not all of any improvement |
| [20:40:32] | stuartm: | but at least for the guide we can now think about staged loading, which will speed up the initial load ... so in the end we'll benefit there |
| [20:40:53] | stuarta: | kinda ajax'y? |
| [20:42:14] | stuartm: | yeah, we're already using it for the upcoming recordings, recordings and rec rules pages, it loads more as you scroll down, or can alternatively just keep loading the page asynchronously in chunks |
| [20:44:05] | stuartm: | for the guide the latter makes more sense since users may be interested in a channel mid-way or near the bottom of the guide, but with upcoming recordings they are more often interested in the next few hours/days and not what is happening in two weeks |
| [21:03:12] | gigem: | stuartm: Send me a patch and I'll try it. skd8ner would be even better. His schedule time always seem to be much longer than everyone else'. |
| [21:20:01] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [21:23:57] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [21:33:41] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [21:57:47] | paul-h: | stuartm: the problem with the missing xmltvids is because you need to also add ?Details=1 to reloadChannelGrid() in channeleditor.js otherwise the xmltvids are never updated |
| [21:58:47] | paul-h: | At least I think that's the problem I'm completely out of my depth with this stuff |
| [22:03:47] | paul-h: | Incidentally I tried the webfrontend on my android tablet and the menu doesn't auto hide which makes it pretty useless because you can't get to the stuff below it |
| [22:05:21] | stuartm: | paul-h: yeah I know, need to fix that :) |
| [22:05:56] | stuartm: | very simple fix, just keep putting it off to work on other things |
| [22:09:33] | dekarl1 (dekarl1!~dekarl@p4FCEE448.dip0.t-ipconnect.de) has quit (Remote host closed the connection) | |
| [22:10:21] | stuartm: | paul-h: I've fixed that channel editor url here, will push tomorrow though because I've got another change in my tree that needs further testing before it's pushed |
| [22:49:45] | paul-h (paul-h!~Paul@2.221.230.194) has quit (Quit: Konversation terminated!) | |
| [23:05:54] | stuartm: | gigem: well it may make a difference on some systems, especially memory constrained systems, but the change has no measurable impact on scheduler times here |
| [23:07:02] | stuartm: | which is not to say that it isn't helping elsewhere, especially with something like the guide grid which is loading and iterating over thousands of programmes |
| [23:11:52] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds) | |
| [23:13:09] | stuartm: | guess I may have started to imagine it would be a magic bullet, and the reality is a little disappointing |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.