| Wednesday, August 19th, 2015, 00:06 UTC | ||
| [00:06:12] | urlgrey_ (urlgrey_!~urlgrey@199-116-73-2.sfo1.office.zencoderdns.net) has quit (Remote host closed the connection) | |
| [00:20:23] | Roklobsta (Roklobsta!~Roklobsta@colaco9.lnk.telstra.net) has joined #mythtv | |
| [01:04:44] | tgm4883 (tgm4883!uid23806@ubuntu/member/tgm4883) has quit (Quit: Connection closed for inactivity) | |
| [01:06:40] | Roklobsta (Roklobsta!~Roklobsta@colaco9.lnk.telstra.net) has quit (Ping timeout: 245 seconds) | |
| [02:07:23] | amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!) | |
| [02:50:06] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds) | |
| [02:50:32] | peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:50:45] | peper03_ is now known as peper03 | |
| [03:03:27] | dblain_ (dblain_!~dblain@c-73-186-115-133.hsd1.ma.comcast.net) has joined #mythtv | |
| [03:03:45] | dblain_ (dblain_!~dblain@c-73-186-115-133.hsd1.ma.comcast.net) has quit (Changing host) | |
| [03:03:45] | dblain_ (dblain_!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [04:26:48] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has joined #mythtv | |
| [04:28:54] | Warped (Warped!~Warped@unaffiliated/warped) has quit (Quit: ChatZilla 0.9.92 [Firefox 40.0.2/20150812163655]) | |
| [04:40:28] | tgm4883 (tgm4883!uid23806@ubuntu/member/tgm4883) has joined #mythtv | |
| [05:12:39] | Warped (Warped!~Warped@unaffiliated/warped) has joined #mythtv | |
| [06:37:07] | lautriv__: | stuarta, wtf -> [ 15.601] (II) intel(0): [DRI2] VDPAU driver: i915 ??? |
| [08:14:45] | SteveGoodey (SteveGoodey!~steve@host86-151-178-227.range86-151.btcentralplus.com) has joined #mythtv | |
| [08:29:27] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [09:48:12] | lautriv__ (lautriv__!~lautriv@f050081199.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds) | |
| [09:53:32] | stuartm: | intel provide a vdpau interface to their hardware acceleration now |
| [09:54:15] | stuartm: | you need to install the vaapi driver instead |
| [09:54:38] | stuartm: | vaapi-driver-intel vs vaapi-driver-vdpau |
| [09:55:42] | stuartm: | actually, no, wrong packages ... I think, don't use the Intel GPUs on my systems ... |
| [09:57:59] | stuartm: | it gets a bit confusing, there are vaapi libraries which expose a vdpau interface, and vdpau libraries which expose a vaapi interface |
| [09:58:42] | stuartm: | so instead of standardising we have wrappers around different APIs |
| [10:03:31] | warpme: | paul-h: sorry for sporadic communication :-p It looks like I'm trying using IRC as RT mail comm. You know – I'm trying to balance professional familly passion personal lives and resting within 24h.... |
| [10:04:47] | brfranse_ (brfranse_!~brfransen@24-197-130-197.dhcp.spbg.sc.charter.com) has joined #mythtv | |
| [10:04:49] | warpme: | regarding mythmusic jump mainmenu issue: it looks like issue was bad interaction between mythtv and Roger's Siddon private patch |
| [10:06:50] | lautriv (lautriv!~lautriv@f050084089.adsl.alicedsl.de) has joined #mythtv | |
| [10:07:14] | brfransen (brfransen!~brfransen@24-197-130-197.dhcp.spbg.sc.charter.com) has quit (Ping timeout: 244 seconds) | |
| [10:07:15] | warpme: | After removing it all started work OK. I have however Q regarding jump mainmenu and mythmusic playback in background. Namelly whe I'm asking FE to jump to mainmenu – FE goes to mainmenu but with playback in background. May You verify this in Your enviroment? |
| [10:08:09] | gary_buhrmaster (gary_buhrmaster!~garybuhrm@2601:647:4801:98e3:222:4dff:fe51:6728) has quit (Ping timeout: 246 seconds) | |
| [10:09:21] | gary_buhrmaster (gary_buhrmaster!~garybuhrm@2601:647:4801:98e3:222:4dff:fe51:6728) has joined #mythtv | |
| [10:11:43] | warpme: | Also in mythmusic it is not possible to determine via remote control in mythmusic: is it in playback or in pause. I'm missing this possibility as my VoIP function needs to be tightly coordinated with FE (it needs released audio when user decided to pickup incomming call). Is it possible to add "query location" returning status and song? |
| [10:12:54] | warpme: | stuartm: are You referring to vdpau driver with vaapi/gl backend? |
| [10:47:32] | dizygoth (dizygoth!~roger@cpc15-stre5-2-0-cust147.1-1.cable.virginm.net) has joined #mythtv | |
| [10:50:33] | dizygoth: | warpme: "private patch" ? You mean your remote image cache patch ? That shouldn't interfere with music. |
| [10:51:32] | dizygoth: | warpme: Or do you mean those LVR media monitor patches you were using ? I've noticed problems with those... |
| [10:51:36] | warpme: | dizygoth: removing "Fix-unsafe-access-to-mythsocket-loopback-cache.patch" make difference. |
| [10:53:14] | warpme: | it was in 4 patches pack when we were fighting with freezing FE |
| [11:02:19] | dizygoth: | warpme: Strange! That simply fixed a var access outside of a lock. But dump it. I'm not in a position to start delving deeper atm. |
| [11:03:46] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has quit (Ping timeout: 260 seconds) | |
| [11:04:05] | dizygoth (dizygoth!~roger@cpc15-stre5-2-0-cust147.1-1.cable.virginm.net) has quit (Quit: Konversation terminated!) | |
| [11:04:06] | jpabq_ (jpabq_!~quassel@67-0-25-104.albq.qwest.net) has quit (Ping timeout: 240 seconds) | |
| [11:04:37] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 256 seconds) | |
| [11:04:44] | warpme: | dizygoth: fortunatelly BE and FE without this patch not freezing with new mythgallery (atleast not in 100 tests) :-) |
| [11:04:53] | jpabq_ (jpabq_!~quassel@67-0-25-104.albq.qwest.net) has joined #mythtv | |
| [11:53:18] | paul-h (paul-h!~Paul@90.204.198.148) has joined #mythtv | |
| [11:54:23] | paul-h: | warpme: NP I understand I'd probably get the sack if I spent all day every day on IRC :) |
| [11:55:37] | paul-h: | Yes I noticed MythMusic continues to play after a jump point. I haven't changed the behaviour so if that's how it works it always done that I assume |
| [11:56:39] | paul-h: | It would be a simple change to stop playing though so I might just make the change since I don't care either way |
| [11:58:48] | paul-h: | I can see a case were for example you want to start music playing then jump to say MythNews while leaving the music still playing in the background |
| [12:04:54] | paul-h: | As for the getting the music player status I started to add some commands to the network control to control the music player for someone who wanted to add some audio playback stuff for podcasts and audio book feeds etc to MythNetvision but he disappeared before he completed it so there is some commands to start/pause/stop playback etc but not to get the player status by the looks of it |
| [12:05:31] | paul-h: | Should be easy to add |
| [12:17:15] | warpme (warpme!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Ping timeout: 252 seconds) | |
| [12:18:59] | paul-h: | stuartm: any preference for if we stop the music player when a jump point is activated or leave it in whatever state it is in – can't say I'm that bothered either way TBH |
| [12:24:25] | stuartm: | hmm, it could go either way, from a ux perspective, I guess stopping the music is probably the best default, selecting a jumppoint suggests the user wants to change modes – making them stop the music first before navigating would be less intuitive and stopping the music after navigating involves even more key presses and bindings |
| [12:25:43] | stuartm: | I see nothing wrong with making the behaviour configurable though, despite already having too many settings, there are some thing you just cannot decide automatically or based on context |
| [13:16:36] | lautriv: | it's long ago when i used mythmusic ( lost my library on a fire ) but that time it was already selectable if music stops when leaving the menu or not. |
| [13:21:41] | paul-h: | lautriv: yeah you can still choose what to do when the user exits MythMusic normally but what we are talking about is when someone uses a jumppoint is execute to jump to another part of Myth |
| [13:26:35] | paul-h: | In that case you can't ask the user what to do so we either always stop playback or just leave it in the state it is in |
| [13:34:44] | enyc: | dekarl: as superm1 my mistakes ;p learning ;p |
| [14:24:05] | gigem: | lautriv, stuartm: I briefly tried the Intel vdpau support last weekend and didn't get very far with MythTV waiting for something that didn't happen at playback startup. I didn't dig any further, but hope to when I have some time. I vaguely recall jya saying something a while back about the AMD vdpau not working well with MythTV, but I don't remember if he meant the Intel version too. |
| [14:26:45] | enyc: | nvidia vdpau always seems to have been the expected-stable variant... hey-ho! |
| [15:09:02] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv | |
| [15:25:52] | urlgrey (urlgrey!~urlgrey@199-116-73-2.sfo1.office.zencoderdns.net) has joined #mythtv | |
| [15:38:33] | SteveGoodey (SteveGoodey!~steve@host86-151-178-227.range86-151.btcentralplus.com) has quit (Ping timeout: 246 seconds) | |
| [15:38:45] | SteveGoodey (SteveGoodey!~steve@host86-151-178-227.range86-151.btcentralplus.com) has joined #mythtv | |
| [16:13:37] | letifosiferrari (letifosiferrari!~letifosif@c-71-202-215-223.hsd1.ca.comcast.net) has joined #mythtv | |
| [16:13:40] | letifosiferrari (letifosiferrari!~letifosif@c-71-202-215-223.hsd1.ca.comcast.net) has quit (Remote host closed the connection) | |
| [16:14:13] | letifosiferrari (letifosiferrari!~letifosif@216.207.42.140) has joined #mythtv | |
| [16:29:51] | lautriv: | pfff, speaking nvidia and stable in the same breath is like postulating monkeys can drive trucks :o) |
| [16:35:58] | urlgrey (urlgrey!~urlgrey@199-116-73-2.sfo1.office.zencoderdns.net) has quit () | |
| [16:52:56] | paul-h: | I think that is 3000 commits to master since 0.27 :) |
| [16:54:32] | paul-h: | So how do we go one now that gigem has bumped the protocol version in his branch but it isn't in master yet and now I want to bump it in master? |
| [17:34:48] | ** enyc gets into new, deffirene , weird build problems ;p ** | |
| [17:34:54] | enyc: | will collect logs when ready if relevant |
| [17:35:15] | ** enyc looks suspiciously at the check-builddeps line... giving me trouble when all build-deps ARE in there... and wonders how on earth this worked once before ** | |
| [17:37:06] | enyc: | now its' working... /me checks fixes/0.27 branch for changes to this ;p |
| [17:41:07] | ** enyc apparently needs to know how to checkin changes carefulal ywrt master vs fixes/0.27 ** | |
| [17:41:21] | enyc: | in any case.. current bug needs documenting/understanding ... will create full log next =) |
| [17:49:08] | enyc: | is there some session-record type function i can use rather than dumping local terminal ?? |
| [17:49:27] | enyc: | or doing lots of >> logfile 2>&1 etc etc... ? |
| [17:57:32] | enyc: | I'm preety sure this is a mistake ... nedes to specify debian/control.in on the checkbuildeps but I don't understand how the hell it *was* working before! |
| [17:57:45] | ** enyc creates patch anyway and comment on github ** | |
| [17:58:26] | joki (joki!~joki@p5B36D877.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds) | |
| [18:02:18] | gigem: | paul-h: My branch is completely unofficial, so it doesn't count, IMO. However, you can let me merge my branch first, which would make it official. I was going to ask again today anyway since nobody has said anything yet. |
| [18:03:54] | superm1: | enyc: debian/rules update-control-files gets called |
| [18:03:59] | superm1: | which builds debian/control |
| [18:05:09] | joki (joki!~joki@p5B36D64E.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:07:18] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [18:08:15] | enyc: | superm1: yes, but after the check as far as I can see |
| [18:10:34] | enyc: | superm1: I *think* (and seems to fix it for me) as-is, it could just use "dpkg-checkbuilddeps debian/control.in" much the same as the installation-of-build-deps refers to debian/control.in rather than (default) debian/control file |
| [18:11:00] | enyc: | which fails first-time-builds due to the misorder condition |
| [18:11:01] | superm1: | enyc: https://github.com/MythTV/packaging/blob/mast . . . debs.sh#L215 |
| [18:11:08] | superm1: | that all comes before any of the building |
| [18:12:04] | ** enyc hrrms and looks at my copy in fixes/0.27 ** | |
| [18:12:50] | enyc: | superm1: https://github.com/MythTV/packaging/blob/fixe . . . debs.sh#L217 wrong order in there! |
| [18:13:20] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Remote host closed the connection) | |
| [18:13:57] | superm1: | enyc: ah, so a change probably needs to be cherry picked to fixes/0.27 |
| [18:14:40] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [18:15:46] | enyc: | okies, should i try to find it by searching history of master version or what? |
| [18:16:43] | superm1: | enyc: ok i just cherry-picked it |
| [18:16:54] | enyc: | i was looking at recent changes and wasn't finding it |
| [18:16:57] | superm1: | you can git pull and you should get it |
| [18:17:05] | superm1: | it was a commit back from 2013 (found it using git blame) |
| [18:17:27] | enyc: | can you search individual lines moving about or what? |
| [18:18:15] | superm1: | yeah if you run git blame on a file it will show you the most recent commit for that line in the file |
| [18:18:20] | superm1: | it's pretty handy for stuff like this |
| [18:18:23] | enyc: | oooooh |
| [18:18:37] | enyc: | i was shown 'svn blame' r.e. whole file change at previous placement |
| [18:18:50] | enyc: | anyway right, thankyou, not be going mad ;p |
| [18:20:06] | superm1: | sure thing, hopefully not too much more of that will come |
| [18:20:15] | superm1: | try to backport when relevant |
| [18:23:17] | enyc: | im still getting used to this multi-dimensional branch-etc thinking! |
| [18:23:42] | enyc: | when I take a 'fork', that is only of a particular 'branch' ?? or can contain the whole lot and changes need amending in all ?? |
| [18:26:23] | superm1: | yeah when you fork from a branch it only has the changes from that branch |
| [18:26:37] | superm1: | you can cherry-pick refs from another branch though to backport |
| [18:26:51] | superm1: | so for example for that fix i just ran #git cherry-pick b8994f15 |
| [18:27:10] | superm1: | which pulled the commit from master and applied it on my current working branch |
| [18:31:01] | enyc: | oooooooooh |
| [18:31:10] | ** enyc undecrstands now ** | |
| [18:31:15] | enyc: | though will have to try this on another fix etc etc |
| [18:32:05] | enyc: | e.g. if i push-request my ipv6-enable-mysql change and you commit to master... it could later (after agreed testing on migration) be cherry-picked into fixes/0.27 ? |
| [18:36:22] | Chutt__ is now known as Chutt | |
| [18:40:59] | superm1: | yep |
| [18:44:22] | enyc: | right.. given thats' how it works and is simple/working on new installs, I'll make that change to push to master, at least |
| [18:44:36] | paul-h: | gigem: OK I'll wait for you to merge your changes before bumping the protocol |
| [18:46:14] | superm1: | well you still have to worry about people upgrading from 0.27 to 0.28, but i think conffile prompts are more acceptable there |
| [18:46:38] | enyc: | nods |
| [18:46:44] | enyc: | it needs to be done sometime! |
| [18:46:49] | enyc: | but it amy not be an issue and i'll check |
| [18:47:24] | enyc: | but given how ridiculous it is, and no disasters happen whichever you choose i think its better to have in master imho |
| [18:49:03] | enyc: | if it *is* an issue hopefully my debian-friend can advise on a sensible migration approach |
| [18:57:25] | ** enyc supposedly merged upstream changes on masterinto local repostiroy copy, except that its' going ... Your branch is ahead of 'origin/master' by 33 commits. ** | |
| [18:59:00] | ** enyc thinks... can't i just delete my fork somehow rather than resynching ;p ** | |
| [19:01:02] | gigem: | paul-h: Okay. If all goes well, I'll push shortly. |
| [19:27:55] | dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [19:29:53] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 244 seconds) | |
| [19:33:00] | enyc: | which. .. iv'e done now i gant get github auth working ;p lol |
| [19:33:32] | ** enyc try again later and all that! ** | |
| [19:41:19] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has joined #mythtv | |
| [19:41:45] | lautriv: | does a frontend differ somehow between live-tv and recordings ? from its own view it should behave the same ... |
| [20:01:12] | kukks (kukks!~Guenter@samba/team/kukks) has joined #mythtv | |
| [20:12:50] | dekarl1 is now known as dekarl | |
| [20:23:47] | lautriv: | stuarta around ? |
| [20:27:09] | lautriv: | ... or maybe someone else has ab idea ... i talked about that stuttering frontend after upgrade to 0.28, in the meantime i found when playing a recording ( so from TV but not live ) i have solid 29/1 but in that case, neither decoding nor the net gives me a reason ? |
| [20:28:29] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) | |
| [20:34:13] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has joined #mythtv | |
| [20:34:15] | paul-h (paul-h!~Paul@90.204.198.148) has quit (Quit: Konversation terminated!) | |
| [20:37:24] | gigem: | paul-h: Pushed. |
| [21:09:41] | vfw (vfw!~cap@74.113.245.73) has joined #mythtv | |
| [21:10:38] | jya: | gigem: vdpau for AMD works super well. |
| [21:11:53] | jya: | For Intel you're better off using vaapi natively. We have lots of crashes reports in Firefox from people using gstreamer with a va-vdpau plugin. |
| [21:16:59] | gigem: | jya: Bummer! I was hoping there might be an easy way to access the better deinterlacing in the newer Intel chips without having to update our VA-API support. |
| [21:19:02] | jya: | Well, there is a good project for you :) |
| [21:20:00] | jya: | But last year, there was lots of reports that vaapi drivers were very crashy or doing a bad job with the new mode |
| [21:20:33] | jya: | Xbmc was instead extracting the image from the vaapi surface and then doing everything in software |
| [21:21:10] | jya: | If native vaapi drivers don't work well, what chances have va-vdpau to work? |
| [21:30:31] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit () | |
| [22:01:11] | SteveGoodey (SteveGoodey!~steve@host86-151-178-227.range86-151.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:03:38] | Tobbe5178 (Tobbe5178!~asdf@2001:2002:51e1:d8ee:4138:4f3d:4e49:a41f) has quit (Read error: Connection reset by peer) | |
| [22:05:32] | gigem: | Ha ha. I'll get to it right after the myriad other projects in my queue. I thought Kodi was using all of the new vaapi features. I know I tried briefly last Christmas when I got my parents an ASUS ChromeBox to ultimately use as a MythTV frontend. As I recall, it looked pretty good, but I didn't try it for that long. |
| [22:27:22] | enyc: | =) I'm wondering how well likes of Hummingboard-i2ex ARMHF will works as mythtv backend+frontend combined... |
| [22:27:34] | enyc: | will find out someday soon! |
| [22:53:57] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-14-240.lns20.mel4.internode.on.net) has quit (Read error: Connection reset by peer) | |
| [23:01:46] | jpharvey (jpharvey!~jpharvey@host81-152-150-71.range81-152.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [23:04:46] | amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv | |
| [23:08:26] | kukks (kukks!~Guenter@samba/team/kukks) has quit (Ping timeout: 244 seconds) | |
| [23:14:41] | jpharvey (jpharvey!~jpharvey@host81-159-17-130.range81-159.btcentralplus.com) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.