MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (90):

aloril, amessina, Anssi, anykey_, Beirdo, brfransen, bsilvereagle, CaCtus491, Captain_Murdoch, cesman, Chutt, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, f33dMB, fetzerch, foobum, foxbuntu`, ghoti, gigem, gregL, GreyFoxx, Guest19086, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, kc, kenni, Kevin`, knightr, kormoc, kurre2, kwmonroe, laga, MaverickTech, monkeypet, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, Peitolm, Peps, petefunk, pheld, poptix, purserj, rhpot1991, rsiebert_, Seeker`, seld_, Sharky-Sleep, skd5aner, sl1ce, Slasher`, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, sutula, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, Vernon_at_work_, wagnerrp, wahrhaft, wolfgang1, xavierh_, XDS2010, _charly_
Friday, December 14th, 2012, 00:13 UTC
[00:13:27] peper03 (peper03!~peper03@port-92-203-34-138.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[00:21:55] sphery: dekarl: ttbomk, we incorporated one of jp abq's patches long ago that appends part # to the programid when there's more than one part
[00:22:30] sphery: so the programid that's stored is actually unique
[00:22:53] sphery: looks like it was in [20318]
[00:22:53] MythLogBot: SVN 20318: (branch master) https://github.com/MythTV/mythtv/commit/ec61613e
[00:26:39] tonsofpcs: rate changes?
[00:28:20] taylorr: stichnot, gigem: the patch I have that calculates and accumulates the frame duration needs to be tested... only reason I haven't tested it is I don't have a dev box with a digital tuner
[00:29:43] cecil is now known as cesman
[00:29:56] cesman (cesman!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has quit (Changing host)
[00:29:56] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[00:30:22] tonsofpcs: gigem: re: #11027 couldn't repeat it last week when I tried later in the week *however* tonight will be the exact same arrangement of shows (as it is a week later) as my initial issue. I'm still running the backend with the logging options you suggested (for 6 days now...) – is it ok to keep it running presuming the issue may crop up again or would that be a pain to grok (and I should restart)?
[00:30:22] ** MythLogBot http://code.mythtv.org/trac/ticket/11027 **
[00:31:03] taylorr: stichnot, gigem: the patch extends the mpeg2 parser only... I could extend the h264 parser but I'm unaware of any broadcast material using h264 that has frame rate changes or repeated frames (I asked for them and it seems no one has any)
[00:32:54] tonsofpcs: taylorr: wait, you're making "film detect" mode actually work in a real honest-to-god not-test-equipment MPEG2 decoder?!?
[00:33:05] taylorr: if anyone knows of any h264 broadcast material that has frame rate material then they need to provide samples.... if it's confirmed that it exists in the wild I can look into extending the h264 parser as well
[00:33:30] tonsofpcs: (we turned this off on our ATSC transport stream about 6 hours after turning it on when the encoders first offered it as it made most decoders barf and/or slip audio)
[00:34:12] taylorr: tonsofpcs: we are making changes to properly track frame rates changes in general so that duration/position are properly displayed
[00:34:14] tonsofpcs: also, doesn't h264 natively handle marking "this frame repeats the last one" in the encode process?
[00:34:27] taylorr: no idea
[00:34:37] tonsofpcs: I think it actually generates a frame with "I'm a dupe"
[00:34:48] tonsofpcs: as opposed to changing frame durations or silly things like that
[00:34:49] taylorr: I know that h264 can mark a frame for the decoder to repeat (at least it's in the ffmpeg source)
[00:34:57] tonsofpcs: yea
[00:35:28] tonsofpcs: most encoders do that automagically if they get a still on input (well, they might wait for an I-frame and then do it, but same idea)
[00:35:43] taylorr: I've yet to see an h264 sample with repeats though... and I've never heard of anyone complaining about h264 broadcasts having duration/position problems
[00:35:53] taylorr: are you a broadcast engineer?
[00:37:00] taylorr: stichnot: are you sure you don't want to just add a timecode for each keyframe? it seems so much easier to implement
[00:37:19] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[00:37:23] tonsofpcs: yes
[00:37:46] tonsofpcs: I don't encode h.264 realtime though (well, not yet... I think I get hardware to play with soon)
[00:37:57] taylorr: cool, you probably could help us out with stuff
[00:38:09] ** tonsofpcs ducks and hides in the corner **
[00:38:59] tonsofpcs: AVC definitely exists in the wild with "repeat frames" but, as mentioned, it's part of the standard and always was so the decoder probably treats it as a real frame and wouldn't cause you timing issues
[00:39:14] taylorr: I used to record digital QAM from my cable provider and it hates repeats but since I've switched to OTA broadcasts I don't seem to have them, or else I'm sure this problem would have been addressed more by me
[00:39:59] tonsofpcs: hmm, I wonder if that's what the local MSO is doing now that screws with decoders...
[00:40:09] tonsofpcs: (they just switched their encoding and it causes issues everywhere)
[00:41:40] taylorr: I added debug to mythtv to output when repeats occur (--loglevel debug -v playback,avsync)
[00:42:36] taylorr: mso meaning the cable operator?
[00:42:39] tonsofpcs: did you change input devices or just ATSC/QAM switch
[00:42:43] tonsofpcs: MSO = Multiple System Operator
[00:43:02] tonsofpcs: = the big guys like Comcast, TWC, Cablevision, Cox, ...
[00:43:16] taylorr: just switched from QAM to ATSC antenna... same physical tuner
[00:43:21] tonsofpcs: (not mom and pops)
[00:43:49] taylorr: we sure hear about it when the MSOs play with their encoders :)
[00:44:25] taylorr: especially when their encoders have bugs like setting b-frames but having DTS=PTS which is impossible and ffmpeg doesn't like it at all
[00:44:41] tonsofpcs: how is DTS=PTS impossible?
[00:45:00] taylorr: it's impossible if b-frames are present
[00:46:15] tonsofpcs: how?
[00:46:26] taylorr: I'm far from an expert and it's been awhile since I looked into this stuff
[00:46:30] tonsofpcs: I frames can still have DTS=PTS, can't they?
[00:46:44] tonsofpcs: and there's still a chance as time slips if B-frames don't follow a continous structure...
[00:47:22] tonsofpcs: I mean, you're just concerned that the DTS/PTS IPBB... / IBPP... patterns can't line up, right? except there's that "I" there :)
[00:47:32] tonsofpcs: err, IBBP/IPBB
[00:48:20] taylorr: I don't remember the specifics, but there are certain conditions when a stream is marked as having b-frames that certain dts/pts combinations aren't correct
[00:49:09] taylorr: ffmpeg used to just NULL both of them and print a warning which is really bad for a player... I convinced them that was a little harsh so now they just through away one of the values :)
[00:49:22] taylorr: err, throw
[00:56:02] tonsofpcs: eh, I don't have my fancy DTS/PTS chart here... bug me at work :-p
[00:56:37] tonsofpcs: (also, The MPEG Handbook is handy. As is a SDI reference [i have a nice poster from a manufacturer that I probably have a spare or two I could send to folks that want])
[00:56:54] darkstarbyte (darkstarbyte!~branden@70.36.67.211) has joined #mythtv
[00:56:58] tonsofpcs: (or if you're in Toronto, send me a PM and I'll tell you who to bug :-p)
[00:56:59] darkstarbyte (darkstarbyte!~branden@70.36.67.211) has left #mythtv ()
[00:57:22] taylorr: tonsofpcs: here is the ffmpeg code that was triggered by a broadcaster somewhere in the midwest.. http://pastebin.com/giVfg7tB
[00:58:03] tonsofpcs: dts missing is possible, yes...
[00:59:08] tonsofpcs: wait, they discard pts and keep dts?
[00:59:39] ** tonsofpcs would think that DTS would be disccarded... but again, no reference handy **
[00:59:49] taylorr: that's if dts isn't missing and dts == pts and delay==1 (I think this means b-frames) and presentation_delayed is set
[01:00:24] tonsofpcs: yes, but read the comment above....
[01:00:43] tonsofpcs: presentation delay can happen due to things other than B-frames
[01:01:18] tonsofpcs: some transits purposely reorder frames to allow for fault tolerance (or other reasons). Sure, these are mostly non-long-GOP, but they can (and do) exist.
[01:01:40] tonsofpcs: ok, need to watch TV now for gigem and #11027
[01:01:40] ** MythLogBot http://code.mythtv.org/trac/ticket/11027 **
[01:03:55] tonsofpcs: hmm, interesting
[01:04:11] tonsofpcs: I just tuned to Big Bang Theory. info says "Repeat Thu Dec 13 2012"
[01:04:26] tonsofpcs: (it is properly recording as a new epissode though)
[01:20:31] neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[01:20:53] neufeld is now known as neufeld_AFK
[01:22:21] jya: skd5aner: you're there?
[01:22:51] jya: can you try some of the issues you had with your hdpvr recording and see if it's any better on the devel/resync-stable10 branch?
[01:23:33] dekarl (dekarl!~dekarl@p4FE847AA.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[01:25:44] dekarl (dekarl!~dekarl@p4FE847AA.dip.t-dialin.net) has joined #mythtv
[01:38:25] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:46:20] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:50:36] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[02:01:12] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:17:36] tonsofpcs: gigem: no issue with it force tuning me away but I still can't tune whereever I want (only items on the same mux) when things start recording
[02:20:09] gigem: tonsofpcs: That latest issue is for danielk22. Once you capture the #11027 issue, yes, you can turn the extra logging off.
[02:20:09] ** MythLogBot http://code.mythtv.org/trac/ticket/11027 **
[02:21:14] gigem: taylorr: Would your code be used with mythcomflag --rebuild? If so, I can upload a sample for you to box.com. If not, I suppose you'll have to send me the patch and tell me what to look for.
[02:22:09] tonsofpcs: gigem: I am kinda wondering if the 11027 issue was because I had yet to actually tune/record from all muxes and now that I have it's "settled in"...
[02:23:34] gigem: Are you running master now or are you still using the older version? The latest master tries harder to avoid interrupting live TV.
[02:24:17] tonsofpcs: still using the same version (0.25?)
[02:25:34] gigem: Okay. If the extra logging is causing problems, I can make a patch that will log more selectively.
[02:27:17] tonsofpcs: I don't think it is. I had some errors when I first started it but it settled down. I do notice that when I move around in the 'guide', playback stutters or pauses a bit mroe than it does with logging not on (but I don't think it should do this at all... SQL DB eating CPU time maybe?)
[02:41:56] rsiebert_ (rsiebert_!~quassel@g225048045.adsl.alicedsl.de) has joined #mythtv
[02:45:14] rsiebert (rsiebert!~quassel@g229054077.adsl.alicedsl.de) has quit (Ping timeout: 260 seconds)
[03:09:33] gigem: tonsofpcs: http://pastebin.com/NXN0bZz0 is an untested patch that should cut down on the logging. With this patch, you can drop the --loglevel debug and just run with -v schedule. The patch is agains master, but it's pretty simple and you should be able to figure out how to apply it 0.25. If not, let me know and I'll make one specifically for 0.25.
[03:11:28] taylorr: gigem: mythcommflag --rebuild should already be generating proper duration... are you seeing duration wrong after this is ran?
[03:12:12] taylorr: the patch I mentioned earlier was for the recorder
[03:53:52] taylorr: jya: I have a sample from skd5aner and will test it against your new branch
[04:14:43] gigem: taylorr: I haven't tried it in a long time, so I can't say yes or no.
[04:16:51] taylorr: jya: the new branch doesn't improve the issue with lost video buffers
[04:54:59] stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv
[04:54:59] stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host)
[04:54:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:56:47] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:59:48] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 244 seconds)
[05:10:57] stichnot: tonsofpcs: re stuttering in the guide. This and some other stuttering problems are likely from DB queries blocking the video thread. That's something earlier identified by danielk22 .
[05:15:03] brfransen (brfransen!~brfransen@64.179.141.163) has quit (Ping timeout: 260 seconds)
[05:16:24] brfransen (brfransen!~brfransen@64.179.141.163) has joined #mythtv
[05:37:39] rsiebert (rsiebert!~quassel@g225052143.adsl.alicedsl.de) has joined #mythtv
[05:40:06] rsiebert_ (rsiebert_!~quassel@g225048045.adsl.alicedsl.de) has quit (Ping timeout: 244 seconds)
[05:42:02] jya: taylorr: can you post the sample somewhere?
[05:46:48] jya: is it something that didn't occur with earlier version of myth? if yes, any ideas one which version it used to work ?
[05:54:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out)
[05:57:29] stichnot (stichnot!~stichnot@adsl-68-127-103-165.dsl.pltn13.pacbell.net) has joined #mythtv
[05:57:29] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[05:57:29] stichnot (stichnot!~stichnot@adsl-68-127-103-165.dsl.pltn13.pacbell.net) has quit (Changing host)
[05:57:30] taylorr: jya: do you have access to stuart's box.com samples directory?
[05:57:38] jya: i do
[05:57:51] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Quit: leaving)
[05:58:29] taylorr: it's the #11159 sample
[05:58:29] ** MythLogBot http://code.mythtv.org/trac/ticket/11159 **
[05:58:54] stichnot: jya: pretty much all of my hdpvr recordings have what I think is the lost video problem. I believe it started at the ffmpeg sync that was in 0.25
[05:59:16] stichnot: I recall it was a problem with pre and post resync recordings
[05:59:54] stichnot: If I jump back to the beginning, either the first try or after a few tries, it gets into the jittery state
[06:00:44] jya: there's never any resync on a stable release… or do you mean the sync that occurred on master after 0.25 was out ?
[06:01:27] stichnot: jya, I'm not really sure any more, it's been too long. I might be able to find my first irc comment on it
[06:02:00] stichnot: what i mean is, I think 0.24 did not have the problem but 0.25 did
[06:02:15] jya: ok… so the sync before 0.25
[06:02:21] jya: that makes it more complicated
[06:02:36] taylorr: jya: it causes video buffers to be lost... software plays back decent since it has more buffers allocated but vdpau has serious issues since it has a lot fewer buffers to begin with... you can view the buffer status in the 'playback data' screen that Mark added (access via the menu during playback)
[06:02:50] jya: I have a strategy for tracking a regression following the new resync… but before 0.25 the sync were far more involved
[06:02:54] taylorr: this problem happened due to the sync for 0.26
[06:03:12] stichnot: but interestingly, I'm sitting here with my laptop running the Slim profile and the TV running VDPAU Normal on an ION box, and I can't reproduce the behavior with Slim
[06:03:12] xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 256 seconds)
[06:03:19] taylorr: it's plays fine for 0.25 and worked fine for skd5aner on 0.25
[06:03:21] jya: taylorr: ah cool, so the sync after 0.25 then
[06:03:29] taylorr: yes, correct
[06:03:40] xris (xris!~xris@xris.forevermore.net) has joined #mythtv
[06:03:40] xris (xris!~xris@xris.forevermore.net) has quit (Changing host)
[06:03:40] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[06:03:54] stichnot: ok, I trust taylorr's analysis more than my memory
[06:04:15] jya: I wonder if it's the same to what I'm seeing
[06:04:40] jya: for me it start playing fine, then it starts stuttering with plenty of "waiting for video buffers"
[06:04:51] jya: it's sync that occurred on June 1st that broke it
[06:04:56] taylorr: jya: if you bring up the 'playback data' osd you'll see the buffer levels
[06:05:17] taylorr: was that one of your mini syncs or the big one by gavin?
[06:05:32] jya: taylorr: the mini, after my big one
[06:05:38] taylorr: oh good
[06:05:57] jya: there's been about 3 sync after Beirdo's one
[06:06:01] jya: in Feb.
[06:06:04] taylorr: does it do better with software decoding and much worse with vdpau?
[06:06:23] jya: i haven't tried anything but vdpau on that board
[06:06:31] jya: having said that, my problem is on a avi file
[06:06:41] taylorr: anyways, your symptoms make it sound very similar
[06:07:52] taylorr: jya: do you have a 0.25-fixes setup to test with?
[06:08:03] jya: http://pastebin.com/Ut2bUY57
[06:08:40] stichnot: I reported this in early June, http://irc.mythtv.org/ircLog/channel/4/2012-06-03
[06:08:51] jya: taylorr: i don't.. but it doesn't really matter at least for the sample Im using. I have no need for a working backend/db. And in my build I disable the check against version and protocol number
[06:10:02] jya: stichnot: you mentioned pre-post Beirdo sync though
[06:10:22] jya: so maybe not the same one
[06:11:53] jya: stichnot: the issue I;m having only occurs using storage group. If the file is local, it plays fine
[06:12:26] jya: my particular mini is using a 802.11n wifi, syncing at about 60Mbit/s
[06:12:32] taylorr: jya: looking at the log... it's obviously losing buffers... what happens is that we lose enough buffers that we hit the minimum threshold to cause prebuffering all the time
[06:13:21] jya: taylorr: I see nothing about dropping stuff thoug (except right at the beginning, which i see for every content nyway)
[06:14:06] stichnot: jya: any idea if it plays fine when "local" actually means NFS? (all my VDPAU frontends are diskless)
[06:14:20] taylorr: jya: the local vs storage groups is weird.... either way the data sent to the decoder should be identical
[06:14:51] jya: stichnot: with NFS or local.. it works fine… I use mythavtest myth://xxx or mythavtest /path/file.avi in the other
[06:15:19] jya: i thought maybe we're just at the threshold speed wise where my wireless speed makes it suffer
[06:15:40] taylorr: jya: ffmpeg requests exactly which byte position and length to read from the file... it should be transparent... I guess the sync could have changed how ffmpeg requests data and triggered a bug in our ringbuffer code
[06:16:01] jya: having said that, I have placed an access point 2 metres from the mini, and the mini was syncing at 300mbit/s over 802.11n (sustaining 11MB/s transfer) yet I saw the same buffering
[06:16:08] taylorr: just one theory... it's past my bedtime so I could be talking crazy
[06:16:26] jya: taylorr: it's actually precisely what I had in mind on what the problem could be
[06:16:48] jya: i wish i had started on this earlier this week, but the resync and finding related issues took my time away
[06:17:06] taylorr: jya: if it's local then it's not using the ringbuffer at all but using raw os level reads
[06:17:09] jya: and you, after you made me realise that following a stable branch was more useful and I had to redo the whole lot
[06:17:17] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv
[06:18:09] taylorr: it should be transparent though for sure.... might need to dump the reads from local vs storage group... what a pain
[06:18:34] stichnot: jya: I wonder if we're talking about the same effects. What I see is that frames are played at the proper frame rate, with smooth audio and without stuttering, except that the frames appear to be displayed in the wrong order, making the video look very jittery
[06:19:05] stichnot: I've seen that same behavior described on the -users list
[06:19:07] jya: stichnot: no, what I'm seeing is the video pausing , and playing again, very stuttery
[06:19:18] taylorr: jya: sorry about the distraction... hopefully the stable branch will be beneficial for future releases
[06:19:40] stichnot: jya: with vdpau?
[06:20:05] jya: taylorr: honnestly, I doubt it.. They will have at the time 0.28 comes a 2.0 release, where they've changed all their ABI and made obsolete plenty of others, like they usually do
[06:20:13] taylorr: jya: the skd5aner issue happens with local disk playback
[06:20:55] taylorr: jya: right but at least with a stable sync you get backported fixes... if we snapshot master all that work is on us to do
[06:21:10] jya: true
[06:21:22] jya: can also probably have resync between point release
[06:21:33] taylorr: absolutely
[06:22:41] taylorr: ok, bedtime... good night
[06:23:20] jya: Actually, it's the biggish resync of May 23, 174c795297e92b612bae94c52c7a6289d68de89b
[06:23:24] jya: have a good night
[06:23:32] jya: thanks for giving some directions
[06:24:27] stichnot: http://www.gossamer-threads.com/lists/mythtv/users/534777 Dan Wilga nicely describes the behavior I see, though I only see it when jumping back to the beginning, and never mid-recording
[06:26:23] jya: only with vdpau ?
[06:26:52] jya: what about if you revert to an older nvidia drivers?
[06:27:13] jya: could it be that between 0.25 and 0.26 they also happened to have upgraded their whole system?
[06:27:47] stichnot: My drivers are pretty old, and I've learned not to upgrade except as a last resort
[06:28:32] stichnot: looks like 280.13
[06:29:00] jya: sounds recent to me.
[06:29:06] jya: I've left 195.xx on mine :)
[06:29:41] jya: i can't think of a time where nvidia didn't introduce some regressions along the way
[06:32:46] stichnot: and as for systems as a whole, I've been on ubuntu 10.04 for about 1.5 years
[06:33:10] jya: ok… good to know
[06:33:53] jya: I wish I had stayed on 10.04 myself… since upgrading to 12.04, I can't resume my PC from sleep using the remote control. have to go and press the power button
[06:34:55] stichnot: I almost had to move to 12.04, until I found out how easy it was to built Qt 4.8 myself...
[06:36:10] jya: that is if you're patient enough
[06:36:23] jya: must take several hours on my mac, which is a 3.4GHz i7 machine
[06:38:40] rsiebert_ (rsiebert_!~quassel@g224250054.adsl.alicedsl.de) has joined #mythtv
[06:38:49] stichnot: I went to lunch and it was done when I got back
[06:39:25] stichnot: this is a quad core + HT i7
[06:41:04] rsiebert (rsiebert!~quassel@g225052143.adsl.alicedsl.de) has quit (Ping timeout: 244 seconds)
[06:41:44] stichnot: of course then I had to rebuild since I was missing fontconfig support the first time, and it seemed a lot longer not being at lunch...
[07:12:40] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[07:37:29] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 260 seconds)
[07:56:50] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[08:06:59] dekarl1 (dekarl1!~dekarl@p4FCEEAE7.dip.t-dialin.net) has joined #mythtv
[08:07:12] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Ping timeout: 252 seconds)
[08:08:09] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv
[08:09:08] dekarl (dekarl!~dekarl@p4FE847AA.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)
[08:09:49] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[08:28:38] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 250 seconds)
[08:49:05] Guest40803 (Guest40803!~quassel@75-161-183-113.mpls.qwest.net) has quit (Read error: Connection reset by peer)
[08:49:32] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 255 seconds)
[08:51:32] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[09:01:54] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[09:03:04] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:65ac:6657:20aa:b6d9) has joined #mythtv
[09:22:01] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has joined #mythtv
[09:22:01] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[09:22:01] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has quit (Changing host)
[09:23:34] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 246 seconds)
[09:24:36] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Ping timeout: 276 seconds)
[09:36:00] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[09:36:24] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[10:33:34] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 256 seconds)
[10:40:41] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[10:44:43] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Ping timeout: 245 seconds)
[10:53:14] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[10:59:17] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 244 seconds)
[11:02:27] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has joined #mythtv
[11:08:30] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has quit (Ping timeout: 264 seconds)
[11:14:29] Peitolm_ (Peitolm_!~moreyc@mandlebrot.random-chaos.org.uk) has quit (Changing host)
[11:14:30] Peitolm_ (Peitolm_!~moreyc@unaffiliated/peitolm) has joined #mythtv
[11:14:33] Peitolm_ is now known as Peitolm
[11:18:59] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has joined #mythtv
[11:23:42] sraue_ (sraue_!~stephan@208-48-239-77-pool.cable.fcom.ch) has quit (Ping timeout: 250 seconds)
[11:28:45] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[11:40:48] Sharky-Sleep is now known as Sharky112065
[11:45:04] Sharky112065 is now known as Sharky-AFK
[11:57:40] wagnerrp_ (wagnerrp_!~wagnerrp_@72.49.217.156) has joined #mythtv
[11:57:41] wagnerrp_ (wagnerrp_!~wagnerrp_@72.49.217.156) has quit (Changing host)
[11:57:41] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[11:57:47] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 244 seconds)
[12:14:43] knightr: Are the mailing lists dead? I am not receiving anything from any of our mailing lists.
[12:23:02] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[12:27:50] stuarta: hmmm, wonder if they are wedged
[12:29:39] Chutt_ (Chutt_!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv
[12:31:46] stuarta: knightr: looks like they are running
[12:32:19] Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Ping timeout: 260 seconds)
[12:51:11] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[12:53:13] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:08:09] jya: righto… found the ffmpeg commit that broke my AVI playback over storage group
[13:08:30] stuarta: \o/
[13:09:29] jya: http://git.videolan.org/?p=ffmpeg.git;a=commi . . . 2235a4319e08
[13:09:50] jya: I think it may just increase the CPU load a tad too much, making my mac mini unable to handle it
[13:12:04] stuarta: :(
[13:14:42] jya: actually, may not be… my CPU is never over 10% here
[13:32:44] jya: is there a way to show log on the backend for any network access done by a frontend ?
[13:32:57] jya: I'd like to check if there's increase network activity following a change
[13:33:54] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 252 seconds)
[13:49:18] stuarta: jya: about the only way you can do that is to profile the backend and see if any of the network code shows up as a busy code path
[13:51:00] jya: with the change in ffmpeg, the only obvious difference showing is that in one case my AVI is detected as a non-interleaved AVI (that fail to play properly via storage group) while the other isn't detected as such, and play fine
[13:52:05] jya: it's likely that code only reveal a bug in our code...
[13:52:16] stuarta: does it play properly when not using storage groups?
[13:52:22] jya: yes
[13:52:27] stuartm: -v network, especially in master might show something
[13:52:43] stuartm: and --loglevel debug
[13:53:02] jya: for the backend or frontend ?
[13:53:55] stuartm: should reveal something at least on both
[13:54:12] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit)
[13:55:49] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:56:51] jya: :) when I do --v network --loglevel debug ; it segfault when playback start
[13:57:02] stuarta: \o/
[14:00:51] zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv
[14:01:02] stuartm: heh
[14:09:02] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:09:17] jya: http://pastebin.com/Tzs7E0ca <- working
[14:09:35] taylorr: jya: remember for skd5aner's issue that playback is bad with vdpau but fine with software decoding doesn't mean that it's a vdpau specific issue... vdpau uses less video buffers and it's more susceptible to playback issues when buffers get lost in ffmpeg
[14:10:21] jya: http://pastebin.com/g3Cur4XX <- non working (non-interleaved AVI)
[14:10:38] jya: the difference seems to be that when it's working, the frontend request 32kB packet
[14:10:56] jya: while for non-interleaved, just before it starts failing, it asks for 1MB packet
[14:11:57] taylorr: jya: I believe there are some optimizations in the ringbuffer code that are #defined so that you can easily disable them... might be worth a look
[14:12:34] taylorr: you might need to disable them on FE and BE both
[14:13:46] jya: i'm keen on simply making a one-line change that revert what ffmpeg did back in may. never had an issue with any of my avis in years until that change came along
[14:14:21] jya: and as I have no idea on what to report to ffmpeg, provided i can't replicate it with stock code, they won't accept a bug report
[14:20:23] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Ping timeout: 244 seconds)
[14:22:17] zombor_ is now known as zombor
[14:22:51] jya: could just be that having 1MB packet over wifi, somehow take just enough time between packet that the decoder is starved in between
[14:23:23] jya: in 3 weeks time none of this would matter, as i would be moving back home, and it's all gigabite wired there
[14:24:12] jya: 9MB/s via wifi though… you would think it's fast enough
[14:28:41] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Remote host closed the connection)
[14:28:59] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv
[14:28:59] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host)
[14:29:00] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[14:32:42] jya: good I can reproduce the problem on my mac too when used over Wifi… syncing at 130mbit/s , I'm 1m from the wifi AP
[14:32:55] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:33:35] ** stuarta has to make do with powerline networking **
[14:35:25] dekarl1: sphery, gigem... #554 was commited (fixup for programs with programid,partnumber *and parttotal*) but #1879 was not (the same but without the requirenment of a parttotal>0). Last night I was ranting about the latter (because thats the one that I stumbled upon) Who uses SD and can say if the latter is still needed or not?
[14:35:25] ** MythLogBot http://code.mythtv.org/trac/ticket/554 **
[14:35:25] ** MythLogBot http://code.mythtv.org/trac/ticket/1879 **
[14:36:59] dekarl1 is now known as dekarl
[14:40:29] dekarl: Is it just me? After I updated BE/FE to latest master last night from an older master (2012-11–03) I get lots of crashes with all kinds of content playback (videos/recordings/ffmpeg decode/vdpau, doesnt change anything)
[14:47:27] sphery: dekarl: so you're saying you saw a listing that had partnumber > 0 but did not have a valid parttotal?
[14:48:00] stuartm: dekarl: no problems here, did you try a distclean?
[14:48:18] sphery: It seems that the patches on 554 were from 4 years ago and those on 1879 from 7 years ago, so I'd assume that the #554 one was more up-to-date (and both seem to use parttotal, too, unless I'm reading it wrong)
[14:48:18] ** MythLogBot http://code.mythtv.org/trac/ticket/554 **
[14:48:18] stuartm: admittedly I'm a day or two behind master atm
[14:48:56] dekarl: sphery: no, but that's exactly the thing I'd like to know :)
[14:49:53] jya: interesting.. I've set a maximum for the readahead in ringbuffer.cpp to never read more than 128kB, it's much much better.
[14:49:55] dekarl: stuartm: hmm, I work with debbuild.sh to the all mythbuntuisms.
[14:49:59] jya: not perfect though
[14:50:00] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[14:50:08] dekarl: s/to the all/to get all/
[14:50:31] sphery: dekarl: I'd suggest asking jpabq_ what he remembers about those patches
[14:51:11] sphery: I'm pretty sure in SD data there will always be a parttotal > 0 when partnumber > 0, but we may need to get one of the SD guys to confirm.
[14:51:32] sphery: let's just say I haven't seen any issues since that went in
[14:53:03] dekarl: I don't want to necro a 6 year old ticket just to add a "has been commited 4 years ago within another ticket" ;)
[14:53:25] joki (joki!~joki@p54862EF5.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[14:53:52] joki (joki!~joki@p548622DE.dip.t-dialin.net) has joined #mythtv
[14:54:08] dekarl: all my programs with partnumber have a parttotal, too. but none of them have a programid :( (xmltv/eit)
[14:58:57] jya: danielk22: you're the ringbuffer expert… with this patch, that limit the size we attempt to read at any one time to 128kB, I can play my troublesome AVI via Storage Group
[15:00:12] stuartm: gigem: is seriesid used anywhere in the scheduler or schedule filters?
[15:00:14] jya: http://pastebin.com/xjXiXe0X
[15:03:44] sphery: dekarl: without programid, comparison would be done via user-specified matching method (title/sub/desc, title/sub, or title/sub-then-desc). Do the descriptions for those at least have differences for the different parts?
[15:04:51] sphery: and what do you mean necro a 6-yr-old ticket? is there another one (since 1879 is closed, already--closed 6yrs ago wontfix, then 554 was reopened and patches uploaded and committed 4yrs ago)
[15:06:32] dekarl: Hmm, I was trying to say "When I stumbled upon 1879 last night it would have saved some dev time if the last entry was something like "duplicate of 554" (or similar) but I don't really want to add something to a ticket that was closed 6 years ago
[15:08:04] sphery: ah, I see... I think that is the case, though--let's confirm with jpabq_ , then we can add in a comment. (And, yes, I'll agree that our ticket system is a mess--we just have way too many tickets/comments in there, now--whether open or closed--for it to be useful, anymore. Even search in it is basically useless.  :( )
[15:12:45] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[15:13:48] sphery: FWIW, though, something I've been considering (though I have no idea what gigem would think of it) is changing xmltv to not compute programid, then creating separate fields for "pre-computed" hashes based on our different comparison techniques (programid+partnumber+parttotal, title/sub/desc, title/sub, title/sub-then-desc) to see if it's has a useful effect on scheduler performance. If so, then we could remove the programid fudging and the ...
[15:13:54] sphery: ... xmltv code that generates a programid (for eps with season and episode #) would no longer put that hash in programid but in the appropriate hash column. That said, it's not high priority for me (since I have only OTA channels and a dual-core backend with great MySQL performance).
[15:17:21] danielk22: jya: We only want to limit the size of network reads, not disk reads this way. We might even want to limit network reads more. You don't gain any advantage with network read efficiency once you go over 64KB.
[15:17:23] dekarl: breaking the rule matching, duplicate matching, scheduling, etc into seperate parts sounds like a good idea
[15:18:01] danielk22: With disks a 1MB read makes sense because reading is fast and seeking is slow.
[15:18:50] dekarl: sphery: and of course I have cases where the programs have title, partnumber, parttotal and nothing else :D
[15:19:31] danielk22: jya: What is the estimate bitrate we're getting for the AVI? Is it bogus?
[15:19:48] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Ping timeout: 248 seconds)
[15:21:07] dekarl: Its all I get from the stations. Adding the mini-series/episodes to tvbrainz and simply using their primary key would be quite easy and elegant (but then tvbrainz is only vaporware)
[15:23:39] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[15:24:22] danielk22: stichnot: If you were having this problem with NFS you might be using tcp as the transport medium. Try adding udp the mount options. TCP was made the default on Linux a few years ago but the performance is much worse than with udp.
[15:24:26] dekarl: hmm, partnumber is 1-n and parttotal is n+1? at least thats what is done in mfdb... http://code.mythtv.org/cgit/mythtv/tree/mytht . . . ser.cpp#n490
[15:24:53] dekarl: xmltv uses "0 to n-1 of a total of n" for series/episode/part numbering
[15:25:59] stichnot: danielk22: I don't know if it's a problem with NFS, as I'm using purely SG
[15:26:45] dekarl: http://paste.ubuntu.com/1437757/
[15:28:05] danielk22: jya: Can you take a look at these warnings? http://code.mythtv.org/buildbot/builders/mast . . . s%20%2811%29
[15:28:09] Sharky-AFK is now known as Sharky-Sleep
[15:28:45] danielk22: It looks like with the audiooutputpulse.cpp one we might be checking for errors incorrectly.
[15:29:18] danielk22: With the audiooutputjack.cpp one the call we're using is depreciated, maybe there is a drop in replacement?
[15:30:24] danielk22: With httplivestream.cpp we're initializing an unsigned short with -1, should be 0?
[15:30:38] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[15:31:30] danielk22: With AirPlay/mythraopconnection.cpp we're trying to return -1 in an unsigned int as an error code.
[15:31:54] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[15:34:09] dekarl: anybody mind if I fix the translating from xmltv_ns to SD style parttotal in xmltvparser.cpp? (by simly removing the +1)
[15:46:42] gigem: stuartm: Yes, seriesid and title, are used, per your request, to match in the scheduler. There is also a "This series" filter in case multiple series use the same title.
[15:46:45] dekarl: sphery, the xmltvparser skips partnumber without parttotal
[15:47:44] gigem: dekarl: I'm not totally sure what your asking for — my head is all stuffed up with a cold. If you'd like to drop the parttotal requirement from that change, I probably wouldn't object.
[15:50:33] gigem: sphery: The hash idea comes up every so often. We'd all like to see it tried, but nobody has done it. BTW, I think the changes I made for 0.26 should really mitigate the problem for many people. There's also one more, potential big, improvement that could be made for EIT users, but I'd like an person more familiar with EIT to do it.
[15:51:40] dekarl: gigem: I'm not sure either :) I'm not sure what partnumber/parttotal is. The xmltv spec says its to signal the story arc parts of multipart episodes with an example where part 1 and part 2 have the same episode number. But thats not how thetvdb does it. As I have no idea how TMS does handles these.
[15:53:14] stichnot (stichnot!~stichnot@65.50.220.101) has joined #mythtv
[15:53:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:53:14] stichnot (stichnot!~stichnot@65.50.220.101) has quit (Changing host)
[15:53:27] dekarl: Maybe we need attributes on trac to keep track of which guide source, country, tv provider a ticket is related to
[15:53:39] gigem: I believe, but am not positive, SD does it as the xmltv spec says. In fact, it wouldn't surprise me if the xmltv spec verbiage came from an old DataDirect schema description.
[15:54:36] dekarl: gigem, yes. lots of xmltv / mythtv guide stuff appears to be modeled to suit DataDirect
[15:55:00] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 248 seconds)
[15:55:45] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[16:05:07] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 260 seconds)
[16:10:05] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[16:17:35] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[16:17:46] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[16:25:31] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[16:38:56] stuartm: gigem: ok cool, I couldn't remember if anything had come of that :)
[16:41:21] stuartm: gigem: and if I didn't say so earlier, thanks for that
[16:50:27] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:58:54] gigem: stuartm: You're welcome. It even caught a program for me last month that I otherwise would have missed becuase of a differnt title.
[17:07:39] stuartm: gigem: there are a few good examples where it does the right thing over here, a quick check of the db throws up "Time Team" and "Time Team Special", or an entire series where each episode has a different title – "World's Top 5 {something}"
[17:09:01] stuartm: and of course with Chrismas coming up, plenty of examples of specials where they've stuck 'Christmas' in the title ...
[17:15:04] stuartm: I should really talk to Nick about getting a proper series id from the radiotimes
[17:20:02] SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has joined #mythtv
[17:41:18] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[17:45:05] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (Quit: Leaving)
[17:57:04] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[17:59:19] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:65ac:6657:20aa:b6d9) has quit (Read error: Connection reset by peer)
[18:05:49] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv
[18:06:20] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[18:06:29] wagnerrp_ is now known as wagnerrp
[18:17:50] Chutt_ is now known as Chutt
[18:36:53] taylorr: stuartm: looks like box.com now supports 250MB files for personal accounts
[18:46:11] dekarl: stuartm: should deleting a video source remove the channels *and the programs*? (I have a case where mfdb inserts the full lineup with all channels/programs over and over for a DVB source *which is temporarily not connected to any card*. After deleting the offending source/channels I'm now left with 500k orphaned programs :/
[18:46:19] stuartm: taylorr: aye, discovered that the other day when I was reading their support forum thread on the limit, lots of people were complaining that 100MB was too low and the final post was made just a few hours before I read it was an announcement about the increase
[18:46:47] stuartm: dekarl: it should yeah
[18:46:49] dekarl: (asking you as you seem to have done the most changes to mfdb channel handling in the last time)
[18:47:47] stuartm: I've never touched that particular bit of code, personally I'd rather switch to innodb and use foreign key constraints to guarantee no orphans
[18:48:28] stuartm: we were talking about switching to innodb a few months back, not sure what happened there
[19:09:23] SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has quit (Quit: Konversation terminated!)
[19:11:46] danielk22: stuartm: weren't we planning to get a report from kormoc who was running it on his machine and logging any issues?
[19:12:41] danielk22: AFAIK the only known issue is with temp tables becoming super slow if the /tmp partition can't fit em.
[19:13:22] danielk22: I think sphery put in a workaround of some kind
[19:15:07] stuartm: ok, so we need to pin down sphery and kormoc :)
[19:16:27] stuartm: if necessary we can mix and match innodb/myisam, get the benefits of inno in the places where data integrity is most important
[19:18:40] dekarl: Why do we have temporary temp tables for the scheduler? Doesn't it make more sense to let them lay around and just truncate them before use? That bites me when I'm trying to EXPLAIN scheduler queries :) (hunting down the JOIN WITHOUT INDEX cases)
[19:21:01] peper03 (peper03!~peper03@port-92-203-104-218.dynamic.qsc.de) has joined #mythtv
[19:27:05] danielk22: IIRC sphery's workaround was to use myisam for the temporary tables.
[19:27:07] gigem: dekarl: When you include speculative scheduling and mythutil/backend --testsched, there can be multiple schedulers running at the same time.
[19:27:55] dekarl: gigem: oh, didn't think of multiple concurrent scheduler runs.
[19:34:38] Gremlyn (Gremlyn!~colin@ip72-197-35-46.sd.sd.cox.net) has joined #mythtv
[19:35:22] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[19:40:58] xris: huh, no more using volume change to detect commercial breaks. http://www.theverge.com/2012/12/14/3766074/fc . . . al-volume-tv
[19:41:45] danielk22: xris: In the larger scheme of things this is not a bad thing :)
[19:41:51] xris: yes.  :)
[19:41:53] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[19:42:09] xris: taylorr, stuartm: not sure if yu guys saw awhile back but Beirdo was offering 50G of box.com storage to anyone with a mythtv.org email address
[19:42:49] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[19:42:54] stuartm: xris: yeah, that's what we're talking about
[19:43:52] ** xris pokes kormoc in IM **
[19:44:05] stuartm: we've been using it to gather and store samples relating to bugs and future regression testing, but it's limited to 250MB per file which is fine for some samples but not others
[19:44:11] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[19:44:46] xris: stuartm: yeah, that and dropbox's sharing mechanisms are just that much better.
[19:45:00] stuartm: e.g. Beirdo wanted samples of UK recordings to tweak the commercial detection routines, but to do that properly takes a lot more space :)
[19:46:37] xris: at one point I had created a directory on our server for that
[19:46:52] xris: but then beirdo went ahead and revoked most people's ssh access when we switched git servers
[19:46:53] Gremlyn: hi all, having a problem with mythtv after restarting my computer where the mythbackend is 'down', as in the front end can't connect to the backend, even though mythbackend is running. here is my mythbackend error log: https://gist.github.com/4288070
[19:47:02] xris: Gremlyn: /topic
[19:47:12] Gremlyn: oh, crap
[19:47:17] xris: :)
[19:47:21] Gremlyn: sorry :P
[19:47:27] xris: no worries. unfortunately a common mistake
[19:47:39] Gremlyn: I can imagine
[19:47:40] stuartm: xris: it's moot anyway because my upstream bandwidth sucks, I was going to stick some files on an SD card and post it (I really need to get that done)
[19:47:54] xris: ah, ouch
[19:51:03] Gremlyn: of course, no one is active in the user support chat :P
[19:56:51] dekarl: oh, how I love such documentation "originalAirDate" => "Optional. Original air date for the program." now that explains everything :)
[19:59:48] kth (kth!~kth@unaffiliated/kth) has quit (Read error: Connection reset by peer)
[20:13:11] Gremlyn (Gremlyn!~colin@ip72-197-35-46.sd.sd.cox.net) has left #mythtv ()
[20:33:12] laga_ (laga_!~laga@h1626373.stratoserver.net) has quit (Ping timeout: 265 seconds)
[20:35:30] tonsofpcs: danielk22, stichnot: Any chance that the video thread can be niced 'more' than the DB queries and backend, could that help this stutter?
[20:35:30] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit)
[20:35:31] laga (laga!~laga@h1626373.stratoserver.net) has joined #mythtv
[20:35:32] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[20:49:38] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has quit (*.net *.split)
[20:49:39] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (*.net *.split)
[20:49:39] jpharvey (jpharvey!~jpharvey@host86-139-32-3.range86-139.btcentralplus.com) has quit (*.net *.split)
[20:49:39] Kevin` (Kevin`!~kevin@router.kwzs.be) has quit (*.net *.split)
[20:49:39] jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (*.net *.split)
[20:49:39] Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (*.net *.split)
[20:49:39] danielk22 (danielk22!~danielk@96.57.9.142) has quit (*.net *.split)
[20:49:39] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (*.net *.split)
[20:49:39] sutula (sutula!sutula@nat/hp/x-zestrkvgjcxcwljn) has quit (*.net *.split)
[20:49:40] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (*.net *.split)
[20:49:40] foxbuntu` (foxbuntu`!~foxbuntu@63-153-251-42.desm.qwest.net) has quit (*.net *.split)
[20:49:40] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (*.net *.split)
[20:49:40] jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has quit (*.net *.split)
[20:49:40] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (*.net *.split)
[20:49:40] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (*.net *.split)
[20:49:40] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (*.net *.split)
[20:49:40] neufeld_AFK (neufeld_AFK!~user@69-165-173-139.dsl.teksavvy.com) has quit (*.net *.split)
[20:49:40] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (*.net *.split)
[20:49:40] Cougar (Cougar!~cougar@kkk.version6.net) has quit (*.net *.split)
[20:49:41] wahrhaft (wahrhaft!~quassel@cpe-71-79-71-188.columbus.res.rr.com) has quit (*.net *.split)
[20:49:41] foobum (foobum!~foobum@cpc23-acto2-2-0-cust294.4-2.cable.virginmedia.com) has quit (*.net *.split)
[20:49:41] kth (kth!~kth@unaffiliated/kth) has quit (*.net *.split)
[20:49:41] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (*.net *.split)
[20:49:41] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (*.net *.split)
[20:49:41] joe___ (joe___!~bob@64.73.32.135) has quit (*.net *.split)
[20:49:41] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (*.net *.split)
[20:49:41] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split)
[20:49:41] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (*.net *.split)
[20:49:41] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (*.net *.split)
[20:49:41] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (*.net *.split)
[20:49:41] peper03 (peper03!~peper03@port-92-203-104-218.dynamic.qsc.de) has quit (*.net *.split)
[20:49:41] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (*.net *.split)
[20:49:41] Mousey (Mousey!~r0dent_@ross154.net) has quit (*.net *.split)
[20:49:41] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (*.net *.split)
[20:49:42] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (*.net *.split)
[20:49:42] anykey_ (anykey_!~anykey@46-126-243-153.dynamic.hispeed.ch) has quit (*.net *.split)
[20:49:42] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (*.net *.split)
[20:49:42] laga (laga!~laga@h1626373.stratoserver.net) has quit (*.net *.split)
[20:49:42] dekarl (dekarl!~dekarl@p4FCEEAE7.dip.t-dialin.net) has quit (*.net *.split)
[20:49:43] jarryd (jarryd!jarryd@im.jarryd.net) has quit (*.net *.split)
[20:49:43] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (*.net *.split)
[20:49:43] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (*.net *.split)
[20:49:43] purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (*.net *.split)
[20:49:44] Peps (Peps!~MiNT@li186-230.members.linode.com) has quit (*.net *.split)
[20:49:44] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split)
[20:49:44] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has quit (*.net *.split)
[20:49:44] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (*.net *.split)
[20:49:44] jya (jya!~jyavenard@mythtv/developer/jya) has quit (*.net *.split)
[20:49:44] brfransen (brfransen!~brfransen@64.179.141.163) has quit (*.net *.split)
[20:49:44] kc (kc!~Casper@unaffiliated/kc) has quit (*.net *.split)
[20:49:45] tris (tris!tristan@camel.ethereal.net) has quit (*.net *.split)
[20:49:45] clever (clever!~clever@47.54.78.167) has quit (*.net *.split)
[20:49:45] ghoti (ghoti!~paul@scratch.it.ca) has quit (*.net *.split)
[20:49:45] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (*.net *.split)
[20:49:45] poptix (poptix!poptix@poptix.net) has quit (*.net *.split)
[20:49:46] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (*.net *.split)
[20:49:46] f33dMB (f33dMB!~f33dMB@li100-62.members.linode.com) has quit (*.net *.split)
[20:49:46] XDS2010 (XDS2010!uid1218@gateway/web/irccloud.com/x-thkwbotjuswejiku) has quit (*.net *.split)
[20:49:47] Beirdo (Beirdo!~gjhurlbu@mythtv/developer/beirdo) has quit (*.net *.split)
[20:49:47] joki (joki!~joki@p548622DE.dip.t-dialin.net) has quit (*.net *.split)
[20:49:47] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (*.net *.split)
[20:49:47] tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has quit (*.net *.split)
[20:49:47] petefunk (petefunk!~pfunk@198.23.147.3) has quit (*.net *.split)
[20:49:47] Slasher` (Slasher`!~Slasher@188.165.164.15) has quit (*.net *.split)
[20:49:47] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (*.net *.split)
[20:49:47] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (*.net *.split)
[20:49:47] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (*.net *.split)
[20:49:47] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (*.net *.split)
[20:49:47] rsiebert_ (rsiebert_!~quassel@g224250054.adsl.alicedsl.de) has quit (*.net *.split)
[20:49:48] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (*.net *.split)
[20:49:48] monkeypet (monkeypet!~monkeypet@c-24-6-135-62.hsd1.ca.comcast.net) has quit (*.net *.split)
[20:49:48] bsilvereagle (bsilvereagle!~bsilverea@osuosc/bsilvereagle) has quit (*.net *.split)
[20:49:48] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@pool-173-48-129-179.bstnma.fios.verizon.net) has quit (*.net *.split)
[20:49:48] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (*.net *.split)
[20:49:48] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (*.net *.split)
[20:49:48] wolfgang1 (wolfgang1!~wolfgang@178-27-144-160-dynip.superkabel.de) has quit (*.net *.split)
[20:49:48] xavierh_ (xavierh_!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (*.net *.split)
[20:49:48] CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (*.net *.split)
[20:49:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (*.net *.split)
[20:49:48] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (*.net *.split)
[20:49:48] jams (jams!~jams@cpe-24-92-95-170.wi.res.rr.com) has quit (*.net *.split)
[20:49:48] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (*.net *.split)
[20:49:48] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (*.net *.split)
[20:49:48] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (*.net *.split)
[20:49:48] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (*.net *.split)
[20:49:48] seld_ (seld_!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (*.net *.split)
[20:49:48] Vernon_at_work_ (Vernon_at_work_!~singv003@lightcloud.verns.net) has quit (*.net *.split)
[20:49:48] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (*.net *.split)
[20:49:48] _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has quit (*.net *.split)
[20:49:48] gigem (gigem!~david@mythtv/developer/gigem) has quit (*.net *.split)
[20:49:48] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (*.net *.split)
[20:49:49] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has quit (*.net *.split)
[21:50:35] Guest19086 (Guest19086!~quassel@75-161-183-113.mpls.qwest.net) has joined #mythtv
[21:50:35] jya__ (jya__!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:50:35] laga (laga!~laga@h1626373.stratoserver.net) has joined #mythtv
[21:50:35] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[21:50:35] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[21:50:35] peper03 (peper03!~peper03@port-92-203-104-218.dynamic.qsc.de) has joined #mythtv
[21:50:35] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[21:50:35] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv
[21:50:35] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:50:35] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[21:50:35] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[21:50:35] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[21:50:35] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[21:50:35] joki (joki!~joki@p548622DE.dip.t-dialin.net) has joined #mythtv
[21:50:35] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:50:35] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[21:50:35] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[21:50:35] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[21:50:35] Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv
[21:50:35] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[21:50:35] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[21:50:35] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[21:50:35] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[21:50:35] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[21:50:35] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv
[21:50:35] dekarl (dekarl!~dekarl@p4FCEEAE7.dip.t-dialin.net) has joined #mythtv
[21:50:35] rsiebert_ (rsiebert_!~quassel@g224250054.adsl.alicedsl.de) has joined #mythtv
[21:50:35] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv
[21:50:35] brfransen (brfransen!~brfransen@64.179.141.163) has joined #mythtv
[21:50:35] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[21:50:35] neufeld_AFK (neufeld_AFK!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[21:50:35] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[21:50:35] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@pool-173-48-129-179.bstnma.fios.verizon.net) has joined #mythtv
[21:50:35] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[21:50:35] seld_ (seld_!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv
[21:50:35] jarryd (jarryd!jarryd@im.jarryd.net) has joined #mythtv
[21:50:35] foxbuntu` (foxbuntu`!~foxbuntu@63-153-251-42.desm.qwest.net) has joined #mythtv
[21:50:35] Vernon_at_work_ (Vernon_at_work_!~singv003@lightcloud.verns.net) has joined #mythtv
[21:50:35] anykey_ (anykey_!~anykey@46-126-243-153.dynamic.hispeed.ch) has joined #mythtv
[21:50:35] wahrhaft (wahrhaft!~quassel@cpe-71-79-71-188.columbus.res.rr.com) has joined #mythtv
[21:50:35] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[21:50:35] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[21:50:35] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[21:50:35] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[21:50:35] tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has joined #mythtv
[21:50:35] petefunk (petefunk!~pfunk@198.23.147.3) has joined #mythtv
[21:50:35] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[21:50:35] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[21:50:35] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv
[21:50:35] MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv
[21:50:35] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has joined #mythtv
[21:50:35] f33dMB (f33dMB!~f33dMB@li100-62.members.linode.com) has joined #mythtv
[21:50:35] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[21:50:35] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[21:50:35] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[21:50:35] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[21:50:35] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[21:50:35] XDS2010 (XDS2010!uid1218@gateway/web/irccloud.com/x-thkwbotjuswejiku) has joined #mythtv
[21:50:35] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[21:50:35] danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv
[21:50:35] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[21:50:35] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[21:50:35] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[21:50:35] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv
[21:50:35] wolfgang1 (wolfgang1!~wolfgang@178-27-144-160-dynip.superkabel.de) has joined #mythtv
[21:50:35] tris (tris!tristan@camel.ethereal.net) has joined #mythtv
[21:50:35] Kevin` (Kevin`!~kevin@router.kwzs.be) has joined #mythtv
[21:50:35] xavierh_ (xavierh_!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv
[21:50:35] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has joined #mythtv
[21:50:35] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[21:50:35] Peps (Peps!~MiNT@li186-230.members.linode.com) has joined #mythtv
[21:50:35] purserj (purserj!~purserj@hosting.collaborynth.com.au) has joined #mythtv
[21:50:35] foobum (foobum!~foobum@cpc23-acto2-2-0-cust294.4-2.cable.virginmedia.com) has joined #mythtv
[21:50:35] clever (clever!~clever@47.54.78.167) has joined #mythtv
[21:50:36] sutula (sutula!sutula@nat/hp/x-zestrkvgjcxcwljn) has joined #mythtv
[21:50:36] jpabq (jpabq!~quassel@75-161-90-147.albq.qwest.net) has joined #mythtv
[21:50:36] CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv
[21:50:36] bsilvereagle (bsilvereagle!~bsilverea@osuosc/bsilvereagle) has joined #mythtv
[21:50:36] jpharvey (jpharvey!~jpharvey@host86-139-32-3.range86-139.btcentralplus.com) has joined #mythtv
[21:50:36] jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[21:50:36] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv
[21:50:36] _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has joined #mythtv
[21:50:36] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[21:50:36] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[21:50:36] poptix (poptix!poptix@poptix.net) has joined #mythtv
[21:50:36] Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv
[21:50:36] monkeypet (monkeypet!~monkeypet@c-24-6-135-62.hsd1.ca.comcast.net) has joined #mythtv
[21:50:36] Slasher` (Slasher`!~Slasher@188.165.164.15) has joined #mythtv
[21:50:36] Beirdo (Beirdo!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv
[21:50:36] jams (jams!~jams@cpe-24-92-95-170.wi.res.rr.com) has joined #mythtv
[21:50:36] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:20f:eaff:fefc:ba0e) has joined #mythtv
[21:50:36] joe___ (joe___!~bob@64.73.32.135) has joined #mythtv
[21:50:36] Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv
[21:59:23] dekarl: is there a use case with a negative chanid? http://code.mythtv.org/trac/ticket/11053#comment:2 I remember seeing negative channums but I'm not sure about chanid as the schema has it as unsigned, too
[22:00:09] jpharvey: peper03: I tried your patch on #11288 and it fixes the problem for me with my change removed.
[22:00:09] ** MythLogBot http://code.mythtv.org/trac/ticket/11288 **
[22:00:47] stichnot: peper03: if #11292 works for me, you will be my hero.
[22:00:47] ** MythLogBot http://code.mythtv.org/trac/ticket/11292 **
[22:01:56] peper03: jpharvey: Cool, thanks! I've not found any regressions yet. Only improvements! There are still playback issues but that patch does seem to a good step in the right direction.
[22:03:37] peper03: stichnot: I do my best :) It's a such a simple fix that I put it in my code as a quick hack and then realised that there isn't much else that needed doing (at least, I hope not). It's an absolute pain when there's no way out of the studio's idents!
[22:04:02] jpharvey: I'll apply the patch to the other frontend and see if anyone complains about anything.
[22:04:05] jpharvey: peper03: Not sure if your change in #11291 is in any way related to a patch i added to #11186 where i tried to fix issues with highlights being drawn in the wrong place with different fill modes?
[22:04:05] ** MythLogBot http://code.mythtv.org/trac/ticket/11291 **
[22:04:05] ** MythLogBot http://code.mythtv.org/trac/ticket/11186 **
[22:06:16] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[22:06:43] peper03: jpharvey: No, I tried your patch but it didn't help that problem. Pure 'luck' that one of the DVDs I happened to pick to test #11288 had an (apparently) unusal authoring issue. VLC and XBMC don't handle it either :)
[22:06:43] ** MythLogBot http://code.mythtv.org/trac/ticket/11288 **
[22:08:16] peper03: Interestingly, I've just found that this particular DVD produces a mainly black screen when played back using VDPAU. Every so often you get the odd glimpse of video but it's mainly black. OpenGL playback is fine. First source I've had with *that* problem.
[22:08:38] danielk22: dekarl: chanid are always >= 1
[22:08:50] danielk22: 0 is the sentinel
[22:09:43] stuartm: btw, I'm thinking of always using the first track in the desired language for DVDs instead of using the track with the greatest number of channels – does anyone know of a DVD in the wild where that would not work?
[22:13:19] peper03: stuartm: Never thought about it in detail before but shouldn't (at least in theory) the choice of audio track be determined by the VM via whatever instructions are authored on the DVD?
[22:14:17] Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv
[22:14:33] peper03: stuartm: I was thinking about adding default language support at some point (you just tell the VM which languages to use by default for menus, subtitles and audio). I wonder if that would help?
[22:15:09] stuartm: peper03: that's why I asked about it the other day, at the time you said that the vm didn't flag the audio track to be used :)
[22:15:57] peper03: stuartm: Ah, I thought you just meant how the audio track was encoded :)
[22:16:40] stuartm: we already ignore commentary tracks when selecting the best audio stream but unfortunately I have DVDs where those haven't been correctly labelled during authoring
[22:17:02] stuartm: and at least one DVD when the highest channel track is commentary instead of main audio
[22:17:28] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[22:17:51] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[22:18:01] stuartm: peper03: I'll move that to the back burner for now then until we can determine the best fix
[22:18:55] stuartm: I still need to figure out the bug causing the wrong audio track to be decoded, even though it thinks the right one is selected :)
[22:19:27] stuartm: and I've a theory to test about why some menus are still stuttering with vdpau
[22:20:21] peper03: stuartm: I would *expect* a DVD to be authored to choose the right audio track based on whatever defaults it has (general user preference/language chosen in menu/whatever). That might not always be the case for "non-professionally" authored DVDs but then I'd just go with track 1.
[22:24:19] peper03: stuartm: How do you feel in general about adding settings for the default language to use for menus/subtitles/audio tracks. I wouldn't want to add more settings for the sake of it but I could imagine there could be plenty of non-native English speakers who'd like their DVDs to default to their own language.
[22:24:21] dekarl: should mythhdhomerun_config go into the same package as mythbackend and mythv-setup?
[22:26:16] skd5aner: gigem: are you sure that it uses callsign and not chanid? I've rescanned my channels dozens of times, and moved and changed my SD lineup and the channel rules never seem to take effect without me redoing them
[22:29:41] stuartm: peper03: the setting already exists
[22:29:57] stuartm: and is used
[22:30:43] peper03: stuartm: Does it? It's not set in the VM.
[22:31:01] peper03: stuartm: Unless I'm blind.
[22:32:51] stuartm: peper03: no, it's not set in the vm, we do the track selection in AVFD::AutoSelectAudioTrack()
[22:33:20] stuartm: setting it in the vm would only work if we have the VM tell us which tracks to use
[22:34:11] stuartm: in theory we already do though, since audio/subtitle track selection from the dvd menu works ... hadn't really thought about that before
[22:34:24] stichnot: stuartm: I wouldn't be surprised if default track selection depends on VM state, and studios play obfuscation tricks to thwart "pirates"
[22:35:21] peper03: stuartm: Ah, from the language setting under 'Appearance'? Ok. You can set the preferred language for menus/subtitles/audio tracks independently in the VM. So, you might decide you'd like 'English' as default audio, but 'French' subtitles.
[22:35:47] stichnot: by "default track selection", I mean the trace that the DVD plays automatically if you navigate through all the up-front menus
[22:35:50] stuartm: stichnot: I am beginning to suspect that's the reason we get the wrong audio track, we ask for the logical stream id from dvdnav but if those values are deliberately wrong it explains a lot
[22:35:54] stichnot: s/trace/track/
[22:36:27] stichnot: and if they aren't doing it, I hope they don't get the idea from reading IRC logs :)
[22:36:35] peper03: In the end, it's only system registers that gets set. The DVD has to query them explicitly (and I don't know how many actually do).
[22:36:40] danielk22: stuartm: I have a Disney DVD where I can't select english as a playback language even in the menus :[
[22:36:43] peper03: s/gets/get/
[22:36:50] stuartm: peper03: I'd say that's going to vary disc by disc, default to the native language as we do now is better IMHO
[22:38:05] stuartm: peper03: but setting those registers to the user-selected default language is a good idea, it might even mean that the language prompts on many DVDs highlight the correct language by default which would be nice
[22:38:37] stuartm: danielk22: well hopefully when peper03 is finished that won't be a problem any more :)
[22:38:59] stuartm: danielk22: unless you bought this DVD in Japan or something and there isn't an English track ;)
[22:39:03] skd5aner: stuartm: actually, several systems in the US leverage those 4 color buttons that are dynamically used – DirecTV (probably largest satellite provider in North America) for example – http://i.walmartimages.com/i/p/00/18/54/63/00 . . . _500X500.jpg and EVERY MCE remote has them – http://www.oneweb.co.uk/mythtv/wp-content/upl . . . e-remote.jpg
[22:39:26] skd5aner: (sorry – reading slowly through backlog :) )
[22:39:57] stuartm: skd5aner: I knew that they were used in some places, but they aren't ubiquitous as they are in the UK
[22:40:26] stuartm: skd5aner: and most MCE remotes don't have them, only those produced for the UK/European market – I've got one that does and two that don't
[22:40:30] peper03: stuartm: Exactly. You're basically giving the DVD every chance to get it right. The only question is, do we allow the user to configure the 3 language settings separately (more visible settings) or just set them to whatever language the user has set his/her Myth installation to?
[22:40:43] stuartm: peper03: the latter, for now at least
[22:41:18] skd5aner: stuartm: I'd say a significant majority of STB remotes in the last 10 years in the US has them, but they're frequently only leveraged directly in an STB's menu systems, so people don't leverage much in the guide or in playback
[22:41:27] stuartm: I think the demand for having menu/audio/subtitle in different languages would be too small
[22:42:16] skd5aner: stuartm: interesting... if I search google images for Windows MCE remote, I couldn't find a picture of one that didn't have the 4 colored buttons... and my two (different brands) have them?
[22:42:57] peper03: stuartm: There may be a similar issue (albeit small) with region codes. There are a number of region 1 discs that implement RCE (basically, they query the player's region at runtime). if the player reports anything other than region 1, you get shown a map of the world.
[22:43:19] stuartm: all of my MCE remotes are outwardly identical except for the presence of those coloured buttons and the Teletext button
[22:43:25] dekarl: stuartm, from game localization I know of the use case of japanese prefering english audio with japanese subtitles to improve their english over localized audio... (I think it was a talk about starcraft localization but I can't remember right now)
[22:44:13] peper03: I'm hoping a friend might have one of the discs that I could test to see what happens at the moment. You could get round it by allowing the user to set the region (like is currently offered for Blu-ray).
[22:44:15] skd5aner: stuartm: My cable STBs for the last several years have the 4 buttons, but they are also shaped... Yellow Triangle, Blue Box, Red Circle, and Green Diamon
[22:44:47] stuartm: dekarl: I'm not saying there isn't a use, I'm just saying that it's not going to apply to the majority of users and they can easily change tracks from the OSD/DVD menu as needed
[22:44:56] skd5aner: stuartm: anyway – just wanted to let you know it's fairly prevalent for them to be on remotes here in the US, but definitely not guarenteed, and most probably have never used them
[22:45:39] dekarl: otoh that would not be different for recordings / video. so separate choice for DVD is not needed
[22:46:46] stuartm: skd5aner: ok, I certainly wasn't going to assume they were present elsewhere, I'd personally love to have all themes display the colours mapped to the actions but that would only draw cries from those without a compatible remote
[22:47:11] skd5aner: Yea, an apple remote with 6 buttons surely won't have them ;)
[22:47:44] peper03: stuartm: AFAIK there is actually only a very small number of DVDs that use RCE, and none recently but if you have one, I'm assuming it can't be played on Myth at the moment.
[22:48:06] stichnot: I would agree with skd5aner here. I have bought several different IR receivers and thrown away the included remote, and I'm fairly certain all of them had the 4 colored buttons. However, my TiVo remote does not have those buttons.
[22:48:07] stuartm: heh, apple six button remote isn't going to have enough buttons for dedicated 'function key' behaviour
[22:48:08] skd5aner: but, I would say it'd be a great idea to leverage them... as long as they aren't the only button that could perform a certain function – it'd be great for shortcuts or other direct actions
[22:48:23] stuartm: peper03: I've never seen one
[22:48:49] skd5aner: stichnot: ha – I was just going to google search for a tivo remote image, was curious about that
[22:49:04] stuartm: any RCE protection is done at the drive level
[22:49:06] skd5aner: stichnot: those have got to be getting more and more sparse though I'd imagine
[22:49:12] stichnot: Like stuartm said, the keybindings would be there in any case, you would just want an appropriate theme to get full effect
[22:49:13] peper03: stuartm: It's only used on region 1 discs. http://www.dvdtalk.com/rce.html
[22:49:31] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit)
[22:50:02] stichnot: skd5aner: I think the number of usable buttons overall is the same, the TiVo has a different set of 4 buttons, including thumbs-up and thumbs-down
[22:50:04] skd5aner: I wouldn't care for them to be there even if my remote was missing the buttons, so long as they weren't huge or obnoxious
[22:50:17] peper03: stuartm: No, RCE is the DVD querying the system register that tells it what region the player is in. If the player reports region-free or multi-region, the DVD jumps to a title showing which regions apply where in the world.
[22:51:29] stuartm: peper03: sorry mixing my terminology, I meant region coding/protection
[22:52:32] peper03: stuartm: Actually, since it is only used on R1 discs, one solution would be to set the player to R1 if no regions can be read from the DVD (most will tell you which regions they can be played on – but not those protected by RCE).
[22:53:14] peper03: Anything that is RCE protected would read R1, most other discs would tell you which regions they support so you'd just set the VM to those regions before playback.
[22:53:20] peper03: And anything else wouldn't care.
[22:57:30] peper03: It sounds more complicated than it would be, I think :)
[23:06:46] stuartm: ok, I'm back to square one on the menu stutter bug, my hunch didn't work out :(
[23:09:14] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Accordion to a recent survey, replacing word with the names of musical instruments in a sentence often goes unnoticed.)
[23:18:49] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (Quit: No Ping reply in 180 seconds.)
[23:20:02] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[23:22:46] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Read error: No route to host)
[23:24:14] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[23:40:13] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[23:40:13] jya__ is now known as jya
[23:41:07] gigem: skd5aner: I'm absolutely positive. The SQL in Scheduler::UpdateMatches() uses "RECTABLE.station = channel.callsign". If you move, your channel rules for the OTA channels will break because the stations' true callsigns are used and those will be different even if the stations are affiliated with the same network. If you perform a claar QAM scan, you can also run into problems because the station might not
[23:41:09] gigem: (never in my case) use the same callsign the SD uses. You can have other problems because SD insists on using unique callsigns for standard- and high-def versions of channels. When/if SD is ever able to add their own value to the guide data, we might be able to make some this easier.
[23:41:42] jya_ (jya_!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv
[23:41:42] jya_ (jya_!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host)
[23:41:42] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:42:47] skd5aner: gigem: gotcha... I've seen the issue in the past when I've had to delete all my video source (and channels) and re-add... a few years ago, I eliminated as many channel recording rules as possible and moved to "all" rules...
[23:43:21] skd5aner: gigem: I have QAM, which I scan, then I change the callsign back to whatever matches the SD callsign, so it should be the same
[23:44:04] skd5aner: but I've seen the issue on cable networks where there ID could change, but the callsign should be the same, but it doesn't stay that way for hte recording rule – I have to go and reset the channel based on selecting an upcoming recording
[23:44:11] skd5aner: ... and reseting the rule
[23:46:38] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[23:49:15] skd5aner: jya: you keep asking about logging network transactions... I've suggested -v network a few times, did that not do what you need?
[23:50:32] clever: 14 09:56:51 < jya> :) when I do --v network --loglevel debug ; it segfault when playback start
[23:51:23] skd5aner: clever: ah, heh – haven't got that far in the backlog yet ;)
[23:52:01] clever: i think that segfault needs to be fixed anyways, rather then worked arround
[23:53:39] skd5aner: but still – he asked the other day and I suggested it twice...
[23:53:42] skd5aner: lol
[23:55:37] Mousey: k, nite internets
[23:55:43] Mousey (Mousey!~r0dent_@ross154.net) has quit (Remote host closed the connection)
[23:58:38] peper03 (peper03!~peper03@port-92-203-104-218.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[23:59:30] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)

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