MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (81):

aloril, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, cesman, Chutt, clever, coling, Cougar, darkdrgn2k, dblain, ElmerFudd, fetzerch, foxbuntu, ghoti, Gibby, gigem, gregL, gregL_, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe_____, johanbr, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, kc, kenni, knightr, knightr_, kurre2, kwmonroe, laga_, moparisthebest, mrand, MythBuild_, MythLogBot, neufeld, Nothing4You, nyloc, peper03, pkendall, poptix, purserj, quovodis, rhpot1991, robink, rsiebert, Seeker`, seld, Sharky112065, skd5aner, SmallR2002, sphery, sraue, stichnot, straximus, stuarta, superm1, taylorr, tgm4883, toeb, tonsofpcs, tris, twiggy2cents, wagnerrp, wilmoore-misc, wolfgang, XDS2010_, xris, _charly_
Tuesday, September 17th, 2013, 00:12 UTC
[00:12:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[00:17:13] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:18:18] stichnot: jya: Interesting. I don't have a source of resolution-changing recordings except for one or two samples from gigem.
[00:19:45] jya: not saying that's the issue here… but I know with HLS recording that can be a problem.. because change of resolution in a HLS recording is common should bandwidth auto-adaptation kicks in
[00:21:05] jya: I tried to implement the required change quickly, but it was failing miserably, and it requires to do things differently.. we had added to our own mpegts demuxer methods to detect changes and callback.. all of those aren't necessary with recent ffmpeg.. hopefully I get on to that for 0.28
[00:43:17] wagnerrp_ (wagnerrp_!6b124e7a@gateway/web/freenode/ip.107.18.78.122) has joined #mythtv
[00:48:20] nyloc (nyloc!~quassel@p3EE2DB45.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[00:51:26] nyloc (nyloc!~quassel@p3EE2DB45.dip0.t-ipconnect.de) has joined #mythtv
[00:59:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[01:02:57] aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has left #mythtv ()
[01:25:16] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[01:34:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:36:46] nyloc (nyloc!~quassel@p3EE2DB45.dip0.t-ipconnect.de) has quit (Ping timeout: 268 seconds)
[01:38:33] nyloc (nyloc!~quassel@p3EE2DB45.dip0.t-ipconnect.de) has joined #mythtv
[02:00:37] dgeary2 (dgeary2!~debian@pa49-187-94-0.pa.nsw.optusnet.com.au) has joined #mythtv
[02:08:41] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:14:35] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Remote host closed the connection)
[02:14:44] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:19:49] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 248 seconds)
[02:21:10] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:23:19] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out)
[02:26:52] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 264 seconds)
[02:27:23] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:27:47] dekarl (dekarl!~dekarl@p4FE854BC.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)
[02:28:10] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:28:29] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:32:31] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 245 seconds)
[02:33:36] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:34:48] dekarl (dekarl!~dekarl@p4FE85B6B.dip0.t-ipconnect.de) has joined #mythtv
[02:37:30] joki (joki!~joki@p548612FC.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[02:38:29] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 248 seconds)
[02:39:49] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:43:28] joki (joki!~joki@p54861329.dip0.t-ipconnect.de) has joined #mythtv
[02:45:00] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 245 seconds)
[02:46:01] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:47:51] Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer)
[02:49:45] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv
[02:51:23] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 268 seconds)
[02:52:29] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[02:57:08] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 240 seconds)
[02:58:46] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[03:01:14] _nyloc_ (_nyloc_!~quassel@p57B4F3F6.dip0.t-ipconnect.de) has joined #mythtv
[03:01:52] nyloc (nyloc!~quassel@p3EE2DB45.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[03:21:49] dgeary2 (dgeary2!~debian@pa49-187-94-0.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat)
[03:46:40] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[03:47:28] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:20:20] dgeary2 (dgeary2!~debian@d110-33-123-54.mas800.nsw.optusnet.com.au) has joined #mythtv
[04:29:51] dgeary2 (dgeary2!~debian@d110-33-123-54.mas800.nsw.optusnet.com.au) has quit (Ping timeout: 240 seconds)
[05:15:45] dekarl (dekarl!~dekarl@p4FE85B6B.dip0.t-ipconnect.de) has quit (Quit: Leaving.)
[05:20:05] dekarl (dekarl!~dekarl@p4FE84A45.dip0.t-ipconnect.de) has joined #mythtv
[05:26:48] dekarl: wagnerrp, its quite possible that both issues are part of the next layer of bugs in mythtranscode's lossless mode (now that ac3 does work again)
[05:27:27] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv
[05:32:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[05:39:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:03:18] MythBuild_ (MythBuild_!~MythBuild@alcor.mythtv.org) has joined #mythtv
[06:04:25] laga_ (laga_!~laga@h1626373.stratoserver.net) has joined #mythtv
[06:05:34] SteveGoodey (SteveGoodey!~steve@host86-162-40-99.range86-162.btcentralplus.com) has joined #mythtv
[06:07:34] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[06:09:06] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (*.net *.split)
[06:09:06] laga (laga!~laga@h1626373.stratoserver.net) has quit (*.net *.split)
[06:09:06] Tobbe5178534 (Tobbe5178534!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (*.net *.split)
[06:09:07] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (*.net *.split)
[06:13:43] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Ping timeout: 264 seconds)
[06:13:43] MythLogBot (MythLogBot!~bot@mythtv/developer/beirdo) has quit (Ping timeout: 264 seconds)
[06:22:17] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[06:23:26] clever (clever!~clever@nwcsnbsc00w-142167021018.dhcp-dynamic.FibreOp.nb.bellaliant.net) has quit (Ping timeout: 240 seconds)
[06:23:55] neufeld`` (neufeld``!~user@69-165-173-139.dsl.teksavvy.com) has quit (Ping timeout: 245 seconds)
[06:24:34] robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds)
[06:24:39] brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 245 seconds)
[06:24:41] robink (robink!~quassel@fatcat.creosotehill.org) has joined #mythtv
[06:24:42] robink (robink!~quassel@fatcat.creosotehill.org) has quit (Changing host)
[06:24:42] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[06:25:40] clever (clever!~clever@nwcsnbsc00w-142167021018.dhcp-dynamic.FibreOp.nb.bellaliant.net) has joined #mythtv
[06:25:57] brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv
[06:26:31] SteveGoodey (SteveGoodey!~steve@host86-162-40-99.range86-162.btcentralplus.com) has quit (Quit: Konversation terminated!)
[06:27:30] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 245 seconds)
[06:53:08] ghoti is now known as 5EXAAKZCN
[06:53:09] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[06:53:26] ghoti (ghoti!~paul@scratch.it.ca) has quit (Max SendQ exceeded)
[06:54:20] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[07:47:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[08:02:16] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:07:39] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (Ping timeout: 276 seconds)
[08:11:35] stuarta_ is now known as stuarta
[08:11:53] stuarta: morning
[08:26:33] caelor (caelor!~quassel@cpc12-sotn9-2-0-cust374.15-1.cable.virginmedia.com) has joined #mythtv
[08:39:24] stuartm: morning
[08:43:08] caelor: morning stuartm
[08:45:28] Guest43400 (Guest43400!~dblain@mythtv/developer/dblain) has quit (Ping timeout: 264 seconds)
[08:46:51] caelor: I raised #11862 on mythmediaserver. I'll try and hang around in the room to answer any questions.
[08:46:51] ** MythLogBot http://code.mythtv.org/trac/ticket/11862 **
[08:47:05] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[08:48:31] stichnot (stichnot!~stichnot@adsl-68-127-28-20.dsl.pltn13.pacbell.net) has joined #mythtv
[08:48:32] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[08:48:32] stichnot (stichnot!~stichnot@adsl-68-127-28-20.dsl.pltn13.pacbell.net) has quit (Changing host)
[08:48:42] stuarta: we like backtraces
[08:50:32] caelor: I'm guessing it's because mythmediaserver doesn't see wide use, but it's very easy to recreate here
[08:55:45] caelor: hopefully the attached backtrace has enough symbols
[09:00:59] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection)
[09:17:25] nyloc (nyloc!~quassel@p5B26F137.dip0.t-ipconnect.de) has joined #mythtv
[09:18:23] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv
[09:18:39] _nyloc_ (_nyloc_!~quassel@p57B4F3F6.dip0.t-ipconnect.de) has quit (Ping timeout: 268 seconds)
[09:18:43] stuartm: is the OSD unpopulated with videos for anyone else – no title/description etc?
[09:19:52] stuarta: no can check from here
[09:24:57] caelor: stuartm, specifically videos, or recordings too?
[09:26:50] caelor: just checked here – title & description shown on OSD for both recordings and videos. Mythbuntu theme
[09:30:44] stuartm: ah nevermind
[09:33:35] caelor: I'm on mythbuntu's 0.27 builds as of yesterday
[09:53:38] stuarta: if i'm reading the code right, that went bang downref'ng a socket handler
[09:53:52] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv
[09:55:01] stuartm: so mis-matched reference counting, or something is outright deleting the socket instead of downrefing
[09:55:27] stuarta: looks like it
[10:00:57] caelor: that was my take from stumbling through the backtrace and code.
[10:01:14] caelor: I could re-run the test with some -v ??? logging, if it'd help
[10:01:44] stuarta: more useful would be running it under valgrind
[10:02:03] stuarta: although that takes a *lot* of cpu and memory
[10:02:46] caelor: well, the box in question is a fileserver running on mini-itx, so I can but try!
[10:03:20] caelor: it shouldn't need to run long
[10:03:21] stuarta: it also increases the runtime by about 10x
[10:03:35] caelor: any preference on valgrind options?
[10:03:57] stuarta: valgrind --error-limit=no --leak-check=full --log-file=mythmediaserver-valgrind.log -v — <cmd>
[10:04:04] stuarta: that'll do for starters
[10:04:28] stuarta: <cmd> is how you startup the media server
[10:04:54] caelor: ok (mythmediaserver --syslog for now). Starting it, will pastebinit a result
[10:05:54] stuarta: can you add the logfile to the ticket?
[10:06:15] caelor: will do. Interestingly, it's not segfaulting under valgrind
[10:06:26] caelor: ah. Yes it did on the 2nd video
[10:06:43] stuarta: goodie. valgrind should tell us who did what with the memory
[10:07:18] caelor: the first video was one that I used last time to segfault it, with the only change to it being that I've now retrieved metadata for it
[10:07:28] caelor: the 2nd video was one without metadata
[10:09:12] caelor: added to ticket
[10:09:57] stuarta: that sounds like a clue
[10:11:05] caelor: I thought it did too
[10:11:29] stuarta: looks like the filetransfer code is the culprit
[10:12:09] stuarta: well at least, doing something funny
[10:47:18] wagnerrp_: stuarta: i wrote it, so i grabbed it, but i'm not going to be able to do anything with it until the weekend
[10:47:33] wagnerrp_: if you think you've got a handle on it, feel free to take over
[10:48:36] stuarta: wagnerrp_: i'll keep it in mind, however i'm currently buried in cases
[10:48:41] stuarta: (work cases)
[10:50:23] caelor: I'm working around it by wrapping mythmediaserver in a bash loop to respawn it, so I'm sure there's more urgent tasks
[10:50:46] wagnerrp_: i should be finishing up here this week, so i'll actually have a few weeks idle to work on things coming up
[10:51:15] caelor: wagnerrp_, I don't know if you spotted above, or if it's a red herring, but there was an indication that the behaviour may differ between videos with metadata and those without
[10:52:40] wagnerrp_: the internal protocol does have the ability to shift a file transfer socket from one file to another
[10:52:50] wagnerrp_: but to be honest, i'm not sure if that ever actually gets used
[10:53:28] caelor: it could easily be a red herring – I only noticed it when running under valgrind, which could also influence a race condition
[10:56:12] stuarta: caelor: valgrind has a tendency to kill race conditions because things run so slowly there is rarely a race
[10:59:04] caelor: indeed – given with the video in question I'd fetched metadata, and then run under valgrind, it's impossible to say which was the reason it didn't segfault on it
[10:59:19] stuartm: well it can potentially expose different races because it runs so slowly, but yeah it's not very useful for debugging most races
[11:00:31] ** wagnerrp_ heads to work **
[11:00:40] wagnerrp_ (wagnerrp_!6b124e7a@gateway/web/freenode/ip.107.18.78.122) has quit (Quit: Page closed)
[11:02:16] stuartm: if someone wants to look at this before the release, it would clear the last major coverity warning – http://code.mythtv.org/trac/ticket/11607
[11:13:21] stuartm: danielk22: I'd really appreciate your feedback on this patch – http://code.mythtv.org/trac/attachment/ticket . . . 97d1e9.patch
[11:23:46] neufeld`` (neufeld``!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[11:23:46] neufeld`` is now known as neufeld
[13:46:23] knightr__ (knightr__!~Nicolas@69.165.170.178) has joined #mythtv
[13:50:10] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 256 seconds)
[13:55:30] stichnot: stuartm: users on the mailing list think that #11020 is going into 0.27... That patch is a stopgap measure, but the real fix is to move the backend queries into the background via the event loop.
[13:55:30] ** MythLogBot http://code.mythtv.org/trac/ticket/11020 **
[13:56:50] Merlin83b: stichnot: Thanks for your explanation on that -users post, all makes sense.
[13:57:00] Merlin83b: (I'm Daniel, from that thread)
[13:57:41] danielk22: stichnot: Yeah a stop gap. I had meant to find the true culprit and then I forgot about this issue.
[13:58:52] danielk22: This should be fine for now. We added a similar hack before another release but I removed it because I thought the underlying problem was fixed.
[14:02:07] stichnot: Merlin83b: np. I use ION frontends in production so it's easy to feel the pain.
[14:04:38] stuartm: danielk22: since you're around, mind looking at http://code.mythtv.org/trac/attachment/ticket . . . 97d1e9.patch ?
[14:07:30] stuartm: my production box ran out of space, following which the mysql timezone tables were completely destroyed – having trouble recreating them, re-run the script but conversions are still failing
[14:09:20] stuarta: :(
[14:10:01] danielk22: stuartm: That's what I was commenting on for stichnot
[14:10:07] stuartm: ah got it, somehow ended up with two instances of mysql running, one of which had cached the old (empty) table
[14:10:31] stuartm: danielk22: oh OK, good, I thought you were referring to #11020
[14:10:31] ** MythLogBot http://code.mythtv.org/trac/ticket/11020 **
[14:13:05] stuartm: two things still irritate me about linux generally – there's no protection against a root partition filling up (no reserved space for critical apps) and when you do run out of space few apps handle it gracefully, mysql in particular fails spectacularly, corrupting files etc
[14:13:09] danielk22: Nope. I don't really like the patch on 11020. The problem of MythProto requests in the event thread is a real problem, but we have existing patterns for addressing these.
[14:14:35] stuartm: ubuntu especially annoys me because apt-get leaves ancient downloads on the filesystem which waste space unless you explicitly tell it to clean up after itself
[14:19:03] stichnot: danielk22: can you point me to a good existing pattern for reference?
[14:19:24] stuartm: danielk22: I don't like that patch either, which is why it hasn't been committed, but aside from moving those requests, there is a problem generally with querying the same information over and over again
[14:20:04] stuartm: the one part of that patch which is good is the removal of the updateChannel calls, those appear to be completely wrong
[14:21:18] stuartm: it's asking the whole channel list to be updated each time you must up or down through the list
[14:22:01] sphery_: it's queried over and over because it can change at any time due to new recordings, new live tv sessions, or channel changes on other live tv sessions
[14:22:11] sphery_ is now known as sphery
[14:22:23] stuarta: stuartm: depends entirely on how you configure mysql.
[14:23:28] stuartm: stuarta: well the default config doesn't handle it well :)
[14:24:10] stuartm: it's not even clear how it corrupted what should have been a read-only table
[14:24:34] danielk22: stichnot: I'd need to have the code in front of me, but I think there is a worker thread or two in the mythfrontend code. Maybe not best practice, but a bit better.
[14:24:52] stuarta: stuartm: if it's myisam anything can happen
[14:25:12] stuarta: innodb, you can power the server off mid write and it'll come up fine
[14:33:32] stuartm: sphery: that's what the backend status events are for, the backend tells us of changes in status so we don't have to poll
[14:38:26] gigem: sphery: I think the solution to the caching issue is to use events so the frontend always knows the current status for all tuners. BTW, I'm mulling over a scheduler refactor that could help in this area. Even then, the real-time nature of things will always be problematic.
[14:38:52] gigem: What stuartm said. I should have read to the end. :)
[14:42:49] sphery: yeah, that's fine--just wanted to make sure that we remember the root reason for assuming it can change anytime
[14:44:39] sphery: I definitely won't argue that code/functionality (or any other) can't be rewritten in a better way
[14:49:59] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[14:52:49] stichnot: danielk22: ok, I'll have a look. But when possible, I prefer adding background work to the event loop, so there are fewer issues with synchronization. (Unless you really want to make use of extra HW threads.)
[14:57:11] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[15:16:39] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[15:46:49] 5EXAAKZCN is now known as ghoti_
[15:49:26] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Ping timeout: 246 seconds)
[15:49:41] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv
[15:51:37] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:53:06] stichnot: gigem, stuartm: Having the frontend listen for tuner status updates is good, but there's also logic about input groups that needs to be applied, which is normally done on the backend. But it should be reasonable to locally cache input groups.
[15:57:00] wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv
[16:05:49] ghoti (ghoti!~paul@scratch.it.ca) has quit (Disconnected by services)
[16:07:47] ghoti_ is now known as ghoti
[16:08:31] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[16:08:56] jpabq___ (jpabq___!~quassel@174-28-147-195.albq.qwest.net) has joined #mythtv
[16:09:14] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 264 seconds)
[16:09:18] jpabq__ (jpabq__!~quassel@75-161-24-249.albq.qwest.net) has quit (Ping timeout: 245 seconds)
[16:11:39] SteveGoodey (SteveGoodey!~steve@host86-162-40-99.range86-162.btcentralplus.com) has joined #mythtv
[16:17:56] knightr__ is now known as knightr
[16:18:03] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[16:18:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[16:21:06] gigem: stichnot: I wasn't going to say much until I had a more complete idea and implementation plan hashed out, but what I'm considering is having the scheduler be the traffic cop for all scheduled *and* live TV use. Frontends would be kept up to date with what video sources and multiplexes are currently available for use. When the frontend wants to change channels, it asks the scheduler and the scheduler tells
[16:21:08] gigem: it which input to use. The frontend doesn't need to know anything about input groups.
[16:22:20] jpabq___ (jpabq___!~quassel@174-28-147-195.albq.qwest.net) has quit (Quit: No Ping reply in 180 seconds.)
[16:22:48] jpabq_ (jpabq_!~quassel@174-28-147-195.albq.qwest.net) has joined #mythtv
[16:23:19] rsiebert (rsiebert!~quassel@g225051061.adsl.alicedsl.de) has joined #mythtv
[16:25:58] rsiebert_ (rsiebert_!~quassel@g225049232.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds)
[16:35:46] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:45:36] caelor: gigem, that sounds sensible – at the moment livetv effectively tramples on the scheduler. In some ways, architecturally, livetv as watching an in-progress recording is more consistent, and a traffic cop scheduler could enable that
[16:46:36] stichnot: gigem: That would be freakin fantastic. A ton of legacy code could be slashed away.
[16:49:08] caelor: it also opens the door to more intelligent use of tuners – such as "changing channel" to a currently recording program could transparently start playing back the recording from the appopriate point instead
[16:50:03] darkdrgn2k (darkdrgn2k!~darkdrgn2@69-165-131-20.dsl.teksavvy.com) has joined #mythtv
[16:50:03] darkdrgn2k3 (darkdrgn2k3!~darkdrgn2@69-165-131-20.dsl.teksavvy.com) has quit (Read error: Connection reset by peer)
[16:50:34] danielk22: stichnot: Adding background work to the event loop is fine so long as it's non-blocking, but MythProto calls are always blocking. Any delay over a few ms in the event loop will be noticeable when watching video.
[16:51:04] danielk22: Of course we could put it in the event loop of a different thread :)
[16:53:13] danielk22: If I were re-factoring the TV class now I would put all that stuff that's in the non-UI thread into a Qt event loop on a separate thread. At the time I didn't realize the potential of the event loop for every thread introduced in Qt4.
[16:53:14] stichnot: danielk22: ah, good point. Then a background thread it is!
[16:53:37] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:10:03] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:27:42] sphery: FWIW, I still believe "intelligent use of tuners" = "terrible idea for Live TV", because a user is watching Live TV, switches to a channel that's being recorded, and releases the tuner, after which new recordings/Live TV sessions start, and the first Live TV user attempts to change the channel and can only go to whatever else is being recorded or watched live on the other frontend because the 2nd Live TV user "stole" his tuner.
[17:32:09] caelor: true enough, but if you're in a "tuner contention" situation, any algorithmic solution could be the wrong one for somebody – which livetv user gets priority over who, and where do scheduled recordings sit in the priority order?
[17:34:22] caelor: at least tuner "de-duplication" tries to minimise tuner usage where possible, making constrained resources go further
[17:52:38] stichnot: sphery: I'm not sure that's any more surprising to a user than a current situation where User 1 changes to a channel on another tuner, then User 2 starts live TV on User 1's old tuner, and now User 1 can't get back.
[18:00:09] sphery: I'd argue that's not bad (it shouldn't be surprising to a Live TV user that he/she is only guaranteed access to the current tuner), but if you add in multirec (which started trying to efficiently use tuners) and user 2 hops on user 1's tuner and user 1 loses the ability to tune outside of the mux, that's definitely broken/surprising
[18:03:24] sphery: So it all comes down to my contention that trying to fake hardware (tuners) with software solutions (multirec/switching to already-recording-the-show tuners/...) is a broken solution when it comes to Live TV. Live TV should have exclusive control of a (physical) tuner, but users don't want to spend the money to get the systems they actually want, so they look at simple situations and say, "we can do it with more efficient usage," and expect ...
[18:03:27] jheizer: Throw in soemone liek me with a single HDPVR (satellite) and 4 OTA so I want to use the hdpvr only when required. Definately a complex problem.
[18:03:30] sphery: ... miracles from the software :)
[18:03:37] sphery: yeah
[18:04:06] jheizer: lmao
[18:04:24] sphery: and, yeah, I'll admit that buying HD-PVR + STB rental for every Live TV user isn't worth the cost, either
[18:05:10] jheizer: Same time cable card tuners are the way to go now so becoming less of an issue
[18:05:44] sphery: tell that to TWC customers :)
[18:05:50] jheizer: true true
[18:06:31] jheizer: Last 2 times I have tried to switch back to cable comcast can't tell me what it will cost per month as I would be a new tv customer, but currently have their internet.
[18:06:50] jheizer: But my HDPVR has been bullet proof so no complaints
[18:06:54] jheizer: just dreams
[18:11:10] jheizer: I only recently started using livetv after something like 7 years using myth. I have to say it has been working great other than the guide being a bit laggy (but after seeing the discussion this morning I fully understand).
[18:14:37] straximus (straximus!6b0761c2@gateway/web/freenode/ip.107.7.97.194) has joined #mythtv
[18:30:59] stichnot: sphery, gigem: Even if we decide sphery's approach is the way to go (and I'm not convinced, yet), I bet the required logic could be implemented in the scheduler and still enable wide swaths of existing code to be removed.
[18:56:47] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[19:11:16] stuartm: release will be tagged tonight, between an hour and two hours from now, if you've got something that should go in then let me know and I can aim for 2 hours e.g. 10PM GMT
[19:11:59] stuartm: I may not get all the stuff associated with a release sorted tonight, in which case it will be done first thing tomorrow morning
[19:13:03] stuartm: don't intend to stay up late tonight :)
[19:31:08] tris (tris!tristan@2001:1868:a00a::4) has quit (Ping timeout: 260 seconds)
[19:33:54] stuartm: stuarta: just did a scan on my production box running 0.27-fixes, it failed to pick up on a change to ITV3, which had moved since the last scan to a different transport ID. The service id and frequency had stayed the same but the transport id was different
[19:34:59] stuartm: this means the channel is un-tunable – although I'm not sure why, since with the right frequency in there the transportid is largely immaterial?
[19:35:36] stuartm: Working – | 1010 | 12294 | 16048 | 538000000 | 1 |
[19:35:52] stuartm: Broken – | 1010 | 12290 | 16048 | 1 | 538000000 |
[19:36:23] stuartm: that's chanid, transport id, serviceid, frequency
[19:36:58] stuartm: obviously the chanid can be ignored ...
[19:41:45] tris (tris!tristan@2001:1868:a00a::4) has joined #mythtv
[19:45:23] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv
[19:45:23] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host)
[19:45:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[19:57:25] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[19:59:50] stichnot: stuartm: I have the sample for #11859, but so far no luck in reproducing the crash
[19:59:50] ** MythLogBot http://code.mythtv.org/trac/ticket/11859 **
[20:01:48] stuartm: stichnot: OK, thanks for taking a look, if you can't reproduce then there's no point holding up the release for it – it can be fixed afterwards and it will be upto distros to provide updated packages against fixes or 0.27.1
[20:03:13] stuartm: have to draw a line somewhere, and mythcommflag crashing for some videos, on some systems isn't the end of the world
[20:03:26] stuartm: might be different if it was affecting the frontend
[20:04:04] stuartm: stichnot: feel free to change the milestone to 0.27.1
[20:08:33] gigem: stichnot, sphery: I never said what policy the scheduler would use in choosing where to send live TV, just that it would be in control. I want to remove surprises like "you just started live TV on the tuner I was about to use and now it's too late to reschedule around it or ask you want I should do."
[20:11:34] SteveGoodey (SteveGoodey!~steve@host86-162-40-99.range86-162.btcentralplus.com) has quit (Quit: Konversation terminated!)
[20:36:21] danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv ()
[22:19:08] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 261 seconds)
[22:32:06] skd5aner: I appreciate all the talk earlier today about the EPG and Live TV – ironically, it's what I was asking about last night. Honestly, the fact that the EPG is so laggy and also causes the audio/video playback in livetv to stutter during every keypress is the only thing I can say is "annoying" about mythtv
[22:36:00] skd5aner: It's the only thing that I can say every commercial STB/DVR I used excels at over MythTV
[22:36:20] skd5aner: that said, it's not a huge issue, just a very obvious one for folks who use Live TV
[22:40:41] johanbr (johanbr!~johanbr@vps.nullinfinity.org) has joined #mythtv
[22:42:44] johanbr: Hi. I just got a MythTV backend running, connected to an HDHomeRun tuner. It appears that the backend *always* has an incoming stream from the tuner, even when there is no frontend connected and no recordings scheduled.
[22:43:43] johanbr: Is this supposed to happen? The reason I ask is that it means there's always some CPU load, and an 18 Mbit/s stream on the LAN.
[22:52:05] straximus_ (straximus_!18d6354b@gateway/web/freenode/ip.24.214.53.75) has joined #mythtv
[23:01:01] skd5aner: johanbr: best to ask in #mythtv-users
[23:04:05] johanbr: skd5aner: ahh, I didn't realize there was a separate users channel, will ask there... thank you!
[23:13:59] straximus_ (straximus_!18d6354b@gateway/web/freenode/ip.24.214.53.75) has quit (Ping timeout: 250 seconds)
[23:29:45] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[23:30:05] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[23:30:05] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[23:30:05] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[23:30:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[23:37:50] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:38:34] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:40:04] dekarl (dekarl!~dekarl@p4FE84A45.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[23:48:01] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[23:57:38] wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has quit (Remote host closed the connection)
[23:58:59] wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.