MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (74):

aloril_, Anssi, Beirdo, brfranse_, caelor_, CeilingKitten, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, dturner, eharris, ElmerFudd, fetzerch, foobum, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, Jay2k1, jheizer, joe____, johanbr, joki, jpharvey, jst_, jwhite, jya, kc, kenni, knightr_, kurre2, kwmonroe, laga_, moparisthebest, MythBuild, MythLogBot, nephyrin, neufeld, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert__, rsiebert___, seld, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, stuarta, stuartm, superm1, taylorr, tgm4883, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang3, XDS2010, xris, _charly_
Wednesday, October 30th, 2013, 00:08 UTC
[00:08:56] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has joined #mythtv
[00:08:56] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[00:08:56] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-170-1-245.hsd1.wa.comcast.net) has quit (Changing host)
[01:38:49] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:54:44] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[03:00:14] rsiebert__ (rsiebert__!~quassel@g225053251.adsl.alicedsl.de) has joined #mythtv
[03:00:16] rsiebert___ (rsiebert___!~quassel@g225053251.adsl.alicedsl.de) has joined #mythtv
[03:03:02] rsiebert_ (rsiebert_!~quassel@g225060184.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds)
[03:03:14] rsiebert (rsiebert!~quassel@g225060184.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds)
[03:08:47] nyloc (nyloc!~quassel@p3EE2CC70.dip0.t-ipconnect.de) has joined #mythtv
[03:13:31] _nyloc_ (_nyloc_!~quassel@p57B4F217.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[03:18:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[03:20:36] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:35:17] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out)
[03:53:19] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[04:04:37] wolfgang3 (wolfgang3!~wolfgang@ppp-46-244-167-45.dynamic.mnet-online.de) has joined #mythtv
[04:07:28] wolfgang2 (wolfgang2!~wolfgang@ppp-82-135-69-19.dynamic.mnet-online.de) has quit (Ping timeout: 240 seconds)
[04:58:40] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[04:59:26] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:32:42] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[06:36:40] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[06:43:22] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 268 seconds)
[06:54:19] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[06:59:55] knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[07:02:56] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[07:10:14] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[07:30:06] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[07:33:46] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[07:33:47] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[07:33:47] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[07:34:00] cecil (cecil!~cesman@pool-173-60-115-165.lsanca.fios.verizon.net) has joined #mythtv
[07:34:29] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 248 seconds)
[07:36:16] knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 245 seconds)
[07:48:07] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:11:25] cecil is now known as cesman
[08:11:45] cesman (cesman!~cesman@pool-173-60-115-165.lsanca.fios.verizon.net) has quit (Changing host)
[08:11:45] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[08:11:58] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[08:27:06] knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[08:27:56] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[08:46:13] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[11:47:48] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[11:47:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[11:49:42] stuartm: sphery, wagnerrp: re the disk-scheduler thread in -users, it's not really true that the disk scheduler cannot factor in auto-expiration, before starting recording we know which recordings can be expired, how old relatively they are (i.e. which should get expired first) and therefore can calculate which disk we'll be able to safely free up the most space on – to work best it just requires the scheduler to be smarter and factor in some stuff that
[11:49:44] stuartm: it probably doesn't now
[11:50:20] stuartm: for example we can start keeping a running average bitrate for each channel which we can use to roughly estimate the amount of space we might need
[11:52:15] stuartm: the scheduler also needs to try and avoid an imbalance in the numbers of expirable recordings on each disk (checking if the pending recording will be expirable according to it's rec rule)
[11:53:15] stuartm: it's a lot of work, but it's not a fundamental impossibility to get it working so that it's not expiring brand new recordings
[12:54:37] sphery: stuartm: we don't--currently--know where those recordings exist, so we had always said it makes the most sense to create a new (rather than modify existing) scheduler that uses auto-expire order as its criteria for disk selection once we store the location of the recordings in the DB... If someone really wants to do it now, though, they can and just find that recording as if we were playing it.
[12:55:26] sphery: I think it would be easy to do if you just create a new one and only use auto-expire order as the criteria (i.e. don't worry about the extras you mentioned--at least at first)
[13:53:45] stichnot: Humph. My GuideGrid changes eliminate Live TV stuttering on my laptop, but not entirely on my ION frontend. This won't do.
[14:50:49] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:51:57] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[14:59:56] Pr0f (Pr0f!~Pr0f@h146.228.67.68.static.ip.windstream.net) has joined #mythtv
[15:00:07] Pr0f (Pr0f!~Pr0f@h146.228.67.68.static.ip.windstream.net) has left #mythtv ()
[15:16:22] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[16:04:26] dekarl (dekarl!~dekarl@p4FE84467.dip0.t-ipconnect.de) has joined #mythtv
[16:04:53] dekarl1 (dekarl1!~dekarl@p4FE857AE.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)
[16:10:35] stichnot: stuartm, sphery: It might be more bang for the buck to write a "defrag"-like utility to rebalance existing recordings in a storage group.
[16:12:11] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[16:15:23] sphery: stichnot: that's also something that will be much easier/more sensible after we track locations of files, but something that I plan to do (along with allowing users to manually move recordings from the UI, even across hosts).
[16:16:20] sphery: The "Auto-expire order" Storage Group Disk Scheduler, though, could be done now, even without knowing the location of all files, since it only requires looking up one or a few recording locations...
[16:17:48] stichnot: sphery: I was thinking of even something as simple as a third-party python script for rebalancing in the meantime
[16:18:39] sphery: I'd think that disk scheduler should be a mix of balanced free space (when file systems aren't full) with some attention to auto-expire order, then kicking in to full auto-expire order when file systems get within, maybe a few 10s of GB (or 100GB) of full?
[16:19:53] sphery: stichnot: yeah, that could be done easily enough... the hardest part is moving the recordings around without taking up too much I/O (but could leverage something like rsync --bwlimit to ensure there are no problems)
[16:20:56] stichnot: yeah, --bwlimit sounds nice, as well as using all of rsync's built-in safety
[16:21:15] sphery: shouldn't be too hard to do, either... I think wagnerrp already has some python scripts that find the physical location of recordings, so it would just be adding in some "what's full" kind of logic, as well as pulling the auto-expire list, then sorting appropriately
[16:21:20] jams: agreed, for doing something like that rsync will fit the bill nicely
[16:21:48] sphery: yeah, I only ever use rsync for moving my recordings because of all the safeties (and niceties, like --progress) it provies
[16:23:40] sphery: anyway, I would love to have an "Auto-expire order" SG Disk Scheduler if for no other reason than to change the default from Percent Free Space--which became the default when new users complained that in their new system with a 2TB file system and a 750GB file system, it always only wrote to the 2TB, so MythTV "doesn't even seem to know about the 750GB"
[16:24:26] sphery: the problem is that when you have full file systems, it tends to cause an "always pick the same file system" effect that causes it to expire old recordings from that file system and write new ones to it, so that eventually there are only new ones to expire
[16:24:49] sphery: so, while it's good for users who start with it, it becomes a problem when file systems fill up
[16:25:17] jams: the problem with rsyncs niceties is that they change from version to version. The core always seems to be consistent though
[16:25:53] sphery: hehe, yeah... and that makes script maintenance a challenge, when you rely on the niceties
[16:27:13] moparisthebest_ (moparisthebest_!~quassel@cpe-184-57-178-66.cinci.res.rr.com) has quit (Read error: Connection reset by peer)
[16:28:36] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has joined #mythtv
[16:31:39] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has quit (Excess Flood)
[16:31:59] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has joined #mythtv
[16:35:38] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[16:40:16] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[16:50:45] dekarl: stichnot, sphery: wrt defrag / load balancing storage. just shout when the brainstorming starts, I can try to harvest experience from my day job
[16:53:32] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:16:02] skd5aner: stichnot: one comment on the guide stuttering – if I use it at "normal speed" – in other words, I tend to navigate the EPG very quickly if I'm trying to skip dozens of channels to get where I want – that's where the stuttering is the worst for me :)
[17:18:30] stichnot: skd5aner: In the changes I'm working on, you may see a lag in refreshing the channel list as you scroll rapidly, but the live TV shouldn't stutter
[17:18:52] stichnot: btw, how powerful is your frontend? Is it Atom based, or something more powerful?
[17:22:02] skd5aner: sphery: I could definitely use an automated recording balancer... here's the proof: http://pastebin.com/VhjRbEXy
[17:23:30] skd5aner: Core2 e6400
[17:23:35] skd5aner: stichnot: ^
[17:23:55] skd5aner: er, core2 duo I guess
[17:24:36] skd5aner: stichnot: http://ark.intel.com/products/27249/intel-cor . . . 1066-mhz-fsb
[17:25:32] stichnot: That should be OK. One thing I've found is that just computing and rendering one row of the guide takes a lot of work in the current implementation, so I'm trying to pull as much out of the UI thread as I can.
[17:25:47] stichnot: My ION frontends are the acid test
[17:28:30] skd5aner: fyi – I use VDPAU for rendoring and decoding
[17:28:36] skd5aner: if that matters
[17:35:52] stichnot: yeah, I kind of expect that if you don't use GPU acceleration on a low-end CPU, you're just gonna have a bad time
[17:36:34] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:39:22] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[17:40:05] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Client Quit)
[18:34:36] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[18:57:46] xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Goodbye.)
[18:58:22] xris (xris!~xris@xris.forevermore.net) has joined #mythtv
[19:01:48] xris (xris!~xris@xris.forevermore.net) has quit (Changing host)
[19:01:48] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[20:13:45] joki (joki!~joki@p548605E1.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[20:15:55] Jay2k1 (Jay2k1!J@188.94.26.27) has joined #mythtv
[20:17:56] Jay2k1: hi! i think i found a bug in the metadata lookup routine. i noticed it because it is showing a porn picture background for a crime series :D
[20:20:21] joki (joki!~joki@p54861C43.dip0.t-ipconnect.de) has joined #mythtv
[20:20:49] Jay2k1: semi-nsfw: https://dl.dropboxusercontent.com/u/11595654/ . . . t-fanart.PNG
[20:21:59] Jay2k1: i found the image in the fanart folder, its filename is 82459_fanart. apparently mythtv uses both tvdb and tmdb for lookups, so i checked that number on both databases.
[20:22:53] Jay2k1: on tvdb, it is indeed the ID of the tv show called The Mentalist. on tmdb though, it's the ID of a porn movie, and one of the images of that movie is what my myth box uses as background
[20:23:17] Jay2k1: so by the show name, it looked up the ID on tvdb but used fanart from tmdb for some reason
[20:40:58] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[20:46:26] stuartm: it's a known bug, fix is in the works
[20:49:22] Jay2k1: alright
[20:50:13] Jay2k1: most bugs are annoying, this one however was quite amusing
[20:58:34] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:04:43] stuartm: technically it wasn't so much a bug as extreme short-sightedness in the design of the metadata stuff
[21:09:54] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[22:04:42] nephyrin (nephyrin!~neph@2620:101:8003:200:7a2b:cbff:fe9e:2e67) has quit (Remote host closed the connection)
[22:05:04] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:19:30] nephyrin (nephyrin!~neph@2620:101:8003:200:7a2b:cbff:fe9e:2e67) has joined #mythtv
[22:50:01] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[22:51:09] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:05:27] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[23:16:16] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 246 seconds)
[23:43:25] Jay2k1: you mean, people didn't think of the fact that some day, mythtv might query more than one database and that multiple DBs might have overlapping IDs? :>
[23:52:09] skd5aner: jay2k1: you'd be surprised how many people have gotten NSFW artwork for a tv show where the inetid matched a naughty movie on tmdb. Happened to me on sportscenter and another person recently on the mailing list
[23:53:09] skd5aner: Jay2k1: I find it funny that more often than not, the wrong artwork retrieved is usually NSFW... what are the odds that a valid ID for TV is always an "adult-themed" movie? too funny

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