MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (72):

aloril, Anssi, Beirdo, brfransen, CeilingKitten, Chutt, clever, coling, Cougar, dblain, dekarl, ElmerFudd, fetzerch, foxbuntu, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe_____, joki, jpabq, jpabq_, jpharvey_, jst_, jwhite, kamamam, kc, kurre2, kwmonroe, laga, moparisthebest, mrand, MythBuild, MythLogBot, nephyrin, neufeld`, NightMonkey_, Nothing4You, peper03, poptix, purserj, quovodis, rhpot1991, robink, rsiebert_, Seeker`, seld, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, toeb, tonsofpcs, tris, wagnerrp_, wahrhaft, wolfgang, XDS2010_, _charly_, _nyloc_
Wednesday, September 4th, 2013, 00:17 UTC
[00:17:54] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[00:21:44] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[00:43:39] SmallR2002 (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[00:55:53] davidshay (davidshay!~davidshay@107.17.234.199) has joined #mythtv
[01:01:35] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:27:38] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:40:52] gigem: peper03: What are the programids? If they end in 0000, they are generic and will never be considered the same as another program with the same id. Also, if the channels get their guide data from different sources (aka have different authorities), they won't be considered the same since each authority effectively defines it's own programid namespace.
[01:54:25] davidshay (davidshay!~davidshay@107.17.234.199) has quit (Quit: davidshay)
[02:29:06] _nyloc_ (_nyloc_!~quassel@p3EE2D56E.dip0.t-ipconnect.de) has joined #mythtv
[02:33:03] nyloc (nyloc!~quassel@p3EE2C1F2.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[02:46:25] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 241 seconds)
[02:46:41] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[02:47:33] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[02:49:43] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:56:02] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[03:04:52] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection timed out)
[03:05:17] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[03:05:17] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[03:05:17] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[03:10:36] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:26:41] joki (joki!~joki@p54863EB5.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[03:27:06] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:28:21] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:32:22] joki (joki!~joki@p54863355.dip0.t-ipconnect.de) has joined #mythtv
[03:55:23] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[03:58:55] jst_ (jst_!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[03:59:42] jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Read error: Connection reset by peer)
[03:59:43] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Ping timeout: 264 seconds)
[04:04:45] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[04:10:45] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[04:14:43] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[04:15:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[05:02:42] dekarl: knightr changing translated texts now wouldn't be so good, right? http://code.mythtv.org/cgit/mythtv/commit/?id . . . d596af060cc7 indicates something about broken providers when it means providers that use a feature of the standard that is not cool
[05:03:03] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[05:08:37] robink (robink!~quassel@unaffilated/robink) has quit (Quit: No Ping reply in 180 seconds.)
[05:08:57] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[05:25:52] knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 256 seconds)
[05:29:45] xris (xris!~xris@mythtv/developer/xris) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0)
[05:34:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[05:36:02] xris (xris!~xris@xris.forevermore.net) has joined #mythtv
[05:38:21] xris (xris!~xris@xris.forevermore.net) has quit (Changing host)
[05:38:21] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[05:48:06] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:06:24] SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has joined #mythtv
[06:07:22] robink (robink!~quassel@unaffilated/robink) has quit (Quit: No Ping reply in 180 seconds.)
[06:07:40] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[06:13:42] SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[06:29:19] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[06:30:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:34:22] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[06:58:34] robink (robink!~quassel@unaffilated/robink) has quit (Quit: No Ping reply in 180 seconds.)
[06:58:51] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[07:09:50] peper03: gigem: IDs are 'fp.bbc.co.uk/7a38sg' and all coming from EIT via satellite. Actually, I've just noticed that only the series ID is different between HD and SD, so if that isn't used for duplicate matching, it would explain why HD and SD recordings are correctly matched.
[07:11:06] peper03: Also, I forgot to mention that this is on 0.26-fixes, in case anything has changed since then. I don't have another DVB-S2 receiver for my dev box so I can't receive most HD channels.
[07:16:11] peper03: gigem: I've also noticed a programme scheduled to record, which I watched earlier in the year. The programme ID for both is the same. Series ID is different and the description for the new showing is missing '[HD]' as it's being repeated on an SD channel, but that shouldn't matter if the programme ID matches, should it?
[07:24:52] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[07:26:31] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 264 seconds)
[07:48:00] tonsofpcs (tonsofpcs!~tonsofpcs@rivendell/member/tonsofpcs) has quit (Ping timeout: 260 seconds)
[08:00:51] tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has joined #mythtv
[08:08:48] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv
[08:26:59] dekarl: peper03: yes
[08:27:28] dekarl: programid matching wins if both programs have one
[08:28:46] dekarl: the seriesid is for series link recording rules that catch all episodes regardless of title (false positives / negatives)
[08:37:47] peper03: dekarl: Hmm. So why is it being re-recorded?
[08:44:23] stuarta: peper03: are the callsigns for the channels different?
[08:45:39] peper03: stuarta: Yes. It's mainly the BBC regional variants.
[08:46:41] peper03: Most of the time it works fine.
[08:47:57] peper03: At the moment it *seems* like the programid is being ignored so the only time it tries to record or re-record too much is when subtitle/description don't match exactly.
[08:48:51] peper03: Having said that, I tried changing the rule to match subtitle only, which is identical, and it *still* scheduled the repeat.
[08:49:16] peper03: I've probably got some setting messed up somewhere, but I've no idea how to track it down.
[08:53:39] stuarta: check the duplicate flag in the database for the old recordings
[08:54:06] stuarta: you may have at some time, told it to rerecord it
[08:55:23] peper03: duplicate flag is 0
[08:55:41] ** stuarta tries to remember what that means.... **
[08:57:51] peper03: As I said, it also affects upcoming recordings causing the same programme to be recorded on two simulcast channels (where I've noticed, BBC 1 HD and BBC 1 Scotland HD)
[08:58:12] stuarta: i've a sql script to sync the callsigns
[08:58:23] peper03: The transport for BBC1 Scotland HD is not in the fixups list, so title/subtitle etc. don't always match.
[08:59:17] stuarta: that's why you were asking last night about them?
[08:59:29] peper03: The repeat program was originally recorded on BBC1 HD and is being repeated on BBC3, so I guess the callsigns shouldn't be the same there, anyway. But if the programid is the same...
[08:59:37] peper03: That's what got me started, yes.
[08:59:51] stuarta: in theory the default authority should be the same
[08:59:58] stuarta: so the full crid should match
[09:00:29] peper03: Querying 'oldrecorded' shows a perfect match for programid.
[09:12:12] stuarta: what about duplicate in oldrecorded?
[09:13:25] peper03: Another repeat from the same series the following day is not scheduled to record (which is correct). Looking at the 'Programme Details' page for the scheduled repeat, it says it was last recorded on the 18th May but oldrecorded says 16th April, so where's the 18th May coming from?
[09:13:53] peper03: duplicate in oldrecorded is what I was looking at before (0 for both).
[09:53:12] dekarl: peper03: its also possible that the implementation does not match the intended function :)
[09:53:53] dekarl: finding a good solution to mythically configure lineups so that simulcast channels get the same call sign would be nice
[09:55:49] peper03: dekarl: The thing is, most of the time it works fine. It's more a niggle than anything else. Just another itch that needs scratching.
[09:56:58] peper03: (or at least, find out what's causing the itch in the first place)
[09:57:21] dekarl: aye, need to look into it. the default authority should not matter as we are comparing crids :)
[09:59:13] stuarta: the crid = default_authority + programid
[09:59:39] stuarta: so it becomes fp.bbc.co.uk/programid
[10:00:09] dekarl: stuarta, I have to look it up, but isn't the default authority part of the programid for crids?
[10:01:05] dekarl: so authority "bbc,co,uk" + relative crid "123" becomes "bbc.co.uk/123" while a crid of "crid://not.bbc.co.uk/123" will become "not.bbc.co.uk/123"?
[10:01:36] stuarta: correct
[10:10:49] dekarl: so programid refers to the field in BBC data streams which gets the authority added and then stored in the database field also called programid?
[10:11:10] dekarl: ;)
[10:11:38] dekarl: I see absolute crids, including authority, over here. I'm not sure how the bbc handles it
[10:11:48] stuarta: after being concat'd with the defauthority
[10:30:39] dekarl (dekarl!~dekarl@p4FE85EB4.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)
[10:31:21] dekarl (dekarl!~dekarl@p4FCEE0A2.dip0.t-ipconnect.de) has joined #mythtv
[10:47:54] stuarta: peper03: you can also push that to 0.27-fixes
[10:48:15] stuarta: s/push/cherry-pick/
[10:51:47] dekarl: can we somehow get attention to http://www.silicondust.com/forum2/viewtopic.php?t=13717 to get rid of some warnings on the buildbot?
[10:57:25] stuarta: i'm not sure who knows upstream for hdhomerun lib. danielk22 do you know??
[11:12:00] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:16:45] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[11:24:32] peper03: stuarta: Done (and it seems like the branch hasn't come crashing down, so that's a bonus :) )
[11:34:04] stuarta: \o/
[11:52:39] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[11:52:39] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[11:52:39] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[11:57:53] superm1: dekarl: #hdhomerun has some of the devs afaik so you can poke them there
[12:16:26] tonsofpcs (tonsofpcs!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has quit (Changing host)
[12:16:27] tonsofpcs (tonsofpcs!~tonsofpcs@rivendell/member/tonsofpcs) has joined #mythtv
[12:22:45] stuartm: peper03: technically 2411 was already there, just lower down under the 'Sky' comment, but it's not the only overlap and doesn't really matter
[12:23:42] knightr: dekarl, nope, it wouldn't... I can contact our translators so that they know how that message should we read and translate it accordingly (that would include the English translations) and if, for some reason, we have no choice and have to break the freeze, I could change the message in the source at the same time...
[12:24:09] knightr: Just let me know how you would want this to be worded...
[12:25:36] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[12:36:16] peper03: stuartm: Ah, yes. I (obviously) missed that. There are quite a few transports in the list that don't exist (any more). At least according to lyngsat.
[12:50:22] stichnot: jya: (in case you read logs) Some time back you asked whether my RemoteFileWrapper class needed to use the flag QIODevice::Text when opening a local file. It turns out that I shouldn't be using that flag at all. If you have a DOS-style file with CR+LF linebreaks, it drops the CR or LF (I don't recall which one). This is generally OK for a text file, except when its encoding is UTF-16, in...
[12:50:24] stichnot: ...which case it turns the 4-byte CR+LF sequence into some mutant 3-byte sequence, which of course ruins everything.
[12:58:51] stuartm: peper03: probably disappeared when they started shifting stuff to the new satellite
[13:03:01] stichnot: jya: btw, I think it would be better if RemoteFile::isLocal() would cache the local-vs-remote state, because (1) basically every RemoteFile operation ends up calling QFile::exists(), and (2) if the file is local with a relative path (not starting with '/'), and it somehow cycles in and out of existence, the RemoteFile operations would try to switch between local and socket operations.
[13:10:18] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[13:11:12] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:11:52] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:17:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[13:18:41] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:21:51] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[13:29:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[13:30:04] danielk22: stuarta: Last time I checked Nick was our contact
[13:57:31] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[13:58:24] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[14:06:03] stuarta: danielk22: thanks
[14:37:10] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[14:55:40] gigem: peper03: If I read the logs correctly, you said oldrecorded.duplicate is 0. In that case, the program will rerecord because entries where duplicate is 0 are not used for duplicate checking. Duplicate can be set to 0 for various reasons, but the most likely are someone chose the "allow rerecord" option or the recorder marked it as damaged.
[15:01:42] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[15:06:46] peper03: gigem: I can't rule out the possibility that it was actively marked to re-record. It's usually only films that we delete and allow to re-record, but finger trouble has been known :)
[15:07:34] peper03: I'm curious then about the upcoming recordings that aren't being detected as duplicates (i.e. it only needs to be recorded once).
[15:13:09] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:13:28] gigem: peper03: I don't follow.
[15:15:05] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[15:16:25] peper03: gigem: I have several channels that are effectively simulcasts. Some are HD, some are SD. A programme is scheduled to record this weekend but it's scheduled to record on two of the channels at the same, even though all instances of the programme have the same programid.
[15:17:37] peper03: All the data is coming via EIT.
[15:19:42] peper03: The only difference I can determine is that one of the channels is not getting the fixups applied and so the title/subtitle/description are slightly different but since the programid is the same, that shouldn't matter.
[15:19:58] gigem: What are the programids? Do the channels have the same callsign/shortname? What is the duplicate check method in the recording rule?
[15:20:42] gigem: Also, what are the titles and seriesids?
[15:22:38] dekarl: peper03: you could also simply disable the SD channels
[15:22:42] gigem: It could be title related. It's not often an issue, but the titles must match before programid (or subtitle, etc.) are used for duplicate checking. We tried removing the title requirement at one time, but it killed performance.
[15:23:22] peper03: dekarl: In this case, it's two HD channels.
[15:24:42] peper03: gigme: That will be it. Because the fixups are not being applied, the subtitle is not being split off. I was under the impression that the programid was checked first and if that matched, everything else was ignored.
[15:24:50] dekarl: ahh, HD and HD+1? should get the same callsign :)
[15:25:00] peper03: s/gigme/gigem/
[15:25:18] peper03: dekarl: No, BBC 1 England HD and BBC1 Scotland HD :)
[15:27:01] peper03: Most of the time they show the same stuff, but there's the occasional programme that's different.
[15:27:07] peper03: Have to run. Back later.
[15:30:04] gigem: peper03: Yeah, that'll do it.
[15:48:49] sphery: peper03: though the title is used for most recording rules (unless you have a custom (or did we also add a "series record"/"season pass" based on series ID?)), so it would imply you have a rule for both titles?
[15:53:13] gigem: peper03: If you're feeling adventurous, you can try the patch at http://pastebin.com/8pqBaMF4 to remove the title requirement for programid matches. It double my scheduling time, but I have a very low "check" time. For others, it could very well increase schedule times by 10–20x or more!
[15:55:02] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[15:55:27] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[15:58:46] dekarl: sphery: http://code.mythtv.org/trac/changeset/02f646a . . . 371f6/mythtv
[16:02:30] gigem: sphery: What dekarl said. I misread your comment or I would have confirmed right away.
[16:11:03] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 268 seconds)
[16:13:28] sphery: Yeah, couldn't remember if that made it in (I know you did a couple versions)... So he may have had a "this series" filter applied.
[16:27:11] rsiebert_ (rsiebert_!~quassel@e179169222.adsl.alicedsl.de) has joined #mythtv
[16:30:08] rsiebert (rsiebert!~quassel@g229054132.adsl.alicedsl.de) has quit (Ping timeout: 256 seconds)
[16:37:34] stuartm: just bought one of those firesale Nook HDs for £79, might give me a reason to check out some of the android mythtv clients
[16:38:23] stuartm: no mpeg-2 support, so it means on-the-fly transcoding to h.264
[16:53:35] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[16:53:53] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[17:00:11] stichnot: So I've noticed something interesting. On my dev laptop, using the Slim playback profile, I get a predictable frontend crash in some ffmpeg sse-like code — it crashes on exit after the second playback of an HD-PVR h.264 video, but only when played back from the Video Gallery. Anyone else see this?
[17:00:39] stichnot: I suspect some heap corruption, and maybe valgrind and a lot of patience would shed more light
[17:02:18] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[17:02:18] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[17:02:18] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[17:15:04] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[17:20:11] jpabq: stichnot: I don't try to watch recordings from the Video Gallery. Sounds to me like something is not getting cleaned up after the first one is finished, so the second one starts up in a bad state.
[17:20:21] peper03: gigem: It's actually a power rule (I'd forgotten that too!) so that explains why it's matching both. Little by little the pieces are falling into place. I couldn't believe it was some bug that was only affecting me and no-one else :)
[17:20:54] peper03: I'll try the patch later. See if I can get the wife to give me a few minutes time on the production box :)
[17:26:25] stichnot: jpabq: In this case, I copy recordings from the production system onto my dev system for testing, and it's easiest to throw them into the Video Gallery. But then I only get two chanced to debug before the crash. :)
[17:27:22] dekarl: btw, is there a reason that we can delete videos from the gallery but not from within the player?
[17:27:45] dekarl: aka is that on purpose or is it a bug
[17:28:24] jpabq: I am guessing it is neither — no one has bothered to add the programming to allow it...
[17:40:07] stuartm: dekarl: guess when we started allowing deletion for videos no-one remembers to remove a if (!video) { delete() } from somewhere in the player code
[17:40:12] dekarl: well, changing ProgramInfo::QueryIsDeleteCandidate is easy.
[17:40:25] dekarl: I wonder if it will work then ;)
[17:40:32] stuartm: remembered
[17:41:27] stuartm: that reminds me that I want to allow deletion of music in mythmusic – way too many crap 'free' downloads hiding in my library
[17:44:13] stuartm: stichnot: I came across a couple of tickets a week ago for crashes in H.264 SSE code
[17:44:39] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[17:45:11] gigem: peper03: Been in that "isn't anybody else seeing this" place many times. Just to clarify, don't use that patch on your production system. It was only meant to give you an idea of how much that simple change costs. Only run it on a development system or with --testsched without installing on a prodcution system.
[17:49:28] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[17:50:36] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[17:50:36] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[17:50:36] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[17:53:34] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[17:54:40] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[17:54:40] knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[17:54:40] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[17:55:58] SteveGoodey (SteveGoodey!~steve@109.158.215.102) has joined #mythtv
[18:06:25] peper03: gigem: That SQL is enough to give me nightmares! What is it exactly that causes the slow down? I assume the change is causing the query to process more data but my SQL is nothing like good enough to work it out just from the query.
[18:15:32] Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Ping timeout: 256 seconds)
[18:18:47] peper03: Ok, another "is it just me?" now. I pulled the latest changes a day or two ago for the first time in about a week. Now I'm getting lots of config warnings (e.g. "config/libtool.m4:138: _LT_SETUP is expanded from..."). I don't remember seeing it mentioned before, so is it just me?
[18:30:43] gigem: peper03: When the title check is done for all duplicate checking, MySQL can use an index to efficiently check only those cases where the titles match. When the title check is moved down to be done along with the subtitle and description checks when programids can't be used, MySQL inefficiently checks all cases, including those where the titles don't match. It might be possible to rewrite the checks to use a
[18:30:45] gigem: subquery or multiple queries, but I've never tried it.
[18:32:49] peper03: gigem: Ok, so it's because of an index. That makes sense. Would it not be possible to create an index for the programids? (my SQL and DB knowledge is just enough to be dangerous so be gentle with me :) )
[18:45:53] peper03: gigem: With that patch, I got 1.57 check compared to 0.11 without. Doesn't actually appear to have prevented the 2nd recording though.
[18:56:50] peper03: stuartm, stuarta: Any objections to cherry-picking the additional fixups into 0.26?
[18:57:50] stuarta: peper03: nope
[18:58:01] stuarta: you break it you get to keep both pieces
[18:58:03] stuarta: :)
[18:58:29] peper03: I think I've got some glue here somewhere for all eventualities :)
[18:59:08] peper03: I guess it makes sense to cherry-pick the previous UK fixup changes too.
[19:00:52] stuarta: i thought i'd already done some of those
[19:01:38] stuarta: oh and if you fancy playing with fixups some more, there are currently episode data in subtitles. eg episodes of chuggington, postman pat etc :)
[19:01:46] ** stuarta runs off for dinner **
[19:01:51] peper03: I was thinking specifically of [5ee73af] (https://github.com/MythTV/mythtv/commit/5ee73af)
[19:02:46] peper03: If I can get my head around it, I'll have a look :) "Choo Choo!"
[19:06:28] stuartm: peper03: you'll need to include the one I committed a few days ago
[19:06:49] stuartm: won't be a clean merge otherwise
[19:07:12] stuartm: ah, you already said as much (working through scrollback)
[19:08:05] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!)
[19:08:28] peper03: stuartm: Yep :) Is the 'Cherry-picked from...' important in the commit message? I thought it got added automatically, but it doesn't seem to want to here...
[19:08:45] stuartm: need to use -x to append that
[19:10:09] stuartm: peper03: it's not vital but it's useful to have that just for reference
[19:10:17] sphery: peper03: We have a programid index (programid, starttime)... I think what gigem is saying is that the patch causes the scheduler to have to compare things that wouldn't normally be compared... Instead of only comparing programids among the 2 episodes of Under the Dome in the listings, it's comparing the programids of those 2 Under the Dome episodes with the programids of all 500 episodes matched by any other recording rule you have. The ...
[19:10:24] sphery: ... index on title just makes it easy for it to find only the Under the Dome episodes and ignore all the other differently-titled episodes when it's only comparing those with the same title.
[19:10:58] stuartm: seriesid?
[19:11:19] stuartm: btw, does Under the Dome get any better?
[19:12:50] sphery: don't think we have a seriesid index, and I haven't read the patch (and probably wouldn't understand it well enough) to know whether it's only comparing programids without looking at title if seriesid is the same
[19:12:54] gigem: peper03: Sphery's right. When an index won't apply to every case, MySQL resorts to performing the entire subtitle and description check on every combination even if they all have programids.
[19:13:55] peper03: sphery, gigem: Ok, that makes it clearer. Thanks.
[19:14:01] stuartm: second and third episodes just seem to waste any tension created in that first episode/pilot, acting isn't great and I'm not really sure what purpose the sub-plots introduced serve and they really aren't working to build out the characters
[19:14:51] gigem: I don't think a seriesid index would help either. As I stated earlier, it would probably take multiple or a complicated subquery to do it efficiently.
[19:15:10] sphery: stuartm: yeah, I was enjoying Dome early and hoped it would go somewhere, but I'm starting to yearn for a new season of "real" (non-summer) shows
[19:15:13] stuartm: never the less, you figure there must be an interesting twist/reveal coming and that it's just taking way too long getting there
[19:15:53] sphery: gigem: yeah, I'd think it would require some major changes since basically everything else in the scheduler is title based
[19:15:55] stuartm: feels like something that probably would have worked better as a mini-series
[19:16:45] sphery: stuartm: definitely... seems they're running out of storyline (even having to introduce new people into the series saying she was hiding out)
[19:17:06] gigem: Yep. Oh, and peper03, that patch was merely meant as an example, I didn't check it for accuracy.
[19:17:52] peper03: gigem: Ok. No problem. Now I know what's going on and why, I can sleep again :)
[19:17:55] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Ping timeout: 245 seconds)
[19:18:56] sphery: dekarl / stuartm : btw, I think you guys might know much better than I what this guy is looking to get http://www.gossamer-threads.com/lists/mythtv/users/551497#551497 ... Is that VISUALIMPAIR audioprop?
[19:20:03] sphery: I replied saying that if the info is in the SD/TMS data and we're not currently storing it, we should be: http://www.mythtv.org/pipermail/mythtv-users/ . . . /352782.html , but I don't know enough to know what exactly "Descriptive Video Service"/"Audio Description" would mean
[19:28:57] stuarta: peper03: it's actually in the program octonauts :)
[19:29:07] stuartm: sphery: sounds like that's what he's looking for and we should be able to use it for scheduling, but at least in the UK we're not able to actually use it – here it's carried as a secondary audio channel which needs to be decoded and combined with the primary
[19:30:48] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[19:31:15] stuartm: although it's not strictly what he was asking, see Recording Priorities, second page, "Audio described priority" for setting a higher priority on AD recordings
[19:32:02] stuarta: that goes back to the priority adjustments based on flags we talked about ages ago. ie. HD program priorities etc
[19:32:04] stuartm: no icon for it in the UI though ...
[19:33:09] peper03: stuartm: I thought it was already combined. I've been bitten a couple of times when I've watched a recording with something other than Myth and suddenly found someone reading the opening credits to me.
[19:33:15] stuartm: but VISUALIMPAIR is the flag in question, it's parsed from EIT but not xmltv (since I'm not aware of xmltv supporting it)
[19:34:14] stuartm: peper03: not on freeview, but some channels on freesat do combine it because Sky boxes don't have the tech to decode both simultaneously – it wastes bandwidth though so the Freeview spec requires hardware to have that ability
[19:34:29] peper03: It was a problem before I got my production box up and running and tried to use DLNA in the TV to play recordings. It would only ever use the first channel, which was audio description.
[19:34:31] peper03: Ah ok.
[19:35:43] stuartm: not quite sure what we're doing for upnp, whether we send the entire TS unmodified or filter it
[19:36:47] stuartm: descriptors for AD are there in the mpeg headers so we could in theory filter that stream out when sending to upnp devices, or even when recording
[19:39:42] peper03: I don't really know anything about the specification. I vaguely recall reading that only one audio channel was supported. Using it made me want to put my foot through the TV, though. FFWD was only about 1.5x normal speed. Took nearly as long to skip over the pre-roll stuff to get to the kids' programmes as it did to watch them!
[19:40:35] peper03: Also, I think my TV didn't like Myth. I had to run some other server.
[19:44:21] stuartm: yeah, I'm learning that 'DLNA' compliant doesn't really mean much, a server/client can be DLNA compliant and still unable to talk to another DLNA compliant device, DLNA basically says in parts "Here's what you must support at a minimum, but if you want to do something proprietary on top then that's OK too"
[19:46:53] peper03: I think I looked at the FFWD thing and found it is implement in the client. It seems like the client basically requests playback from a certain point and then jumps forward a bit and requests playback from there etc. So there didn't appear to be anything that could be done about it on the server :(
[19:47:21] stuartm: the spec has a very Microsoft feel to it ... compromised would be a good way to describe and it's huge – over 800 pages long just to describe the DLNA parts, it already assumes you've read the upnp spec back to front and front to back
[19:47:51] peper03: The best things I ever did for my nerves was to disconnect the Ethernet cable from the TV. All the network stuff on it was sh&te.
[19:55:59] peper03: stuarta: Don't see any episode information.
[20:35:32] Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[21:08:59] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv
[21:08:59] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host)
[21:08:59] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[21:09:50] NightMonkey_ (NightMonkey_!~NightrMon@64.124.185.45) has joined #mythtv
[21:17:29] SteveGoodey (SteveGoodey!~steve@109.158.215.102) has quit (Quit: Konversation terminated!)
[21:22:50] stuarta: hmmm, dvb-t or dvb-s data?
[21:23:00] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[21:24:03] stuarta: hmmm, all my afternoon octonauts have the series data in the subtitle
[21:25:29] stuarta: all dvb-s btw
[21:26:45] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv
[21:46:09] danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv ()
[22:06:18] knightr: stuartm, will we hhave, for sure, another RC?
[22:06:40] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds)
[22:08:18] stuartm: knightr: hard to say, we've not had many bug reports so far so there doesn't seem to be need for one yet
[22:08:27] stuartm: (yet)
[22:09:48] stuartm: depends on how invasive the fixes for reported bugs are, if they need the extra testing or not
[22:30:37] ** stuarta tries being a user and setting up f19 as his mythtv dev box **
[22:34:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[22:42:57] knightr: stuartm, thank you...
[22:44:11] ** knightr uses f19 for his dev box... (actually just upgraded from f18...) **
[22:52:56] stuarta: that particular box had suffered a *lot* of bitrot and become unusable for many things, so it was time to clear it all out and rebuild
[22:53:24] stuarta: the fact that the cpu and gpu are antiques doesn't help much either
[22:54:40] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[22:55:32] knightr: I still have a Pentium II in use here (not for MythTV duty though...)
[22:55:53] knightr: (and before that Pentium (1) 233s...
[22:55:56] knightr: )
[22:57:00] knightr: if I could find the time I still have my file server and my PBX to rebuild...
[22:57:52] knightr: (the file server does other duties as well though which were delegated to another PC for now...)
[22:58:29] knightr: (only partially though, I really need to reinstall Nagios...)
[22:59:11] knightr: gotta go, have to do my bike ride before it gets too dark...
[23:00:18] tonsofpcs: knightr: I had a P2 in use here. I replaced it with a Q6600 because it saved me more in power in a year and a half than the cost of the full PC
[23:44:55] skd5aner: stuartm: from -users: <DonkeyHotei> ok, i decided to give mythfrontend a try. i'm in the setup wizard, at the video config screen, clicked Test Standard Definition, and it downloads a video sample over and over in a loop. how do i get out of this? Esc does nothing
[23:52:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)

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