MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (82):

abqjp, aloril, Anduin_, Andy50, Anssi, anykey_, beata, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, dagar, danielk22, Dave123-road, dlblog, f33dMB, FinnTux, ghoti, gigem, gregL, GreyFoxx, Guest88964, highzeth, hobiga, iamlindoro, ikonia, j-rod|afk, jams, jan2600, jannau, jarle, jcarlos, JEDIDIAH__, joe_, jpabq, jpabq-, jpharvey, jstenback, justinh, jwhite, kc, knightr, kormoc, kurre, kwmonroe, laga, len, mag0o, markk, MatBoy, MaverickTech, mrand, MythBuild, MythLogBot, NightMonkey, noahric, okolsi, pheld, poptix, purserj, reynaldo, sailerboy, Seeker`, simonckenyon, skd5aner, Snow-Man, sphery, sunkan, sutula, taylorr, tgm4883, tomimo, tris, Unhelpful, wahrhaft, weta, xris, xxtjaxx, ybot, _charly_
Thursday, May 12th, 2011, 00:11 UTC
[00:11:29] Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Read error: Operation timed out)
[00:12:00] Dave123-road (Dave123-road!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Ping timeout: 260 seconds)
[00:15:43] ivanl (ivanl!4e56a3aa@gateway/web/freenode/ip.78.86.163.170) has quit (Ping timeout: 252 seconds)
[00:25:05] Dave123-road (Dave123-road!~dave@cpe-66-66-124-175.rochester.res.rr.com) has joined #mythtv
[00:25:13] Dave123 (Dave123!~dave@cpe-66-66-124-175.rochester.res.rr.com) has joined #mythtv
[00:42:07] dlblain (dlblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Read error: Connection reset by peer)
[00:43:57] pushpop (pushpop!~pushpop@pool-173-77-230-33.nycmny.fios.verizon.net) has joined #mythtv
[00:49:37] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:50:03] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[00:50:03] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[00:50:03] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[00:57:40] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[00:59:22] jpabq: sphery, This is what my frontend log shows for GL: http://pastebin.com/2qHDS3qa
[01:01:04] sphery: hmmm... ok, that's very different from danielk22's. I have an idea for how to detect his (just want to check with markk, first), but not sure about yours. Maybe markk will have an idea.
[01:01:52] jpabq: I assume the problem is related to the line "QPainter::begin: Paint device returned engine == 0, type: 3" ?
[01:03:24] sphery: yeah, makes sense... just don't know if it's too late by then. But you said it appears to do the right thing?
[01:12:20] kormoc is now known as kormoc_afk
[01:12:41] markk (markk!~mark@cm180.omega173.maxonline.com.sg) has joined #mythtv
[01:17:16] taylorr: markk: it seems the 8 output surfaces does NOT work which makes no sense
[01:17:52] taylorr: when it happens I see a surface remain visible for multiple frame times
[01:18:32] andreax1 (andreax1!~andreaz@p57B94E39.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[01:19:33] markk: taylorr: so 10 works and 8 doesn't ?
[01:19:44] taylorr: jpabq: have you had any issues with your HD-PVRs since using the irqpoll kernel parameter?
[01:20:01] taylorr: markk: yes, so it seems
[01:21:02] markk: taylorr: is that with or without the extra debugging? that patch definitely had an impact on performance here
[01:21:31] taylorr: with extra debugging
[01:21:55] taylorr: I didn't notice a problem with extra debugging using 10 surfaces
[01:23:58] taylorr: markk: I stopped backporting the dynamic vdpau buffer code since XvMC is causing the backport a little trouble
[01:24:28] markk: taylorr: this might sound silly – but did you try 9 ? out of interest as much as anything else
[01:24:29] taylorr: I'm sure I can get it worked out but I can't test XvMC – do you want me to proceed?
[01:24:40] taylorr: markk: I will try now with 9
[01:26:57] sphery: markk: earlier, today, danielk22 mentioned an issue where the painter auto-selec
[01:27:08] sphery: t code tried to use OpenGL, but his system has issues that make it not work ( http://irc.mythtv.org/ircLog/channel/4/2011-0 . . . -11:16:51:02 ). I was thiking of modifying https://github.com/MythTV/mythtv/blob/master/ . . . dow.cpp#L944 so that it instead calls a function in MythRenderOpenGL to ask whether to use the GL painter or not, and have that function decide based on direct rendering, GL version ...
[01:27:14] jpabq: taylorr, the irqpoll definitely did not hurt.
[01:27:14] sphery: ... not empty, GL_EXT_vertex_array supported, multitexture support available, and anything else we decide to use. Sound reasonable?
[01:28:29] danielk22: sphery: I wouldn't worry too much about my system. I'm pretty sure the driver installation got messed up by an apt-get update.
[01:28:48] taylorr: jpabq: but have you had to reboot your HD-PVR since the change?
[01:29:19] sphery: danielk22: yeah, but that should be easy enough to detect, too... the down side to doing so would be that users might not notice the problem with the driver install, but the up side would be that mythtv would be usable (but with Qt painter)
[01:30:08] sphery: and, if nothing else, having a go/no-go function in MythRenderOpenGL allows us to add additional criteria for the decision as we find it...
[01:30:10] jpabq: taylorr, no, but in the 3? years I have owned my HD-PVRs, I have only had to power-cycle *them* about 5 times total.
[01:30:34] jpabq: The irqpoll, is supposed to help the drop-outs
[01:40:10] Beirdo: heh, I've had to power cycle mine like 5 times in the last month
[01:40:49] markk: sphery: I've no issue with trying to detect a problem and falling back to qt – but the detecting bit may not be straightforward, depending on the issue
[01:42:45] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[01:42:58] danielk22: Beirdo: I only need to do it every few months... Are there any telltale log entries when it goes out to lunch for you?
[01:47:16] ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has left #mythtv ()
[01:59:44] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[02:00:31] Dave123-road (Dave123-road!~dave@cpe-66-66-124-175.rochester.res.rr.com) has quit (Read error: Operation timed out)
[02:03:03] Dave123 (Dave123!~dave@cpe-66-66-124-175.rochester.res.rr.com) has quit (Ping timeout: 258 seconds)
[02:10:35] Dave123-road (Dave123-road!someone@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:21:37] pushpop (pushpop!~pushpop@pool-173-77-230-33.nycmny.fios.verizon.net) has left #mythtv ()
[02:24:28] markk: taylorr: sorry – missed your comment. if the buffer stuff isn't straightforward then leave it – I'd rather we had known (and fixed) issues in 0.24.1
[02:29:28] jpabq: sphery, re http://pastebin.com/2qHDS3qa with what you are proposing would myth fall back to Qt, or would it be using a different way to validate that OpenGL is available?
[02:30:30] jpabq: I am willing to build the nVidia drivers by hand, if that would fix the problem, but installing via rpmfusion is convenient.
[02:30:37] sphery: for yours, the checks I was suggesting would succeed, so it would use OpenGL
[02:30:58] sphery: you said it appears to work, right?
[02:31:51] jpabq: It works, I just get floooooooooded with those texture errors.
[02:32:56] sphery: yeah, not sure what's causing those. a quick look through the 'net showed similar issues in many programs (the QPainter::begin: Paint device returned engine == 0, type: 3 part), but didn't see any explanations of why
[02:34:42] Dave123 (Dave123!someone@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:41:10] Dave123 (Dave123!someone@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving)
[02:42:18] Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:42:34] Dave123-road (Dave123-road!someone@cpe-74-74-200-106.rochester.res.rr.com) has quit (Read error: Connection reset by peer)
[02:44:25] Beirdo: danielk22: normally, I notice by 0-byte recordings. The way I intend to catch it is with the RecordingStarted event
[02:44:43] Dave321 (Dave321!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:44:54] Dave321 (Dave321!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Client Quit)
[02:45:04] Beirdo: I have the script to notice borked recordings in progress, but it's not aborting the recording, that may be a future addition in the code
[02:46:00] Beirdo: i.e. you call the event script and it returns error, we should have a way to abort and reschedule, but I haven't thought it completely through on that side. But I will be adding in there... if it's the HDPVR, power it off, power it back on
[02:46:23] Beirdo: I think there are failures logged as well, I'll have to go look back at old logs
[02:51:39] taylorr: markk: trying min and max = 2 output surfaces
[02:55:52] Dave321 (Dave321!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:56:03] Dave321 (Dave321!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Read error: Connection reset by peer)
[03:00:29] Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving)
[03:15:35] taylorr: markk: doesn't the vdpau presentation queue have an associated timestamp?
[03:17:52] markk: taylorr: yeeees – what are you thinking?
[03:22:55] taylorr: markk: looks like we always set it to zero – wonder if we should set it to the current time
[03:23:15] taylorr: or current time plus some fixed amount
[03:23:40] taylorr: markk: I set the min/max to 2 and haven't had a drop in over 30 minutes
[03:25:34] markk: taylorr: that makes no sense at all:)
[03:26:38] taylorr: I know, but I figured I'd also try smaller to be complete
[03:27:20] taylorr: one difference is if you set min = max then it doesn't have to add additional output surfaces when playback starts
[03:29:16] markk: true – though it's hard to see why that would make a difference
[03:29:58] taylorr: markk: ok we are setting the timestamp for presentation display
[03:30:10] taylorr: maybe we should add some debug for that and make sure the values are sane
[03:30:31] taylorr: it's the only reason I can think of for the queue to get blocked for so long
[03:33:07] taylorr: looks like the code will always set it to zero
[03:36:14] markk: taylorr: you could also try removing the SyncDisplay call – though I remember that caused problems for some reason
[03:52:05] taylorr: markk: I set it back to min 2 and max 4 but set the timestamp to now and it's dropping frames already
[03:53:34] taylorr: markk: xbmc for full hd resolution uses only 2 output surfaces instead of the default 4
[03:53:38] taylorr: I find that very odd
[03:58:20] markk: taylorr:: what happens if you set min and max to 4 – if that works (for whatever reason) – it's a no brainer to commit
[03:58:31] taylorr: trying that now :)
[03:59:10] taylorr: I'll let it run for about an hour and see how it goes
[04:00:37] markk: and of course, the minimum number will never be used for the UI – as we don't support that anymore:)
[04:03:22] taylorr: probably best to get rid of the MIN define then and do all the output surface creation at once
[04:04:33] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (Read error: Operation timed out)
[04:08:06] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:08:31] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv
[04:09:13] taylorr: markk: I hit a large stall with 4 and 4
[04:10:08] taylorr: going to let 2 and 2 run over night
[04:15:47] taylorr: markk: maybe instead of running vdp_presentation_queue_block_until_surface_idle we can use your debug code to spin until the status of the requested surface is IDLE
[04:16:07] taylorr: maybe something is wrong with the way they implemented that function
[04:22:22] taylorr: probably wouldn't work too well since the display rate is almost the refresh rate and we would need to sleep some
[04:22:40] taylorr: which might cause a performance issue
[04:29:25] markk: taylorr: worth a go – you could wrap it up with the existing usleep in that function (i.e. we're already sleeping a little anyway)
[04:31:32] taylorr: markk: I'll try it tomorrow
[04:31:48] taylorr: going to dump the timestamps too and see if there is anything suspicious
[04:33:04] taylorr: markk: did the same guy who did CHD support for XBMC also do VDPAU?
[04:33:33] taylorr: wondering if we could figure out why they use only 2 output surfaces for "FULL_HD"
[04:35:05] kormoc_afk is now known as kormoc
[04:35:25] taylorr: I think his name is Scott Davilla
[04:40:02] markk: I don't remember whether Scott worked on vdpau – his primary area of interest is OS X/apple (hence CrystalHD, VDA etc)
[04:41:09] taylorr: too bad I can't git blame the file :)
[04:41:35] andreax (andreax!~andreaz@p57B94E39.dip.t-dialin.net) has joined #mythtv
[05:10:44] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[05:46:14] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[05:48:54] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[06:08:22] Goga777 (Goga777!~Goga777@shpd-95-53-175-68.vologda.ru) has joined #mythtv
[06:15:09] Elv13 (Elv13!~lepagee@208.92.19.31) has quit (Read error: Connection reset by peer)
[06:25:10] Goga777 (Goga777!~Goga777@shpd-95-53-175-68.vologda.ru) has quit (Read error: Connection reset by peer)
[06:27:33] andreax (andreax!~andreaz@p57B94E39.dip.t-dialin.net) has quit (Ping timeout: 258 seconds)
[06:29:06] andreax (andreax!~andreaz@p57B94E39.dip.t-dialin.net) has joined #mythtv
[06:36:31] andreax (andreax!~andreaz@p57B94E39.dip.t-dialin.net) has quit (Ping timeout: 248 seconds)
[06:36:43] jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv
[06:36:43] jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host)
[06:36:43] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:49:41] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[06:57:55] martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv
[08:30:35] len (len!~quassel@184-97-168-55.mpls.qwest.net) has quit (Remote host closed the connection)
[09:13:05] MatBoy (MatBoy!~MatBoy@82.92.149.152) has joined #mythtv
[09:13:27] MatBoy: hi guys, are there still known blank page issues for mythweb on ubuntu ?
[09:14:21] laga: MatBoy: #mythtv-users
[09:14:54] MatBoy: laga: ok thanks!
[09:43:19] stuarta: i get that on my dev rig. never worked out why yet tho
[09:45:37] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[10:00:21] PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 252 seconds)
[10:05:04] Guest40970 (Guest40970!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[10:05:56] mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[10:06:22] mike is now known as Guest88964
[10:27:52] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[11:48:39] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[11:49:08] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[11:49:08] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[11:49:08] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[12:42:24] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 252 seconds)
[12:43:23] Dave123-road (Dave123-road!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[12:44:10] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[13:14:34] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:16:55] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[13:33:57] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv
[13:39:08] j-rod|afk is now known as j-rod
[13:41:58] danielk22 (danielk22!~danielk@96.57.9.142) has quit (Read error: Operation timed out)
[13:54:55] markk: taylorr: something to think about when you've finished tearing your hair out with vdpau:) any ideas on improving initial av sync? – I quite often get cases where video swings wildly from being X frames behind audio to X frames ahead as we drop frames.
[13:56:54] taylorr: markk: I haven't given much thought to it.... the patches from Mark Speith seem like a good start
[13:57:19] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit ()
[13:57:24] markk: taylorr: I thought they'd all gone in?
[13:58:52] taylorr: I don't think so, there is a ticket with a couple patches to make sure the audio and video are in sync before playback starts
[13:59:16] taylorr: basically looks at the audio and video packet timestamps and throws them away until they are in sync
[14:01:18] markk: http://code.mythtv.org/trac/ticket/9120
[14:01:25] martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection)
[14:03:48] taylorr: those are the ones
[14:04:58] taylorr: and you committed them... not sure how to fix the initial av sync then
[14:06:03] taylorr: markk: with overnight testing using 2 output surfaces I never saw a drop due to vdp presentation queue blocking
[14:06:27] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[14:06:59] taylorr: I still find it odd that XBMC uses 2 for FULL_HD playback and 4 for everything else
[14:08:51] markk: taylorr: dropping it to 2 worries me – but I'll have a test tomorrow. just giving avatar bluray a full run through with 8 surfaces on my ion box to see what the jitterometer looks like... (pretty smooth at the moment)
[14:09:32] taylorr: markk: I thought you didn't experience the stalls?
[14:09:40] markk: taylorr: I can't help but think that there is something different due to the single core.
[14:10:09] taylorr: markk: it happens on jpabq's GT220 and sphery too
[14:10:14] taylorr: they aren't using ION boxes
[14:10:30] taylorr: of course I never confirmed it's vdp presentation queue blocking
[14:10:42] markk: no – nothing I've noticed, but just having a look at some logs from a couple of hours of playback to see if there are some low level 'events' that I don't really pick up visually.
[14:11:13] taylorr: you'll visually pick up a 200 – 500 msec stall :)
[14:12:49] taylorr: markk: should we ask Stephen Warren about what could be wrong?
[14:13:20] taylorr: he could probably tell us exactly what's happening – I probably should enable the NVIDIA debug environment variable
[14:15:44] markk: hrm – hadn't thought about the nvidia debug stuff. I wouldn't approach Stephen until you could confirm it's an nvidia issue – i.e. this works but if I change it to this...
[14:15:55] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv
[14:16:16] taylorr: markk: I'd also like to confirm it's what sphery and jpabq are experiencing
[14:16:48] skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv
[14:17:24] markk: yup – there are clearly other issues at play and I suspect isolating them is not straightforward.
[14:33:16] markk: taylorr: something else I've just been reminded of – do you have opengl vsync enabled in nvidia settings? (remembering that nvidia-settings needs to actually be run in some way after each restart)
[14:34:27] markk: no matter what nvidia might say – opengl vsync has an impact on vdpau 'jitter' (not as reported by myth but I get subtle but annoying video jitter without it enabled)
[14:53:23] taylorr: markk: it was disabled and then I enabled it – should it be disabled or enabled?
[14:53:57] markk: taylorr: enabled
[14:54:42] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 258 seconds)
[14:54:55] taylorr: yes I have it enabled
[14:56:23] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[14:56:27] taylorr: this problem is so frustrating it makes me enjoy doing work at my job :)
[14:57:41] taylorr: I'm going to enable NVIDIA debugging later today and will let you know what I find
[14:58:44] markk: a couple of dozen variables, x thousand combinations thereof, 30 mins for each test – what's not to enjoy:)
[15:12:39] danielk22: iamlindoro: http://www.pastebin.ca/2057457 <-- I typed up something for the channel editor/scanner functionality. If you have any ideas for simplifying it I'd appreciate em. I glossed over a lot of details, but it still sounds pretty complex.
[15:13:37] abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has joined #mythtv
[15:20:29] iamlindoro: danielk22: Have you had a chance to look at the channel editor I put together a month or so ago? I think it should largely meet your specifications (though we would need to selectively add/hide widgets based on recorder type)
[15:22:38] iamlindoro: Otherwise it all seems like a sensible way to handle it-- I had some ideas for usability during the scan that would be nice if feasible-- namely the option to grab a screenshot of each channel for identification purposes, and a drag and drop "channel palette" which basically allows you to assign channel information from the listing source by dragging "Discovery HD" onto the channum in the scanned list.... or something like that
[15:23:19] iamlindoro: ie I can page through the discovered channels, see a screenshot that may help in identifying it, and assign all the info at once by dragging something from my Schedules Direct lineup
[15:25:19] skd5aner: yay – I like the new name suggestions – "capture cards", "video sources", and "input connections" seem to confuse too many people who frequently reference the wrong term – the new ones make sense and look good
[15:28:33] danielk22: iamlindoro: Is that channel editor checked in or is it a demo living somewhere else?
[15:28:44] iamlindoro: danielk22: It's checked in
[15:29:07] iamlindoro: In web setup, Setup->Advanced Setup->Guide Data->Channel Editor
[15:30:05] iamlindoro: Note that there was also a discussion in -developers about the terminology for things like video sources, and we had provisionally gone forward with "Guide Data," but if people feel better about "Lineup" that's fine too
[15:30:32] iamlindoro: danielk22: New web channel editor also allows for some neat stuff like batch channel edit using templates, etc.
[15:30:36] danielk22: Cool. I like the screen grab idea, it would add a few seconds delay but it's doable. When I originally envisioned the new channel scanner you could view the live video in the detail edit screen, but I don't really see myself finding time to do that right now.
[15:31:27] iamlindoro: danielk22: Don't take any of that as resistance to your ideas, by the way, I think that your approach sounds sensible/well thought out
[15:32:46] iamlindoro: Captain_Murdoch and I had discussed implementing scanning as a backend service a few weeks ago, and were both looking at the channelscan_cli code as an example... I had thought that doing it that way might be a neat way to also do a backend idle scan (ie, non-destructively scan when idle, send notifications to the frontend for the user to act on)
[15:32:50] danielk22: iamlindoro: I don't take it as resistance. I just wrote this up this morning after a few days of mulling it over, I don't think of it as complete.
[15:35:30] iamlindoro: cool-- it would be great to have someone who understood the channel scanner a little better looking at this part of it :)
[15:35:46] ** stuarta wakes up **
[15:35:55] danielk22: Some kind of service is needed to do the scan, it's a basic requirement for the web based setup.
[15:35:59] iamlindoro: I know the little bit I learned in the last year fixing some small issues, but by no means to I understand it intimately
[15:36:27] iamlindoro: er do I
[15:37:51] danielk22: It's all about finding time..
[15:38:01] iamlindoro: definitely
[15:39:58] danielk22: I'm now good enough at git that it's not zapping away all my time anymore :) Like I know how to do partial merges by using a commit id in place of HEAD, and I know I can do a diff in emacs with HEAD^^^^ instead of having to look up a commit id to see a few revisions back.
[15:45:01] stuarta: one thing to note with the channel scanner
[15:45:22] stuarta: there are countries that when the channel goes off air, it is no longer even signalled.
[15:45:37] stuarta: that may have changed in recent times, but that's the way it was before
[15:46:02] stuartm: IMHO those need to be dealt with by special rules for the locale
[15:46:33] iamlindoro: stuarta: Sure-- I assume that remark is in relation to having an idle scanner... but that's why sending a prompt to the user to decide what to do with it would be preferable to being destructive
[15:46:46] stuarta: yeah, because for places that do signal it properly it would be nice to do stuff like automatically update the lineup
[15:47:19] stuarta: one alternative would be to blacklist offending netid's
[15:47:31] stuarta: i know 4018 works
[15:48:25] stuarta: ah feck. 9018
[15:48:28] stuarta: close
[15:49:24] stuartm: iamlindoro: I believe any such prompt needs to be displayed based on whether it's even applicable for the country, from a user experience/interface perspective you don't want to keep asking the user what to do all the time when for many countries it's perfectly fine to just delete those channels outright
[15:49:53] stuarta: hence my suggestion based on blacklisting bad networkid's
[15:50:16] danielk22: stuarta: That's why we got rid of middle of the night scanning a long long time ago.. One of the reasons I added the channel scan DB tables was so that we could collect scans at different times of day and then decide a channel was off-air only if it was missing in all the scans.
[15:51:09] stuarta: ah, now i see where you were going with that stuff....
[15:51:23] stuartm: danielk22: well there was another reason – the scanner back then would overwrite existing channels if a small detail changed, e.g. name/number and that caused lost recordings, loss of xmltvids etc
[15:52:34] danielk22: stuartm: Yes, "one of the reasons" :) I addition to the overwrite stuff it's also possible to make better assumptions about channum's once the full scan has completed.
[15:52:47] stuartm: I was one of those who was vocal about disabling the background scan, but it was in the days before I became a developer – as a user all I saw was my channel configurations and recordings being lost
[15:53:48] stuartm: I'm all for a better implementation solution
[15:54:06] danielk22: stuartm: oh, you mean one of the reasons it was removed, not for why I added the tables...
[16:02:06] stuartm: danielk22: aye
[16:07:41] stuartm: Beirdo: experimenting with cppcheck it's lightning fast if it only checks the current config (it looks at config.h), that limits us to only checking the configs we're actually building with buildbot but maybe that's a reasonable trade-off, especially since many of the _possible_ configurations are never going to occur in a real life scenario
[16:09:04] stuartm: alternatively we can specify the configs we specifically want checked, so we could include say – USING_MINGW, USE_LIRC, USING_X11 etc on the command line
[16:10:12] danielk22: stuartm: on the cuymedia.org machine I just had cppcheck run every other hour..
[16:12:50] stuartm: danielk22: well a full check, looking at all possible combinations of configurations, looks to take a few hours on my machine and the default operation therefore ignores all files which have too many ifdefs (including those imported from QT libs)
[16:13:17] stuartm: ideally we want to find a middle ground where as many files as possible are checked but it doesn't take forever
[16:18:55] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Ping timeout: 248 seconds)
[16:32:56] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv
[16:45:06] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving)
[16:50:05] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[16:50:11] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[16:50:30] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[16:50:30] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[16:50:30] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[17:16:06] noahric_ (noahric_!4a7d3b42@gateway/web/freenode/ip.74.125.59.66) has joined #mythtv
[17:16:55] stuartm: for those that like guis, cppcheck now ships with one – http://miffteevee.co.uk/imagebin/cppcheck_gui.png
[17:17:27] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Read error: Operation timed out)
[17:19:40] noahric_ (noahric_!4a7d3b42@gateway/web/freenode/ip.74.125.59.66) has left #mythtv ()
[17:20:46] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[17:25:37] sphery: iamlindoro, danielk22: FWIW, regarding the name of video sources, if we're inventing a new name, I'd prefer it not being Lineup, as that name is already used by Schedules Direct, and the 2 concepts (MythTV Video Source and SD Lineup) are very different. Will be less confusion with a different name.
[17:35:08] danielk22: sphery: do you have a suggestion?
[17:35:36] sphery: the one iamlindoro mentioned is at least different from SD's... Guide Data, I think he said
[17:36:26] sphery: I don't care what we go with if the desire is to have something "intuitive"--because that means it's by definition imprecise (since the concept of a Video Source is /not/ intuitive)
[17:37:00] sphery: just want it to not be the same as something else that's used in relation to MythTV so that I can distinguish concepts when talking about them :)
[17:37:16] danielk22: Huh? What do transport modulation schemes have to do with "Guide Data" ? "Tuning Data" might be more accurate, but I'm not really in love with that...
[17:37:28] sphery: yeah, that's the problem :)
[17:38:27] sphery: not to mention channel change information (use of external scripts and freqid or use of internal analog tuner or internal digital tuning with freqid + in-stream tables, etc.)
[17:38:56] kormoc is now known as kormoc_afk
[17:39:07] kormoc_afk is now known as kormoc
[17:39:29] sphery: I'm OK with using an incorrect term for it since for a large number of users it will make it easier to understand, but just want to make sure we don't overlap with unrelated concepts (though I do agree that lineup is closer to correct than guide data)
[17:40:54] Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv
[17:43:30] danielk22: sphery: The problem is that "Lineup" is accurate for both the MythTV and Schedules Direct channel lineups.. I think the confusion will remain even if they do use different names simply because the concept is the equivalent to an end user.
[17:45:13] sphery: yeah, I completely agree--but having different names will at least make it easier to emphasize the difference, versus trying to say, "Schedules Direct lineup" and "MythTV lineup", which may not be enough for a user (especially new user) to understand what I'm talking about
[17:46:08] sphery: unfortunately I can't come up with /any/ name that's better than Video Source--though I know all our users hate that because they don't understand the term (which feels appropriate since they don't understand the concept, either :)
[17:47:28] sphery: then again, with it's being a "second-level" concept in the new editor, it may be hidden enough that the overlap with SD's name won't be a huge problem (but if so, I fear that it will make proper use of it for people with other-than-the-most-simplistic setups difficult)
[17:48:01] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[17:51:30] stuartm: this was one reason it was suggested way back that the existing Video Source was split up so that guide data, tuning data etc weren't all handled under the same heading – the status quo is very SD/US centric and it might make sense for that territory but elsewhere it means lumping together unrelated concepts
[18:00:05] iamlindoro: Reading the last 30 minutes of log strikes me as an ideal example of why nothing ever gets done
[18:00:33] iamlindoro: Everyone wants everything to tick all their checkboxes, and so in the end, we do nothing instead
[18:01:07] iamlindoro: If it can't be perfect, it should at *least* be approachable
[18:02:09] iamlindoro: And I personally feel that worrying that the user can't differentiate a Lineup at SD and the concept of a Lineup in MythTV meaning something slightly-different-but-still-basically-the-same is a canard
[18:03:12] iamlindoro: Speaking for myself, I think that the user doesn't *need* to know or understand that a Video Source/Lineup/whatever we call it in mythtv also incorporates tuning data. A user cares that a Lineup/Guide Data Source/whatever contains their channels, the end.
[18:06:21] sphery: If we completely drop Video Source from the UI and allow them only to specify the XMLTV or SD lineup information, using Lineup is OK
[18:07:42] sphery: but then we have to automatically figure out whether to use the same or different tuning information with that lineup, which is sometimes easy, but may not always be
[18:07:54] sphery: if you can do that, I'm happy using the name lineup, since it is just a lineup
[18:08:16] sphery: but just don't make it something so that users don't know when they need to create multiple SD lineups and when they don't
[18:24:20] stuartm: iamlindoro: well that's one of the problems, for a user who has an SD account 'lineup' would be a familiar term but what about those using xmltv or eit or ...
[18:24:59] iamlindoro: stuartm: That's why I was happier with the more verbose but more neutral "Guide Data Sources"
[18:25:17] stuartm: and for those other locales, tuning data and guide data will probably come from different sources too
[18:26:12] stuartm: i.e. tuning data and guide data are different concepts when you're dealing with DVB + xmltv
[18:28:08] stuartm: I don't have the answers, but the existing setup is less than ideal – this may be why we need to change the presentation depending on whether the user is configuring for xmltv or SD instead of trying to make a single approach which works for both
[18:29:54] stuartm: fwiw, I notice that the 'username' and 'password' fields are displayed in the current html regardless of whether we're configuring for xmltv or SD (those fields don't apply to xmltv), similarly the option to select the source is entirely missing – I assume that it's work in progress?
[18:34:35] iamlindoro: stuartm: All it presents right now are inputs equivalent to each field in the DB
[18:34:56] stuartm: ok
[18:35:14] iamlindoro: Work in progress implies that I'm doing any work on it, but yes, the ultimate solution should not display irrelevant fields
[18:35:46] iamlindoro: It was just an easy task once I finished up my current round of work on the channel editor
[18:36:02] iamlindoro: (as I had to write APIs to get the sources/sourceids to filter the channel lists)
[18:36:08] iamlindoro: so I threw it in there as a "what the hell"
[18:36:23] stuartm: well I expect that I'll have to get involved at some point to write the xmltv apiconfig integration, so I might be happy to take on all work on the xmltv related config side
[18:38:40] stuartm: weather's just too nice right now to consider spending much time inside
[18:39:00] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[19:10:03] danielk22: iamlindoro: At this point I am fishing for ideas. Once I start implementing stuff you can be sure that I'll ignore ideas that I can't make fit.
[19:10:25] iamlindoro: heh
[19:10:29] iamlindoro: Well good ;)
[19:39:24] jayage (jayage!557f5e0c@gateway/web/freenode/ip.85.127.94.12) has joined #mythtv
[19:40:32] jayage (jayage!557f5e0c@gateway/web/freenode/ip.85.127.94.12) has left #mythtv ()
[19:43:39] jayage (jayage!~Adium@85-127-94-12.dynamic.xdsl-line.inode.at) has joined #mythtv
[19:48:39] foxbuntu (foxbuntu!~foxbuntu@67-3-81-219.desm.qwest.net) has joined #mythtv
[19:48:39] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv
[19:48:39] foxbuntu (foxbuntu!~foxbuntu@67-3-81-219.desm.qwest.net) has quit (Changing host)
[19:54:59] len (len!~quassel@184-97-168-55.mpls.qwest.net) has joined #mythtv
[19:57:22] danielk22 (danielk22!~danielk@96.57.9.142) has left #mythtv ()
[20:00:26] jayage (jayage!~Adium@85-127-94-12.dynamic.xdsl-line.inode.at) has quit (Quit: Leaving.)
[20:11:01] SteveGoodey (SteveGoodey!~steve@host86-160-205-199.range86-160.btcentralplus.com) has joined #mythtv
[20:14:26] abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has quit (Quit: abqjp)
[20:35:52] SteveGoodey (SteveGoodey!~steve@host86-160-205-199.range86-160.btcentralplus.com) has quit (Remote host closed the connection)
[20:43:27] noahric (noahric!4a7d3b42@gateway/web/freenode/ip.74.125.59.66) has joined #mythtv
[20:44:33] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:46:50] noahric (noahric!4a7d3b42@gateway/web/freenode/ip.74.125.59.66) has left #mythtv ()
[20:57:15] jan2600 (jan2600!~jan@ip-83-134-116-186.dsl.scarlet.be) has joined #mythtv
[21:16:53] jpharvey (jpharvey!~jpharvey@host86-147-153-90.range86-147.btcentralplus.com) has quit (Ping timeout: 258 seconds)
[21:22:25] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 246 seconds)
[21:29:27] jpharvey (jpharvey!~jpharvey@host86-185-250-20.range86-185.btcentralplus.com) has joined #mythtv
[21:39:21] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit ()
[21:44:04] skd5aner: any status on a cut of .24.1?
[22:05:11] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 250 seconds)
[22:14:59] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[22:17:04] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[22:18:28] stuartm: skd5aner: it will definitely happen sometime between now and the end of human civilisation
[22:19:27] stuartm: skd5aner: but being more serious, I really hope to find the time before Monday
[22:19:49] skd5aner: stuartm: I don't know... that's still assuming the world isn't going to end in the next couple of weeks http://www.washingtonpost.com/blogs/guest-voi . . . yG_blog.html
[22:20:21] stuartm: :)
[22:21:55] skd5aner: thanks – not trying to pester, as I don't really care when/if it gets released – but I'm going to switch some things over in the 0.24-fixes release notes when it happens and will need to track it to the specific commit that gets tagged as 0.24.1
[22:21:59] skd5aner: :)
[22:22:16] skd5aner: so – just getting a general idea either way – much appreciated!
[22:26:40] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds)
[22:39:17] j-rod is now known as j-rod|afk
[22:40:41] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (*.net *.split)
[22:40:43] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (*.net *.split)
[22:40:44] MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (*.net *.split)
[22:40:44] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (*.net *.split)
[22:40:46] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (*.net *.split)
[22:40:47] purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (*.net *.split)
[22:40:47] okolsi (okolsi!~mythtv@a88-115-42-16.elisa-laajakaista.fi) has quit (*.net *.split)
[22:41:44] skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Ping timeout: 276 seconds)
[22:42:05] skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv
[22:45:42] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv
[22:45:42] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[22:45:42] MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv
[22:45:42] cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv
[22:45:42] superm1 (superm1!~superm1@ubuntu/member/superm1) has joined #mythtv
[22:45:42] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[22:45:42] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has joined #mythtv
[22:45:42] purserj (purserj!~purserj@hosting.collaborynth.com.au) has joined #mythtv
[22:45:42] okolsi (okolsi!~mythtv@a88-115-42-16.elisa-laajakaista.fi) has joined #mythtv
[22:46:33] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[22:52:33] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (Changing host)
[22:52:33] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has joined #mythtv
[23:53:12] Mousey (Mousey!~wtfisme@ross154.net) has quit (Remote host closed the connection)
[23:53:56] abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has joined #mythtv
[23:54:25] noahric (noahric!4a7d3b42@gateway/web/freenode/ip.74.125.59.66) has joined #mythtv

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