| Friday, July 15th, 2011, 00:17 UTC | ||
| [00:17:33] | andreax1 (andreax1!~andreaz@p57B941D8.dip.t-dialin.net) has joined #mythtv | |
| [00:18:57] | andreax (andreax!~andreaz@p57B943CE.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [00:20:52] | iamlindoro: | I hope to someday be proficient enough to send all *my* bugfixes into the past |
| [00:37:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [00:41:23] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [00:41:49] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [00:41:49] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [00:41:49] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [00:43:46] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [01:59:45] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [02:29:04] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [02:39:06] | andreax1 (andreax1!~andreaz@p57B941D8.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [02:48:54] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:35:05] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [04:04:01] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [04:15:05] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [04:23:01] | jpabq: | danielk22, Someone mentioned that when using LiveTV with the HD-PVR, that changing channels would loose sound. I tried it, and indeed that problem has become worse than it used to be (used to only happen when switch between DD5.1 and DD2.0 channels). Anyway, I have found that adding a call to SetV4L2DeviceOptions(chanfd); before every call to StartEncoding(readfd) fixes the problem. Thoughts? |
| [04:25:25] | jpabq: | Seems that when HD-PVR is being told to stop encoding (or maybe on start when it has to re-lock on the stream?), it resets to the default of AAC audio instead of the desired AC3 audio. |
| [06:01:58] | xris: | wagnerrp: any of your commflag/jobqueue things that might be preventing stuff from getting added to the queue automatically? |
| [06:53:14] | MythBuild: | build #1716 of master-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1716 blamelist: Robert McNamara <rmcnamara@mythtv.org > |
| [06:53:16] | iamlindoro: | One buildbot got started before I fixed a build failure just now, so, incoming |
| [06:53:18] | iamlindoro: | ah-yup |
| [06:55:24] | MythBuild: | build #502 of master-freebsd-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/502 blamelist: Robert McNamara <rmcnamara@mythtv.org > |
| [06:57:30] | iamlindoro: | Well now the buildbot's just being a dick |
| [06:57:35] | iamlindoro: | YOU ARE FIXED |
| [06:58:05] | MythBuild: | build #1717 of master-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1717 |
| [06:58:09] | Beirdo: | it doesn't abort past builds when you commit the fix :) |
| [06:59:09] | Beirdo: | looks like the fix missed the deadline by 30s or so for the freebsd build to have combined them |
| [06:59:15] | Beirdo: | heh, oh well :) |
| [07:04:37] | MythBuild: | build #503 of master-freebsd-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/503 |
| [07:05:53] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [07:38:57] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [09:25:19] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 258 seconds) | |
| [09:41:50] | andreax (andreax!~andreaz@p57B941D8.dip.t-dialin.net) has joined #mythtv | |
| [09:46:03] | paul-h (paul-h!~Paul@5adce259.bb.sky.com) has joined #mythtv | |
| [09:46:03] | paul-h (paul-h!~Paul@5adce259.bb.sky.com) has quit (Changing host) | |
| [09:46:04] | paul-h (paul-h!~Paul@mythtv/developer/paul-h) has joined #mythtv | |
| [10:05:01] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:55] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:08:55] | andreax (andreax!~andreaz@p57B941D8.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [10:22:43] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [11:04:11] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has joined #mythtv | |
| [11:13:32] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [11:27:27] | stuartm: | wow, those SD figures are hugely disappointing but probably point to huge numbers of users opting for alternatives? EIT? |
| [11:32:51] | wagnerrp: | xris: shouldnt be, the mythcommmflag commandline doesnt take part in queuing recording tasks |
| [11:33:08] | wagnerrp: | stuartm: EIT isnt an alternative over here |
| [11:33:14] | wagnerrp: | which leaves mc2xml |
| [11:33:33] | wagnerrp: | which is illegal and being actively persued by TMS and microsoft |
| [11:34:12] | stuartm: | wagnerrp: EIT is really that bad? |
| [11:34:56] | sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has quit (Ping timeout: 260 seconds) | |
| [11:35:11] | stuartm: | I mean I've heard it's not great, but ... |
| [11:35:22] | wagnerrp: | i found some site a couple weeks ago that documents tsrecorder (or something like that) dumps |
| [11:35:46] | wagnerrp: | from the four big networks, i had two with 12hrs of EIT (FCC minimum), one with 2 days, one with 3 days |
| [11:35:52] | wagnerrp: | PBS was 12 hours |
| [11:35:59] | stuartm: | ugh |
| [11:36:08] | wagnerrp: | i think the only one with 7 days was some religious network |
| [11:36:49] | wagnerrp: | survey of a couple other major cities showed that was the norm, rather than the exception |
| [11:37:04] | wagnerrp: | where are these figures youre talking about? |
| [11:40:07] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [11:40:26] | sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has joined #mythtv | |
| [11:41:41] | wagnerrp: | there was a thread a couple weeks/months back where some guy was using EIT, because he found it suited his needs |
| [11:42:02] | wagnerrp: | claiming the devs were simply stubborn about US EIT being garbage |
| [11:42:18] | wagnerrp: | and maybe we should actually try it, it may have gotten better in the years since we wrote it off last |
| [11:42:33] | wagnerrp: | so i found that side, found that information, found EIT to still be garbage |
| [11:42:48] | wagnerrp: | and his response was 'why do you need any more than a few hours' |
| [11:42:49] | wagnerrp: | ... |
| [11:51:15] | stuartm: | wagnerrp: -developer list |
| [11:51:46] | stuartm: | two weeks ago (been away, only just read it) |
| [11:53:26] | wagnerrp: | ah |
| [11:55:07] | stuartm: | those numbers were 2.5x higher at least back in the initial days although maybe my memory is wrong, even then many thought they were on the low side and that they would increase with time |
| [11:58:40] | wagnerrp: | i must have missed something, im just seeing an email about SD subscription codes |
| [11:59:46] | wagnerrp: | i see the 'application report', but no actual values |
| [12:00:24] | wagnerrp: | oh, nevermind, i see it |
| [12:13:21] | wagnerrp: | well id like to find the thread, and the link i found with guide data, but i cant seem to |
| [12:13:32] | Jordack (Jordack!~jordack@users.twp.ypsilanti.mi.us) has joined #mythtv | |
| [12:20:48] | wagnerrp: | stuartm: here we go, http://www.mythtv.org/pipermail/mythtv-users/ . . . /316003.html |
| [12:21:15] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [12:21:29] | danielk22: | stuartm: SD had more users in the past but never 2.5x the number of users. |
| [12:22:57] | stuartm: | danielk22: hmm, I must have been thinking of another set of NA usage figures then |
| [12:23:51] | stuartm: | wagnerrp: that guy just seems very lucky, either that or he's not scheduling anything to record more than a couple of days out |
| [12:25:59] | wagnerrp: | stuartm: hes also running mythtv on his plugcomputer backend |
| [12:26:12] | wagnerrp: | so he MUST use EIT |
| [12:26:26] | wagnerrp: | otherwise, the scheduler would become swamped with all the data you get from SD |
| [12:26:58] | wagnerrp: | you know, i hadnt thought of that before |
| [12:27:01] | wagnerrp: | now it makes perfect sense |
| [12:27:46] | wagnerrp: | ill have to remember that one next time he comes around the mailing list and starts advertising his ARM distro |
| [12:29:22] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [12:41:38] | pheld (pheld!gkrmwq@109-109-76-195.bb.cust.telefiber.no) has joined #mythtv | |
| [12:45:20] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 252 seconds) | |
| [12:52:36] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [12:56:12] | paul-h is now known as paul-h_ | |
| [13:03:03] | jstenback (jstenback!~jstenback@nat/mozilla/x-mhivohkgglwbgmgm) has quit (Ping timeout: 258 seconds) | |
| [13:03:42] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [13:35:45] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:35:52] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [13:57:49] | mrand: | wagnerrp: for the shows that I'm interested in, EIT and its short schedule times would actually do fine. The chances of conflict for my recording schedules is very near zero. So I wouldn't personally dismiss it as completely fringe. |
| [13:59:45] | iamlindoro: | mrand: It's fringe because the vast majority of our American users use services which don't provide EIT, or don't provide EITfor more than a couple of channels |
| [14:00:24] | iamlindoro: | I get EIT data on my cable system for ~1–2% of channels, which anecdotal experience suggests is nearly universally the case |
| [14:00:56] | wagnerrp: | right, you only ever get EIT data from the broadcast channels that get retransmitted over cable |
| [14:01:19] | wagnerrp: | if you are using broadcast only |
| [14:01:40] | wagnerrp: | and if you are only watching shows that are only played once, and never have the chance for some intelligent rescheduling |
| [14:01:45] | wagnerrp: | eit can work |
| [14:10:57] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [14:19:49] | danielk22: | wagnerrp: It may be that with cablecard devices such as the HDHomeRun Prime and the Ceton card we will have access to the PSIP on cable systems. It differs slightly from ATSC EIT, but that might make EIT in the US more generally useful. |
| [14:47:00] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [15:04:51] | andreax (andreax!~andreaz@p57B941D8.dip.t-dialin.net) has joined #mythtv | |
| [15:06:33] | stoffel (stoffel!~quassel@p57B4B9D6.dip.t-dialin.net) has joined #mythtv | |
| [15:18:37] | RDV_Linux (RDV_Linux!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [15:25:55] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [16:24:57] | kormoc is now known as kormoc_afk | |
| [16:41:26] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [16:41:55] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:50:08] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has quit (Remote host closed the connection) | |
| [16:50:11] | iamlindoro: | danielk22: Have you talked to Nick about getting Prime engineering samples or at least getting a jump on the line at all? I probed a bit about it when I worked with him to fix the "two tuners at once by IP resets the device" bug a few weeks ago, but he didn't really respond |
| [16:50:40] | iamlindoro: | danielk22: I know that you've already got the Ceton, but I'd love to get my hands on either and haven't yet convinced myself to pay full retail |
| [16:51:13] | iamlindoro: | And then in those moments that I do convince myself to pay full price, the thought of an indeterminate wait time puts me off ;) |
| [16:55:44] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has joined #mythtv | |
| [17:02:23] | danielk22: | iamlindoro: no i haven't. i have had so little mythtv time lately that i think it would just be adding another charge to my monthly cable bill without any benefit. |
| [17:03:41] | Goga777 (Goga777!~Goga777@shpd-95-53-220-56.vologda.ru) has joined #mythtv | |
| [17:06:07] | dekarl: | here's another EIT datapoint. on german dvbt we get 4 (private), 7 (public) or 14 (religous) days of EIT. But with the limitations of DVB-SI and the amount of care that the broadcaster put into it's not good enough for advance scheduling decisions. |
| [17:09:11] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [17:11:36] | Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv | |
| [17:19:04] | xris: | wagnerrp: I'll keep digging into the commflag queue stuff, then. I was hoping the issue was the broken previews, but it's obviously something else. |
| [17:19:14] | xris: | guess I just keep track of what is/isn't getting queued, and go from there. |
| [17:19:43] | dekarl (dekarl!~dekarl@dslb-084-058-100-069.pools.arcor-ip.net) has quit (Read error: Operation timed out) | |
| [17:20:15] | wagnerrp: | someone in the other channel mentioned something about their shows not being flagged automatically |
| [17:20:40] | danielk22: | wagnerrp: mythcommflag rebuilds don't work on video files anymore? |
| [17:21:06] | wagnerrp: | '--video <filename> --rebuild' should work |
| [17:21:45] | danielk22: | wagnerrp: hmm, it isn't but I may not be fully up to date on this machine, i'll pull & rebuild |
| [17:22:10] | wagnerrp: | scratch that, '--video' assumes you want a rebuild |
| [17:22:14] | wagnerrp: | no --rebuild needed |
| [17:22:32] | danielk22: | wagnerrp: still no, go.. rebuilding.. |
| [17:24:01] | wagnerrp: | i may have screwed up the ProgramInfo constructor for use with videometadata content |
| [17:30:07] | wagnerrp: | yeah, its broken, found the issue |
| [17:30:35] | danielk22: | heh, I was just about to type that I confirmed it with the latest master :) |
| [17:31:04] | wagnerrp: | line 1232, should be 'cmdline.toString("video")' rather than 'filename' |
| [17:31:52] | kormoc_afk is now known as kormoc | |
| [17:32:32] | xris: | wagnerrp: of course, I'm not recording a whole lot these days, so it'll be awhile until I can get enough info about what's failing to get flagged. |
| [17:33:05] | wagnerrp: | danielk22: that was it, seems to be working now |
| [17:34:14] | danielk22: | wagnerrp: I'm assuming that's like 1189 in master.. |
| [17:35:59] | wagnerrp: | yeah, apparently the sources on my backend are a bit out of date |
| [17:37:26] | dekarl (dekarl!~dekarl@dslb-084-058-100-069.pools.arcor-ip.net) has joined #mythtv | |
| [17:37:48] | xris: | wagnerrp: what adds the commflag job to the queue for new recordings? |
| [17:38:30] | wagnerrp: | a couple different functions, give me a second to pull it up |
| [17:39:06] | danielk22: | wagnerrp: It now appears to get the filename right, but it exits in about 500ms so I doubt it did anything. |
| [17:40:18] | wagnerrp: | how did you define the filename? |
| [17:40:59] | danielk22: | mythcommflag --video ~/sample5-small.mpg |
| [17:41:39] | wagnerrp: | xris: this gets run... https://github.com/MythTV/mythtv/blob/master/ . . . eue.cpp#L481 |
| [17:41:49] | wagnerrp: | which in turn runs this... https://github.com/MythTV/mythtv/blob/master/ . . . nfo.cpp#L457 |
| [17:42:59] | xris: | you remember what the db flag is for commercial free channels? |
| [17:43:19] | danielk22: | wagnerrp: it appears I just had to add /home/danielk to my videos directory.. now it works. |
| [17:43:57] | wagnerrp: | xris: its a bunch of booleans |
| [17:44:06] | wagnerrp: | autotranscode/commflag/userjob<n>/metadata |
| [17:45:12] | wagnerrp: | danielk22: yeah, theres likely some sanity check in programinfo that requires it be found in a known folder |
| [17:45:34] | wagnerrp: | although its not like it takes long |
| [17:45:58] | danielk22: | heh, yeah. but it doesn't print out an error message either :P |
| [17:47:00] | wagnerrp: | it probably returns GENERIC_EXIT_PERMISSIONS_ERROR |
| [17:47:09] | wagnerrp: | but the user wouldnt see that |
| [17:48:30] | xris: | wagnerrp: I'm wondering if maybe one of the new job type additions is interfering with things |
| [17:51:05] | wagnerrp: | its a non-conflicting bit operator, shouldnt have any effect |
| [17:51:52] | wagnerrp: | jobqueue.type is just an int, not an enum |
| [17:53:58] | xris: | well, meant more that maybe when things got moved around, some setting got disabled in my db |
| [17:54:38] | xris: | anyway, meeting time. :) |
| [18:03:03] | Goga777 (Goga777!~Goga777@shpd-95-53-220-56.vologda.ru) has quit (Remote host closed the connection) | |
| [18:07:54] | xris: | or not... |
| [18:27:57] | jams: | i don't suppose there is a easy way to calculate the avg length of time a grabber provides data for? |
| [18:28:27] | wagnerrp: | average, no |
| [18:28:40] | wagnerrp: | but at polling time, we can just see how far into the future we have guide data for |
| [18:29:07] | jams: | for each grabber? |
| [18:35:59] | wagnerrp: | we could handle each source individually, and the average the length per channel over that source |
| [18:36:23] | wagnerrp: | considering sources are only designed to operate with a single grabber, that should work |
| [18:38:36] | jams: | That sounds like good info to know. |
| [18:39:38] | dekarl: | wagnerrp: I have my sources with 50/50 EIT/xmltv (due to licensing issues) might be more interesting to look at each channel |
| [18:42:09] | wagnerrp: | you can define grabbers per-channel? |
| [18:42:23] | wagnerrp: | i know you can turn EIT on/off per channel |
| [18:42:36] | wagnerrp: | but i thought mixing was advised against, since it screws with the scheduler |
| [18:43:32] | iamlindoro: | wagnerrp: Suspect he's talking about assigning the grabber to the whole source, removing XMLTVids for the channels with EIT, and turning on the onairguide for those |
| [18:43:49] | dekarl: | mixing EIT + xmltv for one channel messes up the data |
| [18:43:50] | iamlindoro: | Thus, each channel is either/or, but the lineup itself is a mix |
| [18:44:17] | dekarl: | plus with tv_grab_combiner you could have multiple grabbers per source in some way... |
| [18:44:20] | wagnerrp: | ah, that could work |
| [18:44:40] | wagnerrp: | average channels on sources with xmltvids for that grabber |
| [18:45:11] | wagnerrp: | actually, no sense averaging, since XMLTV should provide the same amount of data on each channel right? |
| [18:45:35] | dekarl: | so I use EIT for all channels where I can't get my hands on the schedule / synopsis and xmltv for all channels where I have contact to the press service. Giving me between 4 (shortest EIT) and 21 (longest xmltv I output from up to like 8 weeks) days of schedule data |
| [18:45:44] | wagnerrp: | the only reason i was considering handling each individually was because you can get different amounts of data over EIT |
| [18:46:12] | dekarl: | wrong, some source only provide 7 days, or between 2 and 6 weeks depending on some random lunar cycle (or whatever) |
| [18:46:43] | wagnerrp: | dekarl: i mean one source will provide the same amount of data for each channel it supports |
| [18:46:49] | wagnerrp: | s/source/xmltv source/ |
| [18:46:57] | dekarl: | e.g. http://xmltv.spaetfruehstuecken.org/xmltv/00index.html the radio channels from swr are missing one week. I get data before and after that week |
| [18:47:42] | dekarl: | X meaning "some data between 00:00 utc and 23:59 utc" E meaning "no programs" |
| [18:50:07] | dekarl: | or from tv_grab_hr http://www.gonix.net/xmltv/00index.html tv_grab_se_swedb http://tv.swedb.se/xmltv/00index.html tv_grab_no_gfeed http://epg.mspc.no/xmltv/00index.html |
| [18:50:31] | dekarl: | gonix has highly variable number of days |
| [18:56:26] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [19:00:17] | stuartm: | wagnerrp: it's not unusual to mix xmltv and EIT on the same source, it's mixing them on the same channel which doesn't work |
| [19:01:12] | wagnerrp: | stuartm: yeah, i was forgetting you could simply not provide an xmltv if you wanted to run eit |
| [19:01:44] | stuartm: | I'm using EIT for two thirds of the channels available to me, xmltv for the rest – xmltv provides better data and therefore is used on all channels which I regularly record, but xmltv is slow to run and therefore I have EIT fill in for the rest |
| [19:03:00] | stuartm: | oh and you can't get xmltv data for radio channels so those _have_ to use EIT |
| [19:03:21] | stuartm: | which is ironic considering the xmltv source is Radiotimes ... heh |
| [19:04:07] | iamlindoro: | This conversation is an ideal answer for those who stridently insist that as a community we owe American users a web scraper, because information wants to be free |
| [19:05:26] | stuartm: | in the UK although we use xmltv the information isn't free – Radiotimes is owned by the BBC and we pay the BBC through mandatory license fees |
| [19:06:30] | stuartm: | ok, so strictly speaking the Radiotimes is run through their private money making wing and isn't directly funded by the public, but that's a technicality and we have permission to use that data anyway |
| [19:07:19] | dekarl: | wagnerrp: might be an idea to expend the grabber api to let them report "target number of days available", my target are 21 days (but that's only because mythtv defaults to 21) |
| [19:08:22] | dekarl: | stuartm: I use xmltv for radio channels without eit ;) it's a limitation of the RadioTimes data |
| [19:10:14] | stuartm: | dekarl: right, I didn't mean to imply any different, the RadioTimes simply doesn't offer radio data through their xmltv api (which just consists of value seperated text files) |
| [19:11:35] | stuartm: | iamlindoro: the truth is that good quality data costs money to produce, I don't know what it's like in the US but the sort of information you get direct from the channels themselves is poor, generic one sentence descriptions of a program (with bias because their selling their wares) |
| [19:13:31] | stuartm: | I personally like the RadioTimes data because most program descriptions are written by their in-house reviewers who produce detailed descriptions and brutally honest reviews for prime-time shows/films |
| [19:14:03] | wagnerrp: | dekarl: this isnt really a discussion about how to expand mythtv |
| [19:14:14] | stuartm: | they also include cast info etc |
| [19:14:16] | wagnerrp: | but more one of "what statistics can we poll from our users that would be interesting" |
| [19:14:25] | wagnerrp: | jams is talking about smolt |
| [19:14:45] | stuartm: | s/interesting/useful/ |
| [19:14:53] | wagnerrp: | we have a server set up at smolt.mythtv.org, and have integrated an anonymous poller into the frontend and backend |
| [19:16:10] | wagnerrp: | dekarl: so, if youve got any information that you think would be useful for the xmltv project, by all means, speak up |
| [19:17:02] | dekarl is now known as dekarl_afk | |
| [19:17:20] | dekarl_afk: | wagnerpp: I see, will think about what to collect |
| [19:18:40] | wagnerrp: | right now, its polling statistics on what grabbers are being used |
| [19:18:43] | wagnerrp: | but i dont recall what else |
| [19:22:17] | jams: | grabbers,sourcecount and channel_count. Thats about all that is pertinet to this converstation |
| [19:22:28] | iamlindoro: | If we are going to share any part of the information, we should probably make that very clear to the user upfront |
| [19:22:57] | iamlindoro: | Personally I have no problem with sharing statistical, anonymized data with our project, but now that we appear to be dipping in to the same DB that contains unencrypted passwords, I think we need to handle user trust carefully |
| [19:23:01] | wagnerrp: | well its going to be shared on the smolt page |
| [19:23:09] | wagnerrp: | unless are you talking about access to the raw data |
| [19:24:41] | iamlindoro: | Well, I suppose there's a point to the fact that it will be up on the smolt page, I'm just saying that when I added wrote the hardware profile stuff originally, I hadn't anticipated that it would become something where we're plucking values out of the DB to fill |
| [19:25:16] | iamlindoro: | And that's not me saying we can't get some DB data, just that the more aggressive we get, the more concerned I become that someone will have a reaction to it, and I won't be able to blame them for it |
| [19:27:37] | stuartm: | fwiw, we should not still be storing unencrypted passwords at all, hashed passwords if we must and in a different table to the rest of the settings (so that they aren't exposed via raw settings editors such as the one in mythweb) |
| [19:27:53] | iamlindoro: | stuartm: Shouldn't be and aren't are different things |
| [19:27:54] | iamlindoro: | we are |
| [19:27:59] | stuartm: | we are, yes |
| [19:28:39] | stuartm: | and I wasn't volunteering to fix the existing instances today, tomorrow or even this month so I'll just shut up ;) |
| [19:29:05] | iamlindoro: | anyway, don't get the impression that I'm a privacy nut, I'm comfortable sharing all the data that's been discussed |
| [19:29:48] | iamlindoro: | I just want to make sure we maintain user trust by being clear about what exactly we will be pushing up to our servers |
| [19:29:59] | stuartm: | I do agree that we need to be careful about collecting data and that it needs to be limited to the really useful stuff, plus as generic/anonymous as possible |
| [19:33:00] | wagnerrp: | well as it stands, this is the mythtv-specific system data were sending... http://pastebin.com/TW95zUpL |
| [19:33:01] | stuartm: | iamlindoro: speaking as a privacy nut I don't have a problem with this stuff either, but the longer the list grows the less comfortable I'd feel if I was an outside user |
| [19:33:07] | jams: | iamlindoro- thats why the privacy policy was posted with mythsmolt. |
| [19:33:46] | iamlindoro: | stuartm: Yes, you hit the nail on the head, that's exactly my concern |
| [19:34:05] | iamlindoro: | I trust that we won't abuse our data, or the ability to get it... I just want to make sure that everything we take is defensible |
| [19:36:01] | stuartm: | I mean as one example, the more information, the easier it becomes to fingerprint a system – I'm sure that someone with the inclination could easily identify my system from the supposedly anonymised data based solely on the few details I've made public about my setup |
| [19:37:46] | wagnerrp: | well that is one thing |
| [19:37:57] | wagnerrp: | right now, you can access all the information for a specific profile |
| [19:37:59] | stuartm: | if they did that I'd be thoroughly embarrassed for anyone to discover the USB sex toy I have connected ... (j/k) |
| [19:38:06] | wagnerrp: | is there any reason to make that public? |
| [19:38:17] | iamlindoro: | usb product id: 6969 |
| [19:38:31] | stuartm: | ;) |
| [19:38:39] | wagnerrp: | you can pick a UUID and see everythong on that system |
| [19:38:42] | stuartm: | wagnerrp: right, better to keep that private |
| [19:39:10] | iamlindoro: | Right, so it's decided, genders of usb adult toys to be anonymized as "pleasure apparatus" |
| [19:39:54] | stuartm: | better still not to keep the profile sent by the client, just to build stats from it then delete the information but that strikes me as a smolt limitation |
| [19:40:52] | wagnerrp: | stuartm: i dont think having a 'pleasure apparatus' is as bad as being seen with one of these... http://smolt.mythtv.org/client/show/pub_55cb8 . . . 92a3bf4d7db8 |
| [19:41:32] | wagnerrp: | sex toys are one thing... but controlling your TV by flailing your arms and legs about in front of a kinect? embarrassing |
| [19:41:53] | iamlindoro: | wagnerrp: I've seen some usb powered tuxes in there, too |
| [19:42:03] | iamlindoro: | ps, link = 500 server error |
| [19:42:41] | wagnerrp: | http://smolt.mythtv.org/client/show/pub_55cb8 . . . 92a3bf4d7db8 |
| [19:42:42] | stuartm: | The server encountered an unexpected condition which prevented it from fulfilling the request. |
| [19:46:21] | stuartm: | I'm sure we could tweak the hardware info, can anyone a use for knowing which host controllers are in use? Or the brand of the ethernet adaptors? |
| [19:46:43] | wagnerrp: | even worse... getting caught with a 'brooktree corporation bt878 video capture digitv pci' |
| [19:47:25] | wagnerrp: | stuartm: right now, it just scans sysfs, and is otherwise ignorant of what its returning |
| [19:47:40] | stuartm: | what concerns us as a project are which types of tuner hardware (in basic terms, DVB/ATSC/Capture), what speed the ethernet operates at |
| [19:47:58] | iamlindoro: | and of course, wireless and bank passwords |
| [19:48:23] | stoffel (stoffel!~quassel@p57B4B9D6.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [19:48:43] | stuartm: | oh, yeah, I nearly forgot those ... that would have been a silly omission |
| [19:48:58] | iamlindoro: | MythKeyLogger should work nicely for that |
| [19:49:16] | wagnerrp: | jams: heres one from yesterday, with a 'WinTV Nova-DT' classified as class NONE |
| [19:49:19] | stuartm: | iamlindoro: yeah, although I'm thinking about a different name upon release |
| [19:49:27] | wagnerrp: | that is based off internal tables shipped with smolt, right? |
| [19:49:29] | iamlindoro: | MythInputDaemon? |
| [19:49:34] | jams: | yeah it is |
| [19:49:36] | wagnerrp: | meaning those types of things would need to be added to the table? |
| [19:49:38] | jams: | that server is very old |
| [19:50:02] | jams: | shouldn't have that problem when the new one is ready |
| [19:50:11] | iamlindoro: | wagnerrp, jams: Any way to just update using the pciid db? |
| [19:50:16] | wagnerrp: | stuartm: we could have it in the plots and charts that we only specifically document tuner cards, etc... |
| [19:50:23] | jams: | yes |
| [19:50:31] | wagnerrp: | but we would want to collect everything so we can update such things later |
| [19:50:39] | wagnerrp: | and can look back through for missed devices and such |
| [19:50:43] | stuartm: | iamlindoro: that's incredibly close to some code I actually did write but never committed – a full reworking of our input handling :) |
| [19:51:21] | iamlindoro: | stuartm: Yeah, I remember that... and here we are... one?two? years later, and as I said then, Xorg still dicking around fighting about it, no closer to the fix |
| [19:51:47] | stuartm: | wagnerrp: well as I understand it we're updating profiles every 30 days, so whatever is collected can be updated at any time |
| [19:52:17] | stuartm: | we'd only be interested in the most recent data anyway when making decisions about adding/removing features |
| [19:52:17] | iamlindoro: | unless j-rod|afk has an update on that... are we any closer to handling keycodes > 255? |
| [19:53:02] | wagnerrp: | stuartm: actually, i think a historical record of use of tuner hardware would be useful |
| [19:53:06] | stuartm: | iamlindoro: yes and no, Xorg aren't doing much but we might have an alternative |
| [19:53:16] | wagnerrp: | i.e. use of framegrabbers is trending down |
| [19:53:36] | wagnerrp: | use of older graphics cards incapable of opengl output is trending down |
| [19:54:37] | wagnerrp: | although i dont know how much of previous profiles gets stored permanently, and how much only exists in the latest update |
| [19:54:46] | jams: | which is something we can't do, as the old data is overwritten with every update. |
| [19:54:56] | iamlindoro: | stuartm: Anything that doesn't require scripting, or a masters degree in bashology? |
| [19:55:29] | wagnerrp: | i thought there was some information that was retained |
| [19:55:47] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [19:56:53] | jams: | nope. the only time info is retained is if the uuid changes |
| [19:57:20] | wagnerrp: | well scratch that then |
| [19:57:26] | jams: | then after a certain amount of time older records are archived |
| [19:58:06] | stuartm: | iamlindoro: err, a system config which packagers would likely have to include to be installed somewhere under /etc, basically a mapping of scancodes to new input codes |
| [20:00:08] | iamlindoro: | stuartm: Any potential for that to become divergent between distros? Or is it something that we could expect to work as well on Ubuntu as it will on Fedora, and vice versa? |
| [20:01:54] | stuartm: | should be standard across distros, but j-rod would know for certain, he mentioned this in passing to me a month back and the precise detail is already hazy in my memory |
| [20:02:29] | stuartm: | basically the input subsystem will read a userspace map if it exists instead of the standard one, so we can stick a mythtv-mceusb.conf in the right directory for it to do-the-right-thing |
| [20:02:36] | danielk22: | Captain_Murdoch: What is the relation between EventCmdRecPending and ASK_RECORDING, if any? I thought the REC_PENDING event was sent 30 seconds before a recording starts like ASK_RECORDING, but it appears to be doing something else.. |
| [20:02:47] | stuartm: | really not much different to the currrent lircd.conf but without the lirc |
| [20:03:22] | iamlindoro: | stuartm: Well, if it works that's awesome |
| [20:08:52] | stuartm: | writing a theme in vi really isn't my idea of fun, I need my editors back :/ |
| [20:29:33] | Captain_Murdoch: | danielk22, I think the pending recording event is the one that fires off at 120, 90, 60, and 30 seconds before a recording starts. |
| [20:30:25] | ** Captain_Murdoch goes to check source real quick. ** | |
| [20:31:18] | Captain_Murdoch: | yeah, EVentCmdRecPending == REC_PENDING because underscores are stripped and var name is camelcase. |
| [20:32:07] | Captain_Murdoch: | no relation to ASK_RECORDING |
| [20:33:24] | Captain_Murdoch: | probably a little over-complicated in the 120/90/60/30 cases, but I figured that was easier than a setting to allow users to specify how early it fired. |
| [20:33:31] | ** Captain_Murdoch goes afk again ** | |
| [20:45:39] | danielk22: | hmm, has UPnP or mysql.txt loading changed recently? About 50% of my master mythbackend startups fail with "No UPnP backends found" "Would you like to configure the database connection now? [no]" |
| [20:46:32] | iamlindoro: | Some weird reordering to what we parse when happened recently such that my remote FEs try to access the local mysqld.sock, might be related? |
| [20:46:45] | iamlindoro: | they try 10x, then continue correctly with the parsed-from-file information |
| [20:48:29] | danielk22: | iamlindoro: I've seen that too, I get about a dozen messages warning that it can't connect to the local database before it loads up the DB stuff and connects.. I believe that is due to the DB logging and Beirdo is aware of the bug. |
| [20:48:46] | danielk22: | I don't think that's related though.. but I guess it could be. |
| [20:48:47] | iamlindoro: | ah, yeah, that sounds probably |
| [20:48:51] | iamlindoro: | er probable |
| [20:51:01] | danielk22: | yeah, i guess if something gets logged to the db before we load the DB connection info then maybe it wants us to configure DB access and since the backend isn't running in an interactive console it just exits.. |
| [20:51:02] | danielk22: | it's a race since db logging takes about 100 ms to start, so if we read in the db connection info before then we run, otherwise bad things happen |
| [20:51:38] | danielk22: | Beirdo: ^^^ I guess the problem is more serious than just spamming the console with error messages. |
| [20:52:13] | danielk22: | (This is just conjecture, I haven't actually looked at that code.) |
| [20:55:10] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has joined #mythtv | |
| [20:56:57] | Beirdo: | yes, we are aware of that, sphery and I were going to look at that soon. It's messy, but it's benign as it sits now |
| [20:57:20] | Beirdo: | really damn annoying though |
| [20:57:29] | Beirdo: | very high on the list to fix :) |
| [20:58:14] | Beirdo: | OK, and now I have a meeting. no rest for the wicked... and the employed, I guess |
| [20:59:06] | danielk22: | Beirdo: right, it just may not be that benign if it randomly blocks mythbackend startup... |
| [20:59:08] | iamlindoro: | Beirdo: I think he's suggesting that it's not as benign as originally thought |
| [21:00:32] | danielk22: | Captain_Murdoch: I'm pretty sure I broke the REC_PENDING handling :| Since we don't wake the scheduler thread every second anymore that code isn't run often enough.. |
| [21:01:00] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [21:03:58] | danielk22: | Beirdo: we also need something akin to mythbackend --setloglevel since --verbose has been split into --verbose and --loglevel |
| [21:07:02] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (*.net *.split) | |
| [21:18:55] | danielk22: | wagnerrp: I believe mythcommflag may be inserting recordedseek entries when running to commflag while a recording is in progress.. I'm getting errors from the backend about primary key violations inserting into the recordedseek table. |
| [21:25:49] | wagnerrp: | danielk22: what flags are set for the commflagging? |
| [21:25:54] | wagnerrp: | jobqueue flags |
| [21:26:22] | danielk22: | I dunno, where do I see these flags? |
| [21:26:22] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [21:26:38] | wagnerrp: | jobqueue table |
| [21:27:17] | wagnerrp: | its bitwise, an 8 tells it to rebuild, rather than flag |
| [21:27:46] | danielk22: | flags == 2 |
| [21:27:59] | danielk22: | at least for the stuff in the table now |
| [21:28:19] | wagnerrp: | thats what it should be for a live flagging |
| [21:32:25] | SteveGoodey (SteveGoodey!~steve@host86-147-64-6.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:33:43] | Jordack (Jordack!~jordack@users.twp.ypsilanti.mi.us) has quit (Quit: Like a Tank! http://www.youtube.com/watch?v=bxlO8F__7Fk) | |
| [21:41:54] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [21:58:08] | Beirdo: | danielk22: how is it blocking backend startup? |
| [21:58:26] | Beirdo: | hmm |
| [21:58:31] | ** Beirdo scrolled back ** | |
| [21:59:06] | Beirdo: | OK, well we'll be tackling that hopefully really soon. I may start tomorrow if sphery's still entertaining the family |
| [21:59:49] | Beirdo: | if it's acting even worse (that's possibly related to the dblogging), it certainly needs fixing sooner rather than later |
| [22:00:15] | Beirdo: | ooh, yeah, a setloglevel can be done easily enough too. Good idea |
| [22:05:32] | Beirdo: | danielk22: so the issue you are seeing is dblogging on a slave backend, I take it? |
| [22:07:17] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [22:35:20] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Quit: abqjp) | |
| [22:51:02] | pheld (pheld!gkrmwq@109-109-76-195.bb.cust.telefiber.no) has quit (Quit: Leaving.) | |
| [23:36:15] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [23:40:38] | iamlindoro: | paul-h_: Doug Vaughan is asking me about the status of the MythMusic rewrite in reference to writing some new code for mirobridge to pull in audio podcasts... do you have any public comment to share with him? (or, given my own curiosity, with us?) |
| [23:57:58] | omaha (omaha!~omaha@216-15-2-147.c3-0.bth-ubr1.lnh-bth.md.cable.rcn.com) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.