:: #mythtv

Daily chat history

Current users (66):

aloril, amessina, andreaz, Anssi, brfranse_, caelor, Casper0082, CCFL_Man, Chutt, clever_, coling, dblain, dekarl, eee-blt, ElmerFudd, enyc, esperegu, espes__, fetzerch, Gibby_, gigem, goibhniu, gregL, GreyFoxx, J-e-f-f-A, jams, jheizer, joki-, jst, jwhite, jya, kormoc, kurre2, len_, moparisthebest, MythBuild, MythLogBot, nephyrin, peper03, poptix, purserj, rich0, robink, rsiebert, Seeker`, seld, sheedy, skd5aner, sphery, sraue, stuartm, suffice, superm1, taylorr, tgm4883, tonsofpcs, tris, unforgiven512, wagnerrp_, Warped, warpme, XDS2010, xris, zentec_, _charly_, _epineephrine_
Wednesday, October 29th, 2014, 00:28 UTC
[00:28:18] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[00:35:41] andreaz (andreaz! has joined #mythtv
[00:49:14] dym (dym!~patrick@unaffiliated/dym) has joined #mythtv
[01:07:10] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[01:25:04] sheedy is now known as sheedy-away
[01:55:44] andreaz (andreaz! has quit (Read error: Connection reset by peer)
[02:33:45] sl1ce (sl1ce! has joined #mythtv
[02:35:24] sl1ce (sl1ce! has quit (Remote host closed the connection)
[02:54:06] rsiebert (rsiebert! has quit (Ping timeout: 244 seconds)
[03:17:32] rsiebert (rsiebert! has joined #mythtv
[03:38:26] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:41:51] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 265 seconds)
[03:41:51] peper03_ is now known as peper03
[04:19:06] sl1ce (sl1ce! has joined #mythtv
[04:20:03] sl1ce (sl1ce! has quit (Remote host closed the connection)
[04:20:56] sl1ce (sl1ce! has joined #mythtv
[04:53:56] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 250 seconds)
[05:01:45] arescorpio (arescorpio! has joined #mythtv
[05:45:54] arescorpio (arescorpio! has quit (Excess Flood)
[05:50:51] moparisthebest (moparisthebest!~quassel@gateway/tor-sasl/moparisthebest) has quit (Quit: No Ping reply in 180 seconds.)
[05:53:25] moparisthebest (moparisthebest!~quassel@gateway/tor-sasl/moparisthebest) has joined #mythtv
[06:01:42] Roklobsta (Roklobsta! has joined #mythtv
[07:07:34] dekarl: Roklobsta: I took a peek at mysql's slow query log when starting playback and I see queries for loading the seektable (mark types 9 and 33, with the latter taking 15–20 seconds) but its not all related to the playback (its different programs, so it must be something else, like previewgen or so)
[07:14:16] dekarl: stuarta, appears to look at instead (when I remove the wiki/xxx part I end up in trac)
[07:17:44] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[07:33:54] Roklobsta: dekarl: previewgen can mae things busy too
[07:47:28] Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce1d:7924:ae24:f122:d7e2) has joined #mythtv
[08:25:10] lomion0815 (lomion0815!5bd9374e@gateway/web/freenode/ip. has joined #mythtv
[08:51:15] dekarl1 (dekarl1! has joined #mythtv
[08:53:11] dekarl (dekarl! has quit (Ping timeout: 244 seconds)
[08:56:04] joki- (joki-! has quit (Ping timeout: 255 seconds)
[09:00:54] joki- (joki-! has joined #mythtv
[09:06:57] Merlin83b (Merlin83b! has joined #mythtv
[09:16:18] stuarta: dekarl1: curious
[09:41:20] stuartm: dekarl1: fixed
[09:59:16] joki- (joki-! has quit (Ping timeout: 265 seconds)
[10:03:45] dym (dym!~patrick@unaffiliated/dym) has left #mythtv ()
[10:04:24] joki- (joki-! has joined #mythtv
[10:32:23] len_ (len_! has quit (Read error: Connection reset by peer)
[10:52:37] dekarl1 is now known as dekarl
[10:55:11] dekarl: ty
[11:09:19] warpme (warpme! has joined #mythtv
[11:18:38] warpme: hi* It looks like there is issue with full-screen mythtv running on systems with glamor 2D accell (all new AMD and Intel). On system with i.e. 1920x1080, playing 1920x1080 content mythtv draws it into 1920x1078 window. As window size<>screen size – page vblank page flipping is not working on glamor and user has ugly tearing. Do somebody knows why myth plays 1920x1080 content in 1920x1078 window?
[11:19:40] warpme: isn't this 2 lines crop to hide bob DI upper/lower lines to avoid flickering?
[11:43:49] stuartm: stuarta: I thought basic BAT processing had been added?
[11:44:42] stuartm: so all that remains is processing the additional (custom) info
[11:44:48] stuartm: which looks like it might be fun
[11:45:02] stuartm: especially like the idea of filtering out the regional cannels
[11:45:04] stuartm: channels
[12:14:09] sphery: warpme: this sounds a lot like the issues users had when using compositing window managers (such as compiz) which refuse to do proper full-screen (even when properly specified by the app) and put decorations around the window.
[12:14:38] Roklobsta (Roklobsta! has quit (Quit: KVIrc 4.2.0 Equilibrium
[12:18:05] sphery: warpme: for compiz/unity and such, there was an option to enable legacy full screen support, which cleared up the problem
[12:18:22] sphery: (or worked around the WM's refusal to work properly)
[12:47:00] stuarta: stuartm: i've added the basics of bouquet processing. ie the table handling, but the other magic needs adding
[12:47:19] brfranse_ (brfranse_! has joined #mythtv
[12:47:23] stuarta: the main thing i had in mind was allowing the user to select which one applies to them
[12:47:54] stuartm: might take a look, doesn't seem like there's too much work involved to parse that private descriptor
[12:48:51] stuarta: it'll be how you split them when there are multiple bouquets that'll be the fun part
[12:49:31] brfransen (brfransen! has quit (Ping timeout: 244 seconds)
[13:03:33] dekarl: if you want bouquet fun, just point a dish at 19.2 :)
[13:04:48] dekarl: 28.8/Freesat appears to be centrally managed
[13:24:43] warpme: sphery: issue I mention is visible in minimyth2. mythtv runs as full-screen app, I'm using non-windowed wm and xserver hasn't enabled any compositor. In such config (when window_size=screen_size) xserver should use vsync page flipping driven by dri. User should get perfect playback (in non-tearing) sense. Unfortunatelly myth draws h=1078 for h=1080 content and by this page flipping will not work :-( Do You know where in mythtv code I can di
[13:25:17] warpme: s/in/I mean/
[13:27:21] Merlin83b: warpme: That cut off at "in mythtv code I can d"
[13:29:02] warpme: oops – I mean: Do You know where in mythtv code I can disable -2 croping on video output?
[13:33:11] sheedy-away is now known as sheedy
[13:43:14] warpme: dblain: did You receive my logs from scheduller-affinity-wip5?. Attachement was blocked by mailing-list daemon – but I hope You receive PM with logs....
[13:50:04] dekarl: warpme: what does the frontend log show wrt "Desktop video mode" and "UI Screen Resolution"?
[13:51:05] dekarl: also "MythUIHelper: Overriding GUI size"
[13:52:01] warpme: dekarl: I verified current res by using xwininfo. For GUI it reports: -geometry 1920x1080+0+0. For playback it reports: -geometry 1920x1078+-1+-1
[13:53:04] warpme: dekarl: IIRC I have "use GUI size for playabck"
[14:17:56] sphery: warpme: did you mean gigem for the scheduler affinity stuff?
[14:18:32] sphery: also, I'm pretty sure that MythTV doesn't do any "crop off 2 lines of video" stuff, unless you say to (with a crop playback filter)
[14:19:20] sphery: but even then, the window size should be the full size with the video being scaled or letter/pillarboxed into that window
[14:19:47] superm1: jheizer: if you want me to glance through the prerm i can look for obvious mistakes
[14:20:06] superm1: did you already try to add set -x to the top of it to see output?
[14:20:43] jheizer: superm1, thanks, but I FINALLY figured it out. I was copying in everythign fresh on each .deb create, and my script was not copying the prerm in there....
[14:20:51] jheizer: stupid simple mistake
[14:23:17] sphery: are you using a -geometry override rather than using the settings specified in Appearance settings? Also, please make sure you've got "Use GUI size for TV playback" and "Use fixed window size" enabled and "Separate video modes for GUI and TV playback" disabled
[14:23:22] sphery: warpme: ^^^
[14:23:43] gigem: warpme: Yes, I got your logs. Mail to you has been undeliverable for for a few weeks so you never got my confirmation.
[14:24:33] sheedy is now known as sheedy-away
[14:28:48] warpme: sphery: sure. I'll do. Now I'm in work – so can't check this at the moment. Regarding -geometry – no. I'm not using it. All myth video settings are default DB settings – but for sure I'll verify all settings.
[14:31:19] warpme: gigem: let me know if You need any additional testing from me – I'll do this with pleasure.
[14:35:54] jpharvey_ (jpharvey_! has quit (Ping timeout: 255 seconds)
[14:37:19] gigem: warpme: Okay.
[14:49:36] jpharvey_ (jpharvey_! has joined #mythtv
[14:53:12] Jordack (Jordack! has joined #mythtv
[15:08:35] dblain: warpme: was that msg really meant for me?
[15:40:12] warpme: dblain: sorry. I wrongly recall You while scheduler stuff is gigem area. Sorry bother You :-p
[15:56:47] lomion0815 (lomion0815!5bd9374e@gateway/web/freenode/ip. has quit (Quit: Page closed)
[16:01:50] sl1ce (sl1ce! has quit (Remote host closed the connection)
[16:55:28] jpabq: sphery: out of curiosity, on a fresh install, why doesn't mythtv-setup create the mythconverg DB? Is it to allow users to have different users/passwords ?
[17:01:13] SteveGoodey (SteveGoodey! has joined #mythtv
[17:10:38] stuarta: jpabq: that area could use some usability improvments. somebody wrote a patch for me for this, to add a --bootstrap mode to the backend
[17:10:54] stuarta: iirc there's a ticket floating around
[17:11:38] jpabq: I don't have to do it very often, but when I do I cringe at how difficult it would be for someone that has never done any of this stuff before.
[17:12:00] stuarta: yeah it's horribl;e
[17:12:12] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[17:19:38] dekarl: #12264 <- the ticket
[17:19:38] ** MythLogBot **
[17:38:23] rmeden1 (rmeden1! has quit (Quit: Leaving.)
[17:49:46] Merlin83b (Merlin83b! has quit (Quit: Leaving)
[17:50:33] Gibby_ (Gibby_!~Gibby@ has joined #mythtv
[17:52:36] Gibby (Gibby!~Gibby@ has quit (Ping timeout: 272 seconds)
[18:10:54] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[18:11:08] skd5aner (skd5aner! has joined #mythtv
[18:12:42] superm1: jheizer: are you constructing your debs by hand rather than with source packages and dpkg-buildpackage?
[18:13:56] jheizer: superm1, yeah using dpkg-deb --build since it is a website
[18:14:32] jheizer: so all the inst/rm stuff is just configuring and cleaning up apache configs
[18:14:59] superm1: well that's better than entirely by hand
[18:15:31] superm1: but you might still have an easier time if you had real source tree and used dpkg-buildpackage or debuild (wrapper for dpkg-buildpackage)
[18:15:56] superm1: helps to sort out permissions and putting stuff in the right place and generally will help avoid silly errors
[18:16:24] superm1: you'd just have a debian/install file and boilerplate debian/rules that does pretty much nothing in that scenaior
[18:16:26] superm1: *scenario
[18:17:03] superm1:
[18:17:12] jheizer: Ok, thanks. I'll have to check those out. So many ways to do all of this.
[18:18:03] superm1: sure, feel free to hop in ubuntu-mythtv-dev and i'll review it more closely with you and make recommendations if you want
[18:18:05] jheizer: Not sure if what I have working now is the most correct and complete way. But when it is done it all works, and on removal it is all gone.
[18:44:53] Jordack (Jordack! has quit (Quit: i quit)
[18:55:39] SteveGoodey (SteveGoodey! has joined #mythtv
[19:03:00] gigem: Do I have this straight? When MythTV didn't schedule around live TV, it was a bug. Now that it does schedule around live TV, it's still a bug. I think I need to follow stuartm's lead and quit reading the -users list.
[19:07:01] tgm4883: gigem: I don't believe that is what the thread is saying
[19:09:35] tgm4883: gigem: I think the main problem is expectations. The idea is that watching a particular show on live tv and having a scheduled recording for that same show and timeslot would only use 1 tuner, not 2. this is not the case with mythtv
[19:17:14] tgm4883: so if I'm reading correctly, it seems this functionality was broken with the change to mythtv-setup to have that be a drop down rather than input by the user
[19:19:23] gigem: tgm4883: I know. The main gist is the OP's near complete lack of understanding compounded by most responders' well intended, but ineffectual help. To quote George Nassas, however, "the bug he's talking about is watching live TV locks the tuner that was going to be used for the subsequent recording." Note that he doesn't clarify that that is the intended before and therefore not a bug. He then references
[19:19:24] gigem: the livt TV group bug that was fixed several months ago.
[19:25:39] tgm4883: stuartm: If I'm reading github correctly, that looks like something you implemented in mythtv-setup. . . . diff=unified
[19:27:43] tgm4883: stuartm: granted that was 2 years ago, but I'm going to ask this anyway. Should MythTV backend listening on all interfaces still be valid? The comments on that bug from wagnerrp_ seem to indicate it was at some point
[19:28:12] gregL (gregL! has quit (Remote host closed the connection)
[19:28:14] len_ (len_! has joined #mythtv
[19:30:16] stuartm: tgm4883: that change there is unrelated
[19:30:39] tgm4883: stuartm: it is?
[19:30:59] stuartm: it's for setting the IP of the master backend, and has nothing to do with the IPs we listen on for the frontend
[19:31:20] stuartm: for those we read the available addresses from the systems
[19:31:29] stuartm: and listen on all available
[19:31:45] stuartm: I'll see what might be going wrong in a minute
[19:32:41] tgm4883: stuartm: This is all coming from
[19:41:10] stuartm: the problem is that the code in Serverpool isn't checking that it's a backend before applying a backend only condition
[19:41:27] Roklobsta (Roklobsta! has joined #mythtv
[19:41:59] tgm4883: stuartm: so it's a bug then?
[19:42:26] stuartm: but more than that, I'm not sure that condition that wagnerrp_ mentioned in the ticket even applies for ports other than 6543 (myth protocol), I know it doesn't for 6544 (http, services API)
[19:42:49] stuartm: tgm4883: just checking the code in master to be sure, just guessing from the description in the ticket for now
[19:44:39] tgm4883: stuartm: I'm not sure the ticket has anything to do with what the user is seeing, it was linked by another user in the thread
[19:48:03] stuartm: tgm4883: maybe not, but there is an issue there –
[19:48:07] SteveGoodey: stuartm: Thanks for your email. I'll hold off from now on.
[19:48:52] stuartm: SteveGoodey: thanks, just want to see how well it works, if it does the job then it will save you a lot of work
[19:50:03] stuartm: if it doesn't work, then you can go back to the pre-emptive banning while we try to find something that _does_ work :)
[19:50:18] SteveGoodey: Yeah, it was getting a pita!
[19:52:19] stuartm: the options for mediawiki are frankly pathetic compared to everything else, next to nothing is built in, the extensions are all in different states of neglect, a couple I looked at required additional executable files be downloaded from other sites (nothing dodgy about that)
[19:53:11] stuartm: most options focus on prevent edits, but not registrations so you still end up with hundreds, thousands of ghost accounts being created
[19:53:19] stuartm: preventing
[19:55:02] SteveGoodey: I know some sites were only allowing new users after being vetted by an admin. You can understand why but it's a bit restrictive.
[19:55:29] SteveGoodey: Any idea of total users on the wiki?
[19:55:49] stuartm: tgm4883: has anyone reported the issue of the ubuntu forums using mixed content sources (http/https), newer browsers refuse to load http content if the main page is using https, so that's all of the css missing :)
[19:56:50] tgm4883: stuartm: I don't think so, IDK. I hadn't noticed any issues
[19:57:21] tgm4883: oh wtf
[19:57:22] len_ (len_! has quit (Read error: Connection reset by peer)
[19:57:38] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[19:58:23] stuartm: tgm4883: I'm struggling to follow what's actually being reported in the forums, perhaps because of all the guesses being made by some of the users, the patch I posted above may or may not help (untested)
[19:58:33] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[19:58:40] stuartm: it certainly should fix the issue reported in the ticket
[19:58:49] skd5aner (skd5aner! has joined #mythtv
[20:00:25] tgm4883: stuartm: so basically the user has two home networks (named Parents and Kids, I'm assuming 192.168.0.x, 192.168.1.x). His MythTV box is setup on both networks, however the remote frontends cannot connect to the backend when the backend is "setup" on the other lan
[20:01:14] tgm4883: by setup, I mean the OS is still on both networks, but mythtv-setup has the MBE setup for a particular network
[20:01:32] jpharvey_ (jpharvey_! has quit (Ping timeout: 245 seconds)
[20:01:34] stuartm: tgm4883: it's probably because I'm using the EFFs HTTPS Everywhere extension, so it loads – which exists, but all the elements of the page are being loaded with an explicit protocol e.g. "http://" instead of "//"
[20:02:04] tgm4883: stuartm: yea I just noticed it's odd. I've asked in #ubuntuforums about it
[20:02:08] stuartm: tgm4883: ok, that's not the issue being reported in the ticket
[20:02:32] tgm4883: stuartm: Ok, someone else posted that ticket thinking it was related
[20:02:44] tgm4883: stuartm: so that ticket is specific to the frontend then?
[20:02:45] len_ (len_! has joined #mythtv
[20:03:37] stuartm: tgm4883: yes
[20:04:15] tgm4883: ok, i'll try explaining that in the thread. What is the ticket about? Remote frontend telnet control?
[20:05:02] stuartm: tgm4883: yes
[20:06:37] SteveGoodey: Hmm, quick count up approx 17,000 users.
[20:09:18] stuartm: I'm not aware of anything that explicitly prevents a remote frontend connecting to a remote backend on a different subnet, from what I can tell the issue is that the two networks are discrete, i.e. the backend needs to listen on two different IPs
[20:10:12] tgm4883: stuartm: correct
[20:10:13] stuartm: SteveGoodey:
[20:10:40] tgm4883: stuartm: and my understanding of what you said earlier is that should already be happening and your patch may fix that
[20:11:16] stuartm: tgm4883: for the master backend it doesn't actually happen, there we restrict the IPs as wagnerrp_ described in the unrelated ticket
[20:11:45] gregL (gregL! has joined #mythtv
[20:11:48] stuartm: what wagner rp stated in the ticket was accurate, it just wasn't actually relevant to the ticket :)
[20:12:40] tgm4883: stuartm: well it's restricted to those private addresses. But is it scanning for what addresses it should listen on?
[20:12:45] stuartm: listening on multiple IPs is that's not a configuration we normally see, and I'm not sure we can support it currently without a lot of changes
[20:13:03] tgm4883: ah ok
[20:13:18] tgm4883: so then that users specific issue is that it's currenlty working as designed
[20:13:24] SteveGoodey: stuartm: Thanks.
[20:14:22] stuartm: we listen on multiple IPs for everything else, but for historic reasons we have to restrict it to a single IP for the master backend's protocol (port 6543) because remote frontends use the BackendServerIP setting to know where to find the backend
[20:15:37] tgm4883: stuartm: ok, so I'm going to tell the user that you can't make the backend listen on multiple IP addresses. And that the correct way to do it is to forward the traffic from one network to the other, not to have the backend on multiple networks
[20:15:41] tgm4883: sound about right?
[20:15:55] stuartm: one fix would be for the master to store a list of addresses in a new setting (BackendServerIPs) but the code in a number of places would need updating so that the frontends and other clients can parse the list, pick the correct 'local' address and use that
[20:17:13] stuartm: tgm4883: for now IP forwarding is the best approach, it's not something we can fix without considerable code changes and regression testing so it's not something we'd backport
[20:18:24] stuartm: and since it's a minority configuration, one that actually requires some work to reproduce it's not going to be a high priority
[20:21:12] stuartm: in fact, I don't think forwarding will work either, that depends on being able to configure frontends to use a different IP for the backend which is not supported either
[20:25:40] tgm4883: stuartm: so what was that patch for that you posted?
[20:26:51] stuartm: the issue described in that ticket, the frontend network control not working on remote frontends – I'm not sure whether that's actually a problem in master, we may bypass that bit of code entirely, I'd need someone with a remote frontend to test
[20:27:01] tgm4883: ah ok
[20:29:57] stuartm: tgm4883: the forum issue is really a problem of two parts, even if the backend were to listen on both IPs,, the frontends still expect to find a single IP in BackendServerIP, so we'd have to either let users force each frontend to listen on a specific address (more settings, possibly fragile) or we update all the code to pick the 'correct' address from a list which is easier said than done
[20:31:27] stuartm: might be a solution which leverages the existing SSDP mechanism and does away with BackendServerIP entirely
[20:32:17] stuartm: QObject::moveToThread: Current thread (0x1b61750) is not the object's thread (0x21e0f80).
[20:32:19] stuartm: Cannot move to target thread (0x1b61750)
[20:32:31] stuartm: that's new to master ...
[20:35:49] tgm4883: stuartm: the frontends can already specify where teh backend is I thought?
[20:36:06] tgm4883: I know they can user zeroconf, but they can also specify it right?
[20:36:18] stuartm: they can specify where the database is, but not the backend
[20:36:37] tgm4883: ah
[20:36:49] tgm4883: stuartm: so I think the following sums it up
[20:36:51] tgm4883: I've been talking with upstream and the backend can listen on any private address, but multiple addresses is not. IP forwarding is not supported, but may work so it's worth at least a test. Regarding adding that functionality, upstream said "since it's a minority configuration, one that actually requires some work to reproduce it's not going to be a high
[20:36:52] tgm4883: priority". That said, you could certainly supply a patch for review.
[20:37:10] stuartm: it's an overly complicated mechanism, they use SSDP to find the backend, they ask the backend where the database is, from the database they read BackendServerIP for future connections to the backend
[20:42:27] stuartm: you have to understand that since different parts of the code were written by different people at different times they found different solutions to the same problem of how to reach the backend from the frontend
[20:43:37] stuartm: and despite mechanisms like SSDP being added, they weren't used to their full potential because that meant making a lot of changes that would need to be carefully tested which takes time and energy
[20:47:07] stuartm: I think it would make an interesting project for someone though
[20:49:21] stuartm: scrap BackendServerIP as it's currently used, have frontends use SSDP on startup to find the backend(s), each frontend should cache the name of the backend and it's IP to make for faster reconnects, but if it's unable to connect on the old IP it can try SSDP again to find the new IP
[20:51:20] stuartm: that would let the backend listen on as many different networks as you want
[20:51:48] stuartm: you'd even be able to move a frontend between networks and the frontend would automatically rediscover the correct backend
[21:11:49] tgm4883: stuartm: should throw in a setting to force a specific backend in case you have multiple separate backends in the same network
[21:11:55] tgm4883: but yea, that sounds good
[21:15:03] stuartm: tgm4883: well that's why we'd cache the id of the last selected backend, the frontend already prompts users to choose from a list when using ssdp
[21:26:00] goibhniu (goibhniu!~goibhniu@pdpc/supporter/active/goibhniu) has joined #mythtv
[21:29:42] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:33:27] Roklobsta (Roklobsta! has quit (Quit: KVIrc 4.2.0 Equilibrium
[21:36:16] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[21:36:32] skd5aner (skd5aner! has joined #mythtv
[21:48:10] jheizer (jheizer!~jheizer@ has quit (Read error: Connection reset by peer)
[21:52:01] jheizer (jheizer!~jheizer@ has joined #mythtv
[22:22:55] andreaz (andreaz! has joined #mythtv
[22:25:57] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[22:26:21] skd5aner (skd5aner! has joined #mythtv
[22:28:34] Tobbe5178 (Tobbe5178!~asdf@2001:2002:d9d4:ce1d:7924:ae24:f122:d7e2) has quit (Read error: Connection reset by peer)
[22:33:51] dekarl: man, autoexpiring stuff you want to watch while its being recorded is not so nice... (stupid me didn't remove the autoexpire flag) But I could download the episode from the stations VOD service in 5 minutes in quarter HD... really need to look into integrating that into mythnetvision...
[22:38:55] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[22:39:16] skd5aner (skd5aner! has joined #mythtv
[22:41:15] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[22:41:35] skd5aner (skd5aner! has joined #mythtv
[22:52:19] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[22:52:37] skd5aner (skd5aner! has joined #mythtv
[22:56:02] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[22:56:21] skd5aner (skd5aner! has joined #mythtv
[23:41:04] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 256 seconds)
[23:44:17] sheedy-away is now known as sheedy
[23:47:32] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[23:47:56] skd5aner (skd5aner! has joined #mythtv

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