:: #mythtv

Daily chat history

Current users (64):

aloril_, amessina, Anssi, arescorpio, caelor, Captain_Murdoch2, cesman, Chutt, clever, coling, Cougar, dblain, dekarl, eee-blt, ElmerFudd, fetzerch, FrankD_Work, Gibby, gigem, gregL, GreyFoxx_, jams, jarle, jarryd, jheizer_, joki, jpabq, jwhite, kc, kormoc, kurre2, mad_enz, moparisthebest, MythBuild, MythLogBot, nephyrin, nyloc, peper03, poptix-, purserj, RedPenguin, rhpot1991, robink, rsiebert_, ryan_turner|MTW, seld, Sharky112065, sphery, sraue, stichnot, stuartm, superm1_, taylorr, tgm4883, toeb_, tonsofpcs, tris, unforgiven512, wagnerrp, Warped, wseltzer1, XDS2010_, zentec, _charly_
Sunday, July 6th, 2014, 00:07 UTC
[00:07:05] moparisthebest (moparisthebest! has quit (Ping timeout: 252 seconds)
[00:11:44] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:33:13] dumnut (dumnut!~dumnut@2605:a000:140c:e055:869:1d51:924d:13cc) has quit (Ping timeout: 252 seconds)
[00:35:07] dumnut (dumnut!~dumnut@2605:a000:140c:c088:c5b4:dd8e:d28c:164b) has joined #mythtv
[00:41:20] jya: dekarl: it could also be that nothing was repeated in regards to delete[] vs free(), because the buffers were actually never freed !
[00:41:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:59:33] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[01:03:27] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:03:33] gregL (gregL! has quit (Ping timeout: 240 seconds)
[02:17:24] gregL (gregL! has joined #mythtv
[02:25:02] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:43:51] arescorpio (arescorpio! has joined #mythtv
[02:47:08] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 260 seconds)
[02:49:05] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:07:13] CrypticSquared (CrypticSquared!~CrypticSq@unaffiliated/crypticsquared) has quit (Quit: Leaving...)
[03:19:30] CrypticSquared (CrypticSquared!~CrypticSq@unaffiliated/crypticsquared) has joined #mythtv
[03:35:38] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 240 seconds)
[03:37:17] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:42:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[03:50:35] wagnerrp: re #12201, do we actually have any internal use for timecode-based cutlists?
[03:50:35] ** MythLogBot **
[04:42:49] aloril (aloril! has quit (Excess Flood)
[04:42:56] caelor (caelor! has joined #mythtv
[04:43:02] aloril_ (aloril_! has joined #mythtv
[04:43:05] caelor_ (caelor_! has quit (Quit: No Ping reply in 180 seconds.)
[04:43:18] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Excess Flood)
[04:59:58] dekarl: I understood it as frame based cutlist represented in time codes for the edit-decision-list feature of xbmc. but the implementation should be redone
[05:03:08] knightr (knightr! has joined #mythtv
[05:03:08] knightr (knightr! has quit (Changing host)
[05:03:08] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[05:09:34] dekarl: also need to look if the data for the cutlist / commercial list is available on the service api
[05:11:44] arescorpio (arescorpio! has quit (Excess Flood)
[05:20:00] dekarl: I'm not finding such a service
[05:42:36] wseltzer (wseltzer! has quit (Ping timeout: 240 seconds)
[05:48:41] wseltzer (wseltzer! has joined #mythtv
[06:25:58] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[06:25:58] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[06:26:21] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[07:27:32] robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 240 seconds)
[07:30:06] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[07:42:57] dekarl1 (dekarl1! has joined #mythtv
[07:43:28] dekarl (dekarl! has quit (Ping timeout: 260 seconds)
[08:33:37] caelor: urgh. I'm now remembering why I don't rescan my channels very frequently (FreeSat DVB-S). Is it still the (long term) aim to bring channel scanning into the backend so it can be done through the web interface?
[08:35:56] caelor: I'd like to help try and streamline channel scanning, but given it's basically "one size fits all" for the entire world, it seems like any dev work I might put towards it runs the risk of breaking some use case I hadn't realised existed
[08:47:48] dekarl1: caelor: fixibg bugs would be appreciated. e.g. make DVB vs. MPEG vs. SCTE detection more stable. or looking into why the second scan without restarting setup gives a different result
[08:48:19] dekarl1 is now known as dekarl
[08:52:24] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:52:38] jya_: janbar is the one developing and maintaining the mythtv xbmc plugin. But my understanding was that he was dropping libcmyth and instead was focusing on using the service API
[08:52:55] jya_: so he pull request is a bit strange
[08:53:25] dekarl: jya_ I was wondering the same, maybe he's pushing left over patches from his old work?
[08:59:37] jya_: reading on xbmc, i wonder if by backend API, he means the myth protocol
[09:11:30] paul-h (paul-h!~Paul@ has joined #mythtv
[09:13:29] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[09:15:05] paul-h: jya: I should have remembered to add the path when running external apps after the last time you mentioned it – I'll add it shortly
[09:15:19] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[10:18:48] dekarl: appears to implement a mix of service api and native protocol
[10:20:03] dekarl: nice, the doxygen documentation is directly available at
[10:48:12] paul-h: What should type pid_t be initialised to?
[10:50:14] paul-h: Looks like the underlying type is an int
[10:54:09] stuartm: paul-h: not sure if pid is zero-indexed, -1 would be safest for that reason
[10:57:00] peper03: The thread on the -users list started by the guy whose daughter has a broken HDMI cable reminds me of the joke about the guy stopping to ask for directions only to get the reply 'If I was going there, I wouldn't start from here'
[10:57:54] peper03: Never ceases to amaze me how the Internet manages to do that to so many supposedly simple questions...
[10:58:34] stuartm: ok, seems a pid of zero is technically valid – . . . ss-has-pid-0
[11:00:38] stuartm: peper03: yeah, it's something that seems to be out of hand in this community in particular, sometimes it's good to be able to tell people that there is possibly a much better, easier way to do what they are attempting but there are a lot of people who refuse to answer the original question "because you're doing it wrong"
[11:15:18] andreaz (andreaz! has joined #mythtv
[11:15:51] dekarl: peper03: after all his daughter will be puling new wires soon and has a use for these lessons... oh and our lists are searchable, so the next person can avoid the traps
[11:16:34] dekarl: and our community can't be so bad when I hear "I ask the mythtv community becuase they are responsive"
[11:18:30] dekarl: i wonder why no one suggested the obvious '"its just for three weeks" solution of a loose wire and some cable clamps
[11:21:57] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[11:25:07] dekarl: but maybe that's just me having no idea what walls in the US are like ;)
[11:25:49] paul-h: stuartm: Ok thanks I'll go with -1 it's only to keep Coverity happy it's actually set by a call to fork() before it's used anyway
[11:26:23] dekarl: stuartm, is this page ever going to come back? maybe a redirect to the report at their site is enough?
[11:30:45] stuartm: dekarl: haven't figured out yet whether they've just closed their API to Scan (free) users, or whether they just changed it in a way that means the script needs updating
[11:31:51] stuartm: if the former then I'll have it link to their site, but it will only be accessible to devs and selected contributors since we can't make the report public (coverity's rules, not ours)
[11:36:58] stuartm: registering for a coverity forum account now, will ask about whether we're still allowed to use the API
[11:39:00] dekarl: looking forward to an update (I like having the various reports easily available like it was until it broke)
[11:46:13] natanojl: paul-h: Thank you for aa9066fe and d3360f28 ;)
[11:48:14] caelor: dekarl – I'll look into what I can do, but unfortunately any of the scanning bugs I've seen in the past seem to be fixed, and the underling design (and expected behaviour) is something I've not yet got my head around
[11:49:37] caelor: I've not noticed any inconsistencies between rescans, my issue is more to do with with consistency of channel data across sources – aligning callsign, channel numbers and xmltvid
[11:54:32] caelor: as I understand it, schedules direct provides a mapping between a channel source and the scanned channels (effectively the xmltv mapping in DVB land), whereas that mapping is still a manual process in the rest of the world?
[12:00:05] dekarl: caelor: well, for the UK there's Nick's maps of DVB IDs to his own XMLTV IDs
[12:00:55] dekarl: having a collection of DVB channel scans linked to the XMLTV channel IDs of various grabbers could be useful
[12:01:48] dekarl: might link to logos and other data while at it. (e.g. the french logo database effort, the uk atlas effort, the new SD API, etc pp. everyone is inventing their own wheel :(
[12:01:50] caelor: yes, it was that kind of correlation data I was thinking about
[12:03:31] dekarl: I'm thinking about a "DVB table collector" that can scan/collect the SDT/EIT of a network so we software developers can make sense of the data
[12:03:36] caelor: it would be nice if we could say "I expect Freesat on thiis capture device", and magically everything else just worked
[12:04:23] caelor: that would be useful, because if nothing else that data would be the start for background rescanning (e.g. updating for channels that move without manual intervention)
[12:04:42] dekarl: caelor, have you seen that already? . . . ;view=markup
[12:07:51] caelor: I'd seen that before, but the issue at the time was it seemed to be significantly out of date and looked like it'd be abandoned
[12:08:52] caelor: it also seemed to be aligned with xmltv releases, whereas the lineus typically change far more frequently
[12:09:33] dekarl: its part of the supplemental data files, see
[12:10:16] caelor: within the lineups directory, the most recently updated file was 13 months ago (for Virgin HD). There's also the issue that the RT data doesn't have any of the new channels
[12:10:18] dekarl: thats the mechanism that is used to get quick updates to the fixups rolled out without waiting for packages etc
[12:11:05] caelor: ok, so the issue is more likely that there's a lack of fixes/updates being sent upstream
[12:14:33] caelor: do we have any way of making use of the lineup data within myth? there's obviously the dvb channel information, which could be used to correlate between channel scan results and xmltvids
[12:14:34] dekarl: I'm not sure if Atlas already carries the data you are looking for. But my bet is that someone will have to jump an and start a shared metadatabase that collects and maps the data
[12:15:14] dekarl: caelor: we could import it into the logo service and use it to automatically seed the DVB id to Logo map
[12:15:18] dekarl: but thats about it
[12:15:59] dekarl: hence me thinking that a central collection of channel scans would be useful that allows to add references to XMLTV etc
[12:16:58] dekarl: I used random channels.conf files I found on the internet to seed my data buts its just an unfinished experiment
[12:17:03] peper03: dekarl: It's not that the suggestions are invalid just that he originally asked if anyone had tried a wireless solution and if so, how was it? For myself, I'd understand that there's no guarantee that if wireless works for one person, it'll definitely work for me, but a series of "doesn't work" or "works for me" would give me a feeling for whether to bother trying.
[12:17:44] peper03: Plus, I don't remember a single reply in the thread where anyone had actually tried it (i.e. an answer to his original question).
[12:18:32] caelor: ok. My C++ is rusty/non-existent, but I could look into a proof of concept python script that could possibly make a start feeding data into a database, and keeping the mythdb updated according to the central db.
[12:18:51] caelor: if I came up with a schema, is it something that might be hosted on the mythtv infrastructure?
[12:19:48] caelor: I suspect the information could also be used to provide updates back to the xmltv linenups
[12:20:03] dekarl: peper03: well, this one got close . . . /365468.html
[12:20:16] peper03: It's not a huge deal. I'm not disgusted/disillusioned/whatever. Just caught my attention that there were so many replies not actually answering the question posed but still doing the usual thing of going off at a tangent until the responses are recommending how best to get ethernet over power lines...
[12:21:42] dekarl: btw, thanks for getting back to the commflag user on the german forum
[12:22:03] peper03: dekarl: Yes, that's as close as it got .
[12:22:53] peper03: dekarl: No problem. No further replies, so I guess he's either fixed it or given up.
[12:24:21] caelor: one question – what does the backend need to pick up changes to the channels table (not that I'm thinking of updating scanning info in the background at the moment, just curious)?
[12:28:52] caelor: if you did add the recording of SDT/EIT in the background, for developer use, then it's possible that the central database could be updated with scan results on an opt-in basis
[12:49:13] andreaz (andreaz! has quit (Read error: Connection reset by peer)
[13:26:33] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 240 seconds)
[13:29:18] CrypticSquared (CrypticSquared!~CrypticSq@unaffiliated/crypticsquared) has quit (Remote host closed the connection)
[13:29:58] CrypticSquared (CrypticSquared!~CrypticSq@unaffiliated/crypticsquared) has joined #mythtv
[13:34:30] CrypticSquared (CrypticSquared!~CrypticSq@unaffiliated/crypticsquared) has quit (Ping timeout: 255 seconds)
[13:35:16] stuartm: dekarl: huh
[13:46:13] dekarl: stuartm: see, you have at least one user :D
[13:46:34] dekarl: (of that function)
[13:47:46] stuartm: copy paste error, although I'm not sure why I hadn't noticed
[14:23:55] caelor: dekarl if there's passive SDT monitoring, might it be worth adding a "last seen in SDT" column in the channel table? That way we could easily clean up channels which vanish, or it could possibly contribute to detection of failed recordings (e.g. if no data in ringbuffer after 30s, and channel last seen >24hs then assume failed)
[14:32:29] knightr_ (knightr_! has joined #mythtv
[14:36:23] wseltzer1 (wseltzer1! has joined #mythtv
[14:38:31] robink_ (robink_!~quassel@unaffilated/robink) has joined #mythtv
[14:40:14] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv
[14:41:56] robink (robink!~quassel@unaffilated/robink) has quit (*.net *.split)
[14:41:56] wseltzer (wseltzer! has quit (*.net *.split)
[14:41:56] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (*.net *.split)
[14:41:56] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (*.net *.split)
[14:41:57] mad_enz (mad_enz! has quit (*.net *.split)
[14:41:57] peper03_ is now known as peper03
[14:45:26] joki (joki! has quit (Ping timeout: 252 seconds)
[14:46:21] caelor: jya_ – just wanted to say thanks for your work on livetv – with the F1 today overrunning, and me watching it with livetv I'd have missed the end if it wasn't for your fixes (I was running about 10 minutes behind real time).
[14:49:56] mad_enz (mad_enz! has joined #mythtv
[14:51:46] joki (joki! has joined #mythtv
[15:43:41] dekarl: caelor: sounds like an idea. notice that soe broadcasters remove off-air channels instead of marking them as "not running" so a station that is only on Mon-Fri 9–17 will be "missing" > 50 hours
[16:35:25] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[16:43:59] jya__ (jya__! has joined #mythtv
[16:44:15] jya__: paul-h: In . . . 98b67/mythtv
[16:44:33] jya__: Are you sure the include of a boost header is required?
[16:46:21] jya__: stuartm: In regards to #12199, I don't understand how simply scrolling could cause a request to the backend to open a recording... Or is it supposed to be the request to an image?
[16:46:21] ** MythLogBot **
[16:47:22] natanojl: jya__: That was removed in . . . 8a477/mythtv
[16:47:54] jya__: wagnerrp: ill take over #12149, cant let stuff like that not be looked after for extensive period of time
[16:47:54] ** MythLogBot **
[16:48:22] jya__: natanojl: Thanks!
[16:48:34] natanojl: np
[16:48:38] stuartm: jya__: it would be an image, probably the preview image since my theme doesn't display channel icons there
[16:49:14] jya__: How long do you have to scroll before you see that?
[16:49:57] stuartm: jya__: wagnerrp was saying he has a patch for #12199, which is the only reason I didn't take the ticket a couple of days ago
[16:49:57] ** MythLogBot **
[16:50:36] jya__: So you're in the watch recording screen, you start scrolling quickly say by holding the down arrow key, and you just wait for it to happen
[16:50:42] stuartm: jya__: no fixed duration, sometimes I can scroll through the whole list without triggering it, other times between a 1/3 and 2/3s of the way through
[16:50:47] stuartm: jya__: yes
[16:51:53] jya__: stuartm: wagnerrp appeared to be extremely busy these days, bugs he has accepted usually don't get looked after for months.... (And it has happened to me yesterday for one of my recording.
[16:52:57] wagnerrp: i broke the grabbers out into a separate caching handler that uses the name as the tag, and allows grabbers to specify tags they support
[16:53:37] wagnerrp: it basically just needs to be tied in, and there's some header reference issues to deal with
[16:53:50] jya__: How long would that take?
[16:54:01] wagnerrp: maybe a few hours to get it working
[16:54:42] jya__: Because otherwise, I have no problem doing it in the next hour
[16:55:02] jya__: Seeing that I can't sleep anyway thanks to jet lag
[16:55:20] wagnerrp: i'll get something up for testing by tonight
[16:55:28] jya__: Cool
[16:55:43] dekarl: I started to peek at the "grabber guesser", too. I though setting season 1, episode 0 instead of 0 0 as default might help to guess the correct grabber.
[16:56:41] jya__: I'd like if we could set a grabber per directory like they do in XBMC
[16:56:59] jya__: All my TV videos are in a dedicated folder
[16:58:14] jya__: Was also thinking of completely changing the way files are scanned. Let the backend do the scan. And then you can review the outstanding list of unresolved names or conflicts via a menu entry
[16:59:34] jya__: Right now the scan code is crap, there's racing conditions everywhere, if you dare to exit the video screen, chances the frontend will crash, and when the stuff to choose a conflict in metadata resolution appear, you can't even tell which video it refers to
[17:00:20] jya__: The way mythmusic does the scanning is much nicer... A notification when it starts, and another when it's done
[17:01:36] jya__: wagnerrp: The change for #12149 can't require a db schema change. It needs to be backported quickly to 0.27
[17:01:36] ** MythLogBot **
[17:02:21] jya__: I know you had mentioned that it required it earlier on... That's not a good solution I'm afraid
[17:03:00] wagnerrp: ideally it would have a schema update, so all the inetrefs could be updated with their respective grabber globally at once
[17:03:15] wagnerrp: but i could make it take a guess if no tag is listed in the inetref
[17:04:15] jya__: We know when we retrieve a inetref where that inetref come from. So just pass that as an argument when it comes to retrieving the information..
[17:05:00] wagnerrp: that's what i mean. all the existing inetrefs stored in the database, we don't know where it comes from
[17:05:02] jya__: That the grabber does it in two parts, first get the inetref, then retrieve the inetref without any regards of where that inetref relate to already doesn't make much sense
[17:05:33] jya__: Well, that doesn't matter. The issue is retrieval of new ones. It's always been when the issue occurred
[17:06:10] wagnerrp: without a schema update, we'll just trickle in the changes when users update their data as was done during the transition from IMDB to TMDB
[17:06:15] jya__: For existing wrong entry, well, too bad.. But at least it won't happen again
[17:06:37] jya__: That's not how I had picture it.
[17:06:59] jya__: Right now it is done in two steps. First is find the inetref
[17:07:24] jya__: Then once the inetref is found, the grabber is called again, but with just the inetref
[17:07:55] jya__: So the grabber is now trying either tmdb or tvdb
[17:08:02] jya__: That's just silly
[17:09:00] wagnerrp: right. now the inetref will permanently carry the name of the grabber that returned it
[17:09:05] wagnerrp: so grabber selection will only occur once
[17:09:19] dekarl: actually I'd like us stored the "domain" e.g. "seriesid from thetvdb" so we can later switch to themoviedb's tv section but still use the thetvdb ids (helps with matching to eg)
[17:10:16] jya__: After the inetref is found (and there you know where it's coming from), you call the metadata lookup right then with -type TV/movie, and that's it problem solved ... Sure storing the type is better, but that requires a db change
[17:11:09] jya__: Though instead of storing the inetref, we can store TV/inetref or movie/inetref no db change required, and we can make that easily backward compatible
[17:11:53] jya__: Just check for a patter in the inetref record
[17:12:00] wagnerrp: dekarl: i've added an "accepts" tag to the grabber version response
[17:12:21] wagnerrp: so a future "" could specify that it accepts "" inetref numbers
[17:14:20] dekarl: hmm, could set category_type (movie / series) on match
[17:14:46] jya__: That too
[17:15:06] jya__: I don't see why we need a db change. There's enough field to make use of
[17:15:20] wagnerrp: not explicit enough, since for example thetvdb and ragetv are going to carry different indexes
[17:15:41] wagnerrp: there's not going to be a change in the schema
[17:16:03] wagnerrp: but the inetrefs contained within the database will need to be updated at some point with their respective tags
[17:16:28] wagnerrp: the question was whether we do that all at once with a schema update, or simply trickle those changes in slowly as people refresh their data
[17:16:44] wagnerrp: the slow trickle is how we handled the transition from IMDB to TMDB
[17:18:24] jya__: I have no issue if this is done only for new updates.
[17:19:14] jya__: That's what I would have expected anyway. Seeing that it's likely the guessing of where the old inetref was from is going to not always get it right anyway
[17:21:40] dekarl: we could extend metadatalookup to detect recordings of episodes (has season/episode number and inetref) and move that hint up to the recordingrule (set category_type or season/episode number to a fake 1/1)
[17:21:58] dekarl: similar to how we push the inetref from the recording to the rule
[17:23:05] wagnerrp: if a recording made for that rule is a television episode, assume all others will be as well?
[17:23:20] wagnerrp: may want to limit that to the standard rule types, and exclude power rules
[17:23:42] moparisthebest (moparisthebest! has joined #mythtv
[17:28:03] jya__: Right... Back to reading my book
[17:31:15] jya__ (jya__! has quit (Quit: Colloquy for iPad -
[17:44:41] dekarl: wagnerrp: when iamlindoro added it we looked at the various rule types (I use actor search and similar, don't want to update them)
[17:45:23] dekarl: basically extend the existing "inetref to rule" mover to the new mechanism, whichever that may be
[17:57:31] paul-h: jpabq: Coverity ID 1213716 – Possible memory corruption in mythfilerecorder
[17:58:57] paul-h: I think they are saying read() can return -1 which is later used as an index into buf
[18:02:58] paul-h: jpabq: . . . ain.cpp#n409
[18:30:40] poolejj (poolejj! has joined #mythtv
[18:32:47] poolejj (poolejj! has quit (Client Quit)
[18:33:04] poolejj (poolejj! has joined #mythtv
[18:34:04] poolejj (poolejj! has quit (Client Quit)
[18:34:22] poolejj (poolejj! has joined #mythtv
[18:45:15] SteveGoodey (SteveGoodey! has joined #mythtv
[19:15:43] arescorpio (arescorpio! has joined #mythtv
[19:25:47] clever (clever! has joined #mythtv
[19:57:01] poolejj (poolejj! has quit (Quit: ChatZilla [Firefox 30.0/20140611060104])
[20:00:14] Warped (Warped! has quit (Quit: ChatZilla [Firefox 30.0/20140605174243])
[20:04:33] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 240 seconds)
[20:05:00] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 260 seconds)
[20:23:22] robink_ is now known as robink
[20:33:08] wagnerrp: anyone got any suggestions on this?
[20:33:20] wagnerrp: ./metadatagrabber.h:53:25: note: candidate function not viable: 'this' argument has type 'const MetaGrabberScript', but method is not marked const
[20:33:20] wagnerrp: const GrabberType GetType(void) { return m_type; }
[20:35:47] wagnerrp: nevermind. it just wants the const at the end of the declaration
[21:19:26] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:29:45] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:31:33] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 248 seconds)
[21:35:27] stichnot (stichnot! has joined #mythtv
[21:35:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:35:27] stichnot (stichnot! has quit (Changing host)
[21:54:28] dreamcat4 (dreamcat4!~dreamcat4@ has quit (Quit: Lost terminal)
[22:14:16] Warped (Warped! has joined #mythtv
[22:45:04] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 260 seconds)
[22:47:14] paul-h (paul-h!~Paul@ has quit (Quit: Konversation terminated!)
[23:27:45] knightr_ is now known as knightr
[23:51:09] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!)
[23:52:50] dumnut_ (dumnut_!~dumnut@2605:a000:140c:c088:9d7d:2f8f:70f4:a0d5) has joined #mythtv
[23:53:32] dumnut (dumnut!~dumnut@2605:a000:140c:c088:c5b4:dd8e:d28c:164b) has quit (Ping timeout: 240 seconds)
[23:54:03] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[23:56:47] xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Goodbye.)
[23:57:08] dumnut_ (dumnut_!~dumnut@2605:a000:140c:c088:9d7d:2f8f:70f4:a0d5) has quit (Ping timeout: 240 seconds)

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