MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (94):

aloril, andreax, Anduin_, Anssi, anykey_, beata, Beirdo, bernard_, birds, brfransen, caelor, Captain_Murdoch, Casper0082, Chutt, clever, coling, Computer_Czar, Cougar, dagar, danielk22, Dave123, Dave123-road, davide_, dekarl, dlblog, eharris_, elvum, f33dMB, fith, foobum, foxbuntu, ghoti, Gibby, gregL_, GreyFoxx, hads, holomntn, iamlindoro, ikonia, J-e-f-f-A, j-rod|afk, jams, jannau, jarle, jcarlos_, JEDIDIAH___, joe__, jpabq, jpabq-, jpabq_, jstenback, justinh, justpaul, jwhite, kisak, knightr, kormoc, kurre, kwmonroe, laga, leprechau, mag0o, mike|3, mrand, mycosys, MythBuild, MythLogBot, okolsi, paul-h, poptix, pulz, purserj, reynaldo, rooaus, skd5aner, Snow-Man, sphery, Splat1, stuarta, stuartm, sunkan, superm1, sutula, ThisNewGuy1, ThisOtherGuy, tomimo, tris, Unhelpful, wagnerrp, weta, XChatMav, xris, ybot, _charly_
Sunday, February 27th, 2011, 00:17 UTC
[00:17:15] Kunalagon (Kunalagon!~Kunalagon@212.200.241.213) has joined #mythtv
[00:19:07] Kunalagon (Kunalagon!~Kunalagon@212.200.241.213) has quit (Remote host closed the connection)
[01:11:03] dekarl1 (dekarl1!~dekarl@e180131138.adsl.alicedsl.de) has joined #mythtv
[01:11:06] dekarl (dekarl!~dekarl@e180135094.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds)
[01:48:40] jya: Guys, I have the choice of either merging my fork with master/trunk, which will result in a noisy commit as I've made lots of merge in between. Or I do a big diff and apply it as-is and then loose all history. So which one is best?
[01:48:56] jya: I tried to do a rebase, but it spread over a too long period of time and went nowhere
[01:50:59] ** jya : rebooting **
[01:51:14] jya (jya!~jya@mythtv/developer/jya) has quit (Quit: jya)
[01:54:15] jya (jya!~jya@mythtv/developer/jya) has joined #mythtv
[01:56:53] Beirdo: I personally am good with either method. Although, if you are going to basically squash, then merge... could you make a couple commits?
[01:57:05] Beirdo: one with the ffmpeg backport stuff, one with the rest?
[01:57:49] Beirdo: messy history like this wouldn't bother me though. pulling in all of ffmpeg's history... would :)
[01:58:09] Beirdo: which is why I squashed the ffmpeg sync
[02:09:39] andreax (andreax!~andreaz@p57B93F16.dip.t-dialin.net) has joined #mythtv
[02:13:12] jya: Beirdo
[02:13:29] Beirdo: aye?
[02:13:31] jya: Beirdo: did that, first applied a big diff only related only to ffmpeg
[02:13:38] jya: then did the merge
[02:14:02] jya: in the comment of the ffmpeg I put the SHA of all the revision of ffmpeg I used
[02:14:56] Beirdo: from git.ffmpeg.org, I would assume?
[02:15:22] jya: so either the big diff or the merge, are on top of a single commit with ffmpeg changes, so it's easy to revert
[02:15:30] Beirdo: cool
[02:15:57] Beirdo: I guess see what others think about the pros/cons around squashing the history
[02:16:11] jya: I like the merge better, because there are a couple of changes from foobum, and doing a big diff would loose his changes
[02:16:45] Beirdo: yeah. They'd get borged in with your changes
[02:17:34] Beirdo: if you wanted to keep his attribution separate, a merge is the simplest
[02:17:55] jya: personally, I'm not bothered with the stuff git does when merging, I understand why it does it. I know it creates issue with people relying on the post-commit hook
[02:17:59] Beirdo: of course, you could squash stuff down other than his changes, then merge with a shorter branch
[02:18:31] jya: Beirdo: problem is that his changes applies on some code that has changed recently. So in a merge it's easy to show, now none of his patches apply
[02:18:56] Beirdo: heh. Gotcha
[02:19:15] jya: What I first did is do a git format-patch, and extract them all one by one
[02:19:23] jya: thinking I could apply them on top of the current trunk
[02:19:42] Beirdo: I won't be the one making noise about noisy history anyways.
[02:19:44] jya: but it's not so easy. It has evolved since the end of November when I started
[02:19:51] Beirdo: yeah.
[02:20:11] Beirdo: rebasing your branch off current master may take a bit of work
[02:20:16] jya: and in my history a few times before I did a merge, I reverted my changes, apply the merge with master, then re-did the patch
[02:20:29] jya: especially as it would be my first rebase :)
[02:20:44] Beirdo: ouch
[02:20:47] jya: I've spent the whole morning on it already, and I'm getting nowhere
[02:21:04] Beirdo: a lot of merge conflict?
[02:21:12] jya: it's the 5th time I restart from scratch
[02:21:50] jya: to add to the complexity, I didn't do my changes in a branch, but in a github fork
[02:22:03] jya: but , damn, that git merge is brilliant
[02:22:09] Beirdo: that shouldn't make it too much harder
[02:22:21] jya: it had no problem merging even though I had made a big diff for just ffmpeg
[02:22:27] Beirdo: yeah, it's a real nice tool :)
[02:22:38] jya: it didn't attempt to reapply (and fail) any of the previous ffmpeg change
[02:22:55] jya: I have to admit, other than the foobum changes, I do not care much about the history
[02:23:25] jya: I started working on Anssi ffmpeg patches, the whole structure and API have changed several times. That was way before it got committed in ffmpeg
[02:23:41] Beirdo: your changes have removed all of his changes?
[02:23:45] jya: so most of the history is about changing the code to handle the new ffmpeg api
[02:24:01] jya: oh, I was working with Anssi private patches
[02:24:08] jya: before they got accepted in ffmpeg
[02:24:20] Beirdo: ahh, I meant the foobum changes
[02:24:33] jya: yes, they are in the middle
[02:24:54] Beirdo: well, if his code's gone, I'm not sure I'd worry about losing them
[02:25:14] Beirdo: maybe change a commit message to give credit for his help or something? I dunno
[02:25:37] jya: I think I'm just going to do a merge, people should have learnt by now that's how git work and accept it... it's a brilliant tool for merging, doing stuff do make a clean history only add times
[02:25:39] Beirdo: guess it depends on the politics or whatever
[02:26:08] jya: Beirdo: his code is actually a clean-up of my code, fix spelling, re-format etc
[02:26:13] Beirdo: ahh :)
[02:26:25] Beirdo: whatever makes you sleep well at night, I guess :)
[02:26:44] jya: Well, I don't want to get another drama with someone telling me I'm stealing code.
[02:26:57] jya: It has left a nasty after-taste in my mouth that whole think
[02:26:59] jya: thing
[02:27:34] Beirdo: understood
[02:28:58] jya: TBH, my main concern is giving food to the git nay-sayer. Like "look how nasty this is... noisy blah"
[02:29:41] jya: I'm so impressed in how it managed to merge the thing.. took one command line, no conflict nothing. despite my patch in between
[02:31:37] Beirdo: yeah, I hear ya :)
[02:32:07] andreax1 (andreax1!~andreaz@p57B950EA.dip.t-dialin.net) has joined #mythtv
[02:32:35] danielk22: jya: Don't do a merge to our repo, squash first.
[02:33:01] jya: I really wonder how it managed to detect that a patch not applying cleanly isn't a conflict, but one that was already there
[02:33:02] andreax (andreax!~andreaz@p57B93F16.dip.t-dialin.net) has quit (Ping timeout: 240 seconds)
[02:33:24] jya: danielk22: please read the reasons for me wanting to do a merge ...
[02:35:54] danielk22: jya: If it is over a long enough time that you have trouble with it, it will send a storm of messages out to the mailing list.
[02:37:00] jya: danielk22: I know... this mailing list is useless IMHO and forces people to forget some of the great feature of git, just because it's unable to be smart enough to deal with the data
[02:39:10] Beirdo: I think minimizing the size of the branch via squashing can get the best compromise
[02:39:42] jya: Beirdo: say I have a branch (or fork) and master. What's the best way to rebase the whole lot into master?
[02:39:43] danielk22: jya: If you fix the mailing list integration, you can do a merge commit. I'd be very glad if you did. I'd much rather be able to do merge commits alone than have to merge+squash things.
[02:39:46] Beirdo: but I tend to agree, our mailing list shouldn't be the dictating force for workflow
[02:40:15] Beirdo: danielk22: there's nothing broken with the mailing list itself
[02:40:22] jya: by squashing you mean generating a big patch between the two branch and applying it ?
[02:40:34] Beirdo: when you merge into master, all of the commits in the other branch are being pulled into master
[02:40:35] jya: I see references to git squash, but I don't have that with my git command
[02:40:40] Beirdo: ahh
[02:40:50] Beirdo: jya: no, you can squash with rebase
[02:40:56] Beirdo: git rebase -i
[02:41:11] Beirdo: it's fraught with possible fun, but...
[02:41:27] Beirdo: it is the way to do it
[02:41:28] jya: so I do something like git rebase -i master branch or something like that?
[02:41:42] jya: or I rebase in the branch
[02:41:46] jya: then merge into master
[02:41:59] Beirdo: you'd rebase in the branch itself
[02:42:18] Beirdo: let's say you branched off master.
[02:42:31] Beirdo: in the branch, you can do git rebase -i master
[02:42:32] jya: I did...
[02:42:32] martin_ (martin_!~quassel@h-39-23.A155.priv.bahnhof.se) has quit (Read error: Connection reset by peer)
[02:42:58] jya: yeah, but when I do that, I get an editor starting with "noop"
[02:43:02] Beirdo: and it will bring up an editor with all of the commits in order since you branched (all the way back to master)
[02:43:12] Beirdo: oh, then it's a bit more fun
[02:43:13] Beirdo: heh
[02:43:32] jya: that's from the fork
[02:43:39] Beirdo: what you want is to find the SHA1 from before your branch
[02:43:47] jya: I guess I need to do something like git rebase -i upstream/master
[02:44:01] jya: it's a fork I created using github
[02:44:12] Beirdo: yeah, that might catch it correctly
[02:44:29] Beirdo: if the list looks wrong, delete the entire file, and it will abort
[02:44:45] andreax1 (andreax1!~andreaz@p57B950EA.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)
[02:44:56] Beirdo: if it looks right, then you can squash multiple commits into one in there
[02:45:00] jya: I did git rebase -i upstream/master
[02:45:06] Beirdo: it would be like... pick SHA1
[02:45:12] Beirdo: then squash SHA1
[02:45:17] jya: it opened an editor with hundreds of lines
[02:45:25] andreax (andreax!~andreaz@p57B950EA.dip.t-dialin.net) has joined #mythtv
[02:45:26] Beirdo: which would combine the two
[02:45:28] jya: like
[02:45:29] jya: pick 3525239 Minor refacotor of VideoOutputD3D9
[02:45:35] Beirdo: gah
[02:45:40] Beirdo: abort :)
[02:45:56] Beirdo: it will get fun.
[02:46:21] Beirdo: basically, after the -i, you tell it what commit to go back to
[02:46:41] jya: need to find a tutorial somewhere
[02:46:43] Beirdo: git rebase -i --onto upstream/master sha1beforebrancing
[02:46:46] jya: this isn't intuitive at all
[02:46:51] Beirdo: I THINK is what you want
[02:47:20] jya: bah, I'm just going to do a big diff
[02:47:26] Beirdo: yeah, rebase is painful, and not for the light of heart
[02:47:28] jya: what the hell.
[02:47:34] Beirdo: heh, OK
[02:47:49] jya: too bad.. but as you said, that bloody mailing list is dictating us how to work
[02:47:56] jya: such a shame
[02:48:12] Beirdo: more like the expectations of some people on said list
[02:48:14] Beirdo: but yeah
[02:48:42] Beirdo: hard to work around it, it's dictating a different workflow than ideal
[02:48:48] sphery: Out of curiosity, doesn't merging to master change the hashes of previous commits--making all mention of them on e-mails, archives, wikis, forums, ... useless? IMHO, that would be far worse than getting "repeated" e-mails. Or was that something else that changed commit hashes?
[02:48:55] jya: I don't subscribe it to it anymore, I read the github rss
[02:48:56] Beirdo: no.
[02:49:08] Beirdo: merging doesn't change anything previous
[02:49:18] Beirdo: it creates a commit with two parents
[02:49:43] Beirdo: cherry-picking makes a copy and recommits, creating a new SHA1
[02:49:53] jya: sphery: after the merge, I see two commits with the same content, but the original sha is there
[02:50:16] Beirdo: rebasing renumbers any changed commits (including changes of parent commits)
[02:50:29] Beirdo: but a merge doesn't change either branch's history
[02:50:48] Beirdo: it will create a commit with any merge resolution in it, and with two parents
[02:50:49] sphery: ok, was just remembering a couple hashes disappearing or something and thought that was from a merge
[02:51:01] Beirdo: one as the old master, and one as the old whatever else branch
[02:51:04] Beirdo: heh
[02:51:29] Beirdo: that was someone rebasing, and not changing the text in the commits that referred to it by sha1
[02:51:43] Beirdo: then merging the rebased commits
[02:51:49] sphery: ah, ok
[02:52:17] Beirdo: the history was all there, but the textual relationship in the "reverts blah" comment was wrong
[02:52:45] Beirdo: unfortunately, rebase doesn't change those (or the cherry-pick -x comments)
[02:53:24] danielk22: sphery: merges aren't evil, it's just the github integration that makes them evil for us.
[02:53:36] andreax (andreax!~andreaz@p57B950EA.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[02:54:50] Beirdo: yeah, it is somewhat sucky
[02:55:41] danielk22: github integration is also what makes it so trac "Fixes #blah" hooks don't work.. git itself can be hooked up to trac fairly easily if you run your own server. ... but there are also really nice aspects to github ...
[02:56:27] Beirdo: if we can get someone with python experience to help fix the trac github plugin, that would be all fixed
[02:57:24] danielk22: Who worked on the python bindings? wagnerrp?
[02:57:46] Beirdo: I put them in, it only half works, and wagnerrp's been busy :)
[02:57:50] danielk22: I'll gladly airmail some fine beer and or wine..
[02:57:54] Beirdo: hehe :)
[02:58:07] Beirdo: wagnerrp: you wanna help getting that crap working? :)
[02:58:35] danielk22: (And I'm serious on my donation to the effort ;)
[02:59:36] Beirdo: :)
[02:59:37] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out)
[02:59:53] Beirdo: I'm gonna go look at seeing if we can't make the email a bit more sane still
[03:00:13] Beirdo: but github does miss the occasional hook, and there's not much that can be done there
[03:01:31] danielk22: svn missed the occasional hook too. But a 95% solution is still valuable.
[03:01:51] Beirdo: aye
[03:02:11] Beirdo: I'm thinking of adding "if I've seen this SHA1 before, don't report it"
[03:02:31] Beirdo: which should fix the merges
[03:02:44] Beirdo: I'll work on that tonight :)
[03:02:51] jya: sphery: regarding the ignore_schema; the issue came that #ifdef IGNORE_SCHEMA_VER_MISMATCH became #if IGNORE_SCHEMA_VER_MISMATCH
[03:03:08] jya: so all I had to do with change my -D IGNORE_SCHEMA_VER_MISMATCH into -D IGNORE_SCHEMA_VER_MISMATCH=1
[03:03:14] Beirdo: danielk22: do you actively use NuppelVideoRecorder.cpp anymore?
[03:03:17] danielk22: jpabq: I've committed a fix for hdpvr LiveTV in the mythtv-rec branch. I'll cherry-pick it over to master once I've tested DVB recording too.
[03:03:56] sphery: jya: ah, that was changed or? glad you figured it out--I didn't get a chance to look at it today (between a terrible travel experience last night and dying cable modem)
[03:04:08] Beirdo: I have a patch I haven't tested yet that changes the threads in NVR...
[03:04:15] jya: Beirdo: wouldn't anyone using mythtranscode would ?
[03:04:17] Beirdo: using QThreads
[03:04:29] Beirdo: Ooooh
[03:04:33] Beirdo: good call
[03:04:52] Beirdo: OK, I can test that, thanks, I think that would cover it
[03:05:13] danielk22: Beirdo: no, I don't know if I have any suitable hardware installed in a machine either. I have some in the recorder box..
[03:05:14] jya: sphery: I just looked at the code , my -D IGNORE_SCHEMA_VER_MISMATCH used to work , so it's an educated guess
[03:05:40] Beirdo: if that won't hit the code, I'll setup on the dev box to use the PVR250 as a framegrabber
[03:05:43] Beirdo: heh
[03:06:20] danielk22: My latest NTSC/PAL work was with the HVR-2250, but that is sort of in between a PVR-250 and bttv. (It does VBI like a bttv and video like a PVR-250).
[03:06:52] Beirdo: yeah
[03:07:06] Beirdo: I will be happy once it does CC :)
[03:07:28] danielk22: jya: I just added "#define IGNORE_SCHEMA_VER_MISMATCH 1" to dbcheck.cpp manually. That works..
[03:08:00] jya: danielk22: I know that. What I'm saying is that doing #define IGNORE_SCHEMA_VER_MISMATCH only used to work
[03:08:08] jya: no 1 after
[03:08:12] jya: #ifdef vs #if
[03:10:14] danielk22: Beirdo: That's what I was working on last. I got as far as extracting the VBI CC, and I believe I committed that in the rec branch. But inserting it into the mpeg user data will require some thought. (An easy workaround would be to just write out an srt).
[03:10:50] Beirdo: hmm, yeah, that could be.. interesting.
[03:13:34] sphery: So, the protocol uses an #ifndef ( mythtv/libs/libmythbase/mythcorecontext.cpp +207 ), and schema wizard uses #if ( mythtv/libs/libmythtv/dbcheck.cpp +455 )? Is there a preferred approach.
[03:14:22] Beirdo: heh
[03:15:28] danielk22: sphery: in general #if is preferred if you don't intend to set it from the command line, #ifdef otherwise. so in this case #ifdef is better.
[03:15:55] sphery: ok, I'll flip it to the other when I get a chance. thanks
[03:16:14] sphery: (unless someone beats me to it :)
[03:16:34] jya: sphery: Don't think you need to spend time on this. Not many people would use it anyway, and now that it's in my config line, I won't care anymore
[03:17:00] sphery: would only take seconds--and whether you have =1 or not, the #ifdef should work, so...
[03:17:26] sphery: besides, I like the idea of changing it for consistency with the proto stuff :)
[03:27:06] wagnerrp: danielk22: if theres a list of behavior we want, i can look into them
[03:28:31] Beirdo: wagnerrp: for the github-trac thing, the code's theoretically there, but seems to be borked
[03:30:14] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 240 seconds)
[03:31:38] danielk22: wagnerrp: For trac integration we just want text like "Fixes #9999. Fixes #8888, Refs #7777" to close the tickets #9999 and #8888 with the commit message and add a comment to #7777 with the commit message.
[03:32:18] wagnerrp: ah, just the commit hooks so things are automatically closed and/or referenced
[03:32:37] danielk22: wagnerrp: For mailing list integration we don't want a merge commit of mythtv-rec into master to generate 2000 mailing list messages, only 30 or so for the commits that were actually new to that branch.
[03:34:12] jya: pushed...
[03:34:14] danielk22: wagnerrp: yeah, if you could just fix those hooks, you'd be my hero for a day ;]
[03:34:46] Beirdo: danielk22: I'll be looking at fixing the mailing list messages
[03:35:05] Beirdo: but I could use python help on the trac integration par
[03:35:06] Beirdo: t
[03:38:23] danielk22: Beirdo: Did you see my notes on QThread earlier.. the issues with deferred deletion? We don't use deferred deletion much ourselves, but it's used deep in some of the Qt classes and can cause a problem for long lived QThreads that don't run exec()
[03:38:31] danielk22: shortly after starting run().
[03:39:07] jya: Be interested with anyone running mythtv on windows, if DTS-HD and TrueHD passthrough works
[03:39:21] danielk22: Just something to know in case we suddenly start seeing memory usage ballooning.
[03:40:32] Beirdo: danielk22: hmmm, no, I didn't see that, you have a URL for me to look into it?
[03:41:42] Beirdo: oooh, I think I see what you are saying too. That will require some thinking to fix, I think
[03:42:38] Beirdo: anything deleteLater inside that thread won't do it until the thread exits, pretty much, as that's done in the event loop, and without exec() we aren't likely running an event loop
[03:42:55] danielk22: It's in the backlog..11:30:50 AM my time (11 hours ago)
[03:42:56] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[03:43:11] Beirdo: definitely something to look at. Thanks.
[03:43:45] Beirdo: oooh, today. I'll go take a look, right after getting food. Thanks.
[03:45:31] danielk22: right. I'm not sure of a decent fix either. i did some googling this morning for the processEvents hack I knew about from before.. but it's now depreciated and when i googled that all i found was a bunch of people wondering what they were supposed to do now.
[03:46:00] Beirdo: definitely something to be aware of
[03:46:09] danielk22: it's two steps forward two steps back with Qt sometimes..
[03:46:10] Beirdo: okolsi: that should be fixed now.
[03:46:13] Beirdo: yeah
[03:46:34] Beirdo: but food.
[03:58:47] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[04:11:20] jya: Beirdo: looking at bug #9414
[04:12:48] jya: the error with 6 channels is due to the code specifically not allowing 6 channels audio
[04:13:01] jya: code by danielk22 in early 2008
[04:13:15] jya: I'm wondering on how this could have ever worked in 0.23 and earlier
[04:14:05] jya: ahhh I see. it was AC3 all along before, audio wasn't reconfigured if the number of channels change while the streem was always AC3
[04:15:07] wagnerrp: Beirdo: is there a folder where we have our current version of the trac code installed?
[04:15:13] wagnerrp: or are we running vanilla?
[04:16:00] wagnerrp: just wondering if i should start from /opt/archive/trac/Trac-0.12.1.tar.gz, or if theres something better
[04:18:48] jya: that transcode.cpp is sooo buggy. I wonder how it ever worked really :(
[04:37:25] Beirdo: wagnerrp: it's installed via easy_install, so whereever python hid it
[04:38:36] elmojo (elmojo!~elmojo@cpe-173-095-144-220.nc.res.rr.com) has joined #mythtv
[04:38:36] elmojo (elmojo!~elmojo@unaffiliated/elmojo) has joined #mythtv
[04:38:36] elmojo (elmojo!~elmojo@cpe-173-095-144-220.nc.res.rr.com) has quit (Changing host)
[04:39:00] wagnerrp: /usr/lib/python2.6/site-packages/GithubPlugin/github/
[04:39:06] Beirdo: yup
[04:39:09] Beirdo: you got it ;)
[04:39:09] wagnerrp: but i was asking whether its vanilla? or did you make changes?
[04:39:31] wagnerrp: i dont want to edit the in-place one
[04:39:37] Beirdo: I think I made some changes at one point, but it's not in the affected area
[04:39:58] wagnerrp: i see a github.py in your directory
[04:40:06] wagnerrp: which is one of the files in this thing
[04:40:28] Beirdo: ahh yes
[04:40:40] Beirdo: that was my version to point /timeline to github
[04:41:00] wagnerrp: so its vanilla, besides that file?
[04:41:04] Beirdo: that was the change I was making, but we aren't using, so I'm pretty sure it's vanilla at this point
[04:41:25] wagnerrp: ok, ill pull a new version from davglass/github-trac to work on
[04:41:30] Beirdo: OK
[04:41:42] Beirdo: there may be a better branch/fork too
[04:41:49] wagnerrp: how exactly does this thing get loaded into trac?
[04:42:08] Beirdo: oh, I was editing in /usr/src/github-trac
[04:42:13] Beirdo: which was a git clone
[04:42:22] Beirdo: hmmm
[04:42:24] Beirdo: one sec
[04:43:11] Beirdo: in trac.ini:
[04:43:15] Beirdo: [components]
[04:43:20] Beirdo: github.* = enabled
[04:43:43] Beirdo: and then there's a [github] section for such things as config vars
[04:43:59] Beirdo: closestatus currently is set to "closed"
[04:44:10] Beirdo: if that helps :)
[05:57:34] wagnerrp: anyone got a 'fixes #xxxx' lined up?
[05:59:00] jya: wagnerrp: I just committed one
[05:59:10] jya: and manually edited the entry in trac
[05:59:18] wagnerrp: yeah, like two hours ago
[05:59:21] jya: or you want a new commit ?
[05:59:33] wagnerrp: ... which helped me trac down the issue by the way, thanks for that!
[06:01:41] wagnerrp: as far as i can tell, it was just a single line issue, trying to convert from python datetime to integer timestamp, twice
[06:05:20] wagnerrp: ok, the trac commit hooks are working
[06:05:24] wagnerrp: whats next on the todo list?
[06:07:43] Beirdo: Niiice
[06:08:05] Beirdo: OK, gimme a sec, my email hook is borked for the exact moment
[06:11:05] wagnerrp: is this /opt/git/extras/git_hooks/email_hook.pl youre working on?
[06:11:10] Beirdo: yrd
[06:11:13] Beirdo: yes
[06:11:24] Beirdo: are my errors speweing somewhere I can't find?
[06:11:41] ** xris should take this opportunity to keep mucking with smolt. **
[06:11:43] xris: got a new version from jams today
[06:11:47] wagnerrp: well ill leave the perl to you
[06:13:17] Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv
[06:13:39] xris: smolt is python
[06:13:47] xris: oh, the hooks. heh
[06:13:52] wagnerrp: xris: beird... commit hook.. yeah
[06:14:00] Beirdo: not to worry, I'll have it in a second
[06:14:11] Beirdo: config::general being stupid
[06:14:44] xris: wagnerrp: but if you have some spare time, we could use some mythtv-specific stuff added to the client side of smolt. not sure what iamlindoro did with his code, though. been afk too much this weekend.
[06:14:50] Beirdo: there it goes
[06:15:03] Beirdo: I had quoted the regexp in the config file.
[06:15:04] Beirdo: heh
[06:15:15] wagnerrp: sure, let me know what
[06:15:32] wagnerrp: im looking at this cgi/signal stuff
[06:15:48] wagnerrp: going to try to get it to quit spewing garbage on every page
[06:16:06] Beirdo: that would likely speed something up too
[06:22:30] xris: ok, smolt up and running
[06:22:53] Beirdo: resent the last 3 from mythtv too
[06:24:07] Beirdo: done
[06:24:45] jya: Beirdo: I was thinking in regards to adding the ability to keep the original audio stream in mythtranscode (and as such adding support to mode codec in nuv files)
[06:25:10] xris: jya: better to switch to a better codec
[06:25:31] Beirdo: xris: not really
[06:25:44] jya: why even bother with mythtranscode and NuvRecorder; why not just create a temp file cut appropriately, and pass that to an external program
[06:25:46] Beirdo: the fewer times we re-encode, the better
[06:25:47] wagnerrp: Beirdo, xris: on second thought, this doesnt look like something i should remove
[06:25:53] jya: xris: nuv is just a container
[06:25:58] wagnerrp: better we just turn down logging if its an issue
[06:26:02] xris: jya: a container that *only* mythtv supports correctly
[06:26:36] xris: sorry, wrong terminology...
[06:26:39] jya: Beirdo: tools like handbreak will always do a much better job than what myth would do. So either we do lossless transcode
[06:26:41] xris: any effort spent to get it to hold other codecs could better be spent on using a different container
[06:26:51] jya: or we do lossless and let the user call automatically another external program
[06:26:57] xris: jya: handbrake is ffmpeg + extras
[06:27:08] xris: but their comb filter is awesome
[06:27:18] wagnerrp: xris: so what do you want me to do with smolt?
[06:27:40] Beirdo: using something else external is asking for trouble
[06:27:42] wagnerrp: i saw something iamlindoro stuffed in a pastebin earlier this week, but didnt know what i was supposed to do with it
[06:27:47] jya: xris: I agree. But modifying nuv is trivial, adding audio passthrough to mythtranscode is probably about one hour work. Rewriting mythtranscode for use with a different container, several days at least
[06:27:50] Beirdo: ffmpeg is horrible as a moving target
[06:28:00] xris: wagnerrp: honestly, I don't know if it can be done.. but I'd like to get some info about data providers, as well as some geographic data
[06:28:19] xris: might not be able to get geographic from IP, so maybe data providers would be enough
[06:28:30] xris: smolt was written for hardware, but I'd like to use it to collect some other demographic data
[06:28:36] Beirdo: dammit
[06:28:41] Beirdo: it's not working right.
[06:28:58] jya: I see something like in the recording profile, you configure as lossless (just use the cutpoint) or you enter an external tool to use, and myth do the lossless transcode and pass that to it. problem solved :)
[06:29:00] xris: jya: Captain_Murdoch had a bunch of work done on mythtranscode about a year ago.. not sure if it's still pertinent, though
[06:29:28] wagnerrp: xris: like... pull the xmltv grabber?
[06:29:29] Beirdo: I don't see using ffmpeg externally as being a good option
[06:29:36] jya: xris: to be honest, I don't even understand how mythtranscode ever work like it did... there's some black magic there
[06:29:45] xris: wagnerrp: and/or sd, or mce2xml, etc.
[06:30:05] xris: wagnerrp: probably better for me to first send a note to -developers to figure out what kind of info we want to collect.
[06:30:14] jya: Beirdo: not talking about using ffmpeg only.. Just like when we had the external player.
[06:30:33] xris: wagnerrp: smolt may not be the best solution for this
[06:30:36] jya: you leave up to the distribution (buntu, fedora and other) the task to well integrate
[06:30:45] Beirdo: no thanks
[06:31:14] jya: I just look at the amount of work to get mythtranscode to work properly, with modern feature
[06:31:19] Beirdo: seriously, as one who's had to deal with the stupidity that ensues from ffmpeg in particular changing crap around on the command line. Pass
[06:31:35] Beirdo: it's better to use the ffmpeg libs we have already sucked in
[06:31:37] jya: I certainly see no interest in rewriting that when there are so many transcoder out there doing a fine job
[06:31:55] jya: just another case of re-inventing the wheel
[06:32:02] jya: *again*
[06:32:03] Beirdo: welcome to mythtv :)
[06:32:24] wagnerrp: xris: something like http://mythtv.pastebin.com/L20HEN3g
[06:32:50] Beirdo: anyways, I got something to smack around here
[06:34:01] xris: wagnerrp: I suppose. I get errors when I try to run it
[06:34:33] wagnerrp: if youre pasting it directly into an interactive session, add an extra line after the 'pass'
[06:35:16] jya: Beirdo: could just add an "external" option ; on top of RTJPEG and MPEG4
[06:36:03] jya: for the old folks they continue using it as is, for more open-minded people, use an external tool :)
[06:36:13] xris: wagnerrp: gotcha
[06:36:50] Beirdo: jya: I hope you want to field all the tickets for the "my external transcoder isn't working anymore"
[06:36:53] Beirdo: :)
[06:36:54] wagnerrp: i dont know what shows up for other people, other than 'schedulesdirect1'
[06:38:11] xris: wagnerrp: yeah, that'd likely do. not sure how to get it into smolt, though
[06:38:20] wagnerrp: anyway, this is the one iamlin doro pasted, http://mythtv.pastebin.com/wS67ZDrS
[06:38:26] ** jya wondering what else he could do now... **
[06:38:41] wagnerrp: dont know if there was a specific reason he didnt use the bindings
[06:39:13] xris: wagnerrp: copied/pasted from the original scripts
[06:39:14] jya: oh, I know.. work on the digital audio out on mac !
[06:39:23] xris: which may have predated the bindings in their current form
[06:39:43] wagnerrp: xris: well i could rework that pretty quickly if you wanted
[06:40:32] xris: wagnerrp: I'd love it. but let me check first with jams to make sure that everything is set up like it should
[06:40:48] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (*.net *.split)
[06:40:50] wagnerrp: but that would necessitate everyone have the bindings installed for this to work
[06:41:36] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[06:44:07] xris: true
[06:44:17] xris: imho that's fine
[06:45:22] kormoc: the bindings are defaulted to installing, no?
[06:45:28] wagnerrp: correct
[06:45:35] wagnerrp: assuming the prereqs are installed
[06:46:22] wagnerrp: is this how smolt expects the data to be given? 'Value:\nData' ?
[06:46:28] wagnerrp: two lines per item?
[06:46:35] xris: wagnerrp: not sure
[06:46:44] xris: that almost looks like yaml, though
[06:47:35] wagnerrp: kind of
[06:52:16] wagnerrp: woah.. what happened to trac
[06:52:28] xris: ?
[06:52:36] wagnerrp: its like it ran through the whole backlog of commit hooks
[06:52:52] Beirdo: really?
[06:53:31] xris: oops
[06:53:31] wagnerrp: no, thats not what happend
[06:53:52] wagnerrp: i had pulled commits from master into jobqueue-rewrite
[06:53:57] wagnerrp: bringing it up to date
[06:54:17] wagnerrp: all those commits ran back through the parser
[06:55:11] Beirdo: hahaha
[06:55:12] wagnerrp: normally they get squelched from the emailer
[06:55:24] wagnerrp: i guess i should limit the commit hook to master and fixes/*
[06:55:32] Beirdo: here I am trying to reduce the spew on the ML, and you fix something, and away it spews
[06:55:43] Beirdo: fun times
[06:56:27] Beirdo: I think we owe you a beer.
[06:56:34] Beirdo: how hard was it in the end?
[06:56:38] wagnerrp: seriously... it was half a line
[06:56:59] Beirdo: oh jeez
[06:57:13] wagnerrp: hook.py:153
[06:57:17] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[06:57:29] Beirdo: well, if you feel like, you can fork it on github, commit your fix on your fork, then give the original author a pull request :)
[06:57:31] wagnerrp: was something like 'timestamp = to_utctimestamp(datetime.now(utc))'
[06:57:41] wagnerrp: i had to remove the to_utctimestamp
[06:57:46] Beirdo: heh
[06:57:47] Beirdo: nice
[06:57:49] wagnerrp: im thinking theres something messed up in our code
[06:57:54] wagnerrp: either that, or there was a change at some point
[06:58:02] Beirdo: that wouldn't be all that unheard-of
[06:58:25] Beirdo: I don't think we are running anything custom
[06:58:27] wagnerrp: because i recall having to make a similar fix to get And uin's delete_comment patch working properly
[06:58:41] Beirdo: hmmm
[06:59:46] wagnerrp: how are you determining what the branch is to filter off of?
[06:59:53] wagnerrp: i dont see that listed in the commit data
[06:59:58] wagnerrp: just parse it out of the url?
[07:00:06] Beirdo: it's in the JSON
[07:00:35] Beirdo: from ref:
[07:01:24] wagnerrp: im looking, i dont see it
[07:01:46] Beirdo: right down at the end of the output block in the dump
[07:01:59] Beirdo: it's a top-level hash value
[07:02:15] wagnerrp: oh, 'refs/heads/<branch>'
[07:02:19] Beirdo: yup
[07:02:32] Beirdo: that's the one
[07:02:54] Beirdo: and if it's not master or fixes/* I toss it for the email generation
[07:03:11] wagnerrp: should i toss 'cherry picks' as well?
[07:03:23] Beirdo: I wouldn't
[07:03:53] Beirdo: and that will be tricky, especaillay if the person didn't use -x
[07:04:18] Beirdo: OK, WtF is with my typing?
[07:05:25] wagnerrp: will it always be 'refs/heads' ?
[07:06:28] Beirdo: as far as I know, yes
[07:06:41] Beirdo: nothing has proved that false in the json yet :)
[07:07:25] Beirdo: that's every time the hook's been hit (with debug on) whether I send email or not
[07:12:18] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[07:14:09] jya: Are there any instructions on how to build for mac now somewhere?
[07:20:56] wagnerrp: Beirdo: its the monkey's fault, i swear....
[07:21:04] wagnerrp: https://github.com/magicaltrevor/github-trac/ . . . 32eb8548e920
[07:22:29] Beirdo: hhehehe
[07:22:58] Beirdo: jya: the closest I've seen is the osx-packager.pl in the packaging repo
[07:23:16] Beirdo: I think stuarta is still working on getting something to run from the buildbot
[07:23:20] jya: Beirdo: yes, that's what I was using before
[07:23:32] jya: just in a different repo now
[07:23:37] Beirdo: aye
[07:23:49] Beirdo: it worked OK as of a couple days back anyways
[07:24:16] jya: I know how to use that tool to build complete mac binaries
[07:24:27] jya: but what I want to do is build to debug/trace
[07:27:09] wagnerrp: xris: were you going to write up an email asking what information we want to pull through smolt? or do you want me to?
[07:27:59] xris: need to talk to jams first
[07:28:14] xris: ....I think
[07:29:38] xris: and I'm sure he's asleep by now
[07:31:29] Beirdo: danielk22: you'll hopefully be happier with the email now. :) If we see a sha1 again on the same repository, we cowardly refuse to email it again.
[07:32:40] Beirdo: that should cut out stupid dupes
[07:45:00] xris: Beirdo: keeping track of the shas?
[07:50:43] Beirdo: yup
[07:51:02] Beirdo: in mysql. if we see the same sha and same repo, we already sent an email
[07:52:03] Beirdo: we can't control what github sends us, but we can certainly filter it
[08:07:30] wagnerrp: xris: would this smolt stuff be run for each machine? or once for a whole mythtv system?
[08:11:14] Beirdo: I would expect once per machine
[08:11:34] Beirdo: including backend machine (esp. if we want tuner hardware stats)
[08:12:43] Kunalagon (Kunalagon!~Kunalagon@212.200.240.13) has joined #mythtv
[08:13:11] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has joined #mythtv
[08:30:44] florian220788 (florian220788!~florian@dslb-092-073-117-068.pools.arcor-ip.net) has joined #mythtv
[08:31:55] florian220788 (florian220788!~florian@dslb-092-073-117-068.pools.arcor-ip.net) has quit (Client Quit)
[08:46:36] Goga777 (Goga777!~Goga777@shpd-92-101-152-51.vologda.ru) has joined #mythtv
[08:49:16] xris: monthly per machine
[08:49:27] xris: it passes back a uuid so you can keep track of your profile
[09:05:56] Beirdo: the only thing that uses FIFOWriter is transcode... OK
[09:07:28] Beirdo: that means I get to test it using nuvexport, I guess
[09:08:22] xris: heh
[09:08:46] xris: yeah, that was added because things couldn't understand cutlits.. or nuv. or both.
[09:09:10] Beirdo: yup
[09:09:27] Beirdo: it's just next on my hitlist to test after pthreads->QThread
[09:09:41] Beirdo: so was looking at how to put it through its paces
[09:45:00] stuartm: wagnerrp: seems the commit hook is specifying it's own resolution instead of using the default 'fixed' vs 'Fixed'
[09:46:46] davide (davide!~david@host137.12.intrusion.com) has joined #mythtv
[09:48:20] Kunalagon (Kunalagon!~Kunalagon@212.200.240.13) has quit (Quit: Leaving.)
[09:51:05] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 272 seconds)
[09:57:59] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:05:02] mike|33 (mike|33!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[11:05:57] mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[11:22:55] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has quit (Ping timeout: 272 seconds)
[11:38:18] andreax (andreax!~andreaz@p57B950EA.dip.t-dialin.net) has joined #mythtv
[11:49:41] andreax (andreax!~andreaz@p57B950EA.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[11:54:50] Goga777 (Goga777!~Goga777@shpd-92-101-152-51.vologda.ru) has quit (Quit: Leaving)
[12:02:54] andreax (andreax!~andreaz@p57B950EA.dip.t-dialin.net) has joined #mythtv
[12:06:36] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has joined #mythtv
[12:34:31] martin_ (martin_!~quassel@h-39-23.A155.priv.bahnhof.se) has joined #mythtv
[12:42:14] paul-h_: Looks like the plugin compiler warnings count has suddenly shot up
[12:42:57] paul-h_: jya: ^ all of them in audioutput.h
[12:45:11] paul-h_: jya: also some new ones in spdifencoder.cpp
[13:33:26] SteveGoodey (SteveGoodey!~steve@host86-148-198-164.range86-148.btcentralplus.com) has joined #mythtv
[13:42:10] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Quit: Leaving.)
[13:43:49] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[13:49:56] Kunalagon (Kunalagon!~Kunalagon@212.200.240.13) has joined #mythtv
[13:52:32] danielk22: Beirdo: fantastic!
[14:07:27] Captain_Murdoch: jya, Beirdo, xris, wagnerrp, 2009 was the last time I worked on that patch to break out the nuppel writer out of NVR into AVFormatWriter, NuppelWriter, and FileWriterBase. At the time, I was using mythtranscode to generate flv, mp4, mpeg-ts, mpeg-ps, and nuv containers with various video and audio codecs including h264, aac, mp2, mp3, mpeg2video, and for some reason I think even ac3. as my need/desire to transcode grew less an
[14:07:28] Captain_Murdoch: d less it moved down my priority list. main interest now would be to encode for my iPods, etc..
[14:08:18] Captain_Murdoch: jya, the current nuppel format does support AC3 as well, that's audio comptype 'A', mp3 is '3'.
[14:08:49] Captain_Murdoch: jya, the encoder doesn't support ac3, adding it to the decoder was part of what I was working on at the time, but I never hooked it up in the encoder side.
[14:11:24] Captain_Murdoch: and mythranscode doesn't support it. I did play around with NVR supporting it though I believe. I believe we used to use lame to decode audio and I switched that to using libav* so we could support ac3. the main reason for that was the intention to keep the original audio when converting to nuv in mythtranscode, but never got that far.
[14:13:11] ** Captain_Murdoch needs to read and reply on that thread. **
[15:06:20] stuartm: jya: http://code.mythtv.org/buildbot/builders/mast . . . ings%20(105)
[15:21:43] Kunalagon (Kunalagon!~Kunalagon@212.200.240.13) has quit (Quit: Leaving.)
[15:38:19] paul-h_ is now known as paul-h
[16:02:07] mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[16:04:27] mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Ping timeout: 240 seconds)
[16:32:36] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds)
[16:35:24] SteveGoodey (SteveGoodey!~steve@host86-148-198-164.range86-148.btcentralplus.com) has quit (Remote host closed the connection)
[16:36:27] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has quit (Ping timeout: 240 seconds)
[16:39:54] imperfect- (imperfect-!~tbw@38.109.189.31) has joined #mythtv
[16:40:02] imperfect- (imperfect-!~tbw@38.109.189.31) has left #mythtv ()
[18:19:09] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has joined #mythtv
[18:20:53] okolsi: paul-h_: when mythbrowser is used, mouse cursor becomes visible and is seen even on top of video playback
[18:22:17] okolsi: paul-h_: any idea if mythbrowser tries to hide mouse cursor when it is closed? if so, it doesn't seem to work
[18:57:59] Goga777 (Goga777!~Goga777@shpd-92-101-152-51.vologda.ru) has joined #mythtv
[19:29:32] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[19:45:35] jcarlos_ (jcarlos_!~quassel@85.137.96.30.dyn.user.ono.com) has quit (Read error: Operation timed out)
[19:46:51] jcarlos_ (jcarlos_!~quassel@85.137.96.30.dyn.user.ono.com) has joined #mythtv
[19:57:08] robacarp_ (robacarp_!~xbmc@c-76-120-80-221.hsd1.co.comcast.net) has joined #mythtv
[19:57:54] robacarp_: hi. so, does mythtv work as a media center _without_ the tv part?
[20:11:59] justinh: robacarp_: try #mythtv-users, like the channel topic says
[20:17:41] Dave123-road (Dave123-road!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Read error: Connection reset by peer)
[20:17:42] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Read error: Connection reset by peer)
[20:17:59] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[20:18:23] Dave123-road (Dave123-road!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[20:20:40] stoffel (stoffel!~quassel@p57B49F4E.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[20:20:53] paul-h: okolsi: its working as it should here with the cursor visible when over the web browser widget and automatically hiding after a few seconds everywhere else
[20:22:28] paul-h: I think stuartm added some code to make the cursor visible when moved and to auto hide when stationary for a few seconds, maybe that is what you are seeing?
[20:28:23] robacarp_ (robacarp_!~xbmc@c-76-120-80-221.hsd1.co.comcast.net) has quit (Ping timeout: 240 seconds)
[21:02:36] jya: stuartm: that url gives me no such child resource
[21:03:06] jya: ah got it
[21:10:58] jya: stuartm: that's one dumb warning... of course the parameter is unused ; it's the definition of the function only
[21:16:48] jya: stuartm: old are those warnings? the word "digital" isn't even used in audiooutput.h ; and the lines don't match
[21:18:54] stuartm: jya: current master, the line numbers match up with my copy
[21:19:09] jya: they don't match mine
[21:19:21] jya: latest build is 553
[21:19:27] jya: and those warnings aren't there anymore
[21:19:56] jya: you should update your copy :P
[21:20:32] jya: ah I'm on 0.24 , duh
[21:21:19] jya: those warnings are dumb anyway, it would make me change the header so arguments aren't named
[21:22:43] jya: and I wouldn't be able to set default value for the parametres
[21:22:47] Goga777 (Goga777!~Goga777@shpd-92-101-152-51.vologda.ru) has quit (Ping timeout: 240 seconds)
[21:23:22] stuartm: jya: it's complaining because they aren't used in the inline versions found in audiooutput.h – just cast them to void or something in those inline instances
[21:23:34] jya: of course they aren't used.. it's a HEADER
[21:23:50] stuartm: no, there are definitions in that header
[21:24:15] stuartm: { return new AudioOutputSettings; } etc
[21:24:52] jya: sure, I don't want them to be pure virtual. as it would mean they have to be reimplemented in all subclasses
[21:25:29] jya: but the "warning" you are referring to; aren't on those lines
[21:27:10] ** jya needs to find the pragma to remove those warnings.. **
[21:27:30] stuartm: yeah, but that's what those warnings are getting at – you have an implementation of those functions which ignores the arguments and gcc assumes that arguments are there for a reason, hence ignoring them is likely a mistake
[21:28:36] stuartm: jya: MUNUSED might do it
[21:29:19] jya: I can't remove that definition without breaking the redfinition in aobase.cpp
[21:30:30] stuartm: you don't need to
[21:31:06] stuartm: elsewhere we just "(void) digital;" or similar in the body of the function to silence those warnings
[21:34:11] stuartm: jya: I'll do it
[21:34:19] jya: no please
[21:36:10] danielk22: There are two easy ways to get rid of those warnings.. "(void) param_name;" in the function or "/*param_name*/" in the declaration. We use the former more often in MythTV. But I don't know of any real downsides to the latter method.
[21:37:02] jya: danielk22: I find the later more elegant
[21:38:45] clgshaft (clgshaft!~clgshaft@S0106000fea530200.cg.shawcable.net) has joined #mythtv
[21:38:50] clgshaft (clgshaft!~clgshaft@S0106000fea530200.cg.shawcable.net) has left #mythtv ()
[21:40:37] stuartm: gigem: thanks for committing that, it's been a real thorn in my side for a very long time, I believe danielk22 had some changes in his recorder branch which go a little further but a fix in master is worth two in a branch (or something)
[21:44:22] danielk22: stuartm: Some of that looks familiar to my changes in the mythtv-rec branch, but it does look a bit more comprehensive.
[21:45:21] danielk22: I have noticed some discussions in users on things that are fixed in the branch, but until I've pushed the db change I'm keeping those on the down low ;]
[21:45:59] stuartm: :)
[21:46:21] stuartm: gigem: are you planning to backport that commit?
[21:46:40] wagnerrp: stuartm: pretty sure he already did
[21:47:56] stuartm: danielk22: just the other night I lost a recording to a driver/recorder glitch, so I'm looking forward to improvements, especially retry attempts if we fail on the first go
[21:48:20] stuartm: wagnerrp: so he did, I need to pay closer attention
[21:49:02] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[21:49:34] jya: Captain_Murdoch: As I wrote earlier; add new codec support to NUV is quite easy ; and would be a quick way to add audio passthrough to transcoding. But a better solution would be to generate a mkv or use a mp4 container (for use with iPod/iPhone)
[21:49:56] jya: but I'm interested in what you had done already ;
[21:50:54] jya: Ok, removed the warning in spdifencoder ; when weak-linking was removed in the header, the actual code wasn't changed
[21:53:28] stuartm: jya: thanks, I know it might seem petty to pick on these warnings but the fewer there are to the more useful they become, no-one wants to read through hundreds of warnings each time to spot the one genuine problem
[21:55:21] stuartm: s/to the/to read, the/
[21:55:25] ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has left #mythtv ()
[21:56:09] ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv
[21:57:12] ThisOtherGuy (ThisOtherGuy!~a@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv
[22:01:58] eharris_ (eharris_!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[22:02:41] ThisNewGuy1 (ThisNewGuy1!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv
[22:02:50] gregL_ (gregL_!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[22:03:01] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[22:03:29] Dave321 (Dave321!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[22:04:33] wylie (wylie!~wylie@ip24-251-22-58.ph.ph.cox.net) has quit (Ping timeout: 240 seconds)
[22:05:37] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Ping timeout: 240 seconds)
[22:05:37] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 240 seconds)
[22:05:37] ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has quit (Ping timeout: 240 seconds)
[22:05:37] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 240 seconds)
[22:05:37] dekarl (dekarl!~dekarl@e180131138.adsl.alicedsl.de) has joined #mythtv
[22:05:38] davide (davide!~david@host137.12.intrusion.com) has quit (Ping timeout: 240 seconds)
[22:05:38] dekarl1 (dekarl1!~dekarl@e180131138.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds)
[22:05:38] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Ping timeout: 240 seconds)
[22:06:47] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv
[22:17:17] jya: stuartm: ok... removed those.
[22:20:35] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[22:20:57] martin_ (martin_!~quassel@h-39-23.A155.priv.bahnhof.se) has quit (Ping timeout: 272 seconds)
[22:23:44] Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has quit (Quit: No Ping reply in 180 seconds.)
[22:24:07] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 272 seconds)
[22:24:11] Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has joined #mythtv
[22:25:06] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[22:27:55] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 272 seconds)
[22:50:01] Dave321 (Dave321!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Quit: Leaving)
[22:50:10] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[22:58:18] jya: stuartm: Should we remove those QWidget deprecated message? I understand why it was made that way , but as obviously no-one is willing to rewrite all of those for MythUI yet ; those messages become annoying background noise
[22:58:51] stuartm: jya: I was just doing that, at least for the stuff which can be safely ignored
[22:59:40] jya: I had started to write the new audio setup screen using MythUI ; but I quickly went back to something more familiar...
[23:04:08] Beirdo: jya: I just compiled your spdif stuff with the ffmpeg sync I have in progress, seems to be good
[23:04:36] Beirdo: on my local setup, I reverted your ffmpeg backports, then applied the sync, and all seems to be OK so far
[23:04:53] jya: Beirdo: yeah, that's expected.
[23:04:53] Beirdo: just thought you might be interested :)
[23:05:01] jya: how old is your ffmpeg version though?
[23:05:09] Beirdo: umm, one sec
[23:05:13] jya: the last DTS-HD bit was committed by Janne only a few days ago
[23:05:41] jya: it's the last 3 SHA in the comment of my commit
[23:05:50] Beirdo: Feb 20
[23:06:19] ikrabbe (ikrabbe!~ingo@pdpc/supporter/professional/ikrabbe) has joined #mythtv
[23:06:32] Beirdo: but that shouldn't take much to resync again
[23:06:35] jya: good, last change I needed was Feb 14
[23:07:17] jya: I don't think a resync from our last version (around august) is going to be anywhere as difficult as the last one
[23:07:33] jya: our changes mpegts wouldn't apply at all then
[23:07:40] Beirdo: yeah, the only parts I'm worried about is mpegts
[23:08:10] Beirdo: it's still a significantly diverged chunk of code
[23:08:23] Beirdo: and our CPU flag stuff needs a once-over too
[23:08:23] jya: yeah, it almost bear no comparison today
[23:09:06] jya: last time, ffmpeg had changed the way timestamp were reported, how interlaced refresh rates were reported (used to be reported in full frame per second)
[23:09:20] jya: that required *heaps* of changes in our code
[23:09:45] jya: did ffmpeg did much change in their version of mpegts?
[23:10:01] Beirdo: a bit of refactoring, but not much
[23:10:29] jya: the only thing that gave me a little bit of grief was that they changed the location of some headers from libavcodec to libavformat
[23:10:42] Beirdo: hehe
[23:10:45] Beirdo: messy
[23:10:59] Beirdo: of course, we did that internally a bit too lately
[23:11:00] jya: other than that, backporting the changes in their muxer code was easy
[23:11:35] jya: TBH, I don't really care about the ffmpeg resync anymore , I have all the stuff I was interested in already :)
[23:11:59] Beirdo: cool. Well, once we sync (assuming we use what I have), it should still be OK
[23:12:02] jya: what new features did they bring it ?
[23:12:24] jya: jannau is okay for you to do the resync ?
[23:12:57] Beirdo: he said that teh ffmpeg-mt stuff should be merged in soon as well
[23:13:28] Beirdo: past that, I don't recall any caveats past the usual that it's a lot of work
[23:13:53] Beirdo: a pile of new filters, it looks like
[23:14:24] Beirdo: and ASS/SSA, and, srt decoding
[23:14:48] Beirdo: SAP mux/demux
[23:14:54] Beirdo: now THAT could be cool
[23:15:02] iamlindoro: ffmpeg-mt has already been merged, it was a number of weeks ago
[23:15:18] iamlindoro: it's just that the multithreaded implementations of useful codecs like H.264/MPEG-2 aren't
[23:15:30] Beirdo: right. Gotcha
[23:15:54] iamlindoro: But you can have all the multithreaded VP3 you want right now ;)
[23:16:11] Beirdo: the WTV (Windows Television) demuxer, I had to disable due to mpegts differences
[23:16:24] Beirdo: which is a new feature they put in
[23:17:07] Beirdo: but once we look over the mpegts stuff in detail, that may just fall out in the wash anyways
[23:17:19] stuartm: Beirdo: http://code.mythtv.org/buildbot/builders/mast . . . nings%20(15)
[23:18:28] Beirdo: hmmm
[23:18:37] Beirdo: you want me to look into some of those?
[23:18:42] Beirdo: wow, down to 15? :)
[23:19:11] stuartm: fixed a couple and the rest were deprecation warnings in code that I'm not concerned about atm
[23:19:46] stuartm: it would be nice to ignore those which don't concern us, the qt and av* warnings
[23:20:07] Beirdo: some of the QT warnings turn out to be important though
[23:20:37] Beirdo: interesting on the tspacket.h
[23:20:43] stuartm: the subscript warnings can be ignored as we're deliberately operating on memory outside the scope of the array (might be a better way of doing that)
[23:21:18] jya: Is Nigel ion IRC ?
[23:21:27] stuartm: the "mythrender_vdpau.cpp" warning is just bizarre
[23:21:32] stuartm: jya: no
[23:21:32] Beirdo: jya: not that I've ever seen
[23:22:10] stuartm: don't think he's been in here more than once or twice in all the years I've been using/working on MythTV
[23:22:50] stuartm: perhaps the last hold-out after we persuaded gigem to join us here ;)
[23:23:43] danielk22: This place is a ghost town when he's up...
[23:24:08] stuartm: Beirdo: I've no idea what danielk22 plans for the dispatchNow() stuff, it's apparently dangerous yet the playback start/end stuff requires events to be delivered immediately
[23:24:20] Beirdo: yeah, I'm not sure what's with that mythrender_vdpau.cpp one
[23:24:39] Beirdo: although I see a pthread_t in there (sigh).
[23:26:00] Beirdo: yeah, Qt tends to bite our butts along with making our lives simpler
[23:26:02] danielk22: dispatchNow() is easy enough to fix. But AFAIK it's only used by MythMusic, and I am not so clear on it's future. Is it really still being maintained?
[23:26:13] Beirdo: :q
[23:26:22] Beirdo: heh, wrong window
[23:26:50] stuartm: danielk22: paul-h is quietly working on porting it
[23:27:12] ikrabbe (ikrabbe!~ingo@pdpc/supporter/professional/ikrabbe) has quit (Remote host closed the connection)
[23:27:42] Beirdo: stuartm: as for the mythplugins warnings... I fought with that first one (with dcraw plugin) for a few hours a while ago.
[23:27:50] Beirdo: I couldn't make it happy
[23:28:18] Beirdo: other than by putting in a bogus prototype
[23:28:26] Beirdo: which we shouldn't need
[23:29:02] Beirdo: I'll try again later, I guess
[23:29:05] stuartm: visualisers are going away AFAIK so that bit can be ignored, that only leaves the avfdecoder stuff – I have a patch for it, but it needs some changes before I commit it again
[23:29:27] Beirdo: I will be quite happy when we can compile warningless :)
[23:31:28] stuartm: well unless we start ignoring certain meaningless errors in the output that might not happen, but we ought to be able to get it down to ~5
[23:31:37] Beirdo: yup
[23:31:58] Beirdo: there are a few we'll have a hard time getting rid of
[23:40:54] stuartm: I'm not about to re-write the packet parsing code, it's one of those areas which could be broken horribly without care and I don't want to get bogged down for the sake of a few warnings
[23:44:34] Beirdo: yeah, not worth the trouble just for the warnings

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