MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aloril, Anssi, anykey_, brfransen, cesman, Chutt, clever, coling, Cougar, danielk22, dblain_, dekarl, drussell_, ElmerFudd, fetzerch, foobum, frankster, ghoti, gregL, GreyFoxx, Guest43181, IReboot, J-e-f-f-A, jams, jarle, jarryd, jaug0rd0r, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, kc, Kevin`, knightr_, kurre2, kwmonroe, laga, lentferj, Merlin83b, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, PatrickDickey, Peitolm, Peps, petefunk, poptix, purserj, rhpot1991, rsiebert, seld, Sharky112065, skd5aner, sl1ce, SmallR2002_, sphery, sraue, superm1, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wayne__, wolfgang1, XDS2010_, _charly_
Thursday, January 24th, 2013, 01:21 UTC
[01:21:55] joki (joki!~joki@p54864EC6.dip.t-dialin.net) has quit (Ping timeout: 246 seconds)
[01:22:26] joki (joki!~joki@p54864FD3.dip.t-dialin.net) has joined #mythtv
[01:42:08] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[01:45:01] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[01:48:28] Guest43181 (Guest43181!~chatzilla@123.116.116.152) has joined #mythtv
[01:52:53] Guest43181: Is there any mythtv backend for windows?Thanks for answers!
[01:54:17] wagnerrp: not much use for it, since there's no tuner support on windows
[01:54:35] wagnerrp: the backend _should_ run, but there's no reason to do so with nothing to record
[01:54:57] wagnerrp: note, this is the development channel. you should be in #mythtv-users, unless you're planning on developing windows tuner support
[01:55:26] skd5aner: has anyone even really tried to do much with master on windows recently at all? is there even a windows buildbot anymore?
[01:56:17] wagnerrp: offline since late october... http://code.mythtv.org/buildbot/builders/mast . . . -mingw-32bit
[01:56:35] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:ec45:997:10ad:75b3) has joined #mythtv
[01:57:29] wagnerrp: dblain_: i'm getting all sorts of ssdp.cpp "Socket readBlock" errors, and I'm also getting bus terminations
[01:57:44] wagnerrp: not certain they're related, but their timing seems to coincide
[01:57:45] skd5aner: windows – that OS that occasionally get a lot of love all at once, and then gets dumped for several months – like a summer-time girlfriend
[01:58:23] tonsofpcs: gigem: didn't put the patched backend in to place today. Hopefully I have time tomorrow
[01:58:52] tonsofpcs: wagnerrp: no tuner support on windows? not even for network devices like hdhr?
[01:59:12] wagnerrp: the HDHR may work. i'm not sure if anyone has ever actually tested it
[01:59:16] wagnerrp: same with the iptv "tuner"
[01:59:56] wagnerrp: there is a whole lot of code in the backend that assumes it is on a POSIX system
[02:00:13] wagnerrp: i'm not sure if any of that is in a critical area that would prevent recording
[02:01:07] tonsofpcs: I'd try it, but I lack a windows box ;)
[02:01:31] tonsofpcs: I need to get a tuner into tthe hackerspace and get Create on a display all the time
[02:08:54] lentferj (lentferj!~lentferj@p579B7DE1.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[02:09:54] lentferj (lentferj!~lentferj@p579810B8.dip.t-dialin.net) has joined #mythtv
[02:11:51] skd5aner: I think someone was able to get the HDHR working on an OSX backend a few years back
[02:12:28] wagnerrp: OSX sure, but OSX is a POSIX OS
[02:12:34] wagnerrp: there's a lot less that needs to change
[02:12:48] wagnerrp: (for compatibility)
[02:16:14] skd5aner: yea, just sayin'
[02:21:22] gigem: tonsofpcs: Okay. Please let me know if it works for you tomorrow. I test a bit last night on master. It worked as intended, but I wanted to tweak it a little more today. I'm testing again tonight and it's still working as intended.
[02:29:41] tonsofpcs: will do.
[02:29:51] tonsofpcs: checking my record schedules now
[02:30:29] tonsofpcs: looks like tonight wouldn't have been a good test anyway. Tomorrow seems like it should be.
[02:32:16] tonsofpcs: 34.1 at 1900, 1930, 2000 (1h), 2100 (1h2m); 34.2 at 2000 (30m), 2201 (59m); 40.1 at 2100 (1h). I can just set it to 46.3 or 12.1 before 19:20
[02:33:06] tonsofpcs: Monday's usually a good test day but not much happening this coming monday... tuesday will be a nice thorough test.
[02:42:59] stichnot (stichnot!stichnot@nat/google/x-ovtygrjoupmvlluq) has joined #mythtv
[02:43:00] stichnot (stichnot!stichnot@nat/google/x-ovtygrjoupmvlluq) has quit (Changing host)
[02:43:00] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:59:37] wayne__ (wayne__!~wayne@codeworks.gen.nz) has joined #mythtv
[03:29:39] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[04:04:11] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[04:05:48] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has joined #mythtv
[04:06:50] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[04:07:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[04:08:15] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:06:22] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[05:17:53] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 248 seconds)
[05:40:30] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[05:40:51] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Client Quit)
[06:04:51] wayne__ (wayne__!~wayne@codeworks.gen.nz) has quit (Ping timeout: 240 seconds)
[06:20:01] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has quit (Ping timeout: 245 seconds)
[06:38:35] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 255 seconds)
[06:39:56] rsiebert (rsiebert!~quassel@g225056028.adsl.alicedsl.de) has joined #mythtv
[06:41:55] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[06:42:43] rsiebert_ (rsiebert_!~quassel@g225061245.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[06:48:31] Sharky112065 is now known as Sharky-Sleep
[06:51:38] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[06:55:27] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 244 seconds)
[07:10:01] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[07:14:11] gigem (gigem!~david@mythtv/developer/gigem) has quit (Read error: Operation timed out)
[07:16:28] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!)
[07:28:19] gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv
[07:28:20] gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host)
[07:28:20] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[07:34:08] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Ping timeout: 272 seconds)
[07:52:29] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv
[08:40:12] peper03 (peper03!~peper03@port-92-203-127-33.dynamic.qsc.de) has joined #mythtv
[08:52:20] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[08:52:39] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[09:16:55] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Remote host closed the connection)
[09:18:34] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[12:39:59] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[12:56:04] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[13:09:30] danielk22: jya: stichnot: I'll put #11159 at the top of my list. But I'm unsure how quickly I'll get an opportunity to investigate.
[13:09:30] ** MythLogBot http://code.mythtv.org/trac/ticket/11159 **
[13:12:17] danielk22: stichnot: With the 1920x1088 videos the XVideo code drops the last 8 lines from display. IMHO That is the correct way to handle it.
[13:14:21] danielk22: danielk22: stichnot: iPhone videos? I think that might be a question for Captain_Murdoch.
[13:25:05] stichnot: danielk22: do you know where the XVideo code does this? I'm using XVideo on my laptop and I see the green line.
[13:28:17] stichnot: danielk22: I doubt the iPhone aspect is relevant. I pinged you because of extreme network-versus-local difference.
[13:32:25] danielk22: stichnot: grep for fix_1080i .. it looks like the code is in videooutwindow, so it is presumably shared by all the playback methods.
[13:34:38] danielk22: I think the HLS stuff is streamed via http and not using myth streaming. I'm unsure if that is handled by mythtv or by something external like apache or lighttp.. I just don't know enough to guess intelligently.
[13:36:30] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[13:36:32] danielk22: k off to work for me..
[13:37:48] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:57:14] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Read error: Connection reset by peer)
[13:57:26] dekarl (dekarl!~dekarl@p4FCEF12C.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[13:57:40] dekarl (dekarl!~dekarl@p4FCEE536.dip.t-dialin.net) has joined #mythtv
[13:58:10] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[14:07:39] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:16:35] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:17:07] Captain_Murdoch: danielk22, stichnot: HLS files are served via mythbackend's internal HTTP server, I did some testing with serving these up via an external webserver but don't plan on supporting, especially with the way the new on-demand encoding will work.
[14:28:46] stichnot: Captain_Murdoch: Is there a way to get a valid ProgramInfo for the source of an HLS transcode? The mythtranscode main() just does: if (cmdline.toBool("hls")) pginfo = new ProgramInfo();
[14:31:18] stichnot: actually, never mind, it looks like I figured this out a long time ago in a private patch
[14:34:33] Captain_Murdoch: and.. just saw what that iPhone question was about originally. I think I saw the same thing in my 0.25 production system yesterday. I have most of our DVD's ripped and recently moved them from a constantly spinning shared disk in the master backend to a USB disk that goes to sleep. I started experiencing the same issue. I though it was related to the new drive, but could then replicate it with the old one. I had to mount t
[14:34:33] Captain_Murdoch: he drive on the frontend via NFS to get rid of the buffering issue.
[14:35:57] Captain_Murdoch: stichnot, I still need to think through how to relate HLS to the original recording or video. right now HLS just operates on files, it doesn't know about the relationship. there are helper API calls to lookup the filename for a video or recording and start streaming those, but it doesn't store the fact that it's streaming the Castle episode from last Tuesday at 10PM.
[14:36:56] stichnot: Captain_Murdoch: here's how I did it: http://pastebin.com/zicYESu2
[14:36:58] Captain_Murdoch: the new on-demand code doesn't even need the existing table to track the stream.
[14:37:31] Captain_Murdoch: yeah, that patch is similar to what I was going to say, you can lookup a program by basename
[14:37:58] stichnot: I'm working on #11339 which requires a valid ProgramInfo so it can figure out if it's transcoding an in-progress recording
[14:37:58] ** MythLogBot http://code.mythtv.org/trac/ticket/11339 **
[14:52:53] Captain_Murdoch: my new on-demand code doesn't use transcode.cpp, but I do have it doing "m_programInfo = new ProgramInfo(fileName);" on the filename supplied to try to find the recording.
[14:54:00] stichnot: That should be good enough for what I'm doing.
[14:56:04] Captain_Murdoch: I haven't had a chance to look into seeing whether it will stop when it hits the point in the file that was the end when the transcode started. I'm still using the MythPlayer code to grab frames, so if there is any fix on that end, my code will benefit.
[15:00:48] jaug0rd0r (jaug0rd0r!~jaug0rd0r@gateway/tor-sasl/trisquelwithtor) has quit (Ping timeout: 276 seconds)
[15:07:21] jaug0rd0r (jaug0rd0r!~jaug0rd0r@gateway/tor-sasl/trisquelwithtor) has joined #mythtv
[15:09:59] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has joined #mythtv
[15:10:47] stichnot: I think the MythPlayer code ought to work correctly for that (and should support cutlists, DVDs, etc.), but let me know if you see any problems.
[15:41:53] peper03: stuartm: (and anyone else playing along at home) I've done a bit more digging and I think I've found a solution. It's not the easiest solution, but should be do-able (I think) and reliable.
[15:43:00] peper03: I'll do a quick brain dump here if no-one minds for feedback and for myself so I remember what I was thinking.
[15:44:02] stichnot: peper03: I'll be listening :)
[15:44:20] peper03: Playing with VobEdit and looking at the PCI and DSI structures here http://dvdnav.mplayerhq.hu/dvdinfo/ shows that we *can* work out how long to show a still frame for.
[15:46:38] peper03: The snappily-named fields vobu_s_ptm and vobu_e_ptm fields of the PCI structure give us the start and end presentation times for each NAV block (DVDNAV_NAV_PACKET). Additionally, vobu_se_e_ptm tells us the end time of the last frame to be displayed.
[15:49:07] peper03: In other words, say the packet starts at 0 and ends at 43200 (which would be 12 frames at 25fps), if vobu_se_e_ptm is 3600, it would mean we have one frame to show and that should be shown until the end of the nav packet.
[15:49:55] peper03: From this, we could generate 11 copies of the first frame and add them to the buffers and know that we're not going to be surprised by a video frame in that time.
[15:50:25] stichnot: Captain_Murdoch: in the HLS demo page, with the embedded player, I noticed that you don't get valid position/duration information for an in-progress recording. Any ideas how to fix that?
[15:51:13] peper03: The next nav packet will probably only contain audio data and you can't use the vobu_se_e_ptm field then because it's 0 (i.e. ignore me).
[15:53:26] jheizer: stichnot: Cause it is marked as a live stream vs something that is a set time span until the transcode is complete. Best player I have used is iOS and it will still only give you the time remaining until the end of the current;y transcoded amount.
[15:53:42] peper03: However, there is another structure in the DSI structure called vobu_sri. This contains fields to help with searching. One of these fields (sri_nvwv – who thinks these things up?!) tells us the next nav packet that contains video.
[15:54:37] peper03: We could note this and generate more copies of the original still frame to pad out the time until we actually reach this nav packet.
[15:56:01] peper03: By generating actual frames, we could get rid of some of the special handling for still frames (or probably more accurately move it elsewhere and hopefully make it less 'magic').
[15:56:42] peper03: We would also naturally limit the speed at which we buffer data, so we're not suddenly buffering a huge amount of audio data.
[15:57:56] peper03: The trick is probably going to be getting the information from DVDRingBuffer to AVFormatDecoder(DVD) but I've been thinking about that too :)
[15:58:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds)
[16:00:49] peper03: It would be interesting to see if we can't inject data packets into the data we pass from DVDRingBuffer:safe_read to ffmpeg. At least NAV packets should never come in the middle of a video or audio frame, so there shouldn't be any problems caused by inserting our data into the middle of a real A/V packet.
[16:02:51] peper03: The advantage of doing this is that we can pass information back that is synchronised with the A/V stream. This could also be used to replace calls to IsInStillFrame or IsInMenu.
[16:04:27] wayne__ (wayne__!~wayne@codeworks.gen.nz) has joined #mythtv
[16:05:31] peper03: With a bit of luck (haven't gone into the details of this yet), that should remove the problem of the presentation side acting on the state of the decoder side even though they're separated in time by the buffered data.
[16:05:56] peper03: Any questions? :)
[16:10:48] peper03: Seeking on a DVD with just stills is going to be fun, though. Jump back a few seconds and you might need to jump back 30 minutes to read in the last video frame before jumping forwards to the place you actually wanted to get to.
[16:11:56] peper03: Likewise jumping forward – you might need a short stopover on the way to pick up the frame you should be showing when you get to where you're going.
[16:42:09] Sharky-Sleep is now known as Sharky112065
[16:46:28] gryffus (gryffus!~gryffus@62.77.84.170) has quit (Quit: Konversation terminated!)
[17:17:33] Goga777 (Goga777!~Goga777@128-71-147-193.broadband.corbina.ru) has quit (Remote host closed the connection)
[17:25:51] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[17:28:06] jpabq: A new problem has popped up for me within the last week or so. Some recordings are now not watchable while they are recording. I get "This recording is not available yet" when I try to watch it. Checking the disk, the file is being written.
[17:49:08] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[17:52:49] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!)
[18:04:35] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[18:06:50] jpabq: stichnot: It looks like 802e32ba4d is preventing HD-PVR recordings to be watched while they are still recording.
[18:12:39] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[18:16:56] jpabq: Okay, maybe not. With that reverted, it worked at first, but is still not consistent.
[18:43:50] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[19:36:05] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[19:50:34] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[20:00:36] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[20:04:08] kmc_ (kmc_!~kmc@49.176.3.192) has joined #mythtv
[20:29:10] jpabq: There is something funky with the positionmap for an in-progress recording. When I first go into the Watch Recordings screen, it randomly will show a non-zero file size for an in-progress recording. If it shows the size as zero, it won't let me watch it. When it does show a filesize, I can start watching — but if I stop watching the file size will be back to showing zero, and I can't start playback again.
[20:29:50] jpabq: To start playback again, I have to exit and re-enter the Watch Recordings screen a few times, before it will show a non-zero file size, and allow me to watch it, again.
[20:30:40] jpabq: When it does let me watch it, the FIRST time I try to seek, the OSD will show "seeking..." instead of just immediately jumping to the new location. After the first attempt to seek, it will work correctly.
[20:31:50] jpabq: Sorry, that should be "searching..."
[20:37:28] kmc_ (kmc_!~kmc@49.176.3.192) has quit (Remote host closed the connection)
[21:20:10] jpabq: Not what I expected. danielk22: After doing a git bisect, it looks like it is 440573f3febdc8009b74ae1b2366aa7d518a15a7 causing the in-progress recording, playback problem.
[21:20:39] gracent (gracent!~Thunderbi@87.127.165.150) has quit (Quit: gracent)
[21:42:26] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[21:47:33] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[21:49:39] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Read error: Connection reset by peer)
[21:54:17] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[21:55:40] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[21:55:41] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[21:55:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[22:00:28] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:04:05] neufeld is now known as neufeld_AFK
[22:09:38] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[22:12:36] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[22:38:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Quit: Reconnecting…)
[22:38:37] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[22:38:37] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[22:38:37] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[22:42:07] stichnot: jpabq: File size in Watch Recordings screen, and "searching..." in lieu of a position map, should be two separate issues (at least in theory)
[22:55:35] peper03 (peper03!~peper03@port-92-203-127-33.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[22:56:42] jpabq: stichnot: reverting 440573f3febdc8009b74ae1b2366aa7d518a15a7 fixes both problems. I have not dug into why at all, so don't know what the root problem is.
[23:10:20] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)

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