| Tuesday, July 7th, 2015, 00:01 UTC | ||
| [00:01:40] | Roklobsta (Roklobsta!~Roklobsta@1.125.48.104) has quit (Client Quit) | |
| [00:06:42] | MythBuild: | build #46 of master-fedora-armv7hl is complete: Failure [4failed unit test core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . hl/builds/46 blamelist: Karl Dietz <dekarl@mythtv.org > |
| [01:56:57] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 276 seconds) | |
| [01:59:29] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [02:08:10] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 246 seconds) | |
| [02:12:08] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [02:16:36] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 264 seconds) | |
| [02:18:28] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [02:51:06] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 255 seconds) | |
| [02:51:36] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:14:22] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has joined #mythtv | |
| [03:14:47] | arescorpio (arescorpio!~arescorpi@217-242-16-190.fibertel.com.ar) has joined #mythtv | |
| [03:22:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:26:15] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 256 seconds) | |
| [04:33:48] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [04:41:15] | arescorpio (arescorpio!~arescorpi@217-242-16-190.fibertel.com.ar) has quit (Quit: Leaving.) | |
| [05:45:55] | jheizer_ (jheizer_!~jheizer@2601:246:8201:af08:6c9d:b491:1720:e700) has quit (Read error: Connection reset by peer) | |
| [05:45:58] | Chutt__ (Chutt__!~ijr@2605:a000:1225:65:c457:ef1d:60fd:2177) has joined #mythtv | |
| [05:46:01] | jheizer__ (jheizer__!~jheizer@2601:246:8201:af08:6c9d:b491:1720:e700) has joined #mythtv | |
| [05:49:02] | Chutt_ (Chutt_!~ijr@2605:a000:1225:65:c457:ef1d:60fd:2177) has quit (Ping timeout: 248 seconds) | |
| [05:56:45] | dekarl1 (dekarl1!~dekarl@mythtv/developer/dekarl) has joined #mythtv | |
| [05:58:41] | dekarl (dekarl!~dekarl@mythtv/developer/dekarl) has quit (Ping timeout: 256 seconds) | |
| [06:14:12] | Tobbe5178 (Tobbe5178!~asdf@2001:2002:51e1:d8ee:d174:1809:af81:2cbf) has joined #mythtv | |
| [06:17:23] | MythBuild: | build #1646 of master-fedora-32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1646 |
| [06:17:43] | MythBuild: | build #262 of master-f21–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/262 |
| [06:19:15] | dym (dym!~patrick@xstd.de) has quit (Changing host) | |
| [06:19:15] | dym (dym!~patrick@unaffiliated/dym) has joined #mythtv | |
| [06:22:52] | MythBuild: | build #85 of master-debian-jessie-32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . it/builds/85 |
| [06:23:17] | MythBuild: | build #2475 of master-ubuntu-current-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2475 |
| [06:35:09] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has joined #mythtv | |
| [07:03:45] | dekarl1 is now known as dekarl | |
| [07:14:53] | MythBuild: | build #47 of master-fedora-armv7hl is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . hl/builds/47 |
| [07:20:09] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Connection reset by peer) | |
| [07:20:48] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [08:11:04] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [09:09:09] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has joined #mythtv | |
| [09:09:19] | ** stuarta yawns ** | |
| [09:50:04] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has joined #mythtv | |
| [10:08:37] | jpharvey (jpharvey!~jpharvey@host81-159-18-75.range81-159.btcentralplus.com) has quit (Ping timeout: 265 seconds) | |
| [10:22:08] | jpharvey (jpharvey!~jpharvey@host86-149-149-118.range86-149.btcentralplus.com) has joined #mythtv | |
| [10:23:49] | stuarta: | how on earth does that use get configure to issue an unknown cpu error? |
| [10:23:53] | stuarta: | *user |
| [10:24:33] | stuarta: | http://lists.mythtv.org/pipermail/mythtv-user . . . /379901.html |
| [10:50:02] | jheizer__ (jheizer__!~jheizer@2601:246:8201:af08:6c9d:b491:1720:e700) has quit (Read error: Connection reset by peer) | |
| [10:50:31] | jheizer__ (jheizer__!~jheizer@2601:246:8201:af08:6c9d:b491:1720:e700) has joined #mythtv | |
| [11:16:29] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has joined #mythtv | |
| [11:35:33] | sphery: | stuarta: according to http://lists.mythtv.org/pipermail/mythtv-user . . . /379906.html , it's the -4440 (though I haven't looked at code) |
| [11:42:47] | stuarta: | the code doesn't match anything with a – after it |
| [11:43:27] | stuarta: | so it hasn't been working for a long time |
| [11:43:44] | stuarta: | what i don't understand is how it's triggering the unsupported cpu for him |
| [11:46:13] | paul-h (paul-h!~Paul@94.5.245.174) has joined #mythtv | |
| [11:50:08] | paul-h: | FWIW I have a Intel(R) Core(TM) i7–4770T CPU @ 2.50GHz and configure with --enable-proc-opt works fine |
| [11:53:15] | stuarta: | i've got Intel(R) Core(TM) i7–4600U CPU @ 2.10GHz and it also works fine |
| [11:53:27] | stuarta: | which is why i don't understand how he even gets the error |
| [11:53:52] | stuarta: | that said, none of the regexps will match i[357]-* |
| [11:55:55] | stuarta: | asked for the configure line, lets see what he says |
| [12:01:11] | sphery: | stuarta: looking at it, this seems wrong: uname -p: x86_64 |
| [12:01:30] | sphery: | -p should give the Intel(R) Core(TM) i5–4440 CPU |
| [12:01:44] | sphery: | the x86_64 is the -m |
| [12:02:05] | sphery: | broken uname on his system? |
| [12:04:15] | stuarta: | i'm running f22 as well, so i would expect to see the same |
| [12:04:45] | stuarta: | i get x86_64 for both -m and -p |
| [12:04:53] | sphery: | weird |
| [12:06:21] | sphery: | granted, this is AMD, but: http://pastebin.com/NpLhGitG |
| [12:06:54] | sphery: | and man page for uname says, '-p, --processor\nprint the processor type or "unknown"' |
| [12:07:27] | sphery: | oh, and mine is ancient, too :) |
| [12:07:29] | stuarta: | clearly that's a difference between amd and intel cpu's |
| [12:07:49] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has quit (Read error: Connection reset by peer) | |
| [12:07:54] | sphery: | but there's no way your processor is "x86_64" |
| [12:07:57] | sphery: | that's not a processor |
| [12:08:05] | stuarta: | :) |
| [12:09:34] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has joined #mythtv | |
| [12:10:05] | sphery: | and, FWIW, our script agrees that the -p should be giving things like ".*Intel(R).*Core(TM) i[357] CPU.*" |
| [12:10:18] | sphery: | so something uname-wise has changed or is broken |
| [12:10:45] | stuarta: | i'd bet the information comes from the kernel |
| [12:11:05] | stuarta: | my 3.13.0 box reports x86_64 |
| [12:11:42] | stuarta: | interesting |
| [12:11:43] | stuarta: | # cat /proc/cpuinfo | grep "model name" |
| [12:11:43] | stuarta: | model name : AMD Athlon(tm) II Neo N36L Dual-Core Processor |
| [12:12:00] | stuarta: | so it's not an intel specific thing |
| [12:13:01] | sphery: | yeah, we use /proc/cpuinfo to get the $PROC_INFO in the error message--which is why that shows the proper processor info |
| [12:13:26] | sphery: | we should have someone with a current, but not F22, system check uname -m, uname -p, and such |
| [12:13:53] | sphery: | (don't rely on my ancient system) |
| [12:13:55] | stuarta: | my other set of results are on ubuntu lts |
| [12:14:06] | sphery: | and they still give x86_64? |
| [12:14:31] | stuarta: | yes, despite being the athlon i mentioned above |
| [12:23:20] | paul-h: | on gentoo uname -p gives Intel(R) Core(TM) i7–4770T CPU @ 2.50GHz |
| [13:17:12] | stuarta: | paul-h: with your svn removal change, i'd also suggest reporting unsupported cpu issues to the -dev list. the users aren't likely to help ;-) |
| [13:46:01] | dekarl: | morning all |
| [13:59:03] | stuarta: | morning? |
| [14:04:04] | stuarta: | paul-h: thanks |
| [14:08:32] | dekarl: | per freenode FAQ the greating when someone appears is "morning" and its "good night" when someone leaves ;) |
| [14:08:41] | dekarl: | s/great/greet/ |
| [14:09:23] | dekarl: | https://freenode.net/faq.shtml#fst <- there are rules for everything ;) |
| [14:16:34] | stuarta: | :) |
| [14:21:52] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has joined #mythtv | |
| [14:40:54] | Tobbe5178 (Tobbe5178!~asdf@2001:2002:51e1:d8ee:d174:1809:af81:2cbf) has quit (Read error: Connection reset by peer) | |
| [14:54:20] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [15:35:46] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [15:41:04] | kukks (kukks!~Guenter@samba/team/kukks) has joined #mythtv | |
| [15:52:54] | jst (jst!~quassel@198.199.94.175) has quit (Remote host closed the connection) | |
| [15:53:07] | jst (jst!~quassel@198.199.94.175) has joined #mythtv | |
| [16:05:39] | aberrios_ (aberrios_!~aberrios@195.130.201.200) has quit (Quit: Lost terminal) | |
| [16:34:04] | kukks (kukks!~Guenter@samba/team/kukks) has quit (Ping timeout: 246 seconds) | |
| [16:35:14] | kukks (kukks!~Guenter@samba/team/kukks) has joined #mythtv | |
| [16:51:05] | Chutt__ is now known as Chutt | |
| [17:02:02] | gary_buhrmaster: | dekarl: What about those of us who do not want to follow the rules? "Never tell me the rules". |
| [17:22:05] | kukks (kukks!~Guenter@samba/team/kukks) has quit (Ping timeout: 256 seconds) | |
| [17:34:13] | joki (joki!~joki@p5B36D707.dip0.t-ipconnect.de) has quit (Ping timeout: 244 seconds) | |
| [17:39:48] | joki (joki!~joki@p5B36D33A.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:06:47] | jluttine (jluttine!~jluttine@dsl-trebrasgw2-54f9af-12.dhcp.inet.fi) has joined #mythtv | |
| [18:06:55] | jluttine (jluttine!~jluttine@dsl-trebrasgw2-54f9af-12.dhcp.inet.fi) has left #mythtv () | |
| [18:10:43] | dekarl: | gary_buhrmaster: the rule is all your tuners are belong to us! |
| [18:11:21] | gary_buhrmaster: | dekarl: I, for one, welcome our MythTV overlords. |
| [18:16:22] | jheizer__: | I guess I don't get the hate in that ticket. Yes it only 1/2 solves the problem, but still a nice and simple improvement. |
| [18:16:57] | ** jheizer__ is not the ticket op or commenter ** | |
| [18:17:03] | jheizer__ is now known as jheizer | |
| [18:34:40] | gary_buhrmaster: | jheizer: In my opinion, it does not even solve 1/2 of the problem (or, if it does, only in the cases where you never actually are dynamically sharing). It is, at best, a fix for one specific (rare in my experience of testing with attempted sharing) scenario. But I, too, am not the decider. |
| [18:38:58] | gary_buhrmaster: | jheizer: The only argument (I can make) for committed the incomplete patch is to either (a) encourage participation by new people, or (b) that is is a work in progress and the more complete fix has been committed for later. |
| [18:40:57] | jheizer: | I guess I just see solving one of the 2 points that he outlined in the last comment as an improvement and with what looks like very little code changes. |
| [18:41:32] | jheizer: | Especially knowing that the full solution could very well be a giant change. |
| [18:42:04] | jheizer: | Playing defense against other apps invading. |
| [18:49:51] | jafa2 (jafa2!~jafa@2001:470:80ca:2000:2400:af40:e02e:2df4) has joined #mythtv | |
| [20:57:07] | SteveGoodey (SteveGoodey!~steve@host81-147-70-19.range81-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:01:17] | gigem: | jheizer: As has been noted, it only solves half of the problem at best. I'd much rather stick with clearly and correctly stating that MythTV does not support any tuner sharing until it truly supports it. FWIW, while double checking some facts this morning, it doesn't look like doing things properly should be that hard. It mostly boils down to finding someone with the time and motivation to do it. |
| [21:06:02] | gary_buhrmaster: | gigem: I think there is a third piece missing there, the "skills" part. It is the deadly 3 problem. |
| [21:06:26] | dekarl: | gigem, did I understand that correctly, the old HDHR do not support tuner sharing, its only Prime and newer? So with "lock on backend startup" the Prime would act like a regular HDHR or any DVB card? |
| [21:07:31] | Jordack (Jordack!~Jordack@75-151-31-172-Michigan.hfc.comcastbusiness.net) has quit () | |
| [21:08:19] | gary_buhrmaster: | dekarl: AFAIK, even the old HDHRs support the locking via the (legacy) API. Only the new ones can do the "automagical" locking that happens when connecting via the (say) HTTP transfer. |
| [21:09:48] | gary_buhrmaster: | dekarl: Or, if I misunderstood the question, even the old HDHRs can be "stolen" by the last request if one does not request a lock. |
| [21:11:25] | dekarl: | gary_buhrmaster: doh, so why didn't we "just lock them on startup" in the first place? |
| [21:11:36] | gary_buhrmaster: | dekarl: And (again, as I recall) the locks expire if there is no active stream, so you have to refresh the lock if you wanted to keep it. |
| [21:12:17] | gary_buhrmaster: | dekarl: That would be a history question. And since I have forgotten it (if I ever knew), I am doomed to repeat the experience. Again, and again. |
| [21:12:18] | gigem: | gary_buhrmaster: :) My feeling is whomever made the locking patch is *probably* capable of doing the rest too. They just need a little more motivation. |
| [21:13:47] | gigem: | dekarl, gary_buhrmaster: I admittedly did not look all the way into the bowels of libhdhomerun, but I didn't see anything saying that the pool allocation wasn't available on some models. Perhaps it's a matter of needing more recent firmware on the older models. |
| [21:13:49] | jheizer: | I don't think they took it as a friendly push though. |
| [21:14:45] | gigem: | Has there been any follow ups today? I haven't had time to check since this morning, but will try to do so soon. |
| [21:14:46] | gary_buhrmaster: | gigem: I have this feeling that the pooling is a (more) recent addition to the API. But jafa2 would know for sure. |
| [21:15:44] | jheizer: | Completely unrelated note, I just got my Liva and unboxing it now. God damn this thing is tiny. |
| [21:15:53] | gary_buhrmaster: | gigem: The problem with pooling (rather than locking at startup) is still the same (i.e. you may find you do not have the right number of tuners when you need them). |
| [21:18:33] | jafa2: | hi |
| [21:18:48] | jafa2: | mythtv uses the libhdhomerun approach |
| [21:19:04] | jafa2: | so tuner is chosen by the pc/mythtv |
| [21:19:55] | jafa2: | the trick is to call the lockkey api when mythtv wants to tune a channel. |
| [21:20:16] | jafa2: | then release th lockkey when done |
| [21:20:32] | jafa2: | then other apps won't interrupt a mythtv recording |
| [21:20:53] | gigem: | gary_buhrmaster: I know, but that is solvable. We already have a few places where we do prerecording things that an allocation could be done. I also know I'm probably the only one reasonable qualified to make the scheduler changes. I willing to do that if someone else does the recorder parts. |
| [21:21:30] | jafa2: | i understand there is already a patch to add lockkey use |
| [21:22:05] | jafa2: | failover... how does mythtv handle that today (for any type of tuner)? |
| [21:22:34] | gigem: | jafa2: It doesn't. That's part of the problem. |
| [21:22:45] | gary_buhrmaster: | jafa2: re: failover. It (basically) does not (or at least not well). It presumes that if you tell it you have tuner x available, you do. |
| [21:23:48] | jafa2: | ok, suggest treating that as a different issue, commit the lockkey support in the mean time |
| [21:24:09] | gigem: | jafa2: The current recording gets marked as failed, and if there is a later showing the recording rule type allows for it, MythTV will try again later. But there is nothing currently in place to immediately try recording on a different when the first one isn't available. |
| [21:24:55] | jafa2: | ok |
| [21:25:31] | jafa2: | one of the big problems today is that mythtv can start a recording and any other app can take over the tuner |
| [21:25:38] | gary_buhrmaster: | jafa2: Was the libhdhomerun api to get a list of tuners (pool) a recent addition, or was that in it originally? |
| [21:25:43] | jafa2: | causing the recording to fail |
| [21:26:04] | jafa2: | pooling api was not original but has been there for a while |
| [21:26:10] | gary_buhrmaster: | jafa2: In my experience, all my failures have been because MythTV was unable to get the tuner it thought was available. |
| [21:26:11] | jafa2: | maybe 2008 or so |
| [21:26:39] | gary_buhrmaster: | jafa2: My solution was network isolation (personal bypass for the issue). |
| [21:27:21] | gary_buhrmaster: | jafa2: But I am sure there are difference in experience. |
| [21:27:22] | jafa2: | example – mythtv starts recording one tuner 0, then you launch the HDHomeRun android app – the HDHomeRun will probably hand over control of tuner 0 to the android app |
| [21:27:44] | jafa2: | my solution was to write my own dvr :-) |
| [21:28:17] | jafa2: | still a fan of mythtv – used it from 2006 to 2014-end |
| [21:28:23] | jheizer: | My HDHR predates the DLNA abilities so I had no real dog in the fight. It just seemed like a simple patch from someone new and interested that at least gave some safe guards even in an unsupported way. Only reason I brought it up here. |
| [21:29:21] | jafa2: | lockkey set on channel tune, lockkey release when stopping = easy, clean, simple patch which will protect recordings that start ok |
| [21:29:54] | gigem: | jafa2: So are you saying that hdhomerun_device_selector_choose_and_lock() should be usable with all HDHRs? If so, then my assertion from earlier that the full change shouldn't be that hard is probably correct. |
| [21:30:18] | jafa2: | yes – that works for all models |
| [21:30:46] | jafa2: | the selector api – you build a list of hdhomerun device objects and the api picks one that is available |
| [21:31:05] | jafa2: | that is a little trickier to add to mythtv as mythtv doesn't use the device api |
| [21:31:29] | jafa2: | it uses the control and video apis directly |
| [21:33:09] | jafa2: | btw – there was some mention of applying lockkey at mythtv startup – that won't work... the HDHomeRun will release the lockkey after a short timeout if the lockkey owner isn't actively using the tuner |
| [21:34:41] | gary_buhrmaster: | jafa2: Yeah, I mentioned the expiration issue. |
| [21:35:03] | gary_buhrmaster: | jafa2: A background thread would (of course) deal with it, but ugly hack. |
| [21:35:17] | jafa2: | no :p |
| [21:35:20] | gigem: | Excellent, that they all support it. Not so excellent, that it might not be an easy addition to MythTV. |
| [21:46:33] | gigem: | Just spent a little time catching up on the ticket comments. gary_buhrmaster given what jafa2 said about the different APIs, I think static locking at start up with periodic background activity to retain the lock might be the best short-term solution. |
| [21:51:24] | gary_buhrmaster: | gigem: I would tend to agree if you want to be able to announce that this "fixes" sharing issues as a feature in the next release, but I am not a decider here. I can only offer opinions that (if you are smart) you should probably discount as yet another diatribe. |
| [21:52:16] | gary_buhrmaster: | gigem: btw, I presume that the "other" OCUR tuner has similar issues (although I have no idea how they do locking to know if there is a fix for that). |
| [21:52:40] | gary_buhrmaster: | gigem: The "ultimate" solution is probably the mythical (true) DRI recorder. |
| [21:53:03] | amessina (amessina!~amessina@unaffiliated/amessina) has joined #mythtv | |
| [22:00:15] | jafa2: | please don't do lockkey at startup |
| [22:00:38] | jafa2: | if that gets coded it will break a wide range of other apps including HDHomeRun VIEW |
| [22:01:37] | jafa2: | DRI recorder – oh god no |
| [22:02:21] | jafa2: | please grab the lockkey when you want to tune a channel, release it when done streaming that channel |
| [22:05:41] | jafa2: | on the modern HDHomeRun devices you pull the list of channels (json format) and each channel includes a http url – hit the url and it streams video (auto lockkey and auto tuner selection) |
| [22:06:16] | jafa2: | http://<ip of hdhr>:5004/auto/v2 will get tuner channel 2 |
| [22:06:36] | jafa2: | does cablecard auth, tuning resolver, etc automatically |
| [22:06:50] | jafa2: | releases tuner when the http connection closes |
| [22:07:13] | jafa2: | you can even specifify the length – add ?duration=1800 to the url to get a 30 minute recording |
| [22:14:40] | jheizer: | I didn't know the duration part. I've used the url in VLC from my parents prime over VPN before. Works quite nicely. |
| [22:17:38] | gary_buhrmaster: | jafa2: Yeah, I mentioned that (using the modern interface with http) as the solution I was considering doing in my copious free time which would also do tuner pooling. |
| [22:17:56] | gary_buhrmaster: | jafa2: Not likely to happen (from me anyway). |
| [22:18:17] | gigem: | gary_buhrmaster: It's not my call alone. I'm mainly involved because I have an HDHRP and can test any changes. I don't know what, if any, locking mechanism the Cetons have. If OCUR supports it, we certainly don't use it as we abuse the web interface to all command and control. |
| [22:18:32] | jheizer: | And the old HDHR can't do that can it? |
| [22:18:41] | jheizer: | since that is really a DLNA interface |
| [22:19:35] | jheizer: | the direct http that is, no idea on anything else so I'll shut up. haha |
| [22:20:35] | gigem: | jafa2: Would you care to write some MythTV code? :) Seriously, do the new interface also work with non-cablecard devices? IOW, can it be used to record clear QAM or OTA 8VSB? If so, perhaps we could persuade jpabq_ to work on it. He's really the only 'recorder' person we have since danielk22's departure. |
| [22:24:16] | gary_buhrmaster: | gigem: All 4th generation (and the 3rd generation Prime) support the new(er) DLNA/HTTP interfaces. |
| [22:26:17] | gary_buhrmaster: | gigem: Most of the sharing issues are going to happen with apps such as the View (and the Android Live Channels) apps, that use the newer APIs. Sure, there is the WMC and SageTV challenges, but except for initial comparision shopping, I doubt many run in a shared mode for long with multiple DVR solutions. |
| [22:27:00] | gary_buhrmaster: | gigem: Of course, there will always be those exception people (and MythTV users are an exception group). |
| [22:27:41] | gary_buhrmaster: | gigem: s/exception/exceptional/g |
| [22:32:01] | jafa2: | suggest applying lockkey on channel request, release on stream end... that is a simple few line change that will work on all devices, then we can work on http/auto-tuner-allocation when a new model is detected |
| [22:32:33] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) | |
| [22:34:24] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has joined #mythtv | |
| [22:47:38] | gigem: | jafa2: Who is this 'we' you speak of and what do you mean by 'when a new model is detected'? That sounds like exactly what we'd hoped to avoid — apply a partial band-aid now with a (empty?) promise to fix the rest some time in the future. |
| [22:56:51] | Roklobsta (Roklobsta!~Roklobsta@ppp118-209-231-37.lns20.mel8.internode.on.net) has quit (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
| [23:18:24] | paul-h (paul-h!~Paul@94.5.245.174) has quit (Quit: Konversation terminated!) | |
| [23:22:20] | jafa2: | i am happy with the old api – all models support it |
| [23:22:31] | jafa2: | just need lockkey on channel set |
| [23:22:51] | jafa2: | which I believe that patch has already been written for |
| [23:23:52] | jafa2: | the important thing is that if mythtv uses the lockkey it grabs it on tune and releases it at the end of the recording |
| [23:49:30] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [23:49:30] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [23:49:30] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.