[00:32] <mapota> Hi All, I have mythTV running and am getting some scheduling conflicts. I have three playtv units (with each allowing 4 multirec recordings) so 6 tuners total with 24 if you count the virtuals. I am still getting some conflicts though. I would like to try and determine why. Is there information on what the codes means when using "mythbackend -v schedule"?
[00:35] <mapota> i.e. there is a line in the log "Title - Subtitle       CH Station   Day  Start End    S C I   T N Pri". Some of them are obvious but, I am unsure of S C I T and N!!
[01:02] <Bhaal> Anyone had problems with lirc not responding after a resume?  If I restart lirc then all is good for a little while, but its as if it keeps falling asleep or something...
[01:02] <Bhaal> Uh, I am running mythbuntu 12.04
[01:45] <amejia_> anyone mind telling me where the packaging of mythtv for ubuntu is?
[01:46] <mapota> www.mythbuntu.org has some isos, ubuntu based with mythtv packaged on top
[01:47] <amejia_> i meant where the actual development of the packaging occurs
[01:47] <amejia_> i'm guessing this is it 'bzr branch http://bazaar.launchpad.net/~mythbuntu/mythtv/mythtv-master'
[01:47] <Zinn> [bazaar.launchpad.net] ~mythbuntu/mythtv/mythtv-master : changes
[01:47] <tgm4883> amejia, that's correct
[01:47] <tgm4883> amejia, what are you trying to do?
[01:48] <tgm4883> amejia_, https://code.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-weekly-build might be beneficial for you too
[01:48] <Zinn> [code.launchpad.net] mythbuntu-weekly-build : Code : Mythbuntu
[01:49] <amejia_> tgm4883: well, i would like my name updated in the Uploaders field
[01:49] <amejia_> should now be 'Andres Mejia <amejia@debian.org>'
[01:49] <amejia_> superm1: ^^^
[01:49] <amejia_> i don't have permissions to push anyway
[01:50] <Bhaal> Hmmmm, ok, so I have narrowed lirc crashing down to: irsend timing out sending something
[01:51] <Bhaal> by something I mean one the ir signals
[01:51] <amejia_> tgm4883: i think you had that blueprint open to have xbmc in official ubuntu repos
[01:51] <amejia_> tgm4883: xbmc is already available in the repos
[01:51] <tgm4883> yea I closed that blueprint when I saw you guys get it added
[01:52] <amejia_> ok :)
[01:53] <tgm4883> amejia_, should be fixed in revision 546
[01:54] <amejia_> tgm4883: ok great
[01:54] <amejia_> superm1: tgm4883: ok well i'm getting ready for an upload of mythtv to experimental
[01:55] <amejia_> even though mythtv still uses internal ffmpeg, i think an upload to experimental is fine
[01:55] <amejia_> oh, and i mean Debian experimental
[01:55] <Bhaal> Hmmm, ok problem solved...  Seems irsend didn't like sending the 'power' command with a count of 3...
[01:56] <tgm4883> amejia, make that 547 :)
[01:57] <amejia_> ah i see ok
[01:58] <amejia_> yeah, i think an upload to experimental maybe ok, and you can still sync from there for ubuntu
[01:58] <amejia_> experimental can be used to continue working on mythtv up until mythtv is at least release ready for Debian
[01:58] <amejia_> i.e. it uses system libav instead
[01:59] <amejia_> anyway, i'm not exactly familiar with bzr
[02:00] <amejia_> can you make bzr branches similar to git branches?
[02:01] <tgm4883> amejia_, what do you mean?
[02:01] <tgm4883> i'm not too familiar with git ;)
[02:01] <amejia_> oh man :/
[02:02] <tgm4883> and really, I'm not super familiar with bzr either, I know enough to make my own branches, pull and push changes, etc
[02:02] <amejia_> ok you said your own branches
[02:02] <amejia_> how do you do that?
[02:02] <amejia_> bzr checkout <name of new branch>?
[02:03] <tgm4883> bzr branch <name of branch>
[02:03] <tgm4883> that will make a local copy of the branch
[02:03] <tgm4883> well, make a copy
[02:03] <tgm4883> I haven't tested it, but I don't see why it couldn't be local
[02:04] <tgm4883> yea local works as well
[02:04] <amejia_> anyway to push remotely so that others can see?
[02:04] <tgm4883> bzr push <location to push it>
[02:05] <tgm4883> so if I wanted to push it to my stuff on launchpad, I could do
[02:05] <tgm4883> bzr push lp:~tgm4883/mythbuntu/mythtv-fixes
[02:06] <tgm4883> so tgm4883 would own the branch, it would show up under the mythbuntu project with the name mythtv-fixes
[02:06] <amejia_> how will it be viewable through the web interface?
[02:07] <tgm4883> amejia_, you can view all of my branches here https://code.launchpad.net/~tgm4883 (so anything owned by the user tgm4883)
[02:07] <Zinn> [code.launchpad.net] Code : Thomas Mashos
[02:07] <tgm4883> so see anything owned by the mythbuntu project, it would be
[02:07] <tgm4883> https://code.launchpad.net/mythbuntu
[02:07] <Zinn> [code.launchpad.net] Code : Mythbuntu
[02:08] <amejia_> let's see then
[02:11] <amejia_> excellent
[02:11] <amejia_> and so i (or someone) can pull my changes and merge to the main master branch correct?
[02:12] <tgm4883> yes
[02:12] <amejia_> great
[02:12] <tgm4883> via the web interface, you can request a merge to another branch
[02:12] <tgm4883> I'm unsure if you can do that via the cmd line
[02:14] <amejia_> ok on to something else
[02:14] <amejia_> superm1: tgm4883: this whole thing of wanting to upload at least to experimental came from this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570611#109
[02:14] <Zinn> [bugs.debian.org] #570611 - ITP: mythtv -- A personal video recorder application - Debian Bug report logs
[02:14] <amejia_> i think this would be ok, since it wouldn't be in a security-supported release
[02:15] <amejia_> i would have done this for xbmc but i never thought of it before actually
[02:16] <amejia_> there's another message from Christian Marillat http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570611#104
[02:16] <Zinn> [bugs.debian.org] #570611 - ITP: mythtv -- A personal video recorder application - Debian Bug report logs
[02:16] <amejia_> i saw that the ubuntu packaging of mythtv is also from Matt Zimmerman
[02:16] <amejia_> do you guys derive anything from the mythtv packages in debian-multimedia.org?
[02:16] <Zinn> [debian-multimedia.org] Debian Multimedia Packages::Home
[02:17] <tgm4883> amejia, IDK, superm1 was packaging mythtv for Ubuntu long before Mythbuntu was created
[02:17] <amejia_> ok
[02:18] <amejia_> well i for one don't want to use dmo's mythtv packaging, especially if it's not what's used in ubuntu
[02:18] <amejia_> dmo maintainer, Christian, is quite a character i'm afraid
[04:21] <superm1> amejia: ah interesting
[04:22] <superm1> so our packaging was in line with d-mo for a bit, but there are some patches /changes that christian didn't take so we started to go our separate ways with the packaging
[04:22] <superm1> upstream is in full support of the packaging as it stands for ubuntu right now
[04:23] <superm1> which i don't know can be said the same for d-mo.org's packaging (there was some special patching at one point that caused a world of trouble)
[04:23] <Zinn> [d-mo.org] D-mo
[04:23] <superm1> i'll add you to the uploaders field on both fixes and master
[04:23] <superm1> what you want to upload to experimental is -fixes
[04:24] <superm1> eg http://code.launchpad.net/~mythbuntu/mythbuntu-mythtv-fixes
[04:24] <superm1> to build a tarball from it, call debian/rules get-git-source and you end up with a tarball of the latest release in debian/changelog
[04:29] <tgm4883> superm1, I already added him
[04:29] <superm1> tgm4883: oh ok, thanks
[04:29] <tgm4883> I couldn't remember which control file to add him to, so I did both
[04:30] <superm1> if it makes more sense to move our packaging somewhere else so it's manageable from amejia and other debian maintainers i don't mind doing that as long as we're able to commit to that place too
[04:30] <superm1> and we can keep the split between fixes/master
[04:30] <superm1> i guess if we went to git that wouldn't be so hard to just have branches
[04:31] <superm1> it would be really awesome if we could create a debian PPA too, i wonder if launchpad has that on the roadmap
[06:02] <len> After upgrading to Mythbuntu boxes to 12.04 I stopped being able to use the ctrl+alt+<fx> keys to open virtual terminals on both boxes.  After testing I discovered that if I log out so i'm back at the lightdm login screen they start working again.  They only do not work once I've logged into a graphical session.  I think my problem it that something is capturing my cntrl+alt keys and not letting the ctrl+alt+f1, f2, f3, etc sequences
[06:02] <len> though.  What could be blocking this.  It worked fine on both machines before updating and now works on neither.
[06:04] <len> btw, this only happened on my mythbuntu boxes.  I also upgraded two kubuntu boxes to 12.04 and they can open switch to virtual terminal session while logged into an x-session just like they always could.
[06:04] <len> *two mythbuntu boxes
[06:18] <mycosys> any likely gotchas with http://www.umart.com.au/pro/products_listnew.phtml?id=10&id2=179&bid=2&sid=83154 or with http://www.umart.com.au/pro/products_listnew.phtml?id=10&id2=179&bid=2&sid=84206
[06:18] <Zinn> [www.umart.com.au] Umart Online
[06:19] <mycosys> VIA VT1708S and  ALC887 both likely to be ok with 5.1 audio and upmixing?
[06:20] <mycosys> my sad old nforce4 board isnt :(
[06:20]  * mycosys makes pouty face
[06:21] <mycosys> len pl tell me if u find out what cos i have been tryign to do this for years
[06:22] <mycosys> or even better remap em
[06:23] <mycosys> superm1 any clue?
[06:23] <len> mycosys, you haven't been able to ctrl-alt-<f-key> to a virtual term for years?
[06:24] <mycosys> no - i havent been able to stop it happening
[06:24] <mycosys> you used to be able to move em, but no longer
[06:25] <len> It's always worked for for me on every system I've ever used, except these two mythbuntu boxes after upgrading to 12.04.
[06:25] <mycosys> exactly - read again
[06:25] <len> mycosys, why doen't you want to be able to do that?
[06:25] <mycosys> i have a HID remote whose only failing it thst it has keys for ctrl-alt-f1-4
[06:26] <mycosys> it is MILES better than my wmc remotes
[06:26] <mycosys>  would just love to be able to use those keys, and not have to pull out the kb when i hit em accidentally
[06:26] <len> Hmmm.  I've never seen anything quite like that before.
[06:27] <mycosys> there used to be xserver settings you could use to change it co another combo
[06:27] <mycosys> but they quietly ceased working
[06:29] <len> I only lose the ablilty do switch to virtual consoles will in x-sesson.  As soon as I logout back to lightdm, they start working again.
[06:30] <len> suppose I'll have to just start wacking away daemons one at a time to see if ability comes back.
[06:31] <len> Same thing must be happening to other people two though, 'cause it happened to both my mythbuntu boxes.
[06:32] <len> My guess is they it is happening to a lot of people, but so few people actually use the virtual terms they don't notices they can't activate them.
[06:32] <len> sorry about all the typos
[06:40] <mycosys> Option "VTSysReq" "boolean"
[06:40] <mycosys>     enables the SYSV-style VT switch sequence for non-SYSV systems which support VT switching. This sequence is Alt-SysRq followed by a function key (Fn). This prevents the Xorg server trapping the keys used for the default VT switch sequence, which means that clients can access them. Default: off.
[06:41] <mycosys> but it doesnt work
[06:41] <mycosys> Option "DontVTSwitch"  "boolean"  This disallows the use of the Ctrl+Alt+Fn sequence (where Fn refers to one of the numbered function keys).  That sequence is normally used to switch to another "virtual terminal" on operating systems that have this feature.  When this option is enabled, that key sequence has no special meaning and is passed to clients.  Default: off.
[06:41] <mycosys> also doesnt work propertly
[06:43] <mycosys> but that would kill them entirely, rather than remap
[06:43] <mycosys> is sad that a documented feature just disappeared, but stayed documented lol
[07:03] <len> Well, it must be a new kernel driver for the logitech ex100 keyboard.  I plugged in a regular wired keyboard, and it could get vt's from within an x-session.
[07:03] <len> Both the systems exhibiting his new behavior use logitech ex100 keyboards.
[07:04] <len> I wonder if this is a bug or a "feature"
[07:06] <len> Of course wireless devices have been wacky ever since they move ir  remotes in kernel.
[07:07] <len> Maybe the remapping I had to do to get my remotes working effected the keyboard somehow.
[07:08] <len> mycos, why not just remap the scancodes for the keys causing the problems to other keycodes?
[07:09] <len> I mean mycosys
[07:10] <mycosys> mainly cos i had no idea you could - tho - wouldnt that mean remapping either control, or alt, or the f keys, totally, not just the key combo?
[07:12] <len> Well, I don't see how one key could produce more than one scancode.
[07:13] <mycosys> would be a bit crippling to remap any one of those keys
[07:13] <len> I wasn't talking about remapping any keycodes, just one scan-code.
[07:15] <mycosys> be gentle with my very flu addled brain - i am lost in brain fog
[07:16] <len> It's easy to get lost in scancodes and keycodes.  I don't like dealing with them either.  That is what is such a mess with mythtv now.
[07:16] <len> ir remotes are now being treated as keyboards by the kernel now
[07:17] <len> BUT they are producing scancodes mapped to keycodes > 255
[07:17] <len> which are invisible to X-server.
[07:18] <len> The whole thing gives just about everyone a headache.
[07:19] <mycosys> the system knows nothing about it beintg an IR remote - it is a HID keyboard and mouse combo
[07:19] <mycosys> lirc does not deal with it
[07:20] <len> It's keys still generate scancodes that get mapped to keycodes
[07:20] <len> check out ir-keytable
[07:21] <mycosys> why ir?
[07:21] <mycosys> ir-keytable is for standard lirc remotes
[07:22] <len> It's treated the same as a wireless keyboard, right?
[07:22] <len> has a kernel driver
[07:22] <mycosys> no - it is treated the same as a usb wired keyboard
[07:23] <mycosys> a normal USB HID wired keyboard and mouse
[07:23] <len> Does it have a wire?
[07:23] <mycosys> it works in the bios
[07:23] <len> So do wireless keyboards
[07:23] <mycosys> len - from a logical point of view that is irrelevant
[07:24] <mycosys> what it presents to the system is a USB HID keyboard
[07:24] <mycosys> and mouse
[07:24] <mycosys> nor an IR reciever that lirc could deal with and remap
[07:25] <len> lirc has been depreciated
[07:25] <len> almost everything is being treated like a keyboard now
[07:26] <len> I don't use lirc for any of my remotes
[07:26] <mycosys> you dont get the point?
[07:26] <len> but I can still see what scancodes they are generating with ir-keytable
[07:27] <mycosys> can you see the codes of your wired keyboards?
[07:29] <len> What is the name of this device?
[07:30] <mycosys> wireless remote control for pc windows or somethign of the sort :) appropriately  janglish
[07:30] <mycosys> Bus 002 Device 002: ID 147a:e00d Formosa Industrial Computing, Inc.
[07:32] <mycosys>  Driver Modules: "usbhid"
[07:34] <mycosys> i assume the USB ID is suffcient?
[07:36] <len> You should be able to figure out what it is with that.  udev is detecting it.
[07:37] <len> I've got an actual headache right now though, not just the figurative headache this kind of thing gives me.  :)
[07:38] <mycosys> i have a flu that sees to have roughly halved my IQ lol
[07:39] <mycosys> maybe less than half remaining - who knows
[07:39] <mycosys> almost surprised if i could tie shoelaces atm
[07:39] <len> Luckily I don't know anyone who has the flu right now.
[07:39] <mycosys> guessing ur not in australia lol
[07:40] <len> Oh, I was going to say, It's a bit late in the season, but everything is reverse in your hemi
[07:41] <len> I guess that means you're a little early :)
[07:42] <mycosys> lot o sick people right now
[07:42] <mycosys> ironically - i HAVE had my flu shots
[07:43] <len> hmm, maybe you're ground zero for a new strain ;)
[07:44] <len> I'd better get my head to bed.  Goodnight, and good luck.
[07:45] <mycosys> cheers
[09:55] <dekarl1> amejia: MythTV using system ffmpeg/libav is going to take quite some rewriting due to all the changes to make it work well with continous transport streams which line up with the direction upstream is moving, so I'd not make that a blocker for inclusion... see e.g. http://www.mythtv.org/pipermail/mythtv-dev/2011-March/070626.html
[09:55] <Zinn> [www.mythtv.org] [mythtv] Compiling from source: Myth's own FFmpeg
=== dekarl1 is now known as dekarl
[10:59] <ernstp> Trying to play a dvd and I get  Couldn't find an A/V decoder for: '//dev/sr0'  Unable to open video file.
[15:19] <superm1> dekarl: at the same time, beirdo doesn't want to patch the copied ffmpeg any further.
[15:22] <dekarl> I understood that this is mainly to mpegts.c which now gets swapped out for our custom version and patched up all over the place?
[15:23] <dekarl> So references to mpegts get change everywhere or so
[15:29] <superm1> dekarl: well not absolutely positive - i'll watch this sync that's about to happen soon and see what the commits end up saying
[15:32] <dekarl> sure, I just don't understand that "internal patched up copies of code are evil" stance... if there are copies "just because" then I can see it, but for patched stuff where no one has decided which side of the fork to follow its a bit over the top
[15:39] <superm1>  there's no good way to maintain the security of the code in those instances.  so if someone had an exploit / vulnerability in a part that is not patched up and common you'd have to patch that in all apps with a copy of the code
[15:40] <superm1> so with that thought in mind, there should be pressure to get the delta upstream somehow so you don't "need" your own copy
[15:41] <dekarl> which upstream? the one or the other? ;)
[15:41] <superm1> i think it applies in all cases you take your code from somewhere :)
[15:41] <dekarl> and sure, they have a point
[15:41] <superm1> the same pressure exists within ubuntu when we have a delta from debian
[15:41] <superm1> or from debian when there is a patch to the code they take from a project and package
[15:42] <superm1> i'm sure beirdo is sick of having to do these syncs every cycle and isolating the delta and carrying it forward anyway
[15:42] <dekarl> sure, but up until now its cheaper then rewriting the relevant subsystems
[15:43] <dekarl> so mythtv is getting there, just not instantly
[15:43] <superm1> well and i think it's fine for it to be a long term goal
[15:44] <superm1> and in the end it should make things easier for everyone
[15:45] <dekarl> btw, I had another user test channel icons via storage group succesfully and I tested it myself. so adding MYTHCONFDIR to the wrapper scripts before 0.26 would enable us to change MFDB and mythtv-setup to actually put the icons into the DB in SG style
[15:45] <superm1> cool
[15:46] <superm1> but 0.26 should be web style setup though no?
[15:46] <dekarl> old icons would stay in any either home directory with direct access. so to fix it one would just have to kill the icon column and readd them properly
[15:46] <dekarl> migrating the xmltv grabber configuration files would need some thought, though
[15:47] <dekarl> web setup is "on the list" and we have some of the needed parts in the pipeline on xmltv's side (not everything though)
[15:49] <superm1> i feel like if it's a momumental change like moving to a different storage location, it's best to do a schema change that drops the icon column and requires it to re-populate on the next pull
[15:49] <superm1> once web setup is good  to go
[15:52] <dekarl> hmm, that would force everyone to reselect their icons for possible dozens of channels. When the other option is to just do something if you are actually using a remote frontend (so you gain something in return for your effort)
[15:53] <superm1> hmm i didn't realize people actually customized icons on a per channel basis
[15:53] <dekarl> either way, the interesting piece is how to migrate the xmltv configuration over
[15:54] <superm1> well as it gets closer, i'm fine with adding to the wrapper scripts if you think that's the best way to do it
[15:54] <dekarl> over here I have to always pick some manually because there are no defaults (in part due to no icon being available at all)
[15:54] <superm1> ah
[15:54] <superm1> i'd really like to kill the wrapper scripts at some point though (been a long term goal)
[15:55] <dekarl> so we force a user to click through lots of "no, there really is no icon to pick" stuff
[15:55] <superm1> that requires autodetection working a little bit better, there's a bug or two open on it
[15:55] <dekarl> if there is no gain for the user such a click orgy just stinks :)
[15:55] <superm1> haha right
[15:57] <dekarl> if we move /home/<the frontend user>/.mythtv/*xmltv over to /home/<the backend user>/.mythtv/ unless it already exists there, while at the same time adding the MYTHCONFDIR, that would work. (e.g. as a post-inst step or so)
[15:57] <superm1> well the problem you have there is that it might be a multi-user system
[15:57] <solars> hey, does anyone know a guide/tutorial how to install a Cine CT V6? can't find anything and have no idea how to install it
[15:58] <superm1> so how do you know what the "frontend user" is
[15:58] <dekarl> hmm, when you install mythbuntu, you create a user for autologon with the frontend. is this user stored somewhere?
[15:59] <superm1> ah that's true
[15:59] <superm1> lightdm configuration has that
[15:59] <superm1> so if it's a 0.25->0.26 upgrade, parse lightdm configuration, find that user, test for that directory and move it if so
[16:00] <superm1> or better yet, copy it.  i don't think you're supposed to make "changes" to a login user's home directory from package scripts
[16:00] <dekarl> hmm, the other option would be to do nothing at all, as either the user has manually made the xmltv configuration available to the backend user (via cp / ln or so) or is not using xmltv at all :)
[16:00] <dekarl> or the user runs mfdb via cron, etc. pp.
[16:01] <dekarl> hmm, we'd break the latter case when mfdb suddenly looks in /home/mythtv instead of /home/<user>
[16:02] <superm1> people aren't supposed to run mfdb via cron i thought
[16:03] <superm1> i thought it's spawned directly by the backend
[16:03] <dekarl> there are guides out there that suggest to install a cronjob instead of letting the backend do the right thing
[16:03] <superm1> well no need to encourage bad recommendations :)
[16:04] <dekarl> some of them are related to mc2xml (Yuck) others a related to combining multiple grabbers and postprocessing the output
[16:04] <superm1> well anything that helps break mc2xml i'm on board with anyway
[16:04] <dekarl> the latter ones are legitimate but I don't expect there are many of them
[16:05] <superm1> well people doing stuff like that are already doing manual things
[16:05] <dekarl> I keep preaching "write a grabber as small wrapper around you static file" and similar, fueling that fire a bit is not wrong either :D
[16:05] <superm1> they expect to have to update things manually when they upgrade and things break
[16:05] <dekarl> thats true
[16:06] <superm1> so you add a release note saying if you do this annoying postprocessing things with multiple grabbers, you might need to manually migrate blah blah
[16:08] <dekarl> hmm, on the other hand they do run mfdb --file <file> instead of letting it spawn a grabber with a config... so no worries there
[16:08] <dekarl> which is quite cool as it might actually work without breaking systems
[16:10] <superm1> in the end it's just icons anyway if it does break.  i don't think i've ever had functional icons
[16:10] <dekarl> so we don't have to copy anything. either they setup a manual job in parallel to the automatic one and its working before and after, or they did not and its not working before and after. very simple
[16:11] <superm1> cool
[16:11] <dekarl> just adding MYTHCONFDIR any time sounds possible :)
[16:12] <dekarl> and once that change is in we can fix MFDB/setup anytime, improving new installs or reconfigurations of old install, but not breaking running setup. (I think we have discussed all variants)
[16:13] <superm1> so you want to see this happen on 0.25-fixes too?
[16:13] <dekarl> the only thing left out is installations that don't run MYthbuntu packages, but thats off topic here :D
[16:13] <dekarl> I think it is safe to change it in 0.25-fixes
[16:13] <superm1> but it won't actually do anything in 0.25-fixes right?
[16:14] <dekarl> we should look at the schedulesdirect use case, I'm not sure if they drop files somewhere
[16:15] <dekarl> the wrapper scripts check for mythtv group membership already? and that could be extended to fixup permissions of MYTHCONFDIR to allow group write for icons, correct?
[16:17] <superm1> mmm i'd rather do that in a postinstall script for mythtv-common
[16:17] <amejia> superm1: well, i think you should consider moving the packaging stuff to github under mythtv/packaging (that is if you do move)
[16:18] <amejia> superm1: also, debian has a ppa like site coming up based on debexpo
[16:18] <amejia> superm1: at least i heard of debexpo, i don't really follow that however
[16:18] <superm1> amejia: oh cool on ppa
[16:19] <dekarl> superm1: sure, post-install would work, too.
[16:19] <superm1> amejia: well we have a script there under mythtv/packaging right now, but it pulls from bzr and is tightly integrated into our autobuild system
[16:19] <amejia> superm1: xbmc has something similar, the debian dir and a script are in a repository
[16:20] <superm1>  i'll need to do some feasibility checks to see what happens if we lose bzr
[16:20] <amejia> superm1: the script pulls mainline and that's how nightlies are built from master branch
[16:20] <amejia> just saying anyway
[16:20] <superm1> yup same basic thing then
[16:20] <amejia> superm1: and about dmo packages, figured i should stick with ubuntu packaging of mythtv
[16:21] <superm1> cool, obviously would much prefer that :)
[16:21] <amejia> superm1: yeah, plus i've seen some changes done on some of the dmo packages
[16:21] <amejia> christian for some reason thinks it's ok to patch upstream sources without going through upstream themselves
[16:22] <amejia> i've seen some changes to ffmpeg that weren't even discussed upstream
[16:22] <superm1> yeah that's exactly why upstream mythtv got really pissed at bugs coming from his packages
[16:22] <amejia> ok, so mythtv upstream hates dmo too then
[16:22] <amejia> figures
[16:22] <amejia> all of videolan hates dmo as well
[16:23] <superm1> "dont bite the hand that feeds you"
[16:24] <amejia> idk, it's been long suspected christian's using his dmo site to raise money for himself
[16:24] <amejia> and does absolutely nothing for debian or the debian-multimedia team doing packaging in debian
[16:25] <superm1> that's too bad to hear
[16:25] <superm1> amejia: will a build from experimental use the same GCC-4.7 toolchain that quantal is using right now?
[16:26] <dekarl> superm1: I'll be away for a bit doing household and so ;) see you later
[16:26] <superm1> dekarl: ok cya
[16:26] <amejia> superm1: i'm not sure, i think the toolchain is still the one from unstable
[16:27] <superm1> ah ok.  well if it ends in ftbfs similar to this (http://goo.gl/elSAn) it's a known issue right now.  http://code.mythtv.org/trac/ticket/10537
[16:27] <Zinn> [goo.gl] N/A
[16:28] <amejia> ok thanks for the heads up
[16:28] <superm1> there's an ffmpeg patch, but beirdo wants to resync master before he starts adding delta's to ffmpeg
[16:30] <amejia> superm1: any decision on whether it's libav or ffmpeg?
[16:30] <superm1> amejia: yeah they're going ffmpeg
[16:30] <amejia> :(
[16:31] <superm1> there was a discussion about it a week or so ago
[16:33] <amejia> superm1: was it irc or mailing list?
[16:33] <superm1> amejia: IRC
[16:33] <superm1> i happened to ping you on the date it was being discussed
[16:34] <superm1> looks like google didn't index their logs yet though
[16:36] <superm1> amejia: here ya go
[16:36] <superm1> http://irc.mythtv.org/ircLog/channel/4/2012-04-12
[16:36] <Zinn> [irc.mythtv.org] Beirdobot, irc.freenode.net :: #mythtv
[16:36] <superm1> i was originally asking about libhdhomerun, but the conversation went into ffmpeg
[16:41]  * amejia sighs
[16:41] <amejia> superm1: i'll worry about that later
[16:41] <amejia> superm1: the first step would be to see if i can get mythtv in debian experimental at least
[16:41] <superm1> Ok
[16:41] <amejia> superm1: btw, does mythtv have an openssl exception?
[16:42] <superm1> rhpot1991 has good contacts with silicon dust, so i bet libhdhomerun will be sortable
[16:43] <superm1> amejia: no it doesn't
[16:45] <amejia> superm1: i think i'll just do a lintian override on that one
[16:46] <amejia> superm1: since it links to the openssl shared library (not bundles it) from what i've seen
[16:46] <superm1> right
[16:46] <superm1> ok, until we have a comon packaging place, feel free to just do a bzr merge request
[16:46] <amejia> ok
[16:49] <amejia> superm1: what's the difference between master and fixes?
[16:52] <superm1> amejia: fixes tracks the current stable git branch (0.25-fixes)
[16:52] <superm1> master tracks the master development git branch (master
[16:52] <superm1> you'll want to upload 0.25-fixes branch to debian, not the master branch
[19:18] <solars> can anyone tell me how to install a cine ct v6? can't find anything useful
[19:22] <solars> not sure if there are drivers in the kernel, loaded, or if I have to compile them
[19:27] <MTughan> All right, so I've got our database mostly restored (turns out I had grabbed too new a backup, which was actually from after the reinstall), so I have most of my programs now. But audio out doesn't seem to work.
[19:28] <MTughan> We have our output from the built-in audio chipset, running optical from the motherboard to our receiver. I got audio to work using the PulseAudio manager (this is Mythbuntu 12.04), but it's only outputting stereo right now. MythFrontend is configured to output 5.1, so I think the problem's in PA. Is there something I'm missing in the configuration?
[19:31] <MTughan> Nvm, was using the wrong device in MythTV. (needed ALSA:iec958 instead of PulseAudio:default)
[19:35] <MTughan> Now, the other problem we're having: no previews show up in MythWeb. Apache says it's returning ~450 bytes per preview, which sounds too small for an image to me.
[19:36] <MTughan> Pulling it up manually through telnet returns what Apache says is a text/html document, but it has no content. So something's amiss there.
[19:37] <MTughan> Heh… And reading through the headers, something else is definitely up. Apache returns HTTP 200 (OK), but there's a header that says "Status: 404 Not Found".
[20:56] <nycvelo> After upgrading from Mythbuntu 11.10->12.04 LTS, playback of recordings is very green, almost like there's no red in the video. Video was fine in 11.04. How to remedy?
[21:28] <nycvelo> OK, found the fix: Press F multiple times during video playback until "Hue", then change setting from 0% to 50%. (0% is a bad default! It should be 50% in 12.04)
=== MTughan_ is now known as MTughan
[22:36] <superm1> amejia_: i did a bit of an experiment, and I think with a few simple changes to our autobuilds infrastructure, should be able to support packaging at github instead.  thoughts on it being organized like this though: https://github.com/superm1/packaging/tree/fixes/0.25 ?
[22:36] <Zinn> [github.com] superm1/packaging at fixes/0.25 · GitHub
[22:36] <superm1> basically in deb/ is the helper script that will build debs or dsc's, and it just uses the packaging in deb/debian
[22:37] <superm1> so if you are doing a fixes/0.25 build, you checkout packaging-scripts's fixes/0.25 branch, if doing master, checkout out packaging-script's master branch
[22:39] <amejia_> superm1: well i just barely started looking at how packaging is done for mythtv
[22:39] <amejia_> superm1: i don't think i can have much of an opinion about it
[22:39] <superm1> Okay
[22:41] <amejia_> superm1: seems fine though, and probably best if the packaging is all done at github... IMO
[22:42] <amejia_> i suppose you should have people cloning/mirroring the entire packaging for debian, without worrying about cloning/mirroring the stuff at another site as well (i.e. launchpad)
[22:42] <superm1> cool yeah i like having it be the defacto place for all things deb then rather than ubuntu's launchpad.  the only annoying thing i find with doing it this way is when actually uploading packages, the debian/ directory isn't going to be in VCS control while building an actual package to go into debian or ubuntu
[22:43] <superm1> unless you hardlink/symlink your working directory to that from the packaging directory
[22:43] <superm1> whereas right now we have overlapping VCS with bzr and git in the same directory (git for upstream mythtv src, bzr for mythtv packaging)
[22:45] <amejia_> hmmm
[22:45] <amejia_> maybe you want to look at git submodules for that
[22:46] <amejia_> then again, i don't know enough about how the packaging is done :/
[22:46] <superm1> i'll read up on them and see
[22:48] <superm1> how do you manage it on xbmc?
[22:52] <superm1> looking over https://github.com/xbmc/xbmc-packaging it seems like you just have a debian/ top level directory in the packaging and copy debian/ in to the build directory if i'm reading right, so that's actually pretty close to what would be done here
[22:52] <Zinn> [github.com] xbmc/xbmc-packaging · GitHub
[23:43] <munson> hello all fresh install and upgraded distro and it rebooted and now what i seem to be doing is creating a device then scan the channels on the hvr-1600...anyone have that and remember what was needed cuz fetching channels doesn't work at all, click it and nada
[23:44] <munson> capture car is the dvb dvb capture card
[23:46] <amejia_> superm1: that's right
[23:46] <amejia_> superm1: essentially xbmc repository is cloned into that directory
[23:46] <amejia_> superm1: there's options in the script to clone from a different repository, use a different branch, use a different revision, etc.
[23:47] <amejia_> from there the upstream source is copied and the directory is copied to the source tree
[23:47] <amejia_> and the orig tarball is generated