| Monday, January 11th, 2016, 00:06 UTC | ||
| [00:06:46] | cybrNaut (cybrNaut!cybrNaut@mail.bbis.us) has joined #mythtv | |
| [00:28:33] | kukks (kukks!~Guenter@samba/team/kukks) has quit (Quit: Going home ...) | |
| [00:41:32] | gregbert (gregbert!80630232@unaffiliated/gregbert) has quit (Ping timeout: 272 seconds) | |
| [00:43:03] | gregbert (gregbert!~gregbert@gateway/vpn/privateinternetaccess/gregbert) has joined #mythtv | |
| [00:53:14] | gregbert (gregbert!~gregbert@gateway/vpn/privateinternetaccess/gregbert) has quit (Ping timeout: 255 seconds) | |
| [00:55:06] | gregbert (gregbert!f9a1075d@unaffiliated/gregbert) has joined #mythtv | |
| [01:12:48] | Casper0082 (Casper0082!~Casper@pool-96-245-231-186.phlapa.fios.verizon.net) has joined #mythtv | |
| [01:12:48] | kc (kc!~Casper@unaffiliated/kc) has quit (Read error: Connection reset by peer) | |
| [01:12:54] | Casper0082 is now known as kc | |
| [01:13:08] | kc (kc!~Casper@pool-96-245-231-186.phlapa.fios.verizon.net) has quit (Changing host) | |
| [01:13:08] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [01:21:06] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [01:24:11] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 276 seconds) | |
| [01:26:26] | knightr_ is now known as knightr | |
| [01:29:49] | arescorpio (arescorpio!~arescorpi@247-42-16-190.fibertel.com.ar) has joined #mythtv | |
| [01:53:04] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has joined #mythtv | |
| [01:54:53] | pvr4me: | jya: re #12596, I’m here if you want to discuss |
| [01:54:53] | ** MythLogBot http://code.mythtv.org/trac/ticket/12596 ** | |
| [01:59:09] | cybrNaut (cybrNaut!cybrNaut@mail.bbis.us) has quit (Changing host) | |
| [01:59:10] | cybrNaut (cybrNaut!cybrNaut@unaffiliated/cybrnaut) has joined #mythtv | |
| [02:26:59] | cybrNaut: | running "mythfrontend" forces me into an endless configuration loop |
| [02:27:28] | cybrNaut: | i tried deleting ~/.mythtv |
| [02:36:57] | pvr4me (pvr4me!~craigtrel@d24-150-182-175.home.cgocable.net) has quit (Quit: pvr4me) | |
| [03:00:03] | Roklobotomy (Roklobotomy!~blah@ppp118-209-87-144.lns20.mel4.internode.on.net) has joined #mythtv | |
| [03:25:07] | amessina (amessina!~amessina@unaffiliated/amessina) has quit (Quit: Konversation terminated!) | |
| [03:49:38] | Roklobotomy (Roklobotomy!~blah@ppp118-209-87-144.lns20.mel4.internode.on.net) has quit (Read error: Connection reset by peer) | |
| [03:54:36] | andreaz (andreaz!~andre_000@p4FC56A39.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [04:44:11] | arescorpio (arescorpio!~arescorpi@247-42-16-190.fibertel.com.ar) has quit (Remote host closed the connection) | |
| [04:44:35] | joki (joki!~joki@p5B36D868.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [04:49:58] | joki (joki!~joki@91.54.197.238) has joined #mythtv | |
| [06:17:12] | Roklobotomy (Roklobotomy!~blah@ppp118-209-87-144.lns20.mel4.internode.on.net) has joined #mythtv | |
| [08:51:48] | dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [08:55:17] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 276 seconds) | |
| [08:59:17] | willcooke (willcooke!~willcooke@willcooke.plus.com) has joined #mythtv | |
| [08:59:17] | willcooke (willcooke!~willcooke@willcooke.plus.com) has quit (Changing host) | |
| [08:59:17] | willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has joined #mythtv | |
| [09:07:24] | stuarta: | morning all |
| [09:42:32] | Roklobotomy (Roklobotomy!~blah@ppp118-209-87-144.lns20.mel4.internode.on.net) has quit (Remote host closed the connection) | |
| [09:57:10] | Tobbe5178 (Tobbe5178!~asdf@h232n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [10:01:12] | aloril (aloril!~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) has quit (Ping timeout: 265 seconds) | |
| [10:04:42] | aloril (aloril!~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) has joined #mythtv | |
| [10:09:15] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Quit: system upgrade) | |
| [10:38:32] | SteveGoodey (SteveGoodey!~steve@host109-156-128-140.range109-156.btcentralplus.com) has joined #mythtv | |
| [11:36:51] | stuarta (stuarta!~stuarta@callisto.squashedfrog.net) has joined #mythtv | |
| [11:36:51] | stuarta (stuarta!~stuarta@callisto.squashedfrog.net) has quit (Changing host) | |
| [11:36:51] | stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv | |
| [11:56:05] | lautriv_ (lautriv_!~lautriv@f050082231.adsl.alicedsl.de) has joined #mythtv | |
| [11:56:06] | lautriv_ (lautriv_!~lautriv@f050082231.adsl.alicedsl.de) has quit (Changing host) | |
| [11:56:06] | lautriv_ (lautriv_!~lautriv@funtoo/user/lautriv) has joined #mythtv | |
| [11:59:44] | lautriv__ (lautriv__!~lautriv@funtoo/user/lautriv) has quit (Ping timeout: 245 seconds) | |
| [12:48:40] | ** stuarta sighs ** | |
| [12:54:52] | skd5aner (skd5aner!~skd5aner@54.sub-70-198-73.myvzw.com) has quit (Read error: Connection reset by peer) | |
| [13:38:18] | cbovy (cbovy!~cbovy@212.84.139.221) has joined #mythtv | |
| [13:54:17] | cbovy: | hi all, ran into issue while testing 0.28 with multiple IPTV recorders. working smooth in 0.27.5. |
| [13:54:36] | stuarta: | raised a ticket? |
| [13:54:55] | cbovy: | will do, but would like to debug it in more detail. |
| [13:55:05] | stuarta: | sure, that would be good :) |
| [13:55:08] | stuarta: | what's it doing? |
| [13:55:40] | cbovy: | multiple freebox recorders, connected to one source. in 0.27.5 i can schedule overlapping recordings, and will record on different recorders. |
| [13:55:54] | cbovy: | same setup in 0.28 gives conflict, although free recorders available. |
| [13:56:19] | cbovy: | how to debug and check for free recorders? |
| [13:56:19] | stuarta: | hmmm, interesting |
| [13:56:53] | cbovy: | one thing what got my attention was the multirec introduced in 0.28 for freebox recorder. |
| [13:57:46] | stuarta: | so do you have it configured as multiple independent recorders now (and for 0.27) |
| [13:58:19] | cbovy: | yes, I have. |
| [13:58:38] | cbovy: | just did an upgrade. no reconfiguration. |
| [13:58:57] | dmfrey (dmfrey!~dmfrey@68.170.18.123) has joined #mythtv | |
| [13:59:50] | cbovy: | to I wanted to debug the scheduler(?) if that is the right place to look, but the schedule debug flag doesn't give me any clue. |
| [14:03:50] | stuarta: | it's more likely in the logic that decides if a tuner is free |
| [14:04:06] | stuarta: | but still why it should not pick an "independent" tuner is odd |
| [14:10:53] | cbovy: | there has been some changes in the capturecard table (parentid etc). I'm not sure if it is related to that. |
| [14:13:01] | stuarta: | gigem: ^^^ any theories? |
| [14:25:34] | cbovy: | any lead where the status of tuner free is kept/to be able to debug? |
| [14:25:55] | stuarta: | it's dynamic AFAIK, since livetv could be being used |
| [14:26:02] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Quit: Leaving) | |
| [14:27:03] | cbovy: | ok |
| [14:39:29] | stuarta: | sheesh, took a while to build master on my dev/prod backend, 103 minutes with a clean ccache |
| [14:49:03] | jheizer_ (jheizer_!~jheizer@75-132-131-64.dhcp.stls.mo.charter.com) has joined #mythtv | |
| [14:52:06] | jheizer (jheizer!~jheizer@c-73-51-93-177.hsd1.il.comcast.net) has quit (Ping timeout: 240 seconds) | |
| [14:55:17] | cbovy: | stuarta: I'll create a ticket. Can't find any clue in logging, even with 'most'. |
| [14:55:51] | stuarta: | cheers |
| [15:00:32] | stuartm: | any techniques to unmerge a branch? The branch in question contains commits made both before and after the changes in the branch it was merged into |
| [15:01:05] | stuartm: | it basically seems very difficult, if not impossible to do and has side effects if it's done |
| [15:01:39] | stuartm: | which would make this a colossal screw up – assuming I can't fix it |
| [15:12:05] | hackman42 (hackman42!~Adium@66.43.16.227) has joined #mythtv | |
| [15:20:03] | stuarta: | stuartm: has the branch been pushed? |
| [15:21:08] | stuarta: | or the merge been pushed? |
| [15:21:23] | stuarta: | if so it's pretty much a case of creating more changes to back out the merge |
| [15:22:07] | letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has joined #mythtv | |
| [15:24:36] | stuartm: | it had |
| [15:25:29] | stuarta: | :( |
| [15:25:38] | stuartm: | something that git doesn't handle well |
| [15:28:02] | stuartm: | it's resolvable, but just not in the way I'd have liked – all the changes were destined for the main branch anyway so when everything's done the end result will be the same just happened out of sequence |
| [15:28:12] | stuarta: | bugger |
| [15:37:55] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv | |
| [15:43:13] | cbovy: | stuarta: I added two dummy recorders, connected to same videosource, and that works. So it seems to be specific to freebox recorder. |
| [15:43:53] | stuarta: | cbovy: interesting |
| [15:45:28] | cbovy: | now the fun part starts... finding the needle. :-) |
| [16:02:33] | gigem: | cbovy: To test stand-alone scheduling, use "mythbackend -v schedule --testsched --loglevel debug". |
| [16:05:55] | stuarta: | gigem: what about why it wouldn't use the 2nd available recorder? |
| [16:08:09] | cbovy: | found something: |
| [16:08:11] | cbovy: | Assigning input 1 to conflict set 1 |
| [16:08:16] | cbovy: | Assigning input 2 to conflict set 1 |
| [16:08:26] | cbovy: | some conflict set? |
| [16:16:07] | cbovy: | in 0.27.5, the freebox recorders are not listed in table inputgroup. In 0.28, they are. |
| [16:16:44] | cbovy: | and the freebox recorders are listed with the same inputgroupid in 0.28. Is that as expected? |
| [16:19:50] | stuarta: | that would certainly cause the behaviour you are seeing, if they are both in the same inputgroup, the scheduler decides that it can only use 1 at a time |
| [16:22:10] | gigem: | cbovy: I'm not familiar with how any of the IPTV recorders are configured. What do you put in for the "device" field? In 0.28, there is an implied inputgroup for each unique host/device. |
| [16:28:00] | stuarta: | that makes me suspect the workaround / fix may be to remove 1 recorder, and set the other up with > 1 recordings allowed |
| [16:30:24] | cbovy: | one moment. I have now changed the inputgroupid to a unique value in inputgroup table for every iptv recorder. |
| [16:31:52] | cbovy: | yeah, that works. |
| [16:32:28] | cbovy: | so what I have done is to assigned a unique inputgroupid for every iptv recorder in inputgroup table. |
| [16:32:49] | cbovy: | when I added two dummy recorders, they both had a unique inputgroupid. |
| [16:32:59] | cbovy: | the two IPTV recorderd did not. |
| [16:39:24] | ** stuarta wonders if this is a transition issue? ** | |
| [16:40:22] | gigem: | jpabq: ^^^ Is increasing the multirec count the proper fix for IPTV recorders? I suspect not because that's more related to sharing streambuffers, right? |
| [16:41:06] | stuarta: | gigem: jpabq probably the issue here is that they've been both put in the same input group |
| [16:41:11] | stuarta: | by an upgrade |
| [16:41:39] | gigem: | cbovy, stuarta: What gets used as the "device" for IPTV recorders? That needs to be unique for truely independent recorders. |
| [16:42:39] | gigem: | stuarta: Yes. See above. It was intentional. There is an automatically created inputgroup for each unique host/device combination. |
| [16:43:48] | stuarta: | gigem: was that during the DB update? |
| [16:50:01] | gigem: | Yes. One of the commits relating to merging cards and inputs. |
| [16:50:12] | stuarta: | suspected it might be |
| [17:01:58] | dekarl1 is now known as dekarl | |
| [17:14:31] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [17:33:12] | jpabq: | gigem: right. multirec determines how many "recorders" can use the same stream (MPTS). |
| [17:34:32] | jpabq: | Is freebox MPTS or SPTS? Most IPTV streams are SPTS, but it is posible to do MPTS over IP. |
| [17:44:45] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving) | |
| [17:57:10] | Jordack1 (Jordack1!~Jordack@fwci01.twp.ypsilanti.mi.us) has joined #mythtv | |
| [17:57:40] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has quit (Quit: leaving) | |
| [17:57:55] | Chutt_ is now known as Chutt | |
| [17:58:02] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [17:59:20] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit (Ping timeout: 246 seconds) | |
| [18:00:38] | Jordack1 is now known as Jordack | |
| [18:02:33] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:a065:5fb8:72b8:e608) has joined #mythtv | |
| [18:06:26] | dekarl: | jpabq: freebox is SPTS, like basically all end-user IPTV. |
| [18:07:01] | dekarl: | but IIRC we can't do overlapping recordings of the same channel without multirec. So back-to-back recordings with start-early/end-late need multirec, too |
| [18:09:02] | dekarl: | btw, does the hdhr http api do multirec? |
| [18:14:01] | gigem: | dekarl: If jpabq's changes work the same for IPTV as they do for Ceton and HDHR, then in 0.28, you can overlap with 'one' recorder. Note the one is in quotes. It really creates multiple recorders, but the additional ones are autmatically managed, just like has been done for years with DVB cards. |
| [18:30:47] | dekarl: | gigem: it was my understanding, that the HDHR http api is one STPS per device |
| [18:31:07] | dekarl: | while the "old" API allows for one MPTS per device |
| [18:51:00] | jpabq: | I have not looked at the HDHR API. Myth supports multiple recorders using the same "stream" for just about everything, though. Even if the stream is SPTS that is still usefull to allow for overlaps. |
| [18:51:26] | jpabq: | Myth currently does not allow multirec for V4L or analog recorders. |
| [18:52:47] | jpabq: | dekarl: I am guessing the new HDHR api does pid filtering in the hardware? If so, then that would knock it down to SPTS by the time that Myth sees it. I wonder if that is configurable, so Myth could do the pid filtering itself... |
| [18:54:16] | paul-h (paul-h!~Paul@94.6.148.224) has joined #mythtv | |
| [18:54:44] | jpabq: | I have the code written to allow multirec for V4L2 hardware encoders — I have spent the last week trying to get "recording profiles" to work with it, since each V4L2 device has different capabilities. I probably need another week to get it all working. |
| [18:54:54] | dekarl: | doesn't the old one do that, too? |
| [18:55:36] | dekarl: | the only hardware "one channel per frontend" limitation that I'm aware of is the H.264 encode chip (And of that I'm not even sure) |
| [18:55:40] | jpabq: | old one? HDHR? Originally, the HDHR would profile the whole multiplex, and then Myth would grab whatever programs it wanted out of that MPTS. |
| [18:55:57] | jpabq: | s/profile/provide/ |
| [18:56:11] | paul-h: | jpabq: is this patch still required for master after the ffmpeg re-syncs? #12546 |
| [18:56:11] | ** MythLogBot http://code.mythtv.org/trac/ticket/12546 ** | |
| [18:56:18] | dekarl: | ahh ok, I thought I'd seen PID addition/removal in the API |
| [18:56:32] | jpabq: | dekarl: yes, I think the "new" HDHR api allows for that. |
| [18:57:16] | jpabq: | paul-h: I am guessing not. I don't have anything to test it with currently, though. Although, I seem to remember some HLS feeds which did captions that way — I wonder if I can find one again. |
| [18:58:07] | jpabq: | dekarl: but i have not looked at the HDHR code myself. That was all written by Daniel, I believe. |
| [18:59:36] | paul-h: | looks like it's a duplicate of #11932 anyway which I already close – thought it rang a bell :) |
| [18:59:36] | ** MythLogBot http://code.mythtv.org/trac/ticket/11932 ** | |
| [18:59:44] | jpabq: | gigem: dekarl: In theory, IPTV should work with multirec — at least for overlap. |
| [19:01:30] | jpabq: | paul-h: ah, yes. I had forgotten about that original ticket — that is the exact same patch, by the same person. |
| [19:03:23] | jpabq: | The only "recorder" I am not sure about, in regards to multirec is firewire. It is structured differently than any other recorder code. I will have to look at it closer to determine how it works. I *think* it can do multirec. I have no way of testing it though. |
| [19:04:48] | dekarl: | jpabq: IPTV has fun times ahead... wrt multirec but also EIT collection |
| [19:05:02] | jpabq: | EIT over IP? Interesting. |
| [19:06:09] | jpabq: | I need to take some time and stuffy EIT. I have never used it, but I can see the benifit. |
| [19:06:31] | jpabq: | Especially for non-local sources... |
| [19:09:01] | paul-h: | jpabq: wonder if the change to mythtv/libs/libmythtv/avformatdecoder.cpp is still required from that patch? |
| [19:10:03] | dekarl: | sure, why not. Now that the IPTV recorder is the generic "its a MPEG2-TS coming in over the network in one way or another" solution we have all variants. from sniffing MPTS at the headend over plain old TV over DSL, to SAT>IP / HDHR where we attach a good old DTV frontend to the network |
| [19:10:40] | jpabq: | paul-h: If jya has time to look at it, that would be the quickest way to get an answer to that question. If he does not, then I will see what I can figure out. |
| [19:12:01] | dekarl: | open source IP headend solutions add extra options, just for us :) http://www.mumudvb.net/doc/mumudvb-2.0.0/README.html#_mythtv |
| [19:12:45] | jpabq: | dekarl: thanks. I will have to read that. |
| [19:17:47] | jheizer__ (jheizer__!~jheizer@c-73-51-93-177.hsd1.il.comcast.net) has joined #mythtv | |
| [19:20:58] | cbovy: | sorry for raising the topic and then run away for diner. :-) |
| [19:21:24] | jheizer_ (jheizer_!~jheizer@75-132-131-64.dhcp.stls.mo.charter.com) has quit (Ping timeout: 245 seconds) | |
| [19:21:39] | cbovy: | the scenario is a 0.27.5 setup with two separate freebox recorders, with same playlist (url to m3u file) and some videosource. |
| [19:22:44] | cbovy: | after upgrade, I ended up with one freebox recorder, with 2 simultaneous recordings (multirec), with same inputgroupid, so no simultaneous recordings from different channels possible after upgrade. |
| [19:23:15] | cbovy: | after changing the inputgroupid manually (bad bad bad), to a unique ID, everything works as expected. |
| [19:23:40] | dekarl: | cbovy, this is only about multirec, not about recording two unrelated streams? #12322 |
| [19:23:40] | ** MythLogBot http://code.mythtv.org/trac/ticket/12322 ** | |
| [19:24:42] | cbovy: | I think that is a different issue. |
| [19:25:09] | cbovy: | at first glance, it looks similar. |
| [19:25:29] | dekarl: | ok |
| [19:29:00] | cbovy: | could #12322 be related to commit e740947? I've seen similar behavior with http ts. But in this ticket it is about rtp. |
| [19:29:00] | ** MythLogBot http://code.mythtv.org/trac/ticket/12322 ** | |
| [19:30:29] | cbovy: | this commit has also been committed to fixes/0.27 with commit e6f4ba8. (search for IsHTTPTS()). |
| [20:18:16] | cbovy: | I've created a ticket for the iptv/freebox issue: #12598 |
| [20:18:16] | ** MythLogBot http://code.mythtv.org/trac/ticket/12598 ** | |
| [20:22:22] | stuarta: | wtf does this fixup not get run for the channels on this mux, they are there ffs |
| [20:31:49] | cbovy (cbovy!~cbovy@212.84.139.221) has quit (Quit: Leaving) | |
| [20:33:08] | Tobbe5178 (Tobbe5178!~asdf@2001:2002:4e46:4de8:1464:20de:34e9:1a83) has joined #mythtv | |
| [20:35:47] | willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Quit: Do your hobbies) | |
| [20:48:18] | Roklobotomy (Roklobotomy!~blah@ppp118-209-87-144.lns20.mel4.internode.on.net) has joined #mythtv | |
| [21:03:31] | letifosi_ (letifosi_!~letifosif@216.207.42.134) has joined #mythtv | |
| [21:05:52] | paul-h (paul-h!~Paul@94.6.148.224) has quit (Quit: Konversation terminated!) | |
| [21:07:11] | letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has quit (Ping timeout: 276 seconds) | |
| [21:28:11] | gary_buhrmaster: | dekarl: (re wiki update irt memory requirements) the current fedora ARM buildbot only has 512MB of memory (and tv_rec.cpp is no worse than anything else). So, it appears, the statement (of requiring 2GB) is no longer operable. |
| [21:28:57] | gary_buhrmaster: | dekarl: I have no idea (and do not plan to do the research) whether the code changed, or the compilers changed from when those words were originally written. |
| [21:29:48] | stuarta: | i wrote it originally, and either the code or compilers have changed (i suspect the latter) |
| [21:31:09] | gary_buhrmaster: | stuarta: That was my presumption too (but I refer the honorable gentle-person to my previous statement of being lazy). |
| [21:31:21] | stuarta: | :-p |
| [21:31:57] | jheizer__: | hmm, forgot I was going to offer up one of my RPis |
| [21:32:00] | jheizer__ is now known as jheizer | |
| [21:35:30] | gary_buhrmaster: | It took me (about) a year to build the BeagleBone Black (fedora arm) BuildBot. So you could still fail to beat my laziness record (depending on when you started to think about offering it up). |
| [21:36:52] | stuarta: | seriously, why is it when i start watching a single episode of a program, i find it to be the 0th part of a "2" part episode, now i have to watch part's 1 and 2 |
| [21:37:41] | jheizer: | haha just a few weeks ago. I've got a RPi2 that does nothing but act as a network interface to a 1-wire network. So it is idle 99.9% of the time. |
| [21:40:32] | gary_buhrmaster: | I was unaware that watching episode N *requires* one to watch episode N+1. I guess the rules regarding user capture are different on that side of the pond (gleeful laugh: "we got you now!") |
| [21:44:59] | stuarta: | bloody seriessssss |
| [21:47:13] | SteveGoodey (SteveGoodey!~steve@host109-156-128-140.range109-156.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:56:48] | lautriv_: | is there a specific libvpx preferred for myth ? actually i have 1.5.0 and repo fails o.O |
| [22:00:23] | stuartm: | with master you can't make it restart a failed recording? |
| [22:00:56] | stuartm: | hmm, ok, tried again and this time the restart option was there |
| [22:01:26] | jpabq: | stuartm: gigem is working on that. I think he is testing some of Rogers patches. |
| [22:03:35] | stuartm: | ok, good that it's a known issue |
| [22:04:17] | letifosi_ (letifosi_!~letifosif@216.207.42.134) has quit (Remote host closed the connection) | |
| [22:04:50] | letifosiferrari (letifosiferrari!~letifosif@216.207.42.132) has joined #mythtv | |
| [22:16:20] | dmfrey (dmfrey!~dmfrey@68.170.18.123) has quit (Ping timeout: 256 seconds) | |
| [22:19:38] | Jordack (Jordack!~Jordack@fwci01.twp.ypsilanti.mi.us) has quit (Quit: I need a long vacation. I think six months twice a year should work.) | |
| [22:22:10] | dekarl: | gary_buhrmaster: yes, that was my impression, too. That a 512MB buildbot (e.g. original Pi) might be able to build. |
| [22:22:36] | dekarl: | maybe its some compiler flags, too. -O99 vs. -g or whatever |
| [22:23:22] | stuarta: | O1 or O2 maybe |
| [22:23:58] | dekarl: | jheizer: which OS? we could throw a lot in the mix. NetBSD and Raspian are up for grabs :) (two random OS with GPU/VPU support) |
| [22:24:18] | dekarl: | s/lot/lot of OSs/ |
| [22:24:22] | jheizer: | currently running rasbian jessia |
| [22:24:24] | jheizer: | jessie |
| [22:25:19] | jheizer: | before christmas I tried to run the ansible playbooks but got an error |
| [22:25:59] | jheizer: | haven't got to look at it since (got a 3d printer kit that has been a diseaster and eating up and insane amount of my free time to get it working) |
| [22:27:48] | dekarl: | I had errors, too. Worked around it (just commented out offending lines without looking into the root cause) |
| [22:28:12] | jheizer: | ERROR: dnf is not a legal parameter in an Ansible task or handler |
| [22:28:18] | jheizer: | just logged in to see what it was |
| [22:28:35] | jheizer: | seemed like it wasn't trying to run the deb version of things I guess |
| [22:28:58] | gigem: | jpabq, stuartm: I committed some of Roger's fixes and some of my own a month and a half ago. |
| [22:29:34] | jpabq: | gigem: I missed that. I thought you were still testing. |
| [22:30:22] | stuarta: | dekarl: jheizer seems the debian version of ansible is too old to support dnf |
| [22:31:32] | jheizer: | was just working my way to a version comparison |
| [22:32:32] | dekarl: | ahh, good point, there is https://launchpad.net/~ansible/+archive/ubuntu/ansible |
| [22:32:34] | jheizer: | oh man, way old |
| [22:32:42] | stuartm: | gigem: ok, problem disappeared after a couple of minutes so I'm not sure what to make of that |
| [22:32:51] | jheizer: | dekarl, thanks had jsut got there actually |
| [22:32:59] | stuarta: | i wonder if it's possible to make it conditional |
| [22:34:32] | dekarl: | stuarta, do we want the buildbots to build with most options? I can add some dependencies to the apt part. |
| [22:37:08] | gigem: | Can someone explain to me how 'tuning' works with IPTV? As I understand it, cardinput.videodevice contains an URL for an m3u file. Doesn't that unequivocally define what to stream? Either way, how is the channel changed? I'm trying to understand how two recorders configure to use the same m3u makes sense. |
| [22:38:30] | jpabq: | gigem: it uses mythconverg.iptv_channel |
| [22:39:13] | jpabq: | The "channel scanner" for IPTV parses the m3u and populates that table. Then the recorder uses that table to map channel numbers into urls. |
| [22:39:36] | jheizer: | removed the dnf options and running it now |
| [22:40:02] | stuarta: | jheizer: what, commented them out? curious what you had to do exactly |
| [22:40:35] | ** stuarta will take a git diff ** | |
| [22:40:37] | stuarta: | ;-) |
| [22:42:10] | jheizer: | I just removed the mythtv-dnf options all together so it wouldn't get hung up on them |
| [22:44:14] | ** stuarta sighs ** | |
| [22:44:45] | jheizer: | http://pastebin.com/0utZG4Y3 |
| [22:44:48] | jpabq: | One thing about pusing for a new release, it motivates the devs to spend some time on the project :-) |
| [22:44:59] | jheizer: | so not exactly check in worthy |
| [22:45:14] | gary_buhrmaster: | dekarl: My recollection is that we have missed some (compilation) issues if we do not build with most options (a commit in an area no one was building for). That is one reason why I installed many of the optional dev libraries on my Fedora buildbots. |
| [22:45:46] | jpabq: | stuarta: As far as I know, if you set ansible to use yum it will automatically get promoted to dnf on appropriate systems. |
| [22:46:03] | jpabq: | not by ansible, but by the system. |
| [22:46:38] | stuarta: | yeah it does, but for how long |
| [22:46:44] | gary_buhrmaster: | Recent fedora has a yum wrapper that says something to the effect of "yum is gone, long live yum (we now replace your yum with dnf and see what happens)". |
| [22:47:02] | stuarta: | f22 and f23 redirect to dnf |
| [22:50:42] | gary_buhrmaster: | The various rpms (to redirect) still exist in f24 (although I have retrained my fingers to type dnf when I mean yum, so I did not try it). Perhaps by f25 it will finally be gone. |
| [22:53:27] | jheizer: | ansible just finished |
| [22:53:33] | jheizer: | I forget what the next steps were |
| [22:53:44] | jheizer: | Sending ssh key? |
| [22:54:17] | gigem: | jpabq: I see. Thanks. |
| [22:57:53] | jpabq: | Elements of "recording profiles" are seriously broken. Getting this stuff working is taking far to much of my time! |
| [23:00:43] | jheizer: | I'm off for a few hours. stuarta left you the public key via PM. Remind of of the next steps when ever you want. |
| [23:02:41] | peper03: | Wow. Starting playback of a ripped Blu-ray from storage groups on the same machine takes more than 2 minutes! |
| [23:03:12] | stuarta: | peper03: 0.27 or master? |
| [23:03:24] | peper03: | stuarta: master |
| [23:03:25] | ** stuarta wonders if we need to merge some more of lvr's patches ** | |
| [23:03:37] | peper03: | Although I doubt it is different in 0.27 |
| [23:03:45] | peper03: | Starting playback of the same thing without storage groups takes 40ms |
| [23:03:55] | stuarta: | odd |
| [23:04:22] | peper03: | Part of it is the 60ms delay in 'seek' I found the other day. |
| [23:04:43] | peper03: | Removing that helps up to a point, but then the backend seems to crash because of insufficient handles. |
| [23:05:12] | stuarta: | shouldn't do that either |
| [23:06:46] | peper03: | It's parsing *lots* of files to build up the title list. Running out of handles when I remove the delay would seem to indicate some sort of lazy closing. |
| [23:07:14] | stuarta: | huh? wtf is it parsing from files |
| [23:07:37] | peper03: | It's reading all the .CLP files |
| [23:08:06] | ** stuarta has never heard of a .clp file ** | |
| [23:08:13] | peper03: | There's 239 for this disc. |
| [23:08:45] | peper03: | I'm not sure of the exact contents but basically they seem to define individual clips. |
| [23:09:32] | peper03: | They're all pretty small. Most are about 300+ bytes. The largest is about 19KB. |
| [23:10:05] | peper03: | But every time it opens a file, it seeks to position 0, then to the end of the file, then apparently again, and then seeks back to pos 0. |
| [23:10:22] | stuarta: | ugh, just read it ffs |
| [23:10:47] | peper03: | I think it's trying to get the length by seeking. |
| [23:11:26] | stuarta: | it'd be better off fstat'ing, but no doubt that doesn't work well with a proper bluray |
| [23:14:04] | stuarta: | ah but then, if the file isn't in a SG, it doesn't do this, so that makes me wonder if it's incorrectly trying to process the iso as an SG |
| [23:15:17] | peper03: | It's not an iso. It's the directory structure as it would appear if you mounted the disc. |
| [23:17:21] | peper03: | Playing an ISO seems fairly quick even in a storage group but the only ISOs I have to play with are very simple (but I would still expect it to be faster). |
| [23:20:10] | peper03: | And it seems the reason it does all the seeking is to be generic. Certainly the second seek to the end of the file is down to mythfile_tell, which seeks 0 bytes from the current position. |
| [23:25:39] | wbill (wbill!~kurgan@75-131-35-128.static.kgpt.tn.charter.com) has joined #mythtv | |
| [23:45:18] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 256 seconds) | |
| [23:45:22] | peper03: | It appears that the sockets *are* cleaned up lazily – in MainServer::customEvent from what I can see, so if too many files are accessed too quickly, we can run out of file handles. |
| [23:46:46] | peper03: | So for this particular disc, it's accessing 239 clip info files and a further 233 playlist files one after the other. |
| [23:47:47] | peper03: | Anyway, I think that's a problem for another day. |
| [23:49:10] | purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (Ping timeout: 260 seconds) | |
| [23:49:45] | purserj_ (purserj_!~purserj@hosting.collaborynth.com.au) has quit (Ping timeout: 260 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.