MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (84):

MythLogBot, aloril, Anduin, clever, coling, damaltor, danielk22, eharris, jcarlos, jpabq, justinh, jwhite, kenni, knightr, kurre2, mag0o, markk, MythBuild, pheld, poptix, reynaldo, rsiebert, sailerboy, simonckenyon, sphery, sraue, stuarta, superm1, tomimo, Unhelpful, zCougar, _charly_, Anssi, anykey_, Beirdo, brfransen, Cougar, ElmerFudd, foobum, ghoti, J-e-f-f-A, joe__, kwmonroe, laga, purserj, Slasher`, sutula, vallor, wagnerrp, dlblog, gregL, mrand, tris, Chutt, JEDIDIAH__, jams, GreyFoxx, yoyolala, Mousey, davide, natanojl, j-rod|afk, cesman, mmiller, dekarl, mike|3, cattelan, Dave123, skd5aner, mzanetti, high-rez, jpabq-, mirage335, Peitolm, MaverickTech, nutron, jarle, josef__, wahrhaft_, oliver, ikonia, Mkaysi, abqjp, toeb

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-12-26 13:55:38 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229
Friday, December 2nd, 2011, 00:00 UTC
[00:00:04] abqjp (abqjp!~jpabq@174-28-160-138.albq.qwest.net) has quit (Ping timeout: 245 seconds)
[00:00:42] abqjp (abqjp!~jpabq@71-37-150-163.albq.qwest.net) has joined #mythtv
[00:01:42] jpabq- (jpabq-!~jpabq@71-37-150-163.albq.qwest.net) has joined #mythtv
[00:09:42] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Quit: jpabq)
[00:09:43] abqjp is now known as jpabq
[00:09:43] jpabq (jpabq!~jpabq@71-37-150-163.albq.qwest.net) has quit (Changing host)
[00:09:44] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[00:17:45] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Quit: ZNC - http://znc.in)
[00:21:27] vallor (vallor!~Ponzo@pdpc/supporter/monthlygold/vallor) has joined #mythtv
[00:33:25] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 240 seconds)
[00:34:11] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has joined #mythtv
[00:34:11] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has quit (Changing host)
[00:34:11] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv
[00:41:09] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[01:33:02] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[01:37:35] Cougar (Cougar!~cougar@kkk.version6.net) has quit (Read error: Operation timed out)
[01:38:36] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Read error: Operation timed out)
[01:39:30] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[01:40:37] jpabq- (jpabq-!~jpabq@71-37-150-163.albq.qwest.net) has quit (Ping timeout: 240 seconds)
[01:41:42] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[01:42:43] jpabq- (jpabq-!~jpabq@71-37-155-6.albq.qwest.net) has joined #mythtv
[01:45:44] Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv
[01:53:32] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[02:01:16] jpabq| (jpabq|!~jpabq@174-28-179-62.albq.qwest.net) has joined #mythtv
[02:01:19] jpabq- (jpabq-!~jpabq@71-37-155-6.albq.qwest.net) has quit (Ping timeout: 252 seconds)
[02:01:23] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 255 seconds)
[02:01:43] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[02:04:52] davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection)
[02:05:18] davide (davide!~david@host70.16.intrusion.com) has joined #mythtv
[02:25:15] JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) has quit (Ping timeout: 260 seconds)
[02:25:48] JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) has joined #mythtv
[03:32:51] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:41:26] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[04:10:50] foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Ping timeout: 260 seconds)
[04:17:48] foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv
[04:23:35] reynaldo (reynaldo!~rverdejo@pc-59-218-86-200.cm.vtr.net) has quit (Ping timeout: 252 seconds)
[04:35:24] jya: Beirdo: I'm in
[04:37:44] jya: just read the past few pages of talks.. I can't see much the link between UTC and audio :P
[05:06:14] gigem: danielk22: i saw corruption with recordings i made this afternoon using ron's patch and rtp. oddly, i didn't see any in recordings this evening. anyway, it's probably not something unique to the version you committed.
[05:26:37] jeremyseattle (jeremyseattle!~jeremysea@c-24-17-221-37.hsd1.wa.comcast.net) has joined #mythtv
[05:41:38] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[05:58:58] Beirdo: jya: heya..
[05:59:10] jya: hi
[05:59:30] Beirdo: I was wondering if I could interest you in collecting some recordings for testing commflagging with
[06:00:20] Beirdo: I can get many many that are from the US market to test with, but from AU (and UK, hence why I was looking for a stuart), I have none to speak of, so ...
[06:00:52] Beirdo: some that the current commflag does OK on, and fails miserably on... both would be useful
[06:00:59] jya: ok… why type of recording do you need?
[06:01:12] Beirdo: all of the above :)
[06:01:19] jya: I'd say none of the commflag works okay or reliably
[06:01:52] Beirdo: oh, even better then. I don't want to end up just tuning against "normal" US recordings if I can help it
[06:01:53] jya: which is why neither my wife or I use it (though I have set two buttons on the remote precisely for that)
[06:02:06] jya: instead we use the FF 30s RF: 10s
[06:02:15] Beirdo: understandably
[06:02:41] jya: the public networks (ABC, SBS) do work better and more reliably, but there are almost no ads :)
[06:03:08] Beirdo: I was thinking, I could send you a 16GB or 32GB USB stick for a pile of recordings of various types...
[06:03:16] jya: Channel 10 is very bad, more often than not, it skips like 15 minutes at a time (start at one ad and stop two ads later)
[06:03:23] Beirdo: ick
[06:03:44] jya: I have a faster upstream internet: 2.5Mbit/s ; I could always upload them
[06:04:28] Beirdo: Well, that could work too, but transferring many gigabytes... whatever works best, I guess
[06:04:30] jya: depends on how long you're willing to wait.
[06:04:42] jya: by the time you send it, I receive it, and I send it back...
[06:05:01] jya: would be easier to just buy a USB stick here, they aren't that expensive for me to worry about that
[06:05:09] Beirdo: yeah... we'd be a few weeks out for sure.
[06:05:44] Beirdo: sure, if you'd be cool with that, that could easily work. using DVDs would be a lot of discs, potentially
[06:06:58] Beirdo: it would be good to get a bunch from other markets, and knowing that UK and AU both are poorly covered by what we have now... having some from there would be especially useful
[06:08:08] Beirdo: oh wow, this show I'm watching would be perfect for testing scene change detection
[06:08:12] jya: I have some recordings from other countries, but they are usually shorts and won't include a full ad
[06:08:35] jya: they were sent to me over time to identify why swtiching one audio type to another broke
[06:08:44] Beirdo: yeah, if possible, complete recordings would be best for this
[06:08:46] jya: typically , standard program 5.1 -> ad stereo
[06:09:01] jya: so I usually only have the 5s before, 5s after
[06:09:55] jya: what time is it where you are ?
[06:09:58] Beirdo: ooh, that would be good to know too for detection purposes. Right now, audio-wise, I have average power that's higher than usual (indicating dynamic compression) and much lower than usual (silence)
[06:10:00] jya: must be late
[06:10:03] Beirdo: 10:10pm
[06:10:12] jya: is that all ? ok
[06:10:28] Beirdo: yup, I'm in Seattle these days
[06:10:40] jya: if you ever get comm detection working properly, I'd be grateful
[06:10:45] jya: at some state I was using it
[06:10:50] Beirdo: as close to AU time as you'll get on this continent (short of Alaska)
[06:10:51] jya: but typically my usage would be:
[06:11:03] jya: press ENTER to save my current location (and also display the time)
[06:11:06] jya: press skip ad
[06:11:18] jya: pay attention how much it skipped
[06:11:25] jya: if more than 4 minutes, something is wrong
[06:11:54] Beirdo: yeah, makes sense
[06:12:34] Beirdo: every broadcast market seems to have slightly different characteristics, it's what makes it so tricky to get good accuracy
[06:13:00] MythBuild: build #347 of master-vista-mingw-32bit is complete: Exception [exception git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/347 blamelist: Taylor Ralph <tralph@mythtv.org >
[06:13:23] Beirdo: hehe, go, slow windows slave! :)
[06:13:55] Beirdo: let me check the blasted thing to see if it needs a poke with a boot
[06:15:26] jya: Beirdo: over the next few days, I'll pay attention to the ads detection.. maybe make my wife contribute , she watches far more TV than I do (I only ever watch the foreign news)
[06:17:04] Beirdo: OK. A smattering of ones where it works OKish are still useful as well
[06:17:08] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has left #mythtv ("Leaving")
[06:17:19] Beirdo: but certainly, ones where it doesn't work for beans :)
[06:18:47] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has joined #mythtv
[06:22:31] Eddie70 (Eddie70!~yianni@79.103.50.150.dsl.dyn.forthnet.gr) has quit (Ping timeout: 244 seconds)
[06:36:21] Captain_Murdoch: danielk22, it looks like our duration checking via libav* may be broken since removing that extra call to av_estimate_timings(ic, 0); for a file without a seektable, with that line in, I see correct duration, if I remove that line like your patch, then I get incorrect length detected. any idea why that might be happening?
[06:54:29] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 252 seconds)
[06:54:39] jpabq| (jpabq|!~jpabq@174-28-179-62.albq.qwest.net) has quit (Ping timeout: 245 seconds)
[06:55:00] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[06:56:13] jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[06:57:13] jpabq- (jpabq-!~jpabq@174-28-149-119.albq.qwest.net) has joined #mythtv
[07:06:59] jeremyseattle (jeremyseattle!~jeremysea@c-24-17-221-37.hsd1.wa.comcast.net) has left #mythtv ()
[07:10:37] Olti (Olti!~Olti@tmo-102-70.customers.d1-online.com) has joined #mythtv
[07:11:08] Olti (Olti!~Olti@tmo-102-70.customers.d1-online.com) has quit (Client Quit)
[07:45:22] toeb (toeb!~tob@HSI-KBW-078-042-104-026.hsi3.kabel-badenwuerttemberg.de) has joined #mythtv
[07:46:27] markk: not too sure who to raise this one with so going to poke davide and danielk22 :)
[07:49:01] markk: last night I had some strange recording behaviour – exact same problem that I had on the same schedule a week ago. Back to back recordings scheduled on BBC HD here. One at 9pm for 30 mins and the other at 9.30 for 30 mins. When I go to play them back, both start at the beginning of the *second* recording.
[07:52:51] markk: Looking at the files themselves, the second recording is fine (it is the expected show and expected length) and is 2.4GB in size. The first recording is however only 290MB, starts about 2 minutes before the end of the first show and cuts off after almost exactly 4 minutes (I have all my recordings scheduled to start 2 minutes early and finish 2 minutes late).
[07:54:29] markk: Multirec is enabled and there is currently only one tuner for that channel – so it must have been using multirec. Any more info you might need? As I said, seems to be repeatable.
[08:03:33] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[08:03:43] sphery: So you're saying that the first recording started 28min late (which is 30min late, after factoring in your 2min start early) and the 2nd recording started properly and ended properly? Do your backend logs show the first recording starting 28min late or on time?
[08:08:15] markk: sphery: unless we're still logging to the db, I think the backend log is history. I don't honestly know whether the first recording started late or on time – though I have a vague recollection about seeing it come up earlier in the watch list. My gut feeling is that the 'proper' file for the first recording is getting overwritten when the second starts.
[08:08:48] wagnerrp: if youre running trunk, everything goes into the database
[08:09:18] Beirdo: (unless you run with --nodblog)
[08:09:28] wagnerrp: there is that...
[08:10:27] sphery: I need to get that log viewer service done...  :)
[08:11:02] markk: Beirdo: any utility to easily parse out some db logging? 198k entries:)
[08:12:20] sphery: in the meantime, SELECT * FROM logging WHERE application = 'mythbackend' ORDER BY msgtime ASC;
[08:13:06] sphery: and might want to add AND host = '<hostname>' and can qualify it with msgtime > '2011-12–01 00:00:00' or whatever
[08:13:51] ** Beirdo pokes sphery and reminds him about that viewer :) **
[08:14:40] sphery: hey, I reminded myself first (just a few lines above :)
[08:14:46] Beirdo: I know. :)
[08:17:24] markk: 2011-12–01 20:57:02 >> Updating status for Rev.:"Comedy about a vicar running an inner-city church" on cardid 9 (Tuning => Recording)
[08:17:42] markk: so looks like it at least thought it was starting at the right time
[08:19:43] sphery: perhaps the card just didn't provide data for a long time?
[08:19:55] sphery: maybe signal issue or something?
[08:19:59] Beirdo: OMG this gets slow when I dump every frame to disk :)
[08:20:18] Beirdo: I think this is a patented bad idea
[08:20:23] sphery: though repeatable sounds like it might not be a transient error
[08:21:11] markk: 2011-12–01 20:58:10 >> TVRec(8): Failed to set channel to 52100. Reverting to kState_None
[08:21:16] markk: could be an issue:)
[08:21:31] markk: stuartm: didn't you see something like this? ^^
[08:21:50] Beirdo: 'win 13
[08:21:53] Beirdo: ergh
[08:22:43] willcooke (willcooke!~will@willcooke.plus.com) has joined #mythtv
[08:22:43] willcooke (willcooke!~will@willcooke.plus.com) has quit (Changing host)
[08:22:43] willcooke (willcooke!~will@canonical/willcooke) has joined #mythtv
[08:41:10] markk: and just to add further confusion – channel 52100 referenced above isn't the correct channel
[08:50:02] Peitolm: do you have have a mis-config in the channels?
[09:08:15] jeff999 (jeff999!~jeff@58-6-93-73.dyn.iinet.net.au) has joined #mythtv
[09:24:13] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 244 seconds)
[09:31:16] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[09:46:35] stuartm: markk: yes, the same or very similar, it tries to tune a completely wrong serviceid on the right multiplex and fails
[09:48:52] stuartm: e.g. the most recent example it's starting a scheduled recording of BBC HD, it tunes to the correct frequency and inspects the tables but it's looking for the serviceid belonging to CCTV that fails and so does the recording
[09:51:58] stuartm: markk: heh, I've just read back, mine failed on the exact same programme a week ago
[09:53:27] stuartm: Beirdo: I'll sort some examples for you :)
[10:00:37] stuartm: dekarl_zZz: thanks for that, I might actually have time this month to finally write our side of the configuration ui – being Christmas there won't be anything good on TV for the next few weeks
[10:02:09] Beirdo: stuartm: great, thanks. let me know if you'd like me to send you some media
[10:15:16] Olti (Olti!~Olti@tmo-102-223.customers.d1-online.com) has joined #mythtv
[10:15:23] Olti (Olti!~Olti@tmo-102-223.customers.d1-online.com) has quit (Client Quit)
[10:15:30] Olti (Olti!~Olti@tmo-102-223.customers.d1-online.com) has joined #mythtv
[10:16:22] Olti (Olti!~Olti@tmo-102-223.customers.d1-online.com) has quit (Client Quit)
[10:20:42] reynaldo (reynaldo!~rverdejo@pc-59-218-86-200.cm.vtr.net) has joined #mythtv
[10:34:14] reynaldo (reynaldo!~rverdejo@pc-59-218-86-200.cm.vtr.net) has quit (Ping timeout: 245 seconds)
[10:59:05] stuartm: Beirdo: are you able to use SDHC card(s)? They are even easier to post and just as cheap (or even cheaper) – I can pick up a 16GB one for £12 and stick it in a standard envelope
[11:00:42] Beirdo: sure, that would work fine
[11:00:53] Beirdo: and good point :)
[11:04:25] stuartm: I just managed to pick one up in the Amazon black friday lightening deals for £8, but I that's been put to use already so I'll order another :)
[11:05:01] mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[11:05:27] Beirdo: heh, cool
[11:05:56] mike|3 (mike|3!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv
[11:08:08] reynaldo (reynaldo!~rverdejo@200.72.211.67) has joined #mythtv
[11:17:25] reynaldo (reynaldo!~rverdejo@200.72.211.67) has quit (Ping timeout: 240 seconds)
[11:20:17] Beirdo: I think I will head to bed shortly.
[11:21:09] Beirdo: hehehe... that was stooopid
[11:21:12] Beirdo: filled /
[11:22:27] Beirdo: 82GB of raw frames. I *knew* that was a dumb plan to let run that long
[11:23:05] jeff999 (jeff999!~jeff@58-6-93-73.dyn.iinet.net.au) has quit (Ping timeout: 260 seconds)
[11:28:32] markk: stuartm: so Rev followed by Life's Too Short?
[11:30:08] stuartm: markk: just Rev in this case and nothing at all was actually recorded
[11:30:21] markk: what card? (tuner)
[11:32:10] markk: stuartm: so the second recording is probably a red herring (although something gets 'unlocked' when the second recording starts and data starts to get written very late for the first ???)
[11:32:54] markk: trying to eliminate the hardware – my tuner is : TeVii Technology Ltd. DVB-S2 S660
[11:33:00] stuartm: DVB-S2 – Tevii s460 – CX23880 + CX24116 – http://linuxtv.org/wiki/index.php/TeVii_S460
[11:33:36] stuartm: huh, maybe we can't eliminate it then :)
[11:35:10] stuartm: markk: I'd say the second recording can be ignored, I've seen this before when testing tuners using livetv after a couple of recent rescans – it wasn't until it occurred for a scheduled recording that I really took notice
[11:37:09] stuartm: I'm not sure why in your case it still recorded something, someone more familiar with the recorder internals might be able to shed some light (e.g. danielk22)
[11:38:25] stuartm: the hardware in the USB S660 is completely different to the S460 ...
[11:38:28] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:38:39] jeff999 (jeff999!~jeff@58-6-93-73.dyn.iinet.net.au) has joined #mythtv
[11:41:26] stuartm: markk: 52100 is "Travel Ch +1" – I take it you don't normally record from there? Is EIT collection enabled for that channel? I still think this is related to the active EIT scan and perhaps it not being shut down completely before we start tuning for the recording?
[11:42:09] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[11:47:42] stuartm: markk: did you have any other recordings on that card in the hour beforehand? I find that this only happens with the first recording of the evening which again is circumstantial evidence against the eit scan, the scanner has been running but is then suspended by the first recording preventing it trampling subsequent recordings
[11:48:49] stuarta: i sounds to me a bit like a locking issue, ie. the recording is trying to start too early
[11:49:36] stuartm: stuarta: right
[11:55:37] stuartm: if that's the case it would probably require that the active scanner start tuning a new channel just after the recorder hence we aren't seeing this happening more frequently – it takes a very narrow timing of concurrent events
[11:57:35] stuartm: i.e. my recording of last night's Rev went fine – it's probably coincidence that markk saw the same problem with the same programme and channel exactly a week later after me
[11:57:55] stuarta: it's bizarre
[11:58:14] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[12:02:27] stuartm: we can at least start looking at the possibility, stick some debugging in the right places to see whether on certain occasions the scanner is still running when we start tuning for a recording – if so we can fix the locking
[12:09:51] markk (markk!~mark@host86-180-159-105.range86-180.btcentralplus.com) has quit (Remote host closed the connection)
[12:17:03] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[12:37:37] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has joined #mythtv
[12:38:13] reynaldo (reynaldo!~rverdejo@pc-59-218-86-200.cm.vtr.net) has joined #mythtv
[12:38:45] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[12:58:00] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 582911, sources date: 20110403, built on: 2011-08-19 03:31:37 UTC 582911 http://www.kvirc.net/)
[13:01:19] markk (markk!~mark@host86-180-222-112.range86-180.btcentralplus.com) has joined #mythtv
[13:04:33] markk: stuartm: it's probably the same issue I've seen some mornings. last channel is BBC HD and starting live tv fails. I then go back into livetv and it works – BUT, there is still a defunct livetv process sitting in the backend (i.e. backend says it has 2 live tv sessions). so probably a combination of failed tuning triggering some edge behaviour in the backend.
[13:05:26] markk: the extra 'rogue' live tv session and the fact that the recording suddenly started 28 minutes into the programme last night both suggest something isn't being cleaned up.
[13:06:26] davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection)
[13:06:48] davide (davide!~david@host70.16.intrusion.com) has joined #mythtv
[13:07:57] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Read error: Connection reset by peer)
[13:09:08] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has joined #mythtv
[13:09:08] Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has quit (Changing host)
[13:09:09] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[13:16:11] jeff999 (jeff999!~jeff@58-6-93-73.dyn.iinet.net.au) has quit (Remote host closed the connection)
[13:32:37] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 240 seconds)
[13:33:15] danielk22: markk: stuarta: stuartm: I have a feeling EIT scanning isn't getting shut down properly when a real recording is started. There was some other indication of that last week, hopefully I'll recall it after my coffee.
[13:36:12] stuartm: danielk22: could it have been me raising this last week with logs? It's come up again because markk ran into the same last night
[13:37:40] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has joined #mythtv
[13:37:40] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has quit (Changing host)
[13:37:40] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv
[13:37:55] stuartm: http://irc.mythtv.org/ircLog/channel/4/2011-11-24 << Halfway down the page
[13:38:25] stuartm: sadly I chose to place my faith in pastebin.ca which is down, again
[13:46:35] stuarta: doh
[13:48:07] danielk22: Are there any other patch posting places that allow you to upload a patch? cut-n-paste can be a bit annoying and is error prone.
[13:49:01] stuarta: github has a gist section
[13:49:51] stuarta: https://gist.github.com/
[13:49:54] stuarta: worth a try?
[13:50:10] danielk22: https://gist.github.com/ doesn't appear to allow uploading a patch...
[13:50:10] stuarta: bah. cut n paste only
[13:50:41] danielk22: yeah, same problem as pastebin.com
[13:53:00] stuarta: on the bright side. i think it responds more often than pastebin.com :)
[14:02:32] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has joined #mythtv
[14:21:58] dekarl_zZz is now known as dekarl
[14:24:06] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:55:35] j-rod|afk is now known as j-rod
[15:08:06] stuartm: pastebin.ca is the only one I've ever come across, but it's stability has been woeful in the last year – they did release the code for pastebin.ca so if we were motivated enough we could tie it into our trac credentials and host our own public-view, private-paste copy
[15:10:48] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 582911, sources date: 20110403, built on: 2011-08-19 03:31:37 UTC 582911 http://www.kvirc.net/)
[15:11:50] wagnerrp: stuartm: while i see worth in running our own pastebin, why make it writable only by us?
[15:13:13] stuartm: wagnerrp: otherwise you have to deal with spam, inappropriate posting etc and I just don't see that anyone of us has the time to perform full-time moderation
[15:14:02] wagnerrp: ah, didnt even consider the other tools got spammed frequently, although it seems obvious in hindsight
[15:14:06] stuartm: that said, if someone can see a way to make it possible for mythtv users to paste while keeping the wider internet from abusing it ...
[15:15:31] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has joined #mythtv
[15:15:33] wagnerrp: i've actually been considering something more the opposite, file and imagebin writable by all, readable only by us
[15:15:52] stuartm: aside from spam pastebin.com is now the goto place for script kiddies and hackers to communicate and dump the personal/corporate data they've stolen – so I expect they face plenty of DCMA takedown requests
[15:16:26] wagnerrp: something that wouldnt be limited to the 256kB restriction on trac
[15:17:21] stuartm: a proper filebin/ftp would be great, it's sorely lacking
[15:18:05] stuartm: the private read idea is a good way to reduce abuse
[15:18:56] wagnerrp: it would still get abused, but who cares, since no one would be able to read it
[15:19:10] wagnerrp: it would only be people 'tasting' it to see if they could store stuff there
[15:19:38] stuartm: right, hence 'reduce' not 'eliminate'
[15:20:25] stuarta: you would have to make it so people couldn't even see the files they upload
[15:20:42] stuarta: not read, no see, only upload
[15:20:49] stuarta: otherwise they _will_ abuse it
[15:21:08] stuarta: store illegal stuff we don't want the project tarred with
[15:21:15] wagnerrp: thats the idea
[15:25:26] wagnerrp: not the 'illegal' aspect, but perhaps something to be less concerned with uploading the 30–60 second video clips for debugging
[15:25:46] wagnerrp: honestly, i was more just wanting something for images/files as simple as the ones available for text
[15:26:35] stuartm: that should be very easy to do
[15:26:36] wagnerrp: all the ones for images and files are crufted down with account signups, ads, delays, download restrictions
[15:26:51] wagnerrp: an all around painful experience for both sides
[15:27:32] wagnerrp: i have no desire to go pulling anything off rapidshare
[15:28:02] stuartm: it's a pain certainly
[15:53:01] jams: i would venture to say no one would use it if the experiance was anything like rapidshare.
[16:01:10] Eddie70 (Eddie70!~yianni@79.103.32.14.dsl.dyn.forthnet.gr) has joined #mythtv
[16:10:35] Eddie70 (Eddie70!~yianni@79.103.32.14.dsl.dyn.forthnet.gr) has quit (Ping timeout: 244 seconds)
[16:12:25] Eddie70 (Eddie70!~yianni@79.103.14.134.dsl.dyn.forthnet.gr) has joined #mythtv
[16:56:55] jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[17:05:49] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Ping timeout: 240 seconds)
[17:06:17] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[17:32:54] danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.)
[17:35:16] andreax (andreax!~andreaz@p54BF2D18.dip.t-dialin.net) has joined #mythtv
[18:06:00] davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection)
[18:06:27] davide (davide!~david@host70.16.intrusion.com) has joined #mythtv
[18:07:09] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[18:21:00] Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv
[18:23:37] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[18:27:12] taylorr: markk: you might want to sanity check all the libdvd updates and make sure it doesn't cause any regressions for you
[18:28:50] sphery: danielk22: pastebinit is a script that supports (many) pastebin(s) and allows you to upload a file from the command line (among other things)--basically like "cat my.patch | pastebinit". https://launchpad.net/pastebinit + https://help.ubuntu.com/community/Pastebinit
[18:43:35] cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv
[18:48:01] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[19:05:33] rsiebert (rsiebert!~quassel@g226062008.adsl.alicedsl.de) has joined #mythtv
[19:08:31] rsiebert_ (rsiebert_!~quassel@e179135089.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[19:09:40] willcooke (willcooke!~will@canonical/willcooke) has quit (Quit: We will learn more of his wisdom later)
[19:12:31] markk: taylorr: all looks fine – just a little busy atm (and my optical drive seems to have stopped working)
[19:13:22] Eddie70 (Eddie70!~yianni@79.103.14.134.dsl.dyn.forthnet.gr) has quit (Remote host closed the connection)
[19:21:17] taylorr: markk: there is only one remaining item to sync, r1239, which applies to libdvdnav/searching.c – it makes changes to some custom code that looks dangerous
[19:22:08] taylorr: if you want I can generate a diff between our code and the latest dvdnav/dvdread if you want to review what we've done differently
[19:23:05] markk: taylorr: probably worth a look if you have the time
[19:29:40] taylorr: markk: also, should I add the ChangeLog and README files into our repository so we have the same info?
[19:31:48] sphery: taylorr: Beirdo did a README.sync in libav/ffmpeg stuff: https://github.com/MythTV/mythtv/commit/1813a44b97 Might be nice to standardize the approach we use (especially if we're really going to move all these external/3rd party libs to mythtv/external directory)
[19:34:47] jpabq__ (jpabq__!~jpabq@mythtv/developer/jpabq) has joined #mythtv
[19:37:19] jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 248 seconds)
[19:49:09] sphery: danielk22: did https://github.com/MythTV/mythtv/commit/c32fcf7fd fix your ticket at http://code.mythtv.org/trac/ticket/7799 ?
[19:49:17] sphery: er, nvm... seems it was closed
[19:50:01] xris: wagnerrp: not sure if you want to add to your email that we still estimate mythtv usage in north america at around 20–30k people
[19:50:32] wagnerrp: that many people using "other" guide data providers?
[19:50:33] sphery: wow, meaning the rest may be using mc2xml?
[19:50:42] xris: or none at all
[19:50:51] xris: SD had nearly 20k mythtv users for awhile
[19:51:09] xris: but yeah, we estimate around 20k people using mc2xml
[19:51:20] wagnerrp: wow
[19:51:37] xris: that's one of the reasons we want stats
[19:51:38] sphery: extremely sad... too many people using Free and thinking it means free...
[19:52:39] xris: TMS can take hard numbers to MS to help encourage them to track things down. 20k is likely around 10% usage of that MS service
[19:54:02] wagnerrp: jams: would it be difficult to quickly add a stat page on smolt.mythtv.org to display grabber name?
[19:54:52] xris: thought it was supposed to be there already
[19:55:03] wagnerrp: the data is there, its not being plotted
[19:55:09] superm1: why not add code to block mc2xml unless you build with a custom patch?
[19:55:28] wagnerrp: because people will just patch it out and run their own release
[19:55:35] superm1: you have to think that would discourage it significantly by raising the bar at least
[19:55:43] kormoc: superm1, they can always dump the xml and import it as raw files too
[19:55:47] wagnerrp: not really
[19:56:02] wagnerrp: they could just rename the executable, or run it through some other wrapper
[19:57:09] xris: I'd rather get stats first so we can encourage MS to shut the guy down
[19:57:12] sphery: danielk22: OK, this time, I checked carefully and I know the ticket isn't closed...  :) Looks like https://github.com/MythTV/mythtv/commit/f53cc94e8 fixed http://code.mythtv.org/trac/ticket/9744 , right?
[19:57:24] xris: MS thought that there were like 200 users
[19:57:43] wagnerrp: right, theres not really anything we can do while we remain open source
[19:57:48] superm1: well you figure there' probably a whole bunch of these people that use builds from linhes, atrpms, debian multimedia or mythbuntu. any of those folks would lose the regular updates and have to run their own builds regularly
[19:57:58] danielk22: sphery: yeah
[19:58:11] xris: kind of funny/ironic that writing open source stuff has made me want to pirate less software. I even paid for photoshop.
[19:58:22] wagnerrp: superm1: how would you determine they were using mc2xml to block them?
[19:58:58] wagnerrp: if were just collecting data, theres no motivation to hide the fact that youre using it
[19:59:06] superm1: i've never looked at the files that mc2xml spits out, are there particular headers that you can key on?
[19:59:22] kormoc: superm1, no, it's the same backend as SD
[19:59:25] kormoc: same data, same files
[19:59:27] wagnerrp: if were actively blocking it, they can pass it through some other script, that strips out any possible identification information in the XMLTV file
[19:59:32] superm1: oh that's really horrible then.
[19:59:46] wagnerrp: or potentially, just insert the data directly into the database themselves
[20:00:01] superm1: well you can go a different route and give them a nagging then. popup mythosd every few minutes telling them they're pirates and to cut it out
[20:00:03] sphery: I just hope all of those 20K users of mc2xml are donating to the author--after all, it's just not right to steal his software that steals data... From the mc2xml website: This software is not crippled, but it is not freeware either. If you determine that it is useful to you please donate an appropriate amount. If it isn't useful, then you probably won't be using it! :)
[20:00:20] sphery: danielk22: thanks
[20:00:26] sphery: (and thanks for fixing my bug, too :)
[20:00:57] xris: kormoc: not the same backend as sd. but same data. ms implemented the backend
[20:01:26] xris: which is why it has the security hole mc2xml exploits
[20:01:41] xris: or rather.. we assume, since mc2xml is closed source and no one really knows what it's doing.
[20:01:42] danielk22: I have my doubts as to the estimates for mythtv users using mc2xml, I'd sooner believe 200 than 20,000... I just think we'd be getting lots of support requests if there were so many mc2xml users.
[20:05:15] wagnerrp: id believe a few thousand, just because of how commonly it shows up on different forums
[20:05:34] wagnerrp: but more mc2xml users than sd users seems wrong
[20:05:44] wagnerrp: considering we tell them to use sd
[20:38:29] wagnerrp: scratch that, we are sending such data to smolt, but the server subsequently discards it
[20:41:43] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Quit: ZNC - http://znc.in)
[20:41:52] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Read error: Connection reset by peer)
[20:42:15] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[21:17:27] Slasher` (Slasher`!~Slasher@188.165.164.15) has quit (Quit: ZNC - http://znc.sourceforge.net)
[21:18:05] Slasher` (Slasher`!~Slasher@188.165.164.15) has joined #mythtv
[21:28:52] danielk22: If a recording's recstatus is "Failed", does that show up in any of the themes in an obvious way on the watch recording screen?
[21:30:37] sphery: do we actually get a metadata record for a recstatus failed recording?
[21:31:47] danielk22: It's tracked in oldrecorded, I think we have it in the program info that the themes see.
[21:32:03] sphery: ah, so you mean in the Previously Recorded screen?
[21:33:36] danielk22: No, I've written some code to track recording quality, in terms of measuring gaps in the recording. I'm setting the status as rsFailed when the recording is borked, But I don't see any indication in Watch Recordings (in MythCenter) of whether a recording is botched.
[21:35:37] sphery: ah, yeah, TTBOMK, before your code rsFailed meant there was no recording file, therefore, it wouldn't have ever been applicable for a recording in Watch Recordings... davide would know more details on rsFailed
[21:36:36] jams: wagnerrp- the new service is running on alcor, which does have that data. But I don't think a dns change has occured for it yet.
[21:36:43] jams: re smoon service
[21:37:47] wagnerrp: i thought we were sending data to smoon.mythtv.org
[21:38:56] danielk22: davide: ^^ hmm, maybe I should use a new status "rsDamaged"? I want the programs to be re-recorded but still be visible in Watch Recordings, since there is something there that may be watchable.
[21:39:04] jams: yeah thats currently pointing to the old instance. the new service has been setup on alcor (the reimaged mythtv server).
[21:39:31] wagnerrp: ah
[21:39:34] jams: so smoon.mythtv.org needs to be pointed to alcor. And I think httpd also needs to be setup on alcor but not for sure on that
[21:40:02] sphery: danielk22: yeah, if my understanding of rsFailed is correct, having a new status sounds like a good approach to me
[21:40:11] jams: which i'm willing to do, but i didn't want ot step on toes
[21:44:15] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 244 seconds)
[21:52:03] davide: danielk22: sphery is correct that we've never before had "failed" recordings to deal with in Watch Recordings. when will the "damage" detection be done, while recording or later? i think damage perhaps a damaged recording should be flagged separatly from the recording status. iow similarly to how commflagged, autoexpire, 1080, 720p, etc are handled.
[21:52:39] davide: s/think damage/think/
[21:53:14] davide: hmm, by "flagged" i mean displayed to the user.
[21:57:42] jpabq__: danielk22: davide, there is a "recstatus" available to the themer, but that is only used to show the future recording status on the upcomming screen. It is not used in the Watch Recording screen.
[22:00:05] jpabq__: danielk22: I really like the idea of rsDamanged. If you implement that, I will go into the HD-PVR recorder, and set it whenever a recording has to be "restarted".
[22:04:30] sphery: danielk22: also, note that oldrecorded records that aren't -3 (recorded) and 11 (never record) status are cleared out after 10 days, so as davide said, some other location is likely better for storing a damaged flag
[22:04:47] sphery: (since it applies more to the file than to the airing)
[22:06:17] danielk22: Hmm, so I should probably set rsFailed, so that the program is re-recorded, but also flag that information elsewhere to follow the program around...
[22:07:57] danielk22: davide: The detection is done as we record. So we could even check on the quality of an inprogress recording, but right now I just look at it at the end of a recording to decide what the recstatus flag should be.
[22:12:14] jpabq__: It would be nice if the user could see that a recording is "damaged" while it is still recording. If it is not a show that is going to be re-shown soon, the user may be able to do something about the problem to at least fix it for "the rest of the show".
[22:14:09] jpabq__ is now known as abqjp
[22:14:43] davide: jpabq__: that's what i've always used the preview image in watch recordings for.  :) if the preview doesn't come up, then oh crap, something wrong and off i go the computer room to whack the backend.
[22:19:00] davide: danielk22: the more i think about it, the more i think rsRecorded with a separate damaged flag is the way to go. there's much less chance of it rippling in unexpected ways. for auto re-record, we just need to make sure the call path to RI::AddHistory() has a way to turn off the duplicate setting.
[22:19:48] abqjp: davide: I recently bought a new HD-PVR. It has a new quirk which my old ones never exhibited: Three times in the last three weeks, it has gotten into a mode where it *will* record — for a few seconds — and then stop. Result is, I get a few seconds of recording, followed by a gap, followed by another few seconds (after Myth restarts the recording), repeat….. I need to go in and set the poll timeout to be a lot longer to see if we are just no
[22:19:49] abqjp: waiting long enough for data to appear. However, it normally works — it just gets in the mode every several days.
[22:21:52] sphery: davide / danielk22 : if desired, we could change the oldrecorded cleanup to keep around rsDamaged records, too (and keep them at least until re-recorded or forever if you want?)
[22:23:41] davide: abqjp: i don't regret getting my 2 hdpvrs. it was the only option two years ago. i'm so glad, however, to have switched to fios and an infinitv4. it's been rock solid.
[22:24:48] abqjp: Here my options are Comcast, Directv or Dish.
[22:26:16] davide: sphery: i realize that. it's just finding all of the places that check for rsRecorded/rsFailed or whatever else and make sure they now handle rsDamaged in the appropriate way.
[22:26:42] davide: abqjp: i thought comcast was mostly copy-freely.
[22:27:39] j-rod is now known as j-rod|afk
[22:28:11] abqjp: I don't know about now. Back when i was using firewire to record off Comcast, they were copy-freely, and then suddenly they changed everything to copy-once. That was a year before the HD-PVR became available.
[22:33:34] davide: ime, the firewire drm doesn't necessarily mean anything. for example, with my fios, everything except locals is locked down on firewire, while everything except 2 locals (even though they are in clear qam) and premiums are copy-freely with cable card.
[22:35:40] davide: btw, i check ron fraziers database for users of his scanner at http://www.ronfrazier.net/mythtv/cci/index.php. i though comcast was mostly copy-freely, but it appears it's more hit and miss. you'd probably have to try yourself or find someone in your area to check for you.
[22:52:33] andreax (andreax!~andreaz@p54BF2D18.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[22:56:10] sphery: abqjp and stuartm : btw, I tried to reproduce the "mythbackend won't upgrade the database when running in a non-interactive environment" issue you guys mentioned, but it upgraded for me... I didn't see any commits that looked like they'd have made a difference, so if you're still seeing the issue, I may not be able to help track it down
[23:00:40] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[23:01:34] abqjp: sphery: I could probably re-load the DB backup, and try to reproduce. Basically what I did was: "/etc/init.d/mythbackend stop; make install; /etc/init.d/mythbackend start". After a moment, in that window I saw a message that the db needed upgraded and it asked me to type YES. Since that window was not "really" interactive with the mythbackend process, it effectively just hung there. It *was* partially interactive, in that my attempt to type
[23:01:34] abqjp: was being grabbed by something, but I could not tell what the app was grabbing and what bash was grabbing.
[23:02:34] abqjp: sphery: this is under Fedora, using the mythbackend init scripts from contrib. I wonder if the way mythbackend is started, if it is not properly detecting that it is non-interactive.
[23:04:04] sphery: yeah, that's basically what I did (though with other init script), and it detected that it was non-interactive
[23:04:11] sphery: so it just auto-upgraded
[23:05:06] abqjp: If I remember right, it is being started with --daemon
[23:07:47] danielk22: davide: As far as I can tell I'll need to call curRec->AddHistory(true, true, false); in TVRec::FinishedRecording.. is that correct? What is the future flag?
[23:08:41] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[23:09:32] danielk22: davide: maybe not, can I just call curRec->FinishedRecording(false) ?
[23:10:40] danielk22: davide: instead of curRec->FinishedRecording(curRec->GetRecordingStatus() != rsRecorded); I just add "&& !damaged" ..
[23:13:53] davide: danielk22: yes, you'll need the "&& !damaged".
[23:17:10] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[23:23:31] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[23:25:37] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Client Quit)
[23:27:15] davide: danielk22: when do you intend to commit? i'm still pondering rsDamaged. it occurred to me that we already have rsAborted, so we have precedent for something to have a "recorded, but ..." status. the probelm with that is we'd need another status (rsRecordingDamaged?) to indicate damage while still recording.
[23:28:29] danielk22: davide: heh, but i already made the change.. i don't plan to commit for at least a few days.. so mull it over :)
[23:30:15] danielk22: my primary adjective is met if the program re-records. My secondary objective is to show it in the UI, but there is more than one way to accomplish that...
[23:30:41] davide: okay. you too. i'm not keen on rsRecordingDamaged, but i guess there's precedent for another recording status too (rsTuning).
[23:46:01] _gunni_ (_gunni_!~Gunni@koln-4db47222.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 582911, sources date: 20110403, built on: 2011-08-19 03:31:37 UTC 582911 http://www.kvirc.net/)
[23:50:16] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:56:52] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)

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