| Monday, June 16th, 2014, 00:04 UTC | ||
| [00:04:08] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [00:50:53] | jya: | gigem: stuartm anything you know could be related to this issue? http://www.mythtv.org/pipermail/mythtv-users/ . . . /364879.html |
| [00:51:02] | jya: | I can’t think of any changes in the scheduler... |
| [01:09:02] | acle (acle!~tb@or-71-53-74-177.dhcp.embarqhsd.net) has quit (Ping timeout: 252 seconds) | |
| [01:20:12] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [01:34:36] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:11:36] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:13:40] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [02:13:40] | peper03_ is now known as peper03 | |
| [02:35:02] | arescorpio (arescorpio!~arescorpi@162-243-16-190.fibertel.com.ar) has joined #mythtv | |
| [03:11:58] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 240 seconds) | |
| [03:13:31] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:30:31] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) | |
| [03:34:51] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [03:59:24] | gigem: | jya: It's been a very busy weekend, so I'm just seeing this now and too late to do anything. It's likely that all of the programs have the same seriesid, making MythTV consider them all to be the same program even though the titles differ. That's something stuartm requested a year or two ago. We have a 'This series' recording rule filter to make sure other series with the same title get excluded, but we |
| [03:59:26] | gigem: | don't currently have anything except full, custom rules to exclude programs from the same series with different titles. |
| [04:00:10] | jya: | gigem: but he/she mentioned a recent different behaviour. I’m not aware of any recent change to fixes/0.27 there |
| [05:37:40] | arescorpio (arescorpio!~arescorpi@162-243-16-190.fibertel.com.ar) has quit (Excess Flood) | |
| [05:37:41] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [06:10:11] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:10:11] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [06:19:49] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [07:42:55] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 272 seconds) | |
| [07:56:08] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [08:05:23] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [08:17:19] | stuartm: | jya: a change in the guide data would do it |
| [08:18:38] | jya: | so nothing to do with us… |
| [08:22:32] | stuartm: | IMHO yes, though some might disagree with our (my) assessment that programs with the same series ID are the same series, ironically it was to deal with examples almost identical to that one where the programmes don't stick to a common title but are related e.g. Film 2010/2011/2012 (and many other examples which include a year), or "Newsnight", "Newsnight: Extended" |
| [08:37:56] | dekarl1 (dekarl1!~dekarl@p4FE85AF0.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:39:19] | dekarl (dekarl!~dekarl@p4FE8544D.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [08:58:34] | jya: | jpabq: I’ve attempted to remove all use of mythdownloadmanager and instead use MythSingleDownload |
| [08:58:47] | jya: | it always returns an array with 0 bytes here |
| [09:00:15] | stuarta: | morning all |
| [09:01:31] | jya: | evening! |
| [09:05:02] | stuarta: | how is it going today? |
| [09:06:56] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has joined #mythtv | |
| [09:07:37] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has quit (Client Quit) | |
| [09:07:52] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has joined #mythtv | |
| [09:18:01] | stuartm: | gigem: with the 'This series' filter we could perhaps drop the behaviour from the scheduler itself, but default to toggling on the 'This series' filter for 'Record All' rules? That way most people get the desired behaviour by default, but if it causes a problem for some series, like Angela's example, it can be easily disabled |
| [10:28:28] | jya: | jpabq: it’s been a while since I’ve looked at the HLS recorder… It just doesn’t work for me anymore.. not reliably. |
| [10:28:45] | jya: | it does start liveTV very quickly, much quicker than it ever did. |
| [10:28:57] | jya: | but it usually stops and hang the frontend after a couple of minute |
| [10:29:22] | jya: | in the backend log I see that it has hit an error or timeout once, and it pretty much never recover from that |
| [10:30:04] | jya: | it appears that recording itself will work, because the backend will start saving data after a while |
| [10:30:11] | jya: | but it just doesn’t play nicely with liveTV |
| [10:30:20] | jya: | are you using liveTV at all? |
| [10:30:58] | jya: | I thought i would try with 0.27, but I see that youve removed the previous HLS recorder there too, and it behaves just as poorly. |
| [10:31:34] | jya: | I’ve reverted the changes and implemented what we talked about in private mail (eg. the data is dropped completely as you read it, so there’s no “leak†at all) |
| [10:32:16] | jya: | liveTV does take much longer to start I have to admit. I’ve greatly improved that but still it doesn’t start as quickly |
| [10:32:26] | jya: | so I’m a tad puzzled on the way forward… |
| [10:32:51] | jya: | Continue working on the old HLS RingBuffer so it works more like the new one for recordings. |
| [10:32:57] | jya: | and drop the new one |
| [10:33:25] | jya: | or drop the old one completely, and check why it just fails |
| [10:33:44] | jya: | I’m not sure how I could adapt the new HLS so it works as a ringbuffer. |
| [10:34:28] | jya: | The HLSReader::Reader will usually returns 0 bytes several times in a raw. The RingBuffer class would drop playback after only 5 attempts as it will consider we’ve reached the end of the stream |
| [10:34:40] | jya: | so puzzling, puzzling… |
| [10:36:18] | jya: | Personally, I feel it would probably easier to fix the old HLS ringbuffer so it addresses your concerns of memory usage |
| [10:37:14] | jya: | Right now, in live TV with the new one, I can’t even change channel … it appears to tune to the new channel, but it continues playing with the old one. You can see that the HLSRead received an interrupted order, but it continues regardless |
| [10:37:19] | jya: | well, that’s all for me on this |
| [11:20:22] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:59:06] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 255 seconds) | |
| [12:11:46] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [12:14:51] | dekarl1 is now known as dekarl | |
| [12:52:35] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [12:55:21] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has joined #mythtv | |
| [12:55:48] | jheizer (jheizer!~jheizer@73.51.93.177) has quit (Read error: Connection reset by peer) | |
| [13:17:03] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [13:19:25] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [13:19:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [13:19:26] | stichnot (stichnot!~stichnot@adsl-68-125-54-22.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [13:40:53] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 252 seconds) | |
| [14:27:17] | acle (acle!~tb@seattle-nat.cray.com) has joined #mythtv | |
| [14:28:00] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [14:28:15] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 272 seconds) | |
| [14:41:03] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [14:52:41] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [14:52:45] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [14:57:29] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [15:04:38] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [15:12:07] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Remote host closed the connection) | |
| [15:12:08] | acle (acle!~tb@seattle-nat.cray.com) has quit (Read error: Connection reset by peer) | |
| [15:27:34] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [15:42:07] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [15:44:33] | stichnot (stichnot!~stichnot@207.198.105.22) has joined #mythtv | |
| [15:44:33] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:44:33] | stichnot (stichnot!~stichnot@207.198.105.22) has quit (Changing host) | |
| [16:08:21] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [16:10:39] | stuarta: | no answers to my support case re vm's @osuosl |
| [16:10:59] | stuartm: | dblain: have you any thoughts on how the error handling would be done without using throw()? The obvious 'simple' approach is a class member or global error flag/struct that gets populated with the error message and then we return an empty/null object – if the error flag is set we ignore the return value, populate an 'error' object which then gets serialised and sent back to the user |
| [16:11:24] | ** stuarta becomes sad ** | |
| [16:12:42] | stuartm: | stuarta: this page does say to allow them a few days to respond to requests – http://osuosl.org/services/hosting |
| [16:14:35] | stuartm: | have you asked outright in #osuosl? Could be the ticket was triaged to someone who hasn't noticed it, or is out the office ... never know :) |
| [16:14:53] | stuarta: | not yet |
| [16:15:18] | stuarta: | busy few days |
| [16:15:50] | stuarta: | i'll poke on wed |
| [16:26:59] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [16:27:49] | caelor: | interesting responsiveness report (not so much a bug) – I have a SBE that also hosts a frontend. Main recordings storage is NFS mounted. Playing an in progress recording fron that SBE, on the frontend on that host, with -O AlwaysStreamFiles occasionally stutters, whereas it's smooth when not forced to stream (and falling back on reading from NFS) |
| [16:28:25] | caelor: | the stutter seems to coincide with a position map resync (but most resyncs are fine) |
| [16:29:50] | caelor: | is it possible the MBE is blocked from feeding the streamed data by something? I know jya has done a lot of great work in this area making LiveTV better |
| [16:30:28] | caelor: | this is running 0.27.1 |
| [16:30:43] | caelor: | (I'm not in a position to compare to master at present) |
| [16:31:23] | sphery: | MySQL data on a filesystem with barriers on the mbe host, causing I/O wait, which prevents mythbackend process from reading the recording file? |
| [16:31:40] | stuarta: | protocol is crap? |
| [16:35:44] | caelor: | mysql is on a different host to mbe and sbe, but underlying FS _does_ have barriers, which up to now haven't been a problem, but there's no I/O wait on the MBE due to mysql |
| [16:36:32] | caelor: | protocol is a possibility, but if so that might suggest alignment with the position map recalculation, which I'd expect the user experience to be shared with LiveTV, which we know is significantly improved |
| [16:37:03] | caelor: | I wouldn't have mentioned it, except for the discussion a little while back about switching to always stream by default |
| [16:37:37] | stichnot (stichnot!stichnot@nat/google/x-iolncchqklqyjhxb) has joined #mythtv | |
| [16:37:37] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:37:37] | stichnot (stichnot!stichnot@nat/google/x-iolncchqklqyjhxb) has quit (Changing host) | |
| [16:41:51] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has joined #mythtv | |
| [16:44:48] | natanojl: | As far as I know it's the recorder thread that performs the database update and handles the get framecount query (i.e. it's done on the BE where the recording is being made). That is why the optimization in #12016 helped a lot for some people |
| [16:44:48] | ** MythLogBot http://code.mythtv.org/trac/ticket/12016 ** | |
| [16:45:40] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has quit (Quit: Lost terminal) | |
| [16:57:19] | caelor: | more likely to be barriers then |
| [16:57:52] | caelor: | interesting that it doesn't seem to affect NFS file access to the recording – maybe more caching |
| [16:58:38] | stuarta: | that's why i suspect the protocol rather than barriers |
| [16:59:13] | stuarta: | barriers are only going to affect the fdatasync() and related calls, and shouldn't be blocking for any significant length of time on a myth box |
| [17:00:40] | stuartm: | not the protocol perhaps but the level of buffering when streaming |
| [17:01:14] | caelor: | fair enough. disabling forced streaming (which was only enabled to start playback marginally quicker, and also test the streaming codepath in case streaming became default) works for now. In a couple of weeks when family leaves I should be better able to reconfigure and diagnose |
| [17:01:34] | stuarta: | perhaps, i get considerably different data transfer performance via myth protocol or via nfs (using the playback data screen to verify) |
| [17:02:01] | stuarta: | something like ~70Mb/s via myth proto, hitting 1Gb/s via NFS |
| [17:02:06] | stuartm: | the protocol itself is as light as it gets, lighter even than json etc, but if we're not buffering enough or not requesting new data before the buffer is exhausted ... |
| [17:02:45] | caelor: | yes. The suggestion that the upnp server might be suitable for streaming to the frontend was an interesting one |
| [17:03:27] | caelor: | leaving the myth protocol for command & control – might be an interim step ahead of the frontend using the services API more |
| [17:03:29] | stuartm: | right, but it's not going to do anything differently to the internal protocol |
| [17:04:04] | stuarta: | tbh, i dunno why we don't just use some form of iptv |
| [17:04:27] | stuarta: | the data is already digital, the protcol then specifies pretty much everything else we could want |
| [17:04:39] | caelor: | true, I suspect NFS is quite aggresively buffering – especially in this case where the SBE is on the same host, so it's likely the frontend is dipping into cache rather than bouncing it off the MBE |
| [17:05:31] | stuarta: | the frontend in theory should just read it off disk, as the isLocal() checks should evaluate to true, and therefore skip streaming |
| [17:05:37] | caelor: | I suspect the main reason is constraints on (capable) developer time and supporting such a fundamental change |
| [17:06:11] | stuartm: | stuarta: it does |
| [17:06:39] | stuarta: | which means nfs caching is irrelevant |
| [17:06:39] | stuartm: | unless you force it to always stream, as caelor was doing |
| [17:07:04] | stuarta: | so nfs caching is still irrelevant |
| [17:07:40] | stuartm: | oh, for NFS, well of course it will use nfs if you point it to an NFS mounted directory, even if that directory is available locally via another path |
| [17:08:03] | caelor: | it was irrelevant when using forced streaming (and getting the stutter), but not when allowing the isLocal, which will then locate a "local" file on the NFS mounted fs |
| [17:08:33] | stuarta: | back later, time to go talk to the kids |
| [17:08:33] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) | |
| [17:09:54] | caelor: | I'd love to contribute more, but lack cpp experience (and at present running 0.27 rather than master), so tend to try and aim more for "capable tester"... |
| [17:11:02] | caelor: | cheers for the input guys, and don't worry too much about it – I'm aware the config I was running was a "here be dragons" |
| [17:14:08] | kormoc: | stuarta, if you don't get any answers from OSU, let me know. I can poke Lance directly |
| [17:14:32] | kormoc: | stuartm, So I can reproduce that crash on demand, if you have any debugging things you would like me to do |
| [17:17:57] | stuartm: | kormoc: a bt might just confirm that it's the throw() and exactly which one it is |
| [17:18:17] | kormoc: | the trace I attached wasn't complete? |
| [17:20:09] | stuartm: | kormoc: truthfully I missed the fact that there was a bt attached, but since you ask 'bt full' would include a little more info |
| [17:21:30] | kormoc: | gotcha |
| [17:27:45] | stuartm: | dblain: is QScriptEngine thread safe? kormoc's backtrace would suggest not ... |
| [17:40:37] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [17:45:43] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv | |
| [17:46:56] | stuartm: | kormoc: fwiw, seems like whatever the underlying cause of the segfault, we need to stop the WebFrontend from sending multiple identical requests for that stuff, I'm guessing that either there's a double click type situation or your browser is generating two javascript events for each single click |
| [17:49:01] | kormoc: | I'm actually scheduling multiple, as it takes a little while |
| [17:49:39] | stuartm: | ah ok, very quick here, so that didn't even occur to me – that's fine then |
| [17:50:16] | stuartm: | gigem: probably wouldn't hurt to have the Services API's AddRecordSchedule check that we not trying to create an identical recording schedule to one that already exists |
| [17:50:56] | kormoc: | well, a little while as in under 5 seconds, long enough for me to see another show and click the record all button :) |
| [17:53:02] | stuartm: | tbh, it shouldn't even take that, all it does is insert a record in the db and then trigger an asynchronous reschedule, it doesn't wait for the reschedule to occur |
| [17:54:41] | kormoc: | it seems to |
| [18:05:33] | kormoc: | stuartm, could it be while it's updating the recording list? I hit record, it schedules and then refreshes the list, that's the part that's likely getting stepped on? |
| [18:08:35] | stuartm: | it could be ... that seems more likely, the BT doesn't reveal what the second request was for so again I assumed, probably incorrectly :) |
| [18:12:04] | stuartm: | so we definitely need to either a) serialise access to QScriptEngine (easiest, marginal impact on performance) b) spin up more than one instance of QSE and share then between threads (maybe a little more work, benefit is slight and possibility of race conditions with stuff like Watch/Delete, Add/Remove) |
| [18:13:30] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 255 seconds) | |
| [18:14:57] | stuartm: | I say there's a chance of races with b), but in all the years we've had mythweb no-one has every complained of that happening, it would be very rare for a single browser, chances go up if we have multiple users all triggering these actions at once from different browsers |
| [18:15:07] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [18:15:44] | kormoc: | I always hit it with multiple concurrent requests with mythweb |
| [18:16:31] | kormoc: | and browsers will automatically, the channel icons for example could be hit multiple times in a single browser instance |
| [18:19:13] | stuartm: | kormoc: I mean stuff like one user deleting a recording just as another hits 'watch recording', that won't cause a fatal error, but obviously it will trigger some error or an unexpected result |
| [18:19:49] | stuartm: | not the browser requesting stuff like icons or other stuff which isn't directly going to lead to a conflict |
| [18:19:58] | andreaz (andreaz!~andre_000@p5DCA3B0D.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:20:17] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Read error: Connection reset by peer) | |
| [18:20:19] | kormoc: | fair |
| [18:21:17] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [18:23:03] | stuartm: | for images we're directly serving them up, it's only where we interact with the Services API via a server side script (javascript in our case, php in mythwebs) that we have to serialise the access |
| [18:23:16] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Read error: Connection reset by peer) | |
| [18:24:02] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [18:24:15] | stuartm: | the old protocol was synchronous, requests were handled in order, so in fact mythweb wouldn't have faced this particular problem – except maybe when operating directly on the database |
| [18:25:34] | kormoc: | mythweb would run with a single connection per apache thread, which would mean it was multiple threads hitting it at once |
| [18:27:54] | stuartm: | right, but the backend would handle each request from a mythweb instance in order, serialised so you could have a thousand instances of mythweb hitting the backend at once, all that would happen is that it would be very slow, Services API doesn't serialise requests, each is handled concurrently and that's a problem if you want to avoid race conditions |
| [18:28:25] | kormoc: | ahh, gotcha |
| [18:28:46] | kormoc: | I never knew that it serialized like that |
| [18:31:24] | stuartm: | in practice, races should be rare because there won't be very many users, however we what seems to be impossible is concurrent access to the same instance of the script engine, so either we need multiple instances or we decide that serialising access to the script engine is a reasonable compromise |
| [18:31:57] | stuartm: | I'm leaning to the latter since it's just a matter of putting some locking/unlocking in the right places |
| [18:33:23] | kormoc: | might as well start with the seralization |
| [18:37:20] | stuartm: | btw, crashing aside, any thoughts on the webfrontend? There are some rough edges, stuff that I want to change (the ajax loading of pages is one since it makes bookmarking impossible) ... |
| [18:46:51] | tgm4883: | Is it expected that master builds are failing last two days? |
| [18:47:05] | tgm4883: | superm1 isn't around and usually looks at these |
| [18:47:31] | stuartm: | tgm4883: there was some 32bit breakage, think it should be fixed |
| [18:47:49] | stuartm: | although very briefly the 32bit builds were fixed and the 64bit builds broke instead |
| [18:47:55] | tgm4883: | stuartm: so the next build should work then? |
| [18:48:58] | stuartm: | tgm4883: it should, all our builders are up and working |
| [18:49:05] | stuartm: | https://code.mythtv.org/buildbot/waterfall |
| [18:49:38] | stuartm: | although we don't have a 32bit ubuntu build |
| [18:49:40] | tgm4883: | sweet, I'll bookmark that so I look at it next time |
| [19:02:04] | kormoc: | stuartm, it's a good start. The ajax stuff doesn't need to go, we can use stuff like https://github.com/cowboy/jquery-hashchange to fix the bookmarkablity/refreshablilty :) |
| [19:04:14] | stuartm: | kormoc: well there is a pull request to sort the bookmarking, we should take a look at that |
| [19:07:23] | stuartm: | but there were other reasons to drop it, the html it produces isn't strictly compliant atm, page specific css needs to be loaded in the header not the body – now I did start working on a fix for that but after a while I questioned the whole logic of a complicated javascript fix just to avoid re-loading the menu each time (it's really not that much js) |
| [19:07:38] | stuartm: | err, not that much html |
| [19:08:20] | stuartm: | I didn't add the ajax loading btw, that was there before as part of the unfinished web setup stuff |
| [19:10:10] | stuartm: | so I'm not particularly wedded to it and I think a script includes or similar feature might be a better approach, so the header/menu/footer is pulled in from a separate file during script compilation |
| [19:11:24] | stuartm: | compiled scripts are cached, so there's no overhead other than a tiny amount of bandwidth (we use gzip compression) and the rendering time in the browser |
| [19:23:03] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has quit (Read error: Connection reset by peer) | |
| [19:23:32] | jheizer_ (jheizer_!~jheizer@73.51.93.177) has joined #mythtv | |
| [19:25:42] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has quit (Quit: No Ping reply in 180 seconds.) | |
| [19:26:23] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has joined #mythtv | |
| [19:26:23] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [19:26:23] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has quit (Changing host) | |
| [19:28:53] | moparisthebest (moparisthebest!~quassel@cpe-74-140-228-202.swo.res.rr.com) has joined #mythtv | |
| [19:29:20] | stuartm: | kormoc: could you try this patch? http://pastebin.com/76g5SVeU |
| [19:36:08] | caelor (caelor!~quassel@cpc12-sotn9-2-0-cust374.15-1.cable.virginm.net) has quit (Remote host closed the connection) | |
| [19:37:49] | len_ (len_!~quassel@65-128-242-24.mpls.qwest.net) has joined #mythtv | |
| [19:38:57] | caelor (caelor!~quassel@cpc12-sotn9-2-0-cust374.15-1.cable.virginm.net) has joined #mythtv | |
| [19:43:21] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit () | |
| [19:44:48] | stuartm: | kormoc: pushed it, couldn't reproduce the issue with it applied, it didn't seem to cause any problems so ... |
| [19:45:36] | stuartm: | also fixed a bug in the guide scroll area, still need to figure out how to remember the scroll position between reloads |
| [19:58:36] | vallor (vallor!~Ponzo@pdpc/supporter/monthlygold/vallor) has joined #mythtv | |
| [19:58:42] | vallor (vallor!~Ponzo@pdpc/supporter/monthlygold/vallor) has left #mythtv ("http://quassel-irc.org - Chat comfortably. Anywhere.") | |
| [20:01:44] | caelor: | an update on earlier (and sorry for the noise) – looks like it was an NFS issue. Started stuttering even on NFS streamed recordings and shortly after the SBE started with TFW warnings. Myth didn't handle it hugely gracefully, but I think it'd be unreasonable to expect it to... |
| [20:02:14] | caelor: | remounting NFS, and restarting MBE and SBE and it seems fixed. |
| [20:03:20] | caelor: | as a thought – the frontend can stream via the myth protocol, but is there milage in slave backends streaming data to be saved into remote storage groups? |
| [20:10:06] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has joined #mythtv | |
| [20:10:06] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [20:10:06] | cesman (cesman!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has quit (Changing host) | |
| [20:12:02] | dekarl: | caelor: what's wrong with storing it to a local filesystem and then rsyncing it over to the main storage in a post recording event script? |
| [20:25:20] | caelor: | dekarl no local storage on the SBE (I've had a run of hdd failures over the last few weeks, and haven't had chance to replenish. Even the SBE boots using ipxe into an iscsi boot) |
| [20:26:15] | caelor: | longer term, yes, a post-recording rsync hook could work around any NFS issues |
| [20:26:27] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds) | |
| [20:35:06] | MythBuild: | build #2085 of master-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2085 blamelist: John Poet <jpoet@mythtv.org > |
| [20:36:08] | MythBuild: | build #1774 of master-ubuntu-12_04-lts-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1774 blamelist: John Poet <jpoet@mythtv.org > |
| [20:41:31] | kormoc: | stuartm, Can I edit the html 'live'? i.e. if I change it from where mythbackend serves it from, will it take affect or will a restart be required? |
| [20:42:28] | zentec (zentec!~zentec@71.82.202.47) has quit (Ping timeout: 264 seconds) | |
| [20:43:33] | stuartm: | kormoc: you can |
| [20:43:48] | kormoc: | snaz |
| [20:44:02] | stuartm: | although we cache the files, changes on disk are detected and it will reload them |
| [20:45:26] | stuartm: | the exception at the moment are the includes, any filter 'included' at the start of a QSP won't be reloaded unless the file it's included into is also touched |
| [20:46:55] | zentec (zentec!~zentec@71.82.202.47) has joined #mythtv | |
| [20:47:17] | stuartm: | i.e. schedule.qsp includes util.qjs – if you edit util.qjs without also updating the modification timestamp on schedule.qsp then the latter will still be using the old version of util.qjs ... hope that makes sense |
| [20:47:56] | kormoc: | Yeah, that does |
| [20:48:02] | kormoc: | I'll try poking at things tonight |
| [20:50:23] | kormoc: | It might be worth trying to re-write everything into angular or similar now, before too much gets written |
| [21:00:16] | stichnot (stichnot!stichnot@nat/google/x-aziyoucpakugekau) has joined #mythtv | |
| [21:00:17] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [21:00:17] | stichnot (stichnot!stichnot@nat/google/x-aziyoucpakugekau) has quit (Changing host) | |
| [21:06:18] | arescorpio (arescorpio!~arescorpi@86-237-16-190.fibertel.com.ar) has joined #mythtv | |
| [21:14:42] | Steve-Goodey (Steve-Goodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:15:36] | SteveGoodey (SteveGoodey!~steve@host86-134-63-27.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:22:16] | stuartm: | kormoc: I've tried to keep heavy lifting to a minimum on the client side, whatever can be offloaded to the server side script or even better the services API the better, for client side stuff we're using a lot of jQuery |
| [21:24:32] | stuartm: | would prefer not to mix in too much stuff, better to keep things simple to maintain – bad enough at the moment that you have to keep the jquery documentation handy, alongside the css, html 5 specs, services API docs etc |
| [21:24:47] | stuartm: | but I'll take a look at Angular |
| [21:25:58] | kormoc: | well, it's more how you would do rich ui stuff, so rather then re-rendering the entire program guide, when a schedule event returns, it just re-draws for you |
| [21:28:03] | stuartm: | sounds interesting, though would need to be reasonably fast, finding that js ain't as fast as advertised on mobiles/tablets |
| [21:28:40] | kormoc: | it's fairly fast. it's a google project and fairly widely used |
| [21:29:47] | stuartm: | in fact, toggling styles/content on the client side = good, having js create html = bad, from a purely maintenance standpoint, don't want to have to edit multiple places to make layout changes |
| [21:30:55] | kormoc: | well, you would create an angular template and the client renders/applies it, it'll still be a singular place |
| [21:30:57] | stuartm: | WebSocket support is pretty much a 'must have' for me, when I find the right moment I'll start working on that, so guide updates etc won't require polling or other similar hacks |
| [21:31:19] | stuartm: | kormoc: client does all the rendering? |
| [21:31:24] | kormoc: | yeah |
| [21:31:28] | stuartm: | hmm |
| [21:32:41] | stuartm: | I might take some convincing :) Seems insane to render the whole page client side instead of server side |
| [21:33:28] | kormoc: | heh, well, the idea is that it's token replacement to take data and re-render the tempalte vs sending the whole template over the wire many times |
| [21:33:52] | kormoc: | token replacement is fairly fast, even on most mobile setups |
| [21:35:21] | stuartm: | well it's just that there is more to rendering something like the guide than simply plugging in values to a template |
| [21:35:31] | stuartm: | but we'll see :) |
| [22:00:08] | MythBuild: | build #1756 of master-ubuntu-current-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1756 blamelist: John Poet <jpoet@mythtv.org > |
| [22:10:19] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) | |
| [22:14:52] | rsiebert (rsiebert!~quassel@e179131087.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds) | |
| [22:34:52] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [22:42:53] | jpabq_ (jpabq_!~quassel@97-123-207-7.albq.qwest.net) has joined #mythtv | |
| [22:43:30] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 255 seconds) | |
| [22:53:36] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 260 seconds) | |
| [22:54:46] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [23:07:03] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [23:07:33] | jpabq_ (jpabq_!~quassel@97-123-207-7.albq.qwest.net) has quit (Ping timeout: 240 seconds) | |
| [23:47:20] | jya: | stuarta: I can very easily saturate the gigabit interface over the myth protocol.. I get better throughput than over NFS |
| [23:49:14] | tris (tris!tristan@2001:1868:a00a::4) has quit (Read error: Connection reset by peer) | |
| [23:52:57] | jya: | jpabq: the new code related to AES encryption should be made conditional on USING_LIBCRYPTO |
| [23:53:02] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:53:14] | jya: | at this stage, it would be easier for you to stop making change on HLS |
| [23:53:28] | jya: | it’s only going to create conflicts and adding pain... |
| [23:55:20] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.