MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (74):

aloril, amessina__, Anssi, Beirdo_, benklop, bill6502, brfransen, buu, caelor, Captain_Murdoch2, cesman, Chutt, clever, coling, Cougar, dblain, dekarl1, eharris, ElmerFudd, fetzerch, foobum, ghoti, Gibby, gigem, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer_, joki, jpabq, jpharvey, jst, jwhite, jya, jya_, kenni, kurre2, kwmonroe, laga, moparisthebest, MythBuild, MythLogBot, nephyrin, neufeld, Nothing4You, nyloc, peper03, poptix, purserj, robink, rsiebert, rsiebert___, seld, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, tonsofpcs, tris, wagnerrp_, wolfgang2, XDS2010, xris, _charly_
Monday, November 18th, 2013, 00:58 UTC
[00:58:28] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Ping timeout: 245 seconds)
[01:36:02] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv
[01:49:36] benklop (benklop!~quassel@2001:470:f400:47:ae81:12ff:fe31:668b) has joined #mythtv
[03:11:52] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out)
[03:17:04] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:30:03] nyloc (nyloc!~quassel@p3EE2DD27.dip0.t-ipconnect.de) has joined #mythtv
[03:34:26] _nyloc_ (_nyloc_!~quassel@p57B4F04A.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[03:38:25] jya__ (jya__!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[03:39:35] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:42:26] buu: Just to verify I haven't missed anything, there's no way to insert menu items without completely overwriting the menu file, right?
[03:52:36] skd5aner: buu: correct... well, in the sense that you are just inserting it in to an exisitng menu file
[03:53:04] skd5aner: buu: also, did you see my reply to you yesterday about why your logs weren't working properly?
[03:55:59] buu: Yes
[03:56:21] buu: You'd think mythtv could notice such things
[03:56:30] buu: I blame C++ option parsers
[03:59:22] skd5aner: well, yea... there are a few flags that require the "=" and some that don't... that should probably be a bit more consistant, and at the very least, documented in --help better
[04:01:36] wagnerrp: got any examples? they should all be consistent
[04:02:17] wagnerrp: in that "--a=b" and "--a b" should both behave the same
[04:02:23] buu: skd5aner: I suppose that's part of it, but I was thinking more that --logpath should require an argument and if it doesn't get one it should complain.
[04:02:34] buu: wagnerrp: Oh, well, the example in question was --logpath tmp
[04:03:01] buu: mythfrontend -v playback --loglevel=debug --logpath tmp
[04:03:23] skd5aner: buu: you also need the leading \
[04:03:23] wagnerrp: that should work
[04:03:38] wagnerrp: well... yeah, you need a proper absolute path
[04:04:00] wagnerrp: that's outside the scope of the command line parser to determine
[04:09:40] wagnerrp: i suppose there's really no reason for it to be an absolute path
[04:09:51] wagnerrp: we should be able to generate that internally, so long as the path given is a valid one
[04:12:28] skd5aner: wagnerrp: it would have to be a relative path to the working directory I would guess...
[04:13:37] wagnerrp: it would need to store an absolute path internally, or the log server would be broken
[04:15:27] buu: skd5aner: leading \ ?
[04:15:29] buu: what?
[04:15:41] skd5aner: buu: you need to define an absolute path...
[04:15:42] wagnerrp: it want's an absolute path
[04:15:47] wagnerrp: *wants
[04:15:49] skd5aner: tmp != \tmp
[04:15:57] buu: So how is \tmp an absolute path?
[04:16:09] wagnerrp: because '\' means "start from root"
[04:16:16] buu: .... it does?
[04:16:21] wagnerrp: as opposed to "start from current directory"
[04:16:33] skd5aner: sorry /
[04:16:33] buu: Even windows uses / to start from root these days
[04:16:53] wagnerrp: well which ever one
[04:16:56] wagnerrp: point still stands
[04:17:13] buu: wagnerrp: The idea that you'd need to specify an absolute path is ... really strange
[04:17:43] skd5aner: how would mythtv know where "tmp" is without a full path?
[04:17:49] wagnerrp: for the frontend, perhaps
[04:18:09] wagnerrp: for the backend, where it's typically run by init scripts, the idea that you wouldn't specify an absolute path is strange
[04:18:15] wagnerrp: and it's common code between the two
[04:18:43] skd5aner: I could have a hundred "tmp" directories... if I only put tmp, the only thing it could maybe, possibly be able to assume would that it would be relative to the cwd....
[04:19:07] skd5aner: but, I don't think it does that anyway
[04:20:16] skd5aner: not too hard to put the leading "/" in :)
[04:20:50] wagnerrp: (and the path leading up to tmp)
[04:21:16] skd5aner: yea, I'm making the assumption that like most distros, the one one he's talking about is off the root /tmp
[04:21:21] skd5aner: but, maybe not
[04:36:19] xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Goodbye.)
[04:36:28] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[04:37:38] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:44:16] xris (xris!~xris@xris.forevermore.net) has joined #mythtv
[04:44:19] xris (xris!~xris@xris.forevermore.net) has quit (Changing host)
[04:44:20] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[04:55:32] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[05:10:52] aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Read error: Connection reset by peer)
[05:30:45] jpabq: mythbackend has started aborting sometime recently. The stack in the core file is garbage, but the core file ended up getting named core.PreviewGenerato....
[05:32:32] jpabq: I was scrolling through the list of recorded shows on the frontend, each time it has happened, so that would also lend support to the idea that it is happening in the preview generator — or with dealing with images somehow.
[05:33:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[05:40:11] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[05:53:35] buu: skd5aner: Uh, obviously I wasn't talking about /tmp, or I would have put /tmp. A path is *always* relative to the cwd unless prefixed with a leading /
[05:53:56] buu: That goes doubly so when I'm telling a program where to write a file
[05:54:19] buu: This is like the basic definition of how paths work
[06:06:53] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has quit (Quit: No Ping reply in 180 seconds.)
[06:07:18] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has joined #mythtv
[06:11:52] bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv
[06:16:26] bill6502: buu: At least in 0.28-pre --logpath=blah and --logpath=./blah and --logpath=/tmp/blah all worked OK. I created /tmp/blah and did a cd /tmp there prior to testing. Are you sure the user that the MythTV command was running as had write permission.
[06:34:13] Blue1 (Blue1!~nwayno@c-98-225-103-14.hsd1.az.comcast.net) has left #mythtv ()
[07:01:54] bill6502 (bill6502!~bill@205.178.26.43) has left #mythtv ()
[07:02:28] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[07:05:56] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[07:17:40] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[07:36:22] dekarl1 is now known as dekarl
[09:24:56] stuarta: stuartm: your theories on channel groups sound interesting
[09:34:50] stuartm: would have been more interesting if I'd been able to read the DVB SI spec correctly :)
[09:34:58] stuarta: :)
[09:42:22] peper03: skd5aner: Yes, I read that thread. Certainly sounds interesting. It's something I'd thought I'd look into without having an actual schedule in mind. Menus would be certainly good to have.
[09:43:42] peper03: My single Blu-ray disc is perhaps a bit limiting in terms of ability to test, but I could probably borrow some from friends.
[10:50:11] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (Ping timeout: 245 seconds)
[10:53:38] dekarl1 (dekarl1!~dekarl@p4FCEE960.dip0.t-ipconnect.de) has joined #mythtv
[10:56:21] dekarl (dekarl!~dekarl@p4FCEEADF.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[11:38:31] coling_ (coling_!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv
[11:54:35] aberrios (aberrios!~aberrios@195.130.201.200) has joined #mythtv
[12:20:53] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 248 seconds)
[12:22:05] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[12:28:33] peper03: buu: Could you try http://pastebin.com/mgmGsDFc and see whether the DVD plays? That isn't a final fix. It just comments out the bit of code that's causing it to jump back. It looks like the subpicture packets aren't being processed, but from the traces I can't tell why. I'd be interested to know whether the disc plays OK without that safety check.
[12:34:09] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 252 seconds)
[12:34:35] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[13:18:05] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[13:35:21] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131028113308])
[13:56:45] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[14:25:29] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 272 seconds)
[14:32:29] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[14:32:37] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 248 seconds)
[14:47:35] coling_ is now known as coling
[15:39:15] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[15:42:07] _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has quit (Ping timeout: 272 seconds)
[16:30:15] stuartm: dblain: GetProgramGuide is inconsistent with the GetRecordedList and other end points in the why that it returns total/range information, if I change it to match everywhere else, should it still accept the old arguments or do we go for a clean break?
[16:30:15] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[16:30:37] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[16:32:26] stuartm: e.g. NumOfChannels/StartChanId vs TotalAvailable/StartIndex
[16:37:08] stuartm: it also returns the number of programs in Count instead of the number of channels, which is inconsistent
[16:50:53] aberrios (aberrios!~aberrios@195.130.201.200) has quit (Quit: leaving)
[16:57:41] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:09:41] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[17:09:43] dblain: stuartm: I'm all for consistency, but I do want to be careful about breaking clients. We have other breaking changes already commited... right?
[17:12:03] dblain: It would be interesting to know how may clients currently use the Services API.
[17:12:13] stuartm: nothing which breaks backwards compatibility, at least nothing I can recall. There some differences in the ordering of results for GetProgramGuide() but nothing that should adversely affect anyone
[17:12:39] stuartm: everything else has been extensions/additions, and a few bug fixes
[17:13:41] stuartm: could be something I'm forgetting, I'd have to go back over the logs to refresh my memory
[17:14:11] dblain: What do you think? Make 0.28 an API cleanup release, not worring about backward compatibility, or should we stay the course and worry about breaking clients?
[17:17:12] ** dblain is kicking himself for not worring about the API "Big Picture" in the beginning (was focused too much on the framework ) **
[17:21:13] dblain: If I had more time, I'd like to design the entire API, and write stubs for all the methods/services. That way everyone would know the intent of the API, how to use it, and other devs could flesh out the implementation when there was need for a particular method.
[17:22:37] dblain: But I know I can't commit that amount of time. So, if anyone is interested...
[17:25:57] jheizer: FilteredStreamList I believe is the only breaking change I have encountered since starting with .25 services.
[17:26:37] jheizer: .27 has some helpful additions, but I had already worked around then and would still need them for < .27 support
[17:29:11] stuartm: dblain: I think the best idea might be a middle ground, go for API consistency (names, arguments, object values) while trying as best we can to still return the older stuff but deprecating it and marking it for removal in some future release
[17:29:43] dblain: stuartm: works for me.
[17:30:46] ** dblain wonders if there is a means of marking a method/parameter/data property as depricated in WSDL **
[17:31:28] stuartm: at the same time we can perhaps build in a deprecation mechanism – no quite sure how it would work – a deprecated attribute maybe ? Does json even have attributes?
[17:31:32] stuartm: dblain: heh
[17:32:05] stuartm: dblain: when I googled it last week the answer seemed to be no, but I didn't dig into the wsdl spec to check
[17:32:25] skd5aner: stuartm, dblain: how about just versioning the API so that you can keep backwards compatibility while refactoring/adding new functionality?
[17:33:39] skd5aner: Here's some good suggestions I've referenced in the past related to good API versioning practices – https://blog.apigee.com/taglist/versioning
[17:51:24] buu: Step 1 for API Cleanup) Burn down WSDL
[17:51:25] buu: =]
[17:54:12] jheizer: Can't say I can offer any advice on the versioning either. I have always been working in a 1:1 custom code on each side kind of place.
[17:58:56] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:05:50] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:06:28] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:07:23] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:09:28] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:09:38] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:11:11] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:20:47] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[18:21:02] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:21:31] gregL__ (gregL__!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:21:44] stuartm: wsdl is doing no harm, it's entirely optional and is generated automatically from the code
[18:22:47] stuartm: soap/wsdl do suck, but as long as I don't actually have to deal directly with it I'm happy to leave it alone
[18:25:45] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:25:45] gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:25:45] gregL__ (gregL__!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[18:26:18] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:49:09] dblain: buu: wsdl/soap, although a little bloated, "just works" when then language has good support for it. I know it makes calling the services API a no-brainer from .net/c#
[19:15:10] bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv
[19:19:14] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[19:28:35] rsiebert___ (rsiebert___!~quassel@g226062135.adsl.alicedsl.de) has quit (Remote host closed the connection)
[19:31:41] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[19:42:01] bill6502: stuartm: So far, the only thing that 'broke' MythTV Android Frontend was the change of CommFree from int to bool. Channel/GetChannelInfoList had: <CommFree>0</CommFree>, now it's: <CommFree>false</CommFree>. code.mythtv.org/trac/changeset/7c6cd81 . The json parser wasn't happy.
[19:44:39] stuartm: bill6502: ah, didn't expect that to break anything, expected that the type change would be reflected in the wsdl but I guess it's not as though you're versioning the wsdl ...
[19:46:30] bill6502: the client side api is generated by wsdl, but it's only used once to create the code, not at run time.
[19:49:33] buu: dblain: Yeah but C# is the only language that can actually use it =/
[19:49:36] stuartm: of course
[19:51:42] jheizer: Isn't it also commonly used in java?
[19:51:44] dblain: buu: Actually, one of my todo list items (although low on the list now), was to create a Qt tool that would use the WSDL to generate client proxy classes, for use by mythfrontend or other Qt applications.
[19:51:48] stuartm: bill6502: what I meant was that you had different versions of the parser for different versions of the API, but I don't know whether that's really very practical and it means pushing out updates every time there is such a change
[19:53:02] buu: dblain: Well, I'm mostly just being snarky and I haven't looked into the details of your code, but I like to do all I can to encourage people to move away from the mistake that was SOAP, especially if it can in anyway clean up/simplify the code base =]
[19:53:54] dblain: I'd gladly move away from soap, if you can provide a clean, system agnostic replacement.
[19:53:58] buu: Also I just spent the past week attempting to interoperate with "standardized wsdl formats" and as a result I now have 50% less hair.
[19:54:13] stuartm: buu: in our case offering it costs us nothing, it's just one of several options we offer for the services API and requires no maintenance on our part
[19:54:30] dblain: buu: :) You can say that about most "Standards"!
[19:54:49] stuartm: you don't need to use Soap to use the services API
[19:54:54] buu: (There's so many to choose from1)
[19:54:58] buu: !
[19:55:05] jheizer: While SOAP is a bit of a mess, automatically generated and maintained serialization obejcts and calls make it stupid easy to use, Nothing to maintain yourself in turn.
[19:56:22] buu: jheizer: Sure but the problem is the automatically generated stuff is incredibly hard to use from any other language, it tends to expose too much of your internal details, it encourages people not to think about the actual public API, etc.
[19:56:52] buu: dblain: As for clean and agnostic, you already support JSON over REST right? Why not just standardize on that?
[19:57:07] dblain: buu: That said, I designed the Services API Framework to allow for any type of serialization or transport. It currently supports Form POST, REST, POX, SOAP with JSON, XML and p-list serializers
[19:57:55] buu: That sounds fairly clever
[19:58:02] dblain: buu: I wanted a implement one, call by may client types... type of design. I think I achieved it for the most part
[19:58:19] jheizer: buu; using the JSON calls directly I would have to maintain 30+ classes for serialization
[19:58:20] buu: But I'm not sure how you can have a sane REST interface that also matches SOAP without designing them completely differently
[19:58:33] buu: jheizer: How do you mean?
[19:58:43] buu: JSON is a fairly generic structure =]
[19:59:47] jheizer: I rather have results deserialize into a typed/property object than hand access each property bu string
[20:00:47] dblain: buu: The current design is to implement the service as a QT Class, with public slots as the service methods. Any structures passed around needs to be in a data only QT Class where everything is a property. Once done, the Framework does the rest in exposing all the serialization types and protocols
[20:01:53] dblain: It even allows the services to be exposed via the Qt Script engine (used by our server side scripting of html pages)
[20:04:30] buu: I see.
[20:05:06] buu: And you just map these class/method combinations to URIs to implement the "REST" interface?
[20:07:01] dblain: That is done automatically by the framework. When we register the serice, we give it a root url. The framework handles the rest. It uses Qt's introspection (metadata) at runtime to now if it should be a POST or GET, and what the method and parameter names/types are.
[20:08:30] stuartm: the following commit added a new method to the API, complete with two new serialised objects (immediately usable for all protocols and the script interface) – http://code.mythtv.org/cgit/mythtv/commit/?id . . . 24f9acd6c3bb
[20:10:11] dblain: thanks stuartm, an example is worth a 1000 words! :)
[20:11:27] stuartm: that's about as complicated as it gets, there are simpler examples, I picked that one just because it did include examples of object/containers, without those it's just a case of two lines in two headers and the actual definition of the method in a .cpp
[20:11:31] dblain: buu: Although there is room for improvement/enhancments, I'm very proud of the simplicity of my design
[20:14:03] buu: Cool.
[20:14:08] stuartm: here's one as I just described, no new objects, just new methods – http://code.mythtv.org/cgit/mythtv/commit/?id . . . fb9248674ef6
[20:14:43] buu: If I was nitpicking though... doesn't this expose a lot of your internal implementation as part of the API?
[20:14:48] stuartm: the relevant changes in that commit are the ones touching dvr* – the mainserver change wasn't services related, just an internal change to make the implementation easier
[20:15:32] stuartm: buu: these are simplified wrappers for existing internal classes, they don't expose anything more than they need to
[20:15:48] buu: Ah
[20:15:56] buu: So you have a separate set of service specific classes
[20:16:05] dblain: buu: they can be password protected as well if/when we want to
[20:16:22] dblain: buu: yes
[20:16:34] buu: Sounds like a fairly quick way to accomplish the goal
[20:17:28] stuartm: that means we can re-factor internally without changing the external API
[20:19:08] buu: Yeah, that's pretty important.
[20:21:26] stuartm: I wish I hadn't started adding lazy loading to the guide, it's become very complicated
[20:21:28] buu: This may be getting into complex details I haven't gotten to study yet, but why does UndeleteRecording appear to dispatch a string based command to gCoreContext? Obviously I have little knowledge of the internals but I would have expected that to be a method call there?
[20:21:57] buu: Is that because this is a service thing or is that just an implementation detail of the backend?
[20:22:24] stuartm: straight lists such as recording, upcoming, recrules etc are straightforward and it works well there, but the guide has to maintain state in multiple dimensions :/
[20:24:08] buu: Oh and uh, is there any particular reason mythfrontend thinks pulseaudio is a 2.0 output source?
[20:25:14] stuartm: buu: it's not dispatching it to gCoreContext, but having gCoreContext dispatch it as an event to all connected frontends and backends – you could have a method in gCoreContext but we choose not to in this case
[20:25:37] stuartm: the file we're deleting or undeleting may be local or it may be on a remote slave backend etc
[20:27:54] stuartm: if I added an undelete method,it would probably be in the RecordingInfo class, it would then just do exactly what is done there – conceptually better so I'll probably do that when I have the time
[20:28:39] buu: Ohh, I see.
[20:28:53] buu: I forgot about the distributed nature of the system.
[20:29:31] joki (joki!~joki@p548605B7.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[20:30:43] stuartm: buu: jya is the audio guy and may know the answer, generally around here we have a low opinion of pulseaudio and often recommend disabling it unless you've got a good reason for using it
[20:31:28] rsiebert (rsiebert!~quassel@g226062135.adsl.alicedsl.de) has joined #mythtv
[20:31:35] buu: That's unfortunate. It does a lot of nice things with replacing fixing the linux audio infrastructure
[20:34:08] stuartm: it adds a layer of confusion and complexity to an already confused and complex audio infrastructure, it doesn't replace anything, it's a band-aid (plaster)
[20:34:33] joki (joki!~joki@p54862D75.dip0.t-ipconnect.de) has joined #mythtv
[20:35:52] stuartm: OSS 4 was the better solution, replaced ALSA with a much better infrastructure and provided a very nice userspace API, but politics being what they are ...
[20:39:18] anykey_ (anykey_!~guedel@kladde.org) has joined #mythtv
[20:39:24] anykey_ is now known as blafoo
[20:44:45] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection)
[20:51:30] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[20:59:50] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[21:03:46] _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has joined #mythtv
[21:29:14] stuartm: perhaps someone with a huge number of recordings can test the WebFrontend recordings page in master, let me know whether the lazy loading stuff keeps it fast to load/respond without getting in the way?
[21:33:11] dotcomslashnet (dotcomslashnet!~dotcomsla@82-68-176-70.dsl.in-addr.zen.co.uk) has joined #mythtv
[21:34:46] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:36:04] blafoo (blafoo!~guedel@kladde.org) has left #mythtv ()
[21:37:51] stichnot: stuartm: I have about 3K recordings, but I'll have to wait until I get home to test
[21:39:57] stuartm: that'll do, I only have 450 in the default recording group
[21:40:47] stichnot: stuartm: I have a couple of WFE wishes that I haven't mentioned yet. 1) If I want to refresh the recordings page or upcoming recordings page, I'm accustomed to using the browser Reload button or key, but this doesn't really work for WFE since it brings me back to the start page. If the navigation state could be encoded in the URL, or if there were a "refresh" button on the page, it would...
[21:40:49] stichnot: ...help a lot.
[21:42:15] stuartm: stichnot: we'll probably be switching to using includes instead of the current ajax driven 'frame' stuff, so that will fix it and also allow bookmarks to be created
[21:43:34] stichnot: 2) I'd love to be able to filter the Upcoming Recordings by Inactive state. I have a "First Episodes" rule (see customedit.cpp) which is inactive, which I look at from time to time to find new shows to record.
[21:43:50] stichnot: includes sounds good, thanks.
[21:44:57] stuartm: stichnot: noted
[21:46:49] stichnot: For (2), mythweb has a "Deactivated" display filter which works in a clunky way – I have to look for items where the Status field is blank (as opposed to Earlier or Later), and sadly I can't sort by Status so I have to wade through the whole list
[21:51:45] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Read error: Connection reset by peer)
[21:51:51] jheizer_ (jheizer_!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[21:59:44] stuartm: yeah, shouldn't be too difficult to add, looks like it means modifying the services API again
[21:59:52] stuartm: assuming it's done properly
[22:02:20] amessina_ (amessina_!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[22:03:14] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 264 seconds)
[22:10:47] stichnot: And for true awesomeness (since I don't have to pay to send out random suggestions :) ), those upcoming deactivated recordings would be filtered to a channel group, since only a few channels *ever* have new series worth considering. (Or maybe I could just modify the recording rule?)
[22:14:15] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[22:29:41] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:42:16] stuartm: actually, that's a fantastic idea, being able to restrict recording rules to groups would avoid all sorts of title collisions – happens frequently here with a radio program sharing the name of a tv show
[22:43:07] stuartm: so in fact both 'only this group' and 'not this group' type filters by channel group would be very useful
[22:43:49] stuartm: it's more gigem's area than mine
[22:53:02] stichnot: For me, I would use a channel group filter for e.g. HBO programs that can show up on any of 7 HBO channels, but later go into syndication on irrelevant channels
[22:59:30] rsiebert_ (rsiebert_!~quassel@g226060091.adsl.alicedsl.de) has joined #mythtv
[23:01:31] rsiebert___ (rsiebert___!~quassel@g226060091.adsl.alicedsl.de) has joined #mythtv
[23:02:07] rsiebert__ (rsiebert__!~quassel@g226062135.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[23:02:15] rsiebert (rsiebert!~quassel@g226062135.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[23:06:37] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 272 seconds)
[23:07:32] rsiebert_ (rsiebert_!~quassel@g226060091.adsl.alicedsl.de) has quit (Remote host closed the connection)
[23:09:50] rsiebert (rsiebert!~quassel@g226060091.adsl.alicedsl.de) has joined #mythtv
[23:11:21] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[23:22:44] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[23:26:28] rsiebert (rsiebert!~quassel@g226060091.adsl.alicedsl.de) has quit (Remote host closed the connection)
[23:31:06] rsiebert (rsiebert!~quassel@g226060091.adsl.alicedsl.de) has joined #mythtv
[23:31:14] stuartm: Captain_Murdoch2: earlier this year you added GetTitleInfoList – how is that different from GetRecordedList ?
[23:34:19] stuartm: let me rephrase, could it not be implemented via an additional argument to GetRecordedList?
[23:36:01] amessina__ (amessina__!~amessina@50-196-241-78-static.hfc.comcastbusiness.net) has joined #mythtv
[23:36:50] amessina_ (amessina_!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 264 seconds)
[23:45:43] dotcomslashnet (dotcomslashnet!~dotcomsla@82-68-176-70.dsl.in-addr.zen.co.uk) has quit ()
[23:49:38] skd5aner: peper03: cool, no agenda on my part – just curious of your take on it given your area of expertise :)
[23:54:42] skd5aner: stichnot: I have a very similiar rule to the one you describe for premiers/pilots. It's a custom rule, that I too keep inactive, but look at the upcoming episodes to see if there's anything I want to set up a rule for... I basically have just included a lot of "IS NOT" statements in the SQL to exclude a bunch of channels, especially the shopping ones
[23:55:11] skd5aner: stichnot: there's probably other ways of doing it based on show category, channel groups, etc...
[23:58:35] skd5aner: stuartm: hey, just as an FYI, mythbackend is still consistently crashing for me each day... luckily upstart is able to restart it when it does segfault, but my slave backend will never reconnect, it has to be restarted manually

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