| Friday, April 11th, 2014, 00:08 UTC | ||
| [00:08:30] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [00:28:29] | len_ (len_!~quassel@97-127-75-132.mpls.qwest.net) has quit (Ping timeout: 250 seconds) | |
| [00:29:49] | len_ (len_!~quassel@67-6-41-161.mpls.qwest.net) has joined #mythtv | |
| [00:38:25] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [00:40:12] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [01:01:19] | NightMonkey_ (NightMonkey_!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [01:01:28] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Connection reset by peer) | |
| [01:26:44] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [01:37:41] | jya (jya!~jya@61.19.103.146) has joined #mythtv | |
| [01:38:58] | jya: | warpme: I made an error in the previous commit, and didn't disable the read internal mode. Should be good now... Also corrected what I think could cause the still frame issue. Let me know how it goes... |
| [01:41:33] | jya: | wagnerrp: Why don't we simply remove that test checking if the tmdb3.py cache file exists and is available for read and write. After all the tdmb code will create the file itself later, and will error himself if there's an issue creating the file. Deleting those three lines should be all that is required... |
| [01:45:45] | wagnerrp: | jya: yeah, that's what i was planning |
| [01:47:41] | jya (jya!~jya@61.19.103.146) has quit (Quit: Colloquy for iPad - http://colloquy.mobi) | |
| [01:51:14] | joki- (joki-!~joki@p54862CAF.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [01:56:23] | joki (joki!~joki@p548628B4.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:06:24] | _nyloc_ (_nyloc_!~quassel@p3EE2CB10.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:10:38] | nyloc (nyloc!~quassel@p57B4FFFD.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [02:18:12] | len_ (len_!~quassel@67-6-41-161.mpls.qwest.net) has quit (Ping timeout: 258 seconds) | |
| [02:22:24] | len_ (len_!~quassel@67-6-41-161.mpls.qwest.net) has joined #mythtv | |
| [02:47:12] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:50:08] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:51:00] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 252 seconds) | |
| [02:51:00] | peper03_ is now known as peper03 | |
| [03:09:16] | jya (jya!~jya@61.19.103.146) has joined #mythtv | |
| [03:12:21] | jya (jya!~jya@61.19.103.146) has quit (Client Quit) | |
| [03:43:29] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Ping timeout: 255 seconds) | |
| [03:45:22] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
| [04:00:05] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:01:26] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:39:56] | gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:6700::24) has quit (Remote host closed the connection) | |
| [04:58:01] | doev (doev!~doev@p4FD439C4.dip0.t-ipconnect.de) has joined #mythtv | |
| [05:02:21] | arescorpio (arescorpio!~arescorpi@190.19.140.27) has joined #mythtv | |
| [05:06:17] | NightMonkey_ (NightMonkey_!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Quit: Body blow! Body blow!) | |
| [05:11:23] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [05:22:53] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [05:28:38] | arescorpio (arescorpio!~arescorpi@190.19.140.27) has quit (Excess Flood) | |
| [05:42:53] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has joined #mythtv | |
| [05:58:20] | SteveGoodey (SteveGoodey!~steve@host86-132-103-208.range86-132.btcentralplus.com) has joined #mythtv | |
| [06:09:07] | SteveGoodey (SteveGoodey!~steve@host86-132-103-208.range86-132.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:20:41] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:28:35] | len_ (len_!~quassel@67-6-41-161.mpls.qwest.net) has quit (Ping timeout: 252 seconds) | |
| [06:32:07] | len_ (len_!~quassel@75-168-33-125.mpls.qwest.net) has joined #mythtv | |
| [06:43:45] | doev (doev!~doev@p4FD439C4.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds) | |
| [06:51:23] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [06:58:03] | len_ (len_!~quassel@75-168-33-125.mpls.qwest.net) has quit (Ping timeout: 250 seconds) | |
| [06:58:19] | len_ (len_!~quassel@75-168-60-251.mpls.qwest.net) has joined #mythtv | |
| [07:00:45] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [07:03:02] | dekarl: | hmm, maybe I should have been more explicit with my "what you do in your house is your business but do not suggest unsupported configurations on our lists for us to support" or something (wrt no window manager) |
| [07:05:30] | len_ (len_!~quassel@75-168-60-251.mpls.qwest.net) has quit (Ping timeout: 240 seconds) | |
| [07:06:01] | len_ (len_!~quassel@97-127-68-55.mpls.qwest.net) has joined #mythtv | |
| [07:16:06] | jpharvey_ (jpharvey_!~jpharvey@host109-148-236-238.range109-148.btcentralplus.com) has quit (Ping timeout: 252 seconds) | |
| [07:26:01] | len_ (len_!~quassel@97-127-68-55.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [07:29:52] | jpharvey_ (jpharvey_!~jpharvey@host109-148-236-238.range109-148.btcentralplus.com) has joined #mythtv | |
| [07:55:47] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [08:12:17] | doev (doev!~doev@p4FD439C4.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:22:13] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [08:22:44] | stuarta: | morning all |
| [08:26:31] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:27:11] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [08:31:21] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has quit (Ping timeout: 245 seconds) | |
| [08:48:44] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [08:48:48] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Client Quit) | |
| [09:09:39] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Ping timeout: 276 seconds) | |
| [09:24:24] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [09:26:18] | warpme: | jya: I give run for current devel/ringbuffer and results are excellent. All issues gone except "looped image" (which I believe isn't related to your work). |
| [09:29:49] | warpme: | speaking about "looped image" – current devel/ringbuffer has also improvements as now issue is only on 1 mplex (was on 2) and on this mplex is highly repeatable. In past "looped" issue was every few zaps – now is on every. I gather log for it – http://warped.homenet.org/looped1.log pls look on last zap – it had "looped" issue. |
| [09:32:02] | warpme: | jya: I do 4 all-channels zaps without issue. In past on 1st (or maybe 2nd) I was able to catch issues – now 4 were without issues. Give me few days for some more tests – and after that I think devel/ringbuffer cna be merged with master. |
| [09:35:48] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has joined #mythtv | |
| [09:40:34] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [10:18:12] | warpme: | dekarl: I'm wonder how should I setup test/log enviroment to catch issue with sporadic errors in PL chars in EIT EPG. Do You have some suggestions here? |
| [10:28:33] | stuarta: | warpme: what sort of errors? bad fixups, incorrect interpretation etc ?? |
| [10:31:25] | warpme: | stuarta: basically issue is that I have ocasional errors in EPG data. Errors are random and are about few % of whole EPG data. |
| [10:32:53] | stuarta: | but what form do the errors take? |
| [10:33:08] | warpme: | sometimes they are in title, sometimes in description. Unfortunatelly I can't formulate corelation/rule here. Whole issue is because #9480. |
| [10:33:08] | ** MythLogBot http://code.mythtv.org/trac/ticket/9480 ** | |
| [10:34:46] | warpme: | dekarl has hipothessis that there is race between 2 event data sources: long-term and current (I'm not sure do I recall it correctly) |
| [10:35:21] | stuarta: | there shouldn't be, since the now/next data is always preferred over the longer term data |
| [10:37:12] | warpme: | errors looks like bad code page. It pretends like issue where given EIT source has sometimes applied fix-up with wrong code-page |
| [10:39:02] | warpme: | such errors apears for single events or maybe few consecutive events. User sees on EPG program with no errors title but with description having wrong codepage used to display. |
| [10:41:35] | warpme: | unfortunatelly I'm not following how #9480 works – but if I assume that for very.short of period of time code-page fixup is wrongly applied – then effect might be like observed issue... |
| [10:41:35] | ** MythLogBot http://code.mythtv.org/trac/ticket/9480 ** | |
| [10:43:05] | warpme: | stuarta – I'll be away for 30min. |
| [10:45:59] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [10:46:28] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has joined #mythtv | |
| [11:06:34] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has quit (Read error: Connection reset by peer) | |
| [11:06:57] | esperegu (esperegu!~quassel@ip-213-124-221-127.ip.prioritytelecom.net) has joined #mythtv | |
| [11:44:20] | warpme: | stuarta: I see 95652b6 on master. Should I backport and see will it will improve things? |
| [11:47:43] | dekarl1 (dekarl1!~dekarl@p4FE853BB.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:50:07] | dekarl (dekarl!~dekarl@p4FE85033.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds) | |
| [12:11:02] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [12:12:03] | stuarta: | warpme: that addresses a different issue |
| [12:14:31] | dekarl-work: | stuarta, the issue appears different fixups being needed for EIT(a) on the channel and EIT(o) on the "full SI" transponder. see also https://code.mythtv.org/trac/ticket/11809 it fits to "with passive scan everything is ok" as then only EIT(a) could be collected from the actual transports of the channels |
| [12:14:54] | dekarl-work: | but with the active scan also a random channel on the transport of the full SI may be scanned, even though there are no recordings there |
| [12:15:12] | dekarl-work: | re the encoding issue that warpme is seeing |
| [12:15:32] | stuarta: | interesting |
| [12:17:25] | warpme: | dekarl-work stuarta: fyi – I remember that with passive-ony mode my issue GONE. |
| [12:17:29] | dekarl-work: | I have not yet come up with a way to encode "apply fixup depending on ONID/TSID of the transmission" instead of "depending on the ONID/TSID that the transmission is about" |
| [12:17:53] | warpme: | s/ony/only/ |
| [12:18:06] | stuarta: | theoretically there is no difference in the types of data that is collected between active and passive scan |
| [12:18:20] | dekarl-work: | warpme: I need to investigate how you can find up which transport carries the wrong data (likely the Full SI transport) |
| [12:18:47] | stuarta: | it's probably that the EITo cross-carried data is wrong somewher |
| [12:18:53] | dekarl-work: | my bet is that you have no recording rule for any channel in the multiplex with the Full SI |
| [12:19:27] | dekarl-work: | stuarta: that's my conclusion from the ticket, too. (while it should in theory be a plain copy) |
| [12:19:45] | warpme: | dekarl-work: in other words You need info on which mplex(s) issue is present? |
| [12:20:06] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has quit (Ping timeout: 276 seconds) | |
| [12:20:17] | dekarl-work: | warpme: correct, but the mplex of the guide data transmission, not the mplex that the data is about :) |
| [12:20:27] | stuarta: | dekarl-work: but then, we shouldn't see this because we always prefer EITa over EITo, and always prefer the near term data to the long term data |
| [12:20:27] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has joined #mythtv | |
| [12:20:58] | stuarta: | so that begs the question, is 1 mux carrying the data in a different encoding to the other |
| [12:21:01] | stuarta: | others |
| [12:21:22] | dekarl-work: | stuarta, I'm not sure. As the data is not identical there might be differences in eventid, too |
| [12:22:15] | warpme: | dekarl-work: I have impression that EIT is transported over many mplexes. Looking on EIT event logs when EIT scanner is clawling – I see inserted portions of EIT events from almost all mplexes |
| [12:22:26] | stuarta: | warpme: yes it is |
| [12:22:36] | stuarta: | well in most countries |
| [12:23:03] | warpme: | but ofcourse some of them are inserting tenths/hundreds and ome other thousends. |
| [12:23:10] | stuarta: | EITo = EIT other, is EIT data that represents programs on a different mplex, this is the so called cross-carried data |
| [12:23:36] | stuarta: | EITa = EIT actual, is EIT data for programs on this mpled |
| [12:23:38] | stuarta: | mplex |
| [12:24:11] | stuarta: | it's breaks down into 6! different types |
| [12:24:34] | dekarl-work: | warpme, depending on your provider you will only see EITa, or EITa + EITo for present/following or in the case of the FullSI mux you'll see EITa+EITo for everything. |
| [12:25:01] | stuarta: | EITa p/f, EITo p/f, EITa 0–3days, EITo 0–3days, EITa 4–7days, EITo 4–7days <-- highest to lowest prio |
| [12:27:30] | dekarl-work: | stuarta almost... EITa p/f, EITo p/f, EITa complete, EITo complete. But our cache keys of chanid + event_id... |
| [12:27:48] | dekarl-work: | so it only works if both transmissions use identical event_ids |
| [12:28:10] | stuarta: | dekarl-work: the tableid's have a distinction between 0–3 & 4–7 day data |
| [12:28:56] | stuarta: | the repetition rate on the broadcast of the data reduces the further away the event is |
| [12:30:18] | dekarl-work: | indeed, but the two 16 ID blocks for the days is en bloc. 0x4e for EITa p/f, 0x4f for EITo p/f, 0x50–0x5F for EITa, 0x60–0x6F for EITo |
| [12:30:44] | stuarta: | damn i must be a bit rusty |
| [12:30:54] | dekarl-work: | add to that the sub tables for each 3 hour block and it starts to get complicated :D |
| [12:31:11] | stuarta: | most profiles don't implement all of them |
| [12:31:16] | dekarl-work: | either way, our cache first looks at the event_id ;) |
| [12:31:48] | stuarta: | we keep the table id so we know if "better" data arrives |
| [12:32:17] | dekarl-work: | but as we know that the transmissions do differ in at least one aspect I would not be surprised if they differed in another aspect, too. (basically thinking that we might be looking at unrelated guide sources) |
| [12:32:56] | dekarl-work: | but... if the event_id does not match then we are comparing the table_id of an apple to that of an unrelated orange :D |
| [12:33:37] | stuarta: | what might be worth doing, is making a setting that says to ignore the cross carried data. what do you think of that idea? |
| [12:33:39] | dekarl-work: | and then the observation about the difference between active/passive scan starts to make sense |
| [12:34:18] | stuarta: | ie. stop looking at tables 0x60–0x6F |
| [12:34:32] | stuarta: | and maybe 0x4f |
| [12:34:53] | dekarl-work: | I like the idea of more flexibility in choosing the guide data source. e.g. always prefer EITo + EITa p/f, should help with keeping the guide up to date with DVB-S installations |
| [12:35:39] | dekarl-work: | basically a switch to "prefer EITa" or "prefer EITo from the FullSI mux" or "prefer nice MHEG-5 data over EIT" etc pp |
| [12:35:43] | stuarta: | we are missing a whole area in dvb-s, at least on astra they signal an eit channel/mux where data is located |
| [12:35:58] | dekarl-work: | see https://code.mythtv.org/trac/ticket/11809 :D |
| [12:36:34] | stuarta: | :) |
| [12:37:24] | dekarl-work: | ENOTIME and ENODVBS have adjusted its priority on my list a bit towards the lower end, though |
| [12:37:38] | stuarta: | i only suffer ENOTIME |
| [12:43:21] | rsiebert_ (rsiebert_!~quassel@g225186190.adsl.alicedsl.de) has joined #mythtv | |
| [12:44:38] | stuarta: | patch linked from #11119 looks straightforward |
| [12:44:38] | ** MythLogBot http://code.mythtv.org/trac/ticket/11119 ** | |
| [12:46:27] | rsiebert (rsiebert!~quassel@g226061178.adsl.alicedsl.de) has quit (Ping timeout: 250 seconds) | |
| [12:52:38] | moparisthebest (moparisthebest!~quassel@2001:470:1f11:88c::2) has joined #mythtv | |
| [13:14:44] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [13:21:36] | jya: | warpme: that’s great news… I was hoping it would all work nicely now… Are channel changes still as fast for you? there’s the potential for more delay now ; but I’m hoping it stays reasonable... |
| [13:22:45] | warpme: | jya: well....I see slightly slower chan.change – but it is still faster than was before Your work! |
| [13:23:09] | jya: | it should only be slower for where it used to do your Xorg configuration change |
| [13:23:25] | jya: | otherwise, should be just as fast as before that last commit. |
| [13:23:48] | warpme: | also slightly more frequently I have 2–3sec of audio stuter just after entering new channel. |
| [13:24:13] | warpme: | but i need more tests to give You right picture |
| [13:24:16] | jya: | still would like a full -v playback,avlib,file —loglevel=debug log of a session |
| [13:24:26] | jya: | just to see if I can reduce the tests. |
| [13:24:47] | jya: | right now I went with a very conservative approach, just so there’s never ever a false positive. |
| [13:24:55] | jya: | but that slows down things greatly |
| [13:25:16] | warpme: | sure. I already provide log for this looped picture issue (now only on one mplex) |
| [13:25:34] | jya: | the stutter is usually due to the system dropping frames, because we are too close to live and the data arrive too slowly |
| [13:25:56] | jya: | actually, none of the code in place that is supposed to put us slightly behind live are actually doing anything. |
| [13:26:35] | jya: | I have no idea why we would have “looped” image |
| [13:26:48] | jya: | i can’t think of anything I’ve changed that would cause the issue now |
| [13:28:58] | warpme: | jya: I think looped pic issue ISN'T related to Your changes. I had it before. Now I have it as well with little bit different heuristics: on mplex it gone. On other one is more frequent |
| [13:29:07] | jya: | i see 1.1s for your firs channel change in those log, not bad at all |
| [13:29:34] | warpme: | yes. Your work is REALLY nice! |
| [13:30:00] | jya: | great to hear |
| [13:30:22] | jya: | and how far behind live are you during playback now on average? |
| [13:30:25] | jya: | for me I’m always within 1–3s behind |
| [13:30:29] | jya: | 2s being the average |
| [13:30:34] | jya: | used to be close to 10s |
| [13:31:57] | warpme: | in my system is it something like 5s I'm wonder why there is such diference between Yours and mine systems? |
| [13:32:42] | jya: | Im going to add more verbosity to the log… just so I see how much retries it take on average for you |
| [13:33:02] | jya: | warpme: oh, something to remember, if your system isnt 100% on time, it will show |
| [13:33:30] | jya: | because the time showing on the OSD for the live position is the time on the backend, while the current position is the local time |
| [13:34:16] | jya: | on my mac, I find that if I go into the time preferences, uncheck “set date and time automatically” and re-check it that forces the mac to reset the time |
| [13:34:21] | jya: | after that, time is very close |
| [13:34:33] | warpme: | ah indeed. I have NTP between BE and FEs – but You are right. have to make sure that system time is in good sync |
| [13:34:37] | jya: | i find that the mac clock skew several seconds a day |
| [13:34:56] | jya: | it started with maverick |
| [13:35:06] | jya: | the time is really bad now |
| [13:36:31] | warpme: | huh – bad quality RTC chip (oscilator exactly speaking or RC circuit arround it has components with bad tolerance) |
| [13:39:13] | warpme: | ah – I remember. Indeed – it looks like sys.time in OSX is derived from FSB-like – not from RTC pool. I know ppl who have hackintoshes and having diffrent that factory FSB cause total sys.time discrepancy. I was relly surpriced that FSB can have any impact on sys.time! |
| [13:40:10] | warpme: | jya: You may try update EFI firmware and also SMC code... |
| [13:40:32] | jya: | FSB? |
| [13:40:34] | warpme: | or try at least reset SMC |
| [13:40:52] | jya: | what’s FSB? |
| [13:40:59] | jya: | mine is a proper iMac.. |
| [13:41:12] | jya: | but even my macbook air shows these symptoms |
| [13:42:38] | warpme: | front-side-buss. Intel uses QPI protocol on CPU/north-bridge (4 bit per bus cycle) – so 400MHz bus is equivalent 1.6G 1Ł! |
| [13:43:06] | warpme: | 1.6G 1:1 bit:cycle bus |
| [13:44:37] | warpme: | Of course this is about old desing – with discrete north-bridge. |
| [13:46:00] | warpme: | jya: probably https://code.mythtv.org/trac/ticket/11119#comment:15 may look interestig for You... |
| [13:46:31] | stuarta: | i've already reassigned that to jya |
| [13:47:22] | warpme: | stuarta jya: I'm just building BE with this patch – let see how it will go |
| [13:48:59] | stuarta: | we need to have another week of squishing easy bugs |
| [14:00:16] | jya: | why would they use FSB as basis for time… |
| [14:00:27] | jya: | and what architecture today still use FSB |
| [14:02:18] | dekarl-work: | jummy, specimen... https://tvheadend.org/boards/5/topics/8458 |
| [14:15:19] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Remote host closed the connection) | |
| [14:19:56] | jya: | warpme: the still picture, does it only happen with vdpau? |
| [14:30:28] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [14:34:03] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: going home :D) | |
| [14:37:01] | cougar_s (cougar_s!~cougar@void.starman.ee) has left #mythtv ("Client exiting") | |
| [14:38:47] | wagnerrp_ (wagnerrp_!~wagnerrp_@66.42.131.108) has joined #mythtv | |
| [14:38:47] | wagnerrp_ (wagnerrp_!~wagnerrp_@66.42.131.108) has quit (Changing host) | |
| [14:38:47] | wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [14:39:34] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 240 seconds) | |
| [14:39:55] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 240 seconds) | |
| [14:39:59] | cecil (cecil!~cesman@pool-173-60-115-40.lsanca.fios.verizon.net) has joined #mythtv | |
| [14:44:18] | doev (doev!~doev@p4FD439C4.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [14:55:47] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [15:12:43] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [15:16:07] | warpme: | jya: full LiveTV zap of all channels is at http://warped.homenet.org/fullzap.log First 43 channels are HD, rest are SD. |
| [15:37:47] | warpme: | jya: I see You add logging into devel/ringbuffer. Let me rebuild FE and produce zap log with this improved loging. |
| [15:43:20] | gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:6700::24) has joined #mythtv | |
| [16:48:23] | len_ (len_!~quassel@65-128-248-122.mpls.qwest.net) has joined #mythtv | |
| [16:50:48] | warpme: | jya: log on my http server is now with full logging. |
| [16:53:18] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:57:07] | Goga777 (Goga777!~Goga777@128-71-38-77.broadband.corbina.ru) has quit (Quit: Leaving) | |
| [16:57:37] | SteveGoodey (SteveGoodey!~steve@host86-132-103-208.range86-132.btcentralplus.com) has joined #mythtv | |
| [17:23:09] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warpme) | |
| [17:55:40] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [18:24:34] | stuartm: | /mode +bbbb *!*@46.148.30.0/23$##not-a-honeypot *!*@62.109.0.0/19$##not-a-honeypot *!*@62.122.72.0/23$##not-a-honeypot *!*@78.24.216.0/21$##not-a-honeypot |
| [18:24:35] | stuartm: | /mode +bbbb *!*@82.146.40.0/21$##not-a-honeypot *!*@82.146.56.0/21$##not-a-honeypot *!*@91.197.131.0/24$##not-a-honeypot *!*@91.207.60.0/23$##not-a-honeypot |
| [18:24:37] | stuartm: | /mode +bbbb *!*@91.207.116.0/23$##not-a-honeypot *!*@91.213.72.0/24$##not-a-honeypot *!*@91.213.93.0/24$##not-a-honeypot *!*@91.216.3.0/24$##not-a-honeypot |
| [18:24:38] | stuartm: | /mode +bbbb *!*@91.217.90.0/23$##not-a-honeypot *!*@91.217.162.0/24$##not-a-honeypot *!*@91.222.64.0/24$##not-a-honeypot *!*@91.229.76.0/22$##not-a-honeypot |
| [18:24:40] | stuartm: | /mode +bbbb *!*@91.229.248.0/24$##not-a-honeypot *!*@91.233.89.0/24$##not-a-honeypot *!*@92.63.96.0/21$##not-a-honeypot *!*@95.215.140.0/22$##not-a-honeypot |
| [18:24:41] | stuartm: | /mode +bbbb *!*@188.120.224.0/20$##not-a-honeypot *!*@188.120.240.0/21$##not-a-honeypot *!*@188.190.124.0/22$##not-a-honeypot *!*@193.0.146.0/23$##not-a-honeypot |
| [18:24:43] | stuartm: | /mode +bbbb *!*@193.28.144.0/24$##not-a-honeypot *!*@193.104.110.0/24$##not-a-honeypot *!*@193.106.31.0/24$##not-a-honeypot *!*@193.203.48.0/22$##not-a-honeypot |
| [18:24:44] | stuartm: | /mode +bbbb *!*@194.1.184.0/24$##not-a-honeypot *!*@194.29.185.0/24$##not-a-honeypot *!*@194.126.251.0/24$##not-a-honeypot *!*@194.242.2.0/23$##not-a-honeypot |
| [18:24:46] | stuartm: | /mode +bbbb *!*@195.39.252.0/23$##not-a-honeypot *!*@195.78.108.0/23$##not-a-honeypot *!*@195.88.190.0/23$##not-a-honeypot *!*@92.63.104.0/22$##not-a-honeypot |
| [18:24:47] | stuartm: | /mode +b *!*@91.220.202.0/22$##not-a-honeypot |
| [18:24:49] | stuartm: | sorry about that folks |
| [18:24:52] | stuartm: | copy/paste got the better of me |
| [18:28:48] | stuartm: | should anyone be wondering what that's all about – https://botmonitoring.github.io/ |
| [18:29:52] | Mode for #mythtv by ChanServ!ChanServ@services. : +o stuartm | |
| [18:30:01] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@46.148.30.0/23$##not-a-honeypot *!*@62.109.0.0/19$##not-a-honeypot *!*@62.122.72.0/23$##not-a-honeypot *!*@78.24.216.0/21$##not-a-honeypot | |
| [18:31:27] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@82.146.40.0/21$##not-a-honeypot *!*@82.146.56.0/21$##not-a-honeypot *!*@91.197.131.0/24$##not-a-honeypot *!*@91.207.60.0/23$##not-a-honeypot | |
| [18:31:53] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@91.207.116.0/23$##not-a-honeypot *!*@91.213.72.0/24$##not-a-honeypot *!*@91.213.93.0/24$##not-a-honeypot *!*@91.216.3.0/24$##not-a-honeypot | |
| [18:32:23] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@91.217.90.0/23$##not-a-honeypot *!*@91.217.162.0/24$##not-a-honeypot *!*@91.222.64.0/24$##not-a-honeypot *!*@91.229.76.0/22$##not-a-honeypot | |
| [18:33:14] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@91.229.248.0/24$##not-a-honeypot *!*@91.233.89.0/24$##not-a-honeypot *!*@92.63.96.0/21$##not-a-honeypot *!*@95.215.140.0/22$##not-a-honeypot | |
| [18:33:31] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@188.120.224.0/20$##not-a-honeypot *!*@188.120.240.0/21$##not-a-honeypot *!*@188.190.124.0/22$##not-a-honeypot *!*@193.0.146.0/23$##not-a-honeypot | |
| [18:33:50] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@193.28.144.0/24$##not-a-honeypot *!*@193.104.110.0/24$##not-a-honeypot *!*@193.106.31.0/24$##not-a-honeypot *!*@193.203.48.0/22$##not-a-honeypot | |
| [18:34:02] | dekarl1 is now known as dekarl | |
| [18:34:54] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@194.1.184.0/24$##not-a-honeypot *!*@194.29.185.0/24$##not-a-honeypot *!*@194.126.251.0/24$##not-a-honeypot *!*@194.242.2.0/23$##not-a-honeypot | |
| [18:35:07] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +bbbb *!*@195.39.252.0/23$##not-a-honeypot *!*@195.78.108.0/23$##not-a-honeypot *!*@195.88.190.0/23$##not-a-honeypot *!*@92.63.104.0/22$##not-a-honeypot | |
| [18:35:23] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : +b *!*@91.220.202.0/22$##not-a-honeypot | |
| [18:35:35] | stuartm: | well, that was a complete waste of time |
| [18:36:04] | stuartm: | for further information – https://www.eff.org/deeplinks/2014/04/wild-he . . . ovember-2013 |
| [18:37:27] | stuartm: | normal programming now resumes |
| [18:53:30] | Mode for #mythtv by stuartm!~stuartm@mythtv/developer/stuartm : -o stuartm | |
| [19:13:51] | moparisthebest (moparisthebest!~quassel@2001:470:1f11:88c::2) has quit (Ping timeout: 245 seconds) | |
| [19:15:20] | moparisthebest (moparisthebest!~quassel@2001:470:1f11:88c::2) has joined #mythtv | |
| [19:34:35] | TheCrasher (TheCrasher!~TheCrashe@p5080751F.dip0.t-ipconnect.de) has joined #mythtv | |
| [19:47:43] | Steve-Goodey (Steve-Goodey!~steve@host86-132-103-208.range86-132.btcentralplus.com) has joined #mythtv | |
| [19:57:37] | stuarta: | stuartm: did you drink some insanity with your cuppa this afternoon? |
| [19:59:30] | stuartm: | there were some heavy duty painkillers ... |
| [20:03:15] | stuarta: | :) |
| [20:10:28] | stuarta: | how's the back? |
| [21:00:53] | esperegu: | is there a preferred way to solve database upgrade errors? http://dpaste.com/1776781/ |
| [21:02:29] | stuarta: | that's more a #mythtv-users question, but have you had a failed upgrade before? |
| [21:11:08] | esperegu: | stuarta: well. It was running in a gui and failed. and this one I ran on the commandline. So maybe its the previous run? |
| [21:12:45] | stuarta: | probably |
| [21:13:07] | stuarta: | find the backup from the earlier failed upgrade, restore it, and do the upgrade again |
| [21:13:17] | stuarta: | for the paranoid, backup the currently broken one first |
| [21:13:22] | esperegu: | stuarta: it looks like it is continuesly creating a backup: http://dpaste.com/1776797/ |
| [21:13:54] | stuarta: | probably because it's continually trying to do the upgrade |
| [21:24:32] | esperegu: | stuarta: it looks like there were multiple processes doing the upgrade. However the last one still fails because I already have that column. |
| [21:27:52] | esperegu: | it fails on version 1324 |
| [21:29:33] | esperegu: | these are the changes I had to made previously to get it running. how to get around this error? |
| [21:31:17] | esperegu: | I will try to remove those colums and then run it again. |
| [21:44:21] | Steve-Goodey (Steve-Goodey!~steve@host86-132-103-208.range86-132.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:45:58] | esperegu: | stuarta: that seems to have fixed the upgrade. thx |
| [21:46:06] | stuarta: | np |
| [21:54:26] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [21:57:31] | wagnerrp_ is now known as wagnerrp | |
| [22:00:27] | TheCras4 (TheCras4!~TheCrashe@p5DCE4A65.dip0.t-ipconnect.de) has joined #mythtv | |
| [22:01:36] | stuartm: | stuarta: a lot better than yesterday, a night's sleep an' all, so nothing more serious than pulled muscles |
| [22:03:35] | TheCrasher (TheCrasher!~TheCrashe@p5080751F.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [22:06:27] | stuarta: | excellent. night all |
| [22:17:44] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 252 seconds) | |
| [22:17:58] | gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:6700::24) has quit (Quit: Leaving.) | |
| [22:59:51] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [23:15:43] | nephyrin (nephyrin!~neph@corp.mtv2.mozilla.com) has quit (Read error: Connection reset by peer) | |
| [23:15:55] | nephyrin (nephyrin!~neph@corp.mtv2.mozilla.com) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.