| Thursday, August 9th, 2012, 00:06 UTC | ||
| [00:06:27] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has joined #mythtv | |
| [00:51:45] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [01:20:38] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [01:31:17] | Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Quit: “The only way to have a friend is to be one.†― Ralph Waldo Emerson) | |
| [01:35:57] | Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv | |
| [01:36:46] | joki (joki!~joki@p54862C2B.dip.t-dialin.net) has quit (Ping timeout: 246 seconds) | |
| [01:37:22] | joki (joki!~joki@p54862C3D.dip.t-dialin.net) has joined #mythtv | |
| [01:41:25] | foxbuntu (foxbuntu!~foxbuntu@75-170-223-95.desm.qwest.net) has joined #mythtv | |
| [01:41:26] | foxbuntu (foxbuntu!~foxbuntu@75-170-223-95.desm.qwest.net) has quit (Changing host) | |
| [01:41:26] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv | |
| [03:06:37] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:20:35] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [03:34:14] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:34:37] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [05:01:05] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 272 seconds) | |
| [05:08:31] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [05:19:10] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has joined #mythtv | |
| [05:35:52] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 245 seconds) | |
| [05:43:55] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:00:42] | bill6502 (bill6502!~bill@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has left #mythtv () | |
| [06:02:00] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has joined #mythtv | |
| [06:15:33] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [08:12:25] | jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv | |
| [08:12:26] | jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host) | |
| [08:12:26] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:14:24] | xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0) | |
| [08:22:17] | rsiebert (rsiebert!~quassel@g231187081.adsl.alicedsl.de) has joined #mythtv | |
| [08:25:13] | rsiebert_ (rsiebert_!~quassel@g231185022.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds) | |
| [08:42:30] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [09:26:16] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [09:26:16] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [09:26:16] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [10:01:12] | zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv | |
| [10:01:12] | zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host) | |
| [10:01:12] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [10:02:03] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [10:02:50] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has quit (Ping timeout: 268 seconds) | |
| [10:51:05] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [10:51:42] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [11:29:20] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has joined #mythtv | |
| [11:36:21] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [11:40:32] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [11:40:41] | Leesnick (Leesnick!~anonymous@dsl-58-6-152-25.vic.westnet.com.au) has left #mythtv () | |
| [12:02:28] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 244 seconds) | |
| [12:02:30] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [12:05:07] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [12:21:29] | andreax (andreax!~andreaz@p5089E0C5.dip.t-dialin.net) has joined #mythtv | |
| [12:29:45] | jya: | danielk221: looking at why LiveTV doesn't start on my box, I found something rather peculiar |
| [12:30:50] | jya: | I see that TVRec::StopLiveTV is called following MainServer::SendResponse -> MSocketDevice::writeData closing the connection write after calling waitForMore |
| [12:31:12] | jya: | there's a test: if (!timeout) { // connection closed close(); } |
| [12:34:09] | danielk221: | jya: I can't look at it right at this moment, but if you can add some details.. line #'s & log I'll look at it later today. |
| [12:34:35] | jya: | looking at the code for waitForMore, the value if timeout dictates how it will behave. The timeout value isn't initialise in MSocket::Device, so the behaviour of that call is undefined |
| [12:34:54] | jya: | I'll send an email then |
| [12:36:13] | jya: | hum… actually, i'm not reading this properly… but why does writeData close the connection as part of SendResponse, is unknown to me |
| [12:38:27] | jya: | danielk221: does liveTV with HLS work for you? |
| [12:41:32] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [12:42:44] | danielk221: | Last I checked yep |
| [12:44:41] | danielk221: | It wasn't super smooth though. |
| [12:44:52] | jya: | hum... |
| [12:44:56] | jya: | I wonder if that's the cause: |
| [12:45:26] | jya: | http://pastebin.com/6B9AQm6H |
| [12:46:20] | jya: | see that readStringList timed out after 7s ? the backend would take more than 7s to start playback from where I'm located (US stream), so the frontend closes the connection, and as such, the backend kills it before |
| [12:47:04] | jya: | now where do I find this timeout value :) |
| [12:48:10] | jya: | Al Jazeera quality has dropped significantly over the past few weeks, but Nasa TV is still grea |
| [12:48:12] | jya: | t |
| [12:48:52] | danielk221: | jya: Hmm, there really shouldn't be any time we don't respond to a readStringList within a second or less. Even if the recording isn't happening the TVRec even thread should be running. |
| [12:48:59] | danielk221: | s/even/event/ |
| [12:49:24] | jya: | maybe there's a wait somewhere? |
| [12:49:31] | jya: | will try to increase the timeout, will see |
| [12:50:18] | danielk221: | The 7 second timeout is in the mythsocket code, 7 seconts is the "short" timeout and 30 seconds is the long one. |
| [12:51:07] | jya: | that works ! |
| [12:51:10] | danielk221: | It would be good to know that the message is when we timeout.. |
| [12:51:26] | jya: | changed the timeout to 60s in MythSocket::readStringList |
| [12:51:30] | danielk221: | cool.. that gets us somewhere :) |
| [12:51:33] | jya: | started 3 times out of 3 |
| [12:53:31] | jya: | yep.. that seems to make it work |
| [12:53:49] | jya: | can take a while to start, but it does start |
| [12:54:23] | jya: | changing channels work too |
| [12:54:38] | jya: | cool |
| [12:55:16] | jya: | so, for some reasons, the backend stops responding while the HLSRingBuffer is seeking for new data |
| [13:00:59] | jya: | danielk221: here is the complete output of the backend when it makes mythfrontend timeout |
| [13:01:01] | jya: | http://pastebin.com/91ahKDap |
| [13:01:16] | danielk221: | Ok, so we should be able to look at what is blocking by looking the stack trace during during that pause. |
| [13:03:51] | jya: | ok… let me know if there's anything more you want me to provide… i'm a bit wreck today, can't stay up. my dad passed away last night.. been a tad rough |
| [13:03:53] | danielk221: | BTW It should be pretty simple to adapt to the new IPTVRecorder after the merge, just make the HLS RingBuffer class inherit from IPTVStreamHandler and implement the StreamHandler interface + make the IPTVStreamHandler factory return an HLSStreamHandler when the stream is an HLS one. |
| [13:04:21] | danielk221: | jya: ugh, attend to family matters this can wait |
| [13:04:46] | jya: | will look at it as soon as you do the merge, I expect that having the HLS recording not working for a few days is fine. |
| [13:05:04] | jya: | nah, I have to fly 17,000km first, and that keeps my mind busy |
| [13:05:46] | danielk221: | Well a backtrace during that pause would help. It might take a couple tries before we see what's really causing the blocking. |
| [13:06:30] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:06:34] | jya: | ok… i'll do a breakpoint in the two area where the HLS recorder would wait.. and post those |
| [13:06:48] | danielk221: | thx |
| [13:18:33] | jya: | danielk221: ticket #10934. I've attached two logs and two backtrace. log1.txt is with a breakpoint right after the initial packet prefetch. bt1.txt is the corresponding backtrace. log2.txt is with a breakpoint in the wait in safe_read that pause until there's a bit of data ahead (we've almost reached the end of the stream) with the corresponding backtrace |
| [13:18:33] | ** MythLogBot http://code.mythtv.org/trac/ticket/10934 ** | |
| [13:22:52] | jya: | danielk221: maybe that's why you thought the m_hls->Read not exiting immediately was the issue. all it really did is slightly delay things so the timeout on the frontend kicked in and dropped the connection |
| [13:23:02] | danielk221: | jya: bt1 is interesting, it looks like we're in Open() which is expected to return pretty much instantly. |
| [13:23:20] | jya: | i see.. |
| [13:23:29] | danielk221: | jya: I don't think bt2 is an issue since we have a mechanism to make the safe_read exit. |
| [13:23:47] | jya: | yeah, the HLS Open won't be fast on a stream like Al Jazeera |
| [13:24:07] | jya: | they have quite long segment (15s+) and it usually takes about the same time to download them |
| [13:24:08] | danielk221: | jya: I think I was getting hung up later than you were because the initial Open was just fast enough for my system not to time out. |
| [13:25:36] | danielk221: | jya: We can deal with that in the IPTVSignalMonitor, but would it be easy enough to make Open() just start the open process and not actually wait for the download of the first segment to complete? |
| [13:25:59] | jya: | if you think i should change the architecture of the HLS ringbuffer slightly so it's usable by the recorder, let me know and I'll make the appropriate changes… just need some guidance. I originally wrote the HLSRingBuffer class modeled on the HTTPRingBuffer one, and it's blocking too everywhere |
| [13:26:41] | jya: | I could put the prefetch on the first call to safe_read |
| [13:27:03] | danielk221: | I think making Open() block as little as possible would be good both for this issue and down the line when we make it a StreamHandler. |
| [13:27:46] | jya: | however, IRC, when you use the default playback RingBuffer (so playing a hls stream via mythavtest or airplay), then it does something like Open, Seek(END), Seek(0), Play |
| [13:29:09] | jya: | so doing a prefetch in safe_read would likely fix the IPTVRecorder, (if that's where the block is) , but would have to check how I can hack it so the plain PlaybackRingBuffer works |
| [13:29:43] | danielk221: | The difference is that a RingBuffer is supposed to make the frontend wait a bit until we have enough data, but on the backend we just want to start the process in Open(), the data will arrive when it does as fast as possible. |
| [13:30:07] | jya: | that still means Open is supposed to return within 7s if that's how long it takes for the frontend to timeout |
| [13:30:42] | danielk221: | jya: Really it should return almost immediately as it blocking blocks the event thread. |
| [13:31:07] | jya: | because in Open() I'll still have to go fetch the mu8 playlist, and then the list of segments... |
| [13:31:20] | jya: | that could easily take more than 7s to retrieve all the streams |
| [13:32:15] | jya: | maybe I can just create another constructor that will pretty much not wait at all, and everything will occur later |
| [13:33:37] | danielk221: | Another Open() you mean? |
| [13:33:59] | jya: | Open is a private method called by the HLSRingBuffer constructor |
| [13:34:52] | jya: | what I can do is instead, new HLSRingBuffer(url, nowait) will just initialise things and init very quickly |
| [13:34:56] | danielk221: | There could be an OpenNonblocking() and the regular Open() is just { OpenNonblocking(); Wait() }, the recorder can use the OpenNonblocking() everyone else uses the regular RingBuffer::Open() which does the blocking. |
| [13:35:22] | jya: | and IPTVFeederHLS::Run will call a new method HLSRingBuffer::Init() |
| [13:35:46] | jya: | before it get into the loop… Will that do? |
| [13:36:40] | danielk221: | jya: There will have to be something that blocks the reads until the open really completes. As long as that responds to the interrupt signal it should work well. |
| [13:36:52] | jya: | there's a fair amount of work to do with the hls stream before you can get to the mpeg-ts stream. got to read the playlist, retrieve the various streams, analyse the bandwidth required, etc etc.. |
| [13:37:41] | jya: | yes, I'll make the HLSRingBuffer::Interrupt() also interupt the prefetch |
| [13:37:46] | danielk221: | Right, but the recorder really doesn't care that the read takes a long time unless it's time to end the recording. So if it blocks for the open to complete it's not an issue to the recorder or the signal monitor. |
| [13:37:59] | jya: | ok... |
| [13:38:07] | jya: | just an issue with the standard RingBuffer |
| [13:38:22] | danielk221: | which would use the blocking Open(), right? |
| [13:38:26] | jya: | yep |
| [13:38:33] | jya: | actually, open would then call Init() |
| [13:38:46] | jya: | for the TVRec bit, it won't, you have to call Init manually |
| [13:39:02] | jya: | starting to get messy, will be a pain to document this behaviour |
| [14:20:31] | jya: | danielk221: ok.. I have a solution working perfectly now.. |
| [14:21:25] | jya: | however, it does take quite a while for playback to start, even though I can see the recording has downloaded 2 segments. so here it has 18s buffer, yet it only starts after it got about 5 segments… |
| [14:25:50] | jya: | i see on the frontend lock appearing, the signal monitor is closed, and in the backend log, I can see that it calls safe_read lots of time that will read the wall data buffered, however that data seems to be discarded, once it's reached the end of the data downloaded, it goes back into waiting for more data, and from that point playback will start. |
| [14:32:48] | aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 244 seconds) | |
| [14:39:57] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [14:41:48] | danielk221: | jya: I'm guessing it's discarding all the data read in the IPTVSignalMonitor. Can you seek back to the start when we close the stream in the signal monitor? |
| [14:42:09] | jya: | danielk221: not when using liveTV, the data is freed once read |
| [14:42:59] | jya: | but here I can clearly see the IPTVSignalMonitor being destroyed, and the multiple safe_read occur later |
| [14:43:41] | danielk221: | That's odd. Once the signal monitor is destroyed all the safe reads done after that point should be data that we write to disk. |
| [14:44:22] | danielk221: | Are we continuing to read while there are no listeners ? i.e. between the signal monitor tear down and the recorder startup? |
| [14:44:33] | jya: | it looks like it yes |
| [14:45:14] | jya: | as the data is all buffered, it reads by block of around 32kB I believe, so it reads the data very quickly |
| [14:45:15] | danielk221: | oh, wait.. there is one more set of data that is thrown away.. All the data in the recorder until we get the first keyframe.. |
| [14:45:49] | jya: | I don't think it would take 5–6 segments to find a keyframe.. |
| [14:45:55] | jya: | that's over 70s of recordings! |
| [14:46:25] | danielk221: | Is it h.264? Those keyframes can be really far apart. |
| [14:46:50] | danielk221: | There is a setting to disable the keyframe finding, that should verify if this is the issue. |
| [14:46:52] | jya: | it is… but still… Apple's doc states a keyframe should be every 90 frames |
| [14:47:44] | jya: | hum… another case here of the frontend exiting early, and the recorder on the backend isn't stopped |
| [14:48:01] | danielk221: | ugh, http://linux.slashdot.org/story/12/08/09/1340 . . . t-from-nokia |
| [14:48:48] | jya: | I got to Digia website a few months ago.. |
| [14:48:58] | jya: | when I wanted to read the terms of Qt commercial |
| [14:49:06] | jya: | it redirected me to digia |
| [14:49:11] | wagnerrp: | bound to happen, considering nokia went winmobile |
| [14:50:04] | danielk221: | Digia has been like SCO was to Novell with commercial licenses for the last year and a half. They aren't exactly well placed to move the toolkit forward. |
| [14:51:12] | danielk221: | Looks like Nokia also sold 500 of their patents to a patent troll today: http://www.businesswire.com/news/home/2012080 . . . se-Agreement |
| [14:51:37] | jya: | danielk221: I still see the frontend closing the connection with the backend, exiting liveTV with "MythSocket(10dbaa250:111): readStringList: Error, timed out after 7000 ms" |
| [14:52:03] | danielk221: | jya: What is the message it's waiting for the readStringList on? |
| [14:52:49] | jya: | http://pastebin.com/eG4NbKfS |
| [14:53:11] | jya: | RemoteEncoder::SendReceiveStringList(): No response. |
| [14:54:00] | danielk221: | Right, but that doesn't tell us what RemoteEncoder command was. -v network debugging should add that. |
| [14:54:16] | jya: | hold a sec... |
| [14:56:46] | jya: | what I do is start LiveTV on one channel that takes a long time to tune on (channel 302), then I switch to 300 immediately. |
| [14:57:49] | jya: | http://pastebin.com/tLE8ph65 |
| [14:59:04] | jya: | ah the backend had crashed there. |
| [14:59:18] | jya: | redoing it |
| [15:03:04] | jya: | frontend log: http://pastebin.com/0pAKEQ9T |
| [15:03:04] | jya: | backend log: http://pastebin.com/YKfTdKS2 |
| [15:07:10] | jya: | starting France 24 channel via LiveTV: 50.7s… same url via mythavtest: 24.3s |
| [15:08:40] | jya: | ok… off to bed.. good night |
| [15:10:42] | danielk221: | It looks like SetChannel(300) is taking 20+ seconds. |
| [15:11:45] | jya: | and SetChannel shouldn't block either like Open ? |
| [15:12:23] | danielk221: | It can block, just not for very long. |
| [15:14:05] | jya: | I don't know how it changes channel, all I see is that it closes , destroy it and re-open another one. |
| [15:14:15] | jya: | there's no time spent in open now |
| [15:15:52] | danielk221: | All SetChannel() itself does is queue up a channel change and then wait for the queue to be empty. The rest is all handled in the event loop. |
| [15:17:04] | danielk221: | We can safely increase the timeout for SET_CHANNEL to 30 seconds, but it would be a better experience for the end user if we figure out why that is taking so long. |
| [15:17:27] | jya: | something is dodgy anyway… I see the following.. |
| [15:18:50] | jya: | the France 24 stream is downloading, and playing… I switch channel to 300 (Nasa TV), it starts downloading Nasa TV (France 24 continues to download, playback in the frontend has paused). I see that it gets a Signal Lock for Nasa TV, then stops downloading NasaTV. France 24 continues to download a little bit further, and finally stop |
| [15:19:07] | jya: | and mythfrontend goes back to the beginning, no messages or error is displayed |
| [15:19:26] | danielk221: | that does look a bit fishy |
| [15:20:11] | jya: | I'm pretty sure the NasaTV being interrupted right after getting a lock on nasatv, is the same issue as earlier, MythFrontend as closed the connection after a 7s timeout |
| [15:20:46] | jya: | so something else is blocking the event thread when changing channels, not sure what |
| [15:27:11] | danielk221: | jya: When we shut down the HLSRingBuffer we need to join the thread doing the downloads right? Could that be taking a long time? |
| [15:51:15] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 268 seconds) | |
| [16:06:05] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [16:11:01] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [16:12:49] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [16:21:24] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has joined #mythtv | |
| [16:41:19] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Remote host closed the connection) | |
| [16:41:36] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [16:42:56] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:46:17] | Steve-Goodey (Steve-Goodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has joined #mythtv | |
| [16:52:41] | stichnot (stichnot!~stichnot@192.55.54.36) has joined #mythtv | |
| [16:52:41] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:52:41] | stichnot (stichnot!~stichnot@192.55.54.36) has quit (Changing host) | |
| [16:55:50] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [16:56:57] | gigem (gigem!~david@pool-71-123-128-97.dllstx.fios.verizon.net) has joined #mythtv | |
| [16:56:57] | gigem (gigem!~david@pool-71-123-128-97.dllstx.fios.verizon.net) has quit (Changing host) | |
| [16:56:57] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:58:39] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [17:02:07] | danielk221 (danielk221!~danielk@96.57.9.142) has quit (Ping timeout: 240 seconds) | |
| [17:12:39] | Defense|Twin (Defense|Twin!~jepz@e177230012.adsl.alicedsl.de) has joined #mythtv | |
| [17:12:59] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 244 seconds) | |
| [17:24:35] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [17:41:36] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:55:18] | pppoe_dude (pppoe_dude!~pppoe_dud@unaffiliated/blimpdude) has joined #mythtv | |
| [17:55:32] | pppoe_dude: | hi |
| [17:56:28] | pppoe_dude: | random and off topic question, but do you know if you can use the hd homerun without an antenna (just a cable or so) even just to test/see if you can get a couple of channels? |
| [17:57:15] | pppoe_dude: | (digital signal) |
| [17:57:17] | danielk22: | pppoe_dude: wrong channel. This is the mythtv development channel. |
| [17:57:39] | pppoe_dude: | oh my apologies |
| [17:57:45] | pppoe_dude: | thought i was in the users channel! |
| [18:11:43] | Defense|Twin (Defense|Twin!~jepz@e177230012.adsl.alicedsl.de) has quit (Remote host closed the connection) | |
| [18:49:37] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 240 seconds) | |
| [19:03:46] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [19:06:13] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [19:07:11] | andreax1 (andreax1!~andreaz@p54BF219B.dip.t-dialin.net) has joined #mythtv | |
| [19:08:25] | andreax (andreax!~andreaz@p5089E0C5.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [19:30:47] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 250 seconds) | |
| [19:38:56] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [19:44:46] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [20:13:51] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 276 seconds) | |
| [20:14:13] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has joined #mythtv | |
| [20:30:03] | pppoe_dude (pppoe_dude!~pppoe_dud@unaffiliated/blimpdude) has quit (Quit: Ex-Chat) | |
| [20:33:32] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [20:37:08] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [20:45:29] | stoffel (stoffel!~quassel@pD9E4162C.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [20:50:32] | SteveGoodey (SteveGoodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [20:59:39] | stichnot_ (stichnot_!stichnot@nat/intel/x-ohvtdrtxeorlqcgc) has joined #mythtv | |
| [21:01:34] | stichnot_ is now known as stichnot | |
| [21:11:37] | Steve-Goodey (Steve-Goodey!~steve@host86-144-4-78.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:16:37] | dekarl (dekarl!~dekarl@p4FCEE30A.dip.t-dialin.net) has joined #mythtv | |
| [21:18:28] | dekarl1 (dekarl1!~dekarl@p4FE85BBE.dip.t-dialin.net) has quit (Ping timeout: 265 seconds) | |
| [21:36:20] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 248 seconds) | |
| [21:39:47] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:47:16] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 246 seconds) | |
| [21:51:18] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [21:57:50] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [21:58:42] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 244 seconds) | |
| [22:02:51] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [22:11:01] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [22:11:30] | Beirdo_ (Beirdo_!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv | |
| [22:13:59] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [22:14:01] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [22:15:44] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [22:16:26] | Beirdo (Beirdo!~gjhurlbu@mythtv/developer/beirdo) has quit (Ping timeout: 260 seconds) | |
| [22:17:38] | stichnot_ (stichnot_!~stichnot@134.134.139.72) has joined #mythtv | |
| [22:19:05] | stichnot (stichnot!stichnot@nat/intel/x-ohvtdrtxeorlqcgc) has quit (Ping timeout: 252 seconds) | |
| [22:19:18] | stichnot_ is now known as stichnot | |
| [22:26:32] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [22:27:56] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [22:46:50] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [22:48:13] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [22:56:42] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [22:58:03] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [23:01:22] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 250 seconds) | |
| [23:16:47] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [23:21:44] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 250 seconds) | |
| [23:25:46] | n1md4 (n1md4!~nimda@80.87.131.250) has joined #mythtv | |
| [23:25:50] | n1md4 (n1md4!~nimda@80.87.131.250) has left #mythtv () | |
| [23:34:23] | aloril (aloril!~aloril@84.249.126.153) has joined #mythtv | |
| [23:44:26] | stichnot (stichnot!~stichnot@134.134.139.72) has quit (Ping timeout: 265 seconds) | |
| [23:45:38] | aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 244 seconds) | |
| [23:53:35] | Captain_M (Captain_M!~irchon@68-24-131-10.pools.spcsdns.net) has joined #mythtv | |
| [23:54:32] | Captain_M (Captain_M!~irchon@68-24-131-10.pools.spcsdns.net) has quit (Remote host closed the connection) | |
| [23:58:06] | Captain_M (Captain_M!~irchon@68-24-131-10.pools.spcsdns.net) has joined #mythtv | |
| [23:58:39] | Captain_M (Captain_M!~irchon@68-24-131-10.pools.spcsdns.net) has quit (Remote host closed the connection) | |
| [23:59:36] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.