| Sunday, April 27th, 2014, 00:13 UTC | ||
| [00:13:06] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [00:59:07] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [00:59:07] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [00:59:07] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [00:59:41] | knightr_ (knightr_!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 264 seconds) | |
| [01:08:17] | brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 265 seconds) | |
| [01:16:01] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [01:21:36] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [01:49:33] | arescorpio (arescorpio!~arescorpi@190.19.140.27) has joined #mythtv | |
| [02:07:35] | _nyloc_ (_nyloc_!~quassel@p3EE2CC48.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:11:38] | nyloc (nyloc!~quassel@p3EE2D287.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [02:15:33] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:28:20] | brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 255 seconds) | |
| [02:30:43] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [02:32:30] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:35:28] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 252 seconds) | |
| [02:35:28] | peper03_ is now known as peper03 | |
| [03:08:00] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.3) | |
| [03:08:24] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has joined #mythtv | |
| [03:08:24] | gigem (gigem!~david@pool-71-170-165-247.dllstx.fios.verizon.net) has quit (Changing host) | |
| [03:08:24] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [03:22:44] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [03:23:49] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:24:25] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [05:07:11] | arescorpio (arescorpio!~arescorpi@190.19.140.27) has quit (Excess Flood) | |
| [05:17:45] | xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Goodbye.) | |
| [05:23:51] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [05:59:54] | Goga777 (Goga777!~Goga777@128-71-38-155.broadband.corbina.ru) has joined #mythtv | |
| [06:07:53] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [06:07:53] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [06:08:02] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [06:22:48] | Goga777 (Goga777!~Goga777@128-71-38-155.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [06:23:21] | Goga777 (Goga777!~Goga777@128-71-38-155.broadband.corbina.ru) has joined #mythtv | |
| [06:25:42] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]) | |
| [06:29:19] | Goga777 (Goga777!~Goga777@128-71-38-155.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [07:10:00] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [07:12:17] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [07:13:44] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [07:21:12] | doev (doev!~doev@p4FD40F46.dip0.t-ipconnect.de) has joined #mythtv | |
| [07:31:58] | joki (joki!~joki@p5486004B.dip0.t-ipconnect.de) has quit (Ping timeout: 276 seconds) | |
| [07:37:33] | joki (joki!~joki@p54861F2C.dip0.t-ipconnect.de) has joined #mythtv | |
| [07:52:23] | dekarl: | stuartm, should two transmissions of the same movie with alternate names but the same programid be considered the same? E.g. on a US station with the US title and on BBC America with the UK title. (I'm making that one up, may as well be the german theatrical title on a movie channel vs. the german tv title on a regular tv channel) |
| [07:52:53] | SteveGoodey (SteveGoodey!~steve@host109-158-213-162.range109-158.btcentralplus.com) has joined #mythtv | |
| [08:01:18] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [08:49:49] | dekarl1 (dekarl1!~dekarl@p4FCEE64C.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:52:02] | dekarl (dekarl!~dekarl@p4FCEE6E8.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [09:13:39] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:36:45] | paul-h (paul-h!~Paul@94.6.232.146) has joined #mythtv | |
| [09:37:15] | paul-h: | jya: are you missing a continue here https://code.mythtv.org/cgit/mythtv/tree/myth . . . ter.cpp#n143 |
| [09:38:23] | paul-h: | jya: Coverity ID 1061551 Dereference after null check |
| [09:42:51] | stuartm: | dekarl1: I can't think of a reason they shouldn't be considered the same |
| [09:43:10] | paul-h: | I've lost my MythTV mojo not sure how long I can be bothered with this any more :( |
| [09:43:15] | dekarl1 is now known as dekarl | |
| [09:43:23] | paul-h: | My own fault for playing with XBMC |
| [09:43:58] | paul-h: | Make MythTV look like a pile of shit if I'm honest |
| [09:43:59] | dekarl: | stuartm, I asked because of https://github.com/MythTV/mythtv/commit/7fd0a . . . 3f587c0R2125 |
| [09:45:12] | dekarl: | also considering adding more unit tests around there, then refactor a bit (e.g. use IsGeneric() instead of GetProgramID.endsWith("0000")) |
| [09:45:27] | stuartm: | dekarl: good point |
| [09:45:30] | stuartm: | paul-h: :( |
| [09:52:18] | stuartm: | paul-h: of course it's a negative feedback loop, if no-one wants to work on MythTV because there's a better looking product available then MythTV is never going to improve and I think that would be a great shame, having some choice in the linux/open source world is a good thing |
| [09:57:39] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [09:59:02] | peper03: | dekarl: As I understand it, the title is used as the first filter and then the programids are checked afterwards so differing titles are enough to prevent duplicate detection – http://irc.mythtv.org/ircLog/channel/4/2013-09-04:18:30:43 |
| [10:02:20] | warpme: | paulh: I’m wonder what areas of XBMC You think are much better than in MythTV? |
| [10:02:51] | warpme: | except look&fell as this is I believe mainly skin thing.... |
| [10:04:16] | warpme: | s/fell/feel/ |
| [10:06:32] | SteveGoodey: | Am I right in thinking you still need e.g. Mythtv to get tv shows into XBMC? |
| [10:15:19] | dekarl: | peper03: aye, that's how it is currently implemented. But I'd like to start fix stuff. E.g. all the implicit assumptions the the guide is coming from Data Direct all over the code... Now that we get program and series ids from different DVB channels everything works a bit differently. |
| [10:19:10] | dekarl: | e.g. we have two programs with different program ids, but we know they are from different id domains, so we can't use them for comparison. |
| [10:20:46] | warpme: | I think it might be interesting to compare usecases/scenarios. I’m not sure about XBMC capab. in following scenario: lets assume case where You have house with few rooms where You want to provide SAT TV. Is this possible with XBMC alone? I think no. So key MythTV aspect is convergence of TV & rest of multimedia. You may say – TV is not big deal. Sure, but I see how biggest SAT provider here in Poland tries mimmic MythTV concept with their |
| [10:20:46] | warpme: | multiroom sol. They have small fraction od MythTV capab. but alrerady received international award for most advanced home TV system… |
| [10:22:42] | dekarl: | warpme: I think with a "plain" SAT>IP LNB and XBMC you can watch LiveTV (no recordings though). Though I'm not sure if that already works with proper SAT>IP protocol or with IPTV headend + Multicast Playlist mode of the SAT>IP server |
| [10:24:37] | dekarl: | also available as small server box that you can hook to a switch/lnb http://www.elgato.com/en/eyetv/eyetv-netstream-4sat |
| [10:30:52] | dekarl: | with SAT>IP support popping up all over the place, but without multirec (or so it appears from the brochures), it might be a nice selling point to add a SAT>IP server to MythTV. (If I understood correctly that would be more or less a variant of UPNP LiveTV support) |
| [10:31:39] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [10:34:05] | warpme: | dekarl: right. Indeed area where tablet/PC user can somehow access SAT TV is growing. I’m looking on multiroom TV mainly from usecase perspective. For my style of watching TV DVR is key. Decoupling watching time from TV schedule timeline is so convieneint. Also putting only Eth cabling in house for TV/movies/music/internet was key for me… |
| [10:38:30] | warpme: | dekarl: if I would consider where so valuable dev resources should be alocated – I think defining target MythTV use cases and make them features-complete/stable is worth to consider. I’m trying to say assgning resources to areas where competition is beter is worse strategy than improve areas of competitive advanatge. |
| [10:47:50] | warpme: | Basing on my uswers feedback (and also my personal preference) – most nice recent MythTV addition is WebFrontend. Having it compete (in sence of accessing TV/movies/music) might be really nice function for remote viewing Your media scenario. Just my 0.02$ |
| [10:48:08] | warpme: | s/uswers/users/ |
| [10:56:40] | dekarl: | that reminds me to look into having the HLS streaming obey the cut list |
| [11:08:59] | warpme: | dekarl: that would be perfect. I would say possibility to start HLS from arbitrary is even more desirable. You know when user during many Years is not forced to watch any commercials at all (because of DVR capab.), situation when he must watch them using HLS is real PAIN! |
| [11:09:42] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Read error: Connection reset by peer) | |
| [11:10:03] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [11:12:05] | stuartm: | warpme: glad to hear you like the WebFrontend |
| [11:12:18] | dekarl: | IIRC Captain_Murdoch had some plans wrt on-demand HLS transcoding, so you can start at a bookmark without having to wait until the transcode has caught up to that position |
| [11:14:04] | stuartm: | I've been momentarily sidetracked into playing with electronics atm and I'm writing a small app to make programming XRF/SRF/ARF radios stupidly easy for newbies, but I'll turn my attention back to the Webfrontend within the next week |
| [11:17:46] | warpme: | stuartm: I’ll will install XBMC to get taste about it (and compare with MythTV). I think WebFrontend is REALLY nice feature and we can consider it as another differentiator of MythTV compared to competition. For me ideal selling scenarion is home converged media server providing remote access to all content for client-less users. Saying client-less I mean standard HTML5 browser on any type device. Assuming this I think You done EXCELLENT w |
| [11:17:47] | warpme: | with WebFrontend! |
| [11:18:48] | dekarl: | stuartm, I see lots of talk about the form factor of the boards, but whats the on-air protocol? DECT-ULE? |
| [11:19:36] | dekarl: | hooking the environmental sensors of the baby phone into MythTV would be nice ;) |
| [11:20:07] | warpme: | stuartm: I know sometime period of rest can give fresh view and new energy. So nice You have plans to improve MythTV! |
| [11:22:12] | dekarl: | How common are programmes produced in 14:9? I only noticed this aspect ratio on UK series around the time of 4:3 to 16:9 migration. wrt https://www.themoviedb.org/talk/51575cfc19c29 . . . 6841e5000016 |
| [11:32:18] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [11:45:00] | jya_: | paul-h: looks like it |
| [11:45:34] | jya_: | paul-h: I can see where you’re coming from… reading various forums, more and more people seem to be switching to xbmc as frontend |
| [11:48:04] | jya_: | i do think that xbmc looks much nicer up front than mythfrontend. it does more things, the search for metadata is heaps better and faster, it works on many platforms.. |
| [11:49:05] | jya_: | but when used on a daily basis, there are 1000s of small options that are only available in myth that makes it a much better experience |
| [11:49:40] | jya_: | the almost PnP availability of the video/image/music library. start a frontend and pang it’s there with all the data |
| [11:49:58] | jya_: | being able to make a bookmark on one TV, and restart on another |
| [11:50:04] | jya_: | tiny things like that |
| [11:51:25] | jya_: | the quality of the source code in myth, is in many places a disaster. it feels like some fix with sticky tapes that no-one is willing to touch |
| [12:13:45] | warpme: | jya: maybe we should consider escape forward. Instead of thinking how to get mythtv on non-intel hw (effectively this is attempt to get mythtv on small devs.) we can consider to get it running on those devs via HTML5 browser+streaming. I would say this is more Plex like route that XBMC like one... |
| [12:16:49] | warpme: | Also services API might be key. Growing community od 3rp party devs arround services API is one from best things which happens for myth. By this we can consider to offer diferent paradigm compared to XBMC/PLEX: openess as catalyst to grow ecosystem. |
| [12:17:07] | warpme: | s/3rp/3rd/ |
| [12:35:06] | paul-h: | the xbmc add-on system is really cool http://addons.xbmc.org/ |
| [12:37:53] | dekarl: | paul-h: I hate the VoD experience where you basically have a XBMC frontend to various VoD portals and can navigate them seperately, but there's nothing like a common interface to search for content and get results from all VoD services. But I've only took a short look before I ran away screaming (and put setting up a VoD content database on the list) |
| [12:38:36] | dekarl: | basically I'd love to get VoD services integrated into Atlas and the put Mythnetvision on top of that. |
| [12:39:05] | dekarl: | (and yes, once that's done its easy to write a plugin for XBMC, too. The hard part is the mythical integration ;) |
| [12:40:56] | dekarl: | jya_, I totally agree with the source code. Everywhere I look I only find loose ends and regressions |
| [12:41:44] | jya_: | dekarl: hopefully not my code :P |
| [12:42:30] | ** dekarl whistles ** | |
| [12:42:32] | jya_: | paul-h: I think we should aim at a similar add-on system as xbmc |
| [12:43:26] | jya_: | easy to code (python) , easily integrated and adding features fully embedded into current function |
| [12:43:28] | dekarl: | jya_: I can't even remember the last time that someone contributed a addon for one of the interfaces that we do already have. e.g. weather grabber, movie grabber, etc. |
| [12:43:36] | rsiebert (rsiebert!~quassel@f052139178.adsl.alicedsl.de) has joined #mythtv | |
| [12:44:19] | jya_: | like for xbmc, i could install within a few seconds a foreign subtitle , ran it, found the subtitle and could let my wife enjoy a french movie |
| [12:44:44] | jya_: | dekarl: there’s no easy way to integrate a plugin in myth |
| [12:44:53] | jya_: | there’s no central database of any kind. |
| [12:44:58] | jya_: | like there is for the themes |
| [12:46:34] | jya_: | you pretty much need to hack things to add any functionality to myth |
| [12:46:36] | dekarl: | jya_: splitting these out into a separate repo like thems should not be a problem. But the work is not worth it if there are no contributions at all :( |
| [12:46:36] | dekarl: | e.g. https://github.com/MythTV/mythtv/tree/master/ . . . ernetcontent https://github.com/MythTV/mythtv/tree/master/ . . . pts/metadata https://github.com/MythTV/mythtv/tree/master/ . . . ther/scripts |
| [12:46:42] | rsiebert_ (rsiebert_!~quassel@g225115106.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [12:46:57] | dekarl: | Ohh, there are some weather scripts. Still not so many |
| [12:47:45] | jya_: | dekarl: what entitlement would their be to anyone contributing to myth really? seeing on how we manage our devel list.. either there’s no answer, or the tone is rather unfriendly… |
| [12:51:17] | warpme: | jya, dekarl: I think gathering opinions from 3rd party devs working i.e. with servicesAPI might be valuable pointers about what should be changed/improved if we want to encourage new ppl into project |
| [12:51:25] | paul-h: | dekarl: the xbmc add-on systems is far superior to anything we have right now – even allows you to create the GUI to go with the add-on all through easy to use python |
| [12:52:23] | jya_: | agreed |
| [12:52:58] | dekarl: | jya_, aye. |
| [12:53:33] | jya_: | actually, what worries more so, is that there are areas no-one in the dev team has the skill to fix. Like the VDPAU issue with some videos. I looked into it, but that’s way over my head. I wrote to markk hoping he could have a look seeing that it’s his code, but he didnt answer me |
| [12:54:44] | jya_: | i think it has something to do with the number of frames kept in the buffer ; when using VDPAU there are only 4; while using ffmpeg decode there are over 12 |
| [12:57:12] | dekarl: | hmm, removing old stuff from the rendering system would be nice (finish the move to mythui, make opengl mandatory, so we can use shaders for color space conversion, think #10922, etc... lots of loose ends :( |
| [12:57:12] | ** MythLogBot http://code.mythtv.org/trac/ticket/10922 ** | |
| [12:57:44] | dekarl: | seeing such patches sit in a ticket for two years makes me sad |
| [13:01:54] | warpme: | dekarl: this is probably result of issue jya mentioned. I’m wonder by what reasons markk feft project. Not to ask him to return – but rather for learning what might be improved |
| [13:05:33] | dekarl: | IIRC there was much resistance to rip out old stuff to get our technical debt under control |
| [13:07:34] | jya_: | that one look simple enough (not the code, the difficulty in applying) |
| [13:09:14] | jya_: | it all sparked with the team refusing to integrate the AirPlay RSA key in the source code |
| [13:09:24] | jya_: | but there were lots of underlying problems |
| [13:13:48] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]) | |
| [14:03:01] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [14:04:05] | stuartm: | dekarl: tbh not too sure about the radio protocol, for the end user it's basically a serial device, they promote the use of their own data protocol LLAP which is really very basic but fine for the intended usage of these things (remote control/programming of pi/arduino like devices, or basic functions such as remote sensors/relays) |
| [14:04:52] | stuartm: | they aren't compatible with other devices operating in the same frequencies |
| [14:05:13] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [14:07:38] | stuartm: | dekarl: I was going to raise the subject of ripping out old stuff again, not just old technologies like Xv and the QT painter but also old themes, and an even more aggressive cull of little used features/screens and settings |
| [14:11:18] | stuartm: | paul-h: I've mulled a complete re-write of our plugin system and the addition of script backed widgets (user script just provides values to insert into theme defined placeholders), but I'm probably still thinking too small |
| [14:12:49] | stuartm: | fwiw, it might not be too much of stretch to make mythui accessible via the services API, so you can create and define screens through whatever scripting language you want |
| [14:16:47] | dekarl: | Ahhh Lightweight Local Automation Protocol , not LocalTalk Link Access Protocol ;) |
| [14:17:20] | stuartm: | heh yeah |
| [14:19:07] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517]) | |
| [14:23:23] | stuartm: | the company that develops them (based on TI radios) is local to me – http://shop.ciseco.co.uk/ |
| [14:26:21] | stuartm: | I'm toying with automating some stuff (heating/watering) in the greenhouse and wireless control of garden lighting, that sort of basic and fairly unoriginal stuff :) I've thought about how it might be used with MythTV, but I've been unable to come up with any ideas that aren't already possible with system events and a script (dimming lighting etc) |
| [14:27:55] | wagnerrp: | i've been trying to come up with a cheap wire protocol to link in a bunch of IO nodes |
| [14:28:16] | wagnerrp: | i want to run something out to the pool to instrument the pump and other equipment, but don't want ethernet |
| [14:29:02] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv | |
| [14:29:46] | wagnerrp: | there's no real reason i couldn't, but i rather have some kind of bus that can just tie in new devices directly, rather than needing a switch |
| [14:32:24] | stuartm: | I'm fairly new to this stuff and going with a wireless solution appealed because running additional cabling would have been a lot of work, and probably more expensive ultimately |
| [14:33:38] | stuartm: | I'm likely to stick with their protocol as their own sensor firmwares use it, so it's easier than rolling my own |
| [14:37:18] | stuartm: | it's a bit silly to call it a protocol really, it's almost too lightweight for the title 12 byte packets – first byte is the packet start indicator 'a', then a device ID e.g. AB, the command/descriptor e.g. TMPA followed by any values e.g. 18.14 |
| [14:37:45] | stuartm: | so a temperature reading send from the greenhouse becomes aGHTMPA18.14 |
| [14:39:46] | stuartm: | - is used to pack out the 12 bytes e.g. "aGHBATT2.35-" is a periodic packet telling me that the battery on the GH device is providing 2.35v |
| [14:41:30] | stuartm: | http://shop.ciseco.co.uk/llap/ http://openmicros.org/index.php/articles/85-l . . . ap-reference |
| [14:42:32] | stuartm: | note that I'm not endorsing it, I'm not familiar with the alternatives or suitability for your particular purpose |
| [14:43:19] | Goga777 (Goga777!~Goga777@128-71-218-43.broadband.corbina.ru) has joined #mythtv | |
| [14:54:20] | stuartm: | of course there's a little more to it at the radio level, there are network ids + AES encryption etc, so it's a protocol within a much more complicated protocol served up via rs-232 serial |
| [14:57:59] | stuartm: | and if a packet gets lost somewhere, well you might never know (this is where it's suitability for alarm systems comes into question) |
| [14:58:05] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [15:26:38] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [15:28:06] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Client Quit) | |
| [16:31:51] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [16:55:37] | Goga777 (Goga777!~Goga777@128-71-218-43.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [17:00:41] | Goga777 (Goga777!~Goga777@128-71-218-43.broadband.corbina.ru) has joined #mythtv | |
| [17:07:43] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [17:09:34] | Goga777 (Goga777!~Goga777@128-71-218-43.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [17:35:18] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [18:01:29] | monkeypet (monkeypet!~monkeypet@c-24-6-133-78.hsd1.ca.comcast.net) has quit (Ping timeout: 264 seconds) | |
| [18:07:36] | tonsofpcs (tonsofpcs!~mythbuntu@rivendell/member/tonsofpcs) has quit (Ping timeout: 240 seconds) | |
| [18:09:21] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [18:09:45] | tonsofpcs (tonsofpcs!~mythbuntu@cpe-67-255-119-102.stny.res.rr.com) has joined #mythtv | |
| [18:16:56] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [18:18:03] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [18:32:48] | gigem: | dekarl: Program titles must match before any other duplicate checking is done. We tried very briefly using just programid a while back, but it made scheduling way too slow. Specifically, it was the checking of the oldrecorded table for previous recordings. |
| [18:35:58] | gigem: | jya: XBMC does indeed look nice and has much nicer eye candy than MythTV. I've never tried to use it for any extended period of time, though, since recorded TV is by far my primary use case and the DVR interface in XBMC is way behind mythfronend in that functionality. |
| [18:37:58] | gigem: | stuartm: I'm also in favor of ripping out old stuff like Xv, Qt painting, analog/framegrabber recorders and other little used stuff. I only ask that if it something I actually used, it be ripped out in such a way that I can try to maintain it locally for myself. |
| [18:39:00] | dekarl: | gigem, strange. I wonder if I can fix ProgramInfo etc, but leave the scheduler SQL alone. |
| [18:39:20] | dekarl: | then revisit the SQL later and try to find out why its slowed down |
| [18:45:18] | stuartm: | gigem: if it's a feature used by a developer I'd be inclined to leave it alone, there's plenty of stuff that is obsolete which can go first |
| [18:48:19] | stuartm: | ripping stuff out, isn't a solution on it's own, but maybe it will focus attention on improving what's left i.e. if someone is using Xv simply because something doesn't work so well for them with vdpau, they'll have good reason to see it fixed |
| [18:50:41] | stuartm: | something for the next release anyway, we've got a rough set of goals for 0.28 (aka 1.0), if we get that out the door in reasonable shape users will be more forgiving when we tell them the next release will be a break with the past |
| [18:51:07] | gigem: | stuartm: Regarding your other showing/same program changes. I apologize for being so delinquent in giving you feed back. Short of serious errors in one of my areas, I don't have a lot of time for MythTV development. Perhaps it would help if you told me what you're trying to accomplish. As it stands, I'm not really in favor of the changes. My biggest problem is that it gives the user the false impression |
| [18:51:09] | gigem: | that a program is scheduled to record on some channel when it isn't. Admittedly, I'm looking at the issue from a scheduling point of view and just because some program happens to be on another channel at the same time does not mean it's scheduled. In short, recstatus should only be applied to programs that are actually scheduled. Also, why is that specific case of such interest? Isn't it just as |
| [18:51:11] | gigem: | interesting if that program is on at another time too? Again what are you trying to accomplish? If it's to catch cases where programs can be on any of a family of networks (eg. ESPN/ESPN2/ESPNU, BBC1/BBC2, etc.), I think extending the scheduler to handle network groups would be a better approach. |
| [18:53:33] | gigem: | stuartm: My reason for suggesting to consider pet developer features for removal is to continue simplifying things. Don't get me wrong, I love the power of MythTV, but even I've come to accept that it is way more complicated for many people. |
| [18:53:40] | stuartm: | gigem: it's specifically to handle the case where the same channel with SD/HD or regional variations are all in the program guide – the existing situation can give the false impression that the showing _won't_ be recorded |
| [18:55:26] | stuartm: | if you've got 20 different versions of BBC One in the guide, spread around because of different channel numbers, you don't want to have to check each and every one in the guide to see whether a programme will be recorded |
| [18:55:41] | gigem: | stuartm: SD/HD *should* use the same callsign. That's specifically what the feature is for. Regional variations could be handled with the netwrok family thing I mentioned. |
| [18:56:09] | stuartm: | fwiw, the changes don't say "This showing will be recorded", it says "This showing will be recorded on another channel" |
| [18:57:06] | stuartm: | which IMHO is better than the status quo where it either says "This programme will be recorded at a later date" or it doesn't indicate that it will be recorded at all |
| [18:57:31] | stuartm: | it really doesn't change much, just gives the user more information |
| [18:58:12] | gigem: | I know, but you're still blurring the fact that showing on that channel is *not* scheduled. Again, why is the case, and only the case, where it will be recorded on another channel so important. Is it really more important than the cases where it won't be recorded at that time, but will at another? |
| [18:58:52] | stuartm: | fwiw, the change I committed which highlights those programmes in green will be reverted/replaced, if you see how those are handled in the WebFrontend they get their own colour highlight (blue) indicating that a rule exists matching that showing but not that the exact entry will be recorded |
| [18:59:29] | stuartm: | gigem: the latter cases are already handled correctly |
| [18:59:32] | stuartm: | the former isnt' |
| [19:00:30] | stuartm: | in the former case it doesn't indicate that it will be recording at that time |
| [19:01:11] | gigem: | It will be a very rare case for me, which is why I haven't raised a big stink. I'm more concerned about the support aspect. It's hard enough getting sufficient details to diagnose problems from some users and this could make it much harder. |
| [19:02:12] | stuartm: | I really cannot understand how it could cause more confusion – all it does is change the string which appears to be more accurate |
| [19:02:12] | gigem: | Right, but isn't just as important to let the user know it *is* scheduled and will or will not be recorded at some other time? That's why we have the early/later showing and conflict statuses. |
| [19:02:42] | stuartm: | gigem: sorry, you've lost me now |
| [19:04:14] | stuartm: | I'm not sure we're understanding each other or what the change I made actually does |
| [19:06:05] | stuartm: | it only exposes the rsOtherShowing status to the user, it doesn't falsely give the impression that something will record when it won't or otherwise hide the future recording status (at least that's not the intent) |
| [19:09:00] | gigem: | Unless you've made more changes or reverted something, this is how it could be confusing. Say you schedule something on BBC1. You have two instances of BBC1 (terrestrial and satellite) and There are 3 showings, one showing gets marked will record, another (at the same time) gets marked other shwoing, and the rest get marked as earlier/later showing. Now, let's say BBC2 just happens to have 3 showings of |
| [19:09:02] | gigem: | the same program and one is at the same time it will record on BBC1, another at the same time as one of the earlier/later showings on BBC1 and the last at a completely different time. As I understand your changes, one BBC2 showing will automagically get marked as other showing, and the others won't get marked at all. My point is if you're trying to give the user as much information as possible, why are the |
| [19:09:04] | gigem: | other showings marked as earlier/later as well? |
| [19:09:07] | stuartm: | I really do think it simplifies things rather than the other way around and yes, it makes more of a difference in some countries than others where you've got the exact same programme being broadcast simultaneously on different channels – critically it does this without the user having to micro manage their channels into groups or to use the same callsign (a concept which is completely foreign outside the US FWIW) |
| [19:10:14] | stuartm: | gigem: that's not what happens at all |
| [19:10:57] | stuartm: | all showings at the same time get marked "Other showing", the others would all be correctly marked as "Earlier/later" just as they were previously |
| [19:11:15] | gigem: | Callsign is just the term we use over here. I'm sure everyone else also has shorts by which they refer to their channels. |
| [19:13:03] | stuartm: | if 10 different channels show the exact same program at the exact same time, one will be marked "Will record" the other nine will be marked "Other channel/showing", those at different times are still marked as "Earlier/later" |
| [19:13:04] | gigem: | Then I don't think I understand your change. Or it actually changes more programs than you think it does. I'll run a test later to confirm it either way. |
| [19:13:52] | stuartm: | gigem: it's possible I've overlooked something, but I've been using the changes for months and never had anything marked incorrectly |
| [19:14:33] | gigem: | I could be wrong, and I will check, but the last time I looked at the changes, I believed it would also mark programs that weren't scheduled at all as other showing too. That's my concern. If that's not the case, then I don't have a problem. |
| [19:14:52] | stuartm: | the recent ticket raised a scenario with the recording popups for an "other showing" case, that's easy to fix and I will be doing so soon |
| [19:15:55] | stuartm: | gigem: well to be honest I do most often use "Record All" or "Record One", exactly what it should do for "Record this showing" I've not given so much thought to |
| [19:17:10] | gigem: | Okay. I'll run a few tests later and will let you know the results. I hope I'm wrong and this is all much to do about nothing. |
| [19:21:22] | stuartm: | I still tend to believe that when most users chose "Record this showing", it's still not confusing for it to say on other channels "This programme will be recorded on another channel", if only so users know they did schedule it already – I know we're disagreeing slightly on the terminology of 'showing' – for me, the same programme (same episode/content) on at the same time is the same showing no matter if it's on a completely different channel |
| [19:22:47] | stuartm: | gigem: fwiw, I would first revert https://github.com/MythTV/mythtv/commit/82b02823c4 – that commit can cause confusion and wasn't part of my original change, it's clearer in the WebFrontend guide where we highlight earlier/later/other showings in their own colour |
| [19:23:20] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [19:32:10] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 276 seconds) | |
| [19:32:22] | Seeker` (Seeker`!~cjo20@host86-150-48-131.range86-150.btcentralplus.com) has joined #mythtv | |
| [19:32:23] | Seeker` (Seeker`!~cjo20@host86-150-48-131.range86-150.btcentralplus.com) has quit (Changing host) | |
| [19:32:23] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [19:47:19] | stuartm: | gigem: I thought I'd used a more distinctly different shade/colour, but here's an example from tonight of the same episode being shown on three different channels – two at the same time, one an hour later – http://mythtv.co.uk/imagebin/other_showing.png |
| [19:48:03] | jpharvey (jpharvey!~jpharvey@host86-179-38-232.range86-179.btcentralplus.com) has quit (Remote host closed the connection) | |
| [19:49:47] | stuartm: | the dark green one is the one which will be recorded, the light green indicates otherShowing/earlierShowing, now unfortunately I couldn't get the hover popup to remain on screen while I took the screenshot but the later episode is correctly showing "Earlier showing" while the concurrent showing shows "Other showing" |
| [19:50:52] | stuartm: | when I have more time I'll get a better screenshot showing multiple concurrent showings of the same programme |
| [19:51:00] | stuartm: | i.e. more than just two |
| [19:53:09] | stuartm: | and yes, light green/dark green might be too subtle a distinction, started off with the dotted green border style that was used in mythweb but I didn't actually like it |
| [19:56:41] | jpharvey (jpharvey!~jpharvey@host86-179-38-232.range86-179.btcentralplus.com) has joined #mythtv | |
| [19:57:00] | monkeypet (monkeypet!~monkeypet@c-24-6-133-78.hsd1.ca.comcast.net) has joined #mythtv | |
| [20:14:33] | dekarl: | our ffmpeg doesn't yet have av_guess_frame_rate? I'd love to leave the details to the ffmpeg project re #12047 http://lists.ffmpeg.org/pipermail/ffmpeg-deve . . . /141279.html |
| [20:14:33] | ** MythLogBot http://code.mythtv.org/trac/ticket/12047 ** | |
| [20:23:46] | dekarl: | looks like its only in 2.0 and improved in 2.2 https://github.com/FFmpeg/FFmpeg/commit/ef7b6 . . . e130cbd125c9 https://github.com/FFmpeg/FFmpeg/commit/2969f . . . ae542ca9eef8 |
| [20:28:01] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [20:31:38] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 252 seconds) | |
| [20:31:38] | peper03_ is now known as peper03 | |
| [21:10:16] | gigem: | stuartm: As I suspected, your changes are too aggressive and can incorrectly mark unscheduled programs as other showings and not add any indication whatsoever to unscheduled showings at other times on other channels. To recreate, give SD and HD versions of the same channel different callsigns (it sounds like this is already your norm) and schedule an all record with the this channel filter set. For the |
| [21:10:18] | gigem: | showings on the other channel (the one you didn't originally schedule on and, technically, aren't scheduled) only the ones that occur at the same time as the real recordings get marked as other showing. All of the others don't get marked with anything. That is what I don't like. I'll try to come up with a better way to mark programs as other showing, but doesn't mark unscheduled programs in the process. |
| [21:19:20] | stuartm: | gigem: ok, I'm finally understanding what your objection is :) |
| [21:21:46] | stuartm: | not that I personally have any issue with it marking 'unscheduled' programs as 'other showing', since technically that's still an accurate description but I can see the descrepancy that it doesn't do the same for earlier/later showings |
| [21:23:08] | _nyloc_ (_nyloc_!~quassel@p3EE2CC48.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [21:23:08] | stuartm: | given I don't use normally use the 'this channel' filter I concede that excluding the other channels in that circumstance is easier than adding rsOtherEarlierShowing etc |
| [21:26:56] | nyloc (nyloc!~quassel@p3EE2CC48.dip0.t-ipconnect.de) has joined #mythtv | |
| [21:27:15] | dekarl: | wrt callsign, I don't think we have anything close. We get the name of the service via SDT and its "4plus" vs "4+" vs "vier+" vs "Vier+" in all variants, nothing to make sense of automatically. Add the HD, +1, +24, regional variants and you've got lots of service names that all map to a channel that carries mostly identical content |
| [21:28:50] | stuartm: | dekarl: yeah, we've had the discussion about this previously, to the best of my knowledge and largely confirmed in the past few if any countries have something like the callsign – a unique and consistent identifier for a given channel |
| [21:30:19] | stuartm: | channels have names, the names can and frequently do change, sometimes significantly, other times subtly (distribution of spaces, capitalisation) basically any time a broadcaster decides the answer to their low ratings is to reband |
| [21:30:22] | dekarl: | well, we do have the same call signs, e.g. DCF77 for the radio time service, but our tv company structure and the US company structure leads to completely different solutions. So the call sign has no meaning for tv services |
| [21:31:09] | dekarl: | hehe, and there's Christmas24 vs. Movies24 changing its brand twice a year |
| [21:32:23] | wagnerrp: | stuartm: problem i'm having is im unsure where to start, since i do have experience in it, but only in industrial buses |
| [21:32:24] | stuartm: | and no-one wants to manually fix up their 'callsign' field when they've got an 800 channel satellite lineup |
| [21:33:09] | wagnerrp: | where the IO hardware is $500, plus $150 per card, and $1500 for a PC interface card because they're low volume and implemented on an FPGA... just because they can :) |
| [21:33:15] | dekarl: | Atlas and Nick's grabber both have metadata that could be used to map "mostly the same programming" channels together |
| [21:33:37] | dekarl: | but I don't know of machine readable data outside of the UK |
| [21:33:47] | wagnerrp: | i seriously can't fathom why one would need an FPGA to drive a single 12Mbps differential pair |
| [21:34:05] | skd5aner: | I've been pretty quiet lately, but I read the backlog conversation of today, and lots of good discussion. I really hope MythTV can continue to evolve and differentiate itself from things like XBMC, but honestly – they're blowing mythtv out of the water when it comes to community, innovation/features, UI, and other feature/functionality items... |
| [21:34:08] | stuartm: | wagnerrp: well you're already well ahead of me as I'm a complete novice :) I wouldn't have a clue where to start with a wire protocol, data's a bit different |
| [21:34:57] | dekarl: | skd5aner: I beg to differ, they blow us out of the water wrt marketing and tooting their horn on feature. e.g. audio engine |
| [21:35:13] | stuartm: | wagnerrp: in your position I think I'd probably come down to using an established solution, either ethernet or serial |
| [21:35:16] | skd5aner: | I think mythtv still rules when it comes to the foundation that is the DVR functionality, and certain things that go with that... but really, I remember the days when there was excitement to release new plugins, when new functionality came in bulk during releases... |
| [21:36:06] | skd5aner: | now, there's a generally long release cycle with few features to "brag" about and a lot of under-the-covers work... not to devalue those contributions, but a non-developer user only sees the changes they see via usage... |
| [21:37:21] | skd5aner: | dekarl: yup, better at marketting... and perhaps making a "sexier" product – but that stuff brings users, and with users come contributors, and with contributors comes developers... it's a cycle that's working for them |
| [21:37:27] | stuartm: | skd5aner: well I for one admit to be short of ideas for new features, aside from on-demand streaming (which is a constant and likely unwinnable battle) I really can't think of much that MythTV lacks |
| [21:37:33] | skd5aner: | and stealing away those same things from this project |
| [21:38:24] | skd5aner: | stuartm: well, for so many years feature requests from the community were met with "either submit a patch or don't speak up at all" at worse, and at best was "enter it on a wiki page that hardly anyone ever checks... |
| [21:39:55] | skd5aner: | stuartm: I admit that, shy of a few things I'd like, it's really good at doing the core things related to DVR... but there are tons of holes. I can do playlists in recordings, but no videos, for example... I can do commercial skip in recordings, but not videos, etc... |
| [21:40:09] | stuartm: | well to be fair, many of those feature requests were sent to the wiki because they were stupid (no, really they were) – if the idea really was any good it was either something that the devs wanted to do anyway, or it was taken on board |
| [21:40:09] | skd5aner: | most of the plugins need some serious TLC |
| [21:40:37] | skd5aner: | Some, I suppose... I should really go out there – it's been 2 years since I think I last peaked... |
| [21:40:47] | dekarl: | stuartm, we lack H.264 virtually lossless transcoding. It looks like no one else has it either and our MPEG-2 virtually lossless transcode also appears to be a unique selling point. Lets add hardware supported MPEG-2 -> H.264 transcode for all the new chips that support it. And we have something to go shopping for users ;) |
| [21:41:33] | stuartm: | playlists in videos is so stupidly easy that I actually got angry with another dev who wouldn't just copy and paste the feature from the recordings screen (maybe I'll do it tomorrow if I remember this conversation) |
| [21:41:38] | skd5aner: | I know what I'm saying comes off as negative, but really it's tough love... I really love being a part o this community and project. After 10 years, I want to stick with MythTV until I don't have any other options... |
| [21:42:08] | stuartm: | dekarl: ah, yeah that's one feature I'd like, but one way outside my skill set |
| [21:42:26] | skd5aner: | but at the same time, I look at some of the other stuff coming out around it and think "man, I wish MythTV could do that, or looked like that, or blah blah blah" because for a long time I thought MythTV was the leader in the space, but I don't really think that's true anymore |
| [21:42:39] | skd5aner: | I can tell you... as an FYI... |
| [21:43:03] | skd5aner: | I'm getting ready to move, and unfortuantely, it looks liek I'm going to be switching to satellite. Which means I'm going to have to use HD-PVRs exclusively connected to my STBs to record. |
| [21:44:05] | skd5aner: | Skipping and rewinding/ffwd is REALLY painful on HD-PVR h.264 material... I'm kinda dreading that. I'm curious if XBMC can handle that better or if they have the same issues because of how ffmpeg handles it |
| [21:44:09] | dekarl: | and getting closer to ffmpeg known-good-practice would be nice. I remember a high WTF! frequency when we looked at mythtranscode issues the last time ;) |
| [21:44:58] | dekarl: | currently playback startup takes 10–20 seconds on a diskless remote FE, but I didn't see anything obvious :/ (hoping that the ringbuffer changes might improve it a bit) |
| [21:45:15] | stuartm: | skd5aner: is that still the case? I thought there was some recent work specifically to help with the huge keyframe gaps on HDPVR material |
| [21:46:08] | skd5aner: | stuartm: still running 0.27, so perhaps in master |
| [21:46:17] | skd5aner: | I've been REALLY out of the dev cycle loop for a few months |
| [21:46:28] | skd5aner: | life has really... taken a hold of me :) |
| [21:50:09] | wagnerrp: | stuartm: i could layer something simple on top of rs-485 |
| [21:50:36] | wagnerrp: | that's honestly all many industrial buses do, except they standardize the hardware a bit more, and charge you out the ass |
| [21:58:17] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Read error: Operation timed out) | |
| [22:02:47] | skd5aner: | as an FYI, I'm starting to get in to some home automation stuff, but primarily just zwave devices like lighting switches... it's amazing how fragmented the market is on protocols |
| [22:04:29] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [22:04:32] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 245 seconds) | |
| [22:05:12] | dekarl: | paul-h: re #12063 I can take a look at it if you want |
| [22:05:12] | ** MythLogBot http://code.mythtv.org/trac/ticket/12063 ** | |
| [22:05:28] | SteveGoodey (SteveGoodey!~steve@host109-158-213-162.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:05:36] | skd5aner: | I built a house several years ago, and wired cat5 to every lightswitch outlet in the house in preperation to use ALC OnQ, but by the time I finished building the house, Lengrad discontinued the line... so I started looking at wireless solutions rather than wired |
| [22:05:49] | skd5aner: | I think that's the general direction to go anyway... |
| [22:06:04] | stuartm: | aye it's a shame about the fragmentation, and that while you can get low priced kit based on open/standard protocols it tends to look rubbish, conversely you can get nice looking stuff that's entirely proprietary |
| [22:06:33] | wagnerrp: | wireless for static installation... blasphemy... :P |
| [22:07:08] | stuartm: | wireless for light switches is a problem here, I've not actually tried it but brick walls with metal back boxes ... |
| [22:07:17] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [22:07:22] | skd5aner: | Google announced "Android@Home" as their HA platform doing their IO conference a few years back, then quiet let that project die... musta thought the space wasn't ready yet |
| [22:08:04] | skd5aner: | wagnerrp: well, for new construction, it was a major pain to run cable to light switches... for retrofit, it'd be next to impossible |
| [22:08:37] | skd5aner: | I probably had at least 1 mile of cat5 to every switch in my house... man that was a hard project |
| [22:08:47] | skd5aner: | and then, never used a single one of them :P |
| [22:08:53] | skd5aner: | waste of time and money |
| [22:08:56] | stuartm: | no way I'm giving Google even more access to my personal data – let's face it, they only want to get into that space to know how often you're at home, how much TV you watch, how frequently you visit the bathroom ... too creepy |
| [22:09:11] | wagnerrp: | yeah, that's why a star topology protocol makes no sense for distributed device nets |
| [22:09:22] | skd5aner: | stuartm: yup, i'm sure that's true... but I'd give an arm and a leg for Google Fiber right now |
| [22:10:47] | stuartm: | wagnerrp: well this is one reason wireless is so appealing, you can create a network and add new nodes without a major construction project |
| [22:11:07] | skd5aner: | stuartm: I've had good luck with zwave switches, but yea... construction materials can make/break it. Also, you get what you pay for... I bought a ton of GE switches 80% off when Radio Shack was clearing them out, some of them can act a little funky |
| [22:11:28] | stuartm: | but there are practical issues, such as the fact that wireless can be stunted by older (more solid) construction materials :( |
| [22:11:57] | skd5aner: | Yea, that's how zwave works... add a switch, add it to the the network, and it "just works" – each switch you add acts as a relay as well, so you can extend the reach of your network |
| [22:12:49] | skd5aner: | at the end o the day though, I wish everything was just IP 802.11 based... would make app development easier |
| [22:27:09] | paul-h (paul-h!~Paul@94.6.232.146) has quit (Quit: Konversation terminated!) | |
| [22:34:35] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:37:11] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
