:: #mythtv

Daily chat history

Current users (73):

aloril, Anssi, Beirdo, brfransen, CeilingKitten, Chutt, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, fetzerch, foxbuntu, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe_____, joki, Jordack, jpabq, jpabq_, jpharvey_, jst_, jwhite, kamamam, kc, kurre2, kwmonroe, laga, moparisthebest, mrand, MythBuild, MythLogBot, natanojl, nephyrin, neufeld`, Nothing4You, peper03, poptix, purserj, quovodis, rhpot1991, robink, rsiebert_, Seeker`, seld, sl1ce, SmallR2002, sphery, sraue, SteveGoodey, stichnot, stuarta, stuartm, superm1, tgm4883, toeb, tonsofpcs, tris, wagnerrp_, wahrhaft, wolfgang, XDS2010_, _charly_, _nyloc_
Tuesday, September 3rd, 2013, 19:26 UTC
[19:26:33] peper03: Hmm. Just managed to get MythFrontend to lock up hard by trying to call up the OSD menu in a DVD menu. Thread 1 is blocked on a mutex in DecoderBase::GetTracks. Any easy way to find out which thread has the mutex?
[19:41:45] knightr: hnmm nice, cherry-picking now works when there are binary files... (that didn't use to work)
[19:47:28] stuartm: think it depends on whether there is any merging necessary
[19:51:45] gregL (gregL! has joined #mythtv
[19:56:41] gregL (gregL! has quit (Remote host closed the connection)
[19:56:54] dekarl: stuarta, can I change . . . rce.cpp#L208 to allow max 0xFFFF? we could also change it to 0 = disabled / reserved to 0xffff, but -1 will do, too
[19:57:17] dekarl: or does it have to be 10^n?
[19:58:59] dekarl: looking at other instances it should work well
[20:19:28] peper03: jya: Looks like [7e7a78c] ( broke it. I happened to be using a DVD with a still menu, so the call in AvFormatDecoder::GetFrame() to ReadPacket() doesn't return until something is selected. During that time the decoder thread has the lock.
[20:20:32] peper03: We talked about a while back ( ) but that was obviously something I didn't try. Calling up the OSD menu whilst in a still frame will cause MythFrontend to lock.
[20:37:16] Jordack (Jordack! has quit ()
[20:49:04] dekarl: stichnot: the packagers can run crunchgen(1) on it if they like
[20:58:13] Steve-Goodey (Steve-Goodey! has joined #mythtv
[20:58:54] SteveGoodey (SteveGoodey! has quit (Ping timeout: 264 seconds)
[21:01:09] stichnot: cool.
[21:18:04] stuarta: dekarl: looking
[21:19:12] stuarta: yeah sure. art of my thinks that a spinbox isn't the right thing. i had to test with netid=4164, so i did a db update :)
[21:19:24] stuarta: *part of me thinks...
[21:23:04] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[21:32:44] knightr: will we have, for sure, a RC2? (I think so but I need to know so I know how much time the translators have left...)
[21:34:04] peper03: Not sure if some fixups aren't missing for UK transponders. If I'm reading it right, 2036, 2061,2411 and 2614 should be added. Does that look right (going off lyngsat's list).
[21:35:06] stuarta: peper03: dvb-t or dvb-s ?
[21:35:12] peper03: stuarta: dvb-s
[21:35:21] stuarta: entirely possible
[21:36:36] peper03: I was checking against the 'ONID-TID' field on this page:
[21:37:16] peper03: Is that right?
[21:41:55] stuarta: certainly looks like it
[21:44:27] kamamam (kamamam!62c4feb9@gateway/web/freenode/ip. has joined #mythtv
[21:48:14] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Read error: Operation timed out)
[22:07:16] gregL (gregL! has joined #mythtv
[22:14:00] peper03: gigem: I've noticed a few times that programmes with the same programme ID and series ID but on different channels are being scheduled to be recorded. The subtitles are different but I thought as long as the programme ID is the same no further comparisons are made. Is that not the case?
[22:16:40] peper03: The programmes are simulcast. The HD and SD versions have different programme IDs and yet don't seem to conflict but two HD channels with the same programme ID do. Duplicate matching is set to 'Subtitle and description' and 'current and previous' is set for the scope.
[23:02:18] SmallR2002 (SmallR2002! has quit (Ping timeout: 276 seconds)
[23:04:35] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:11:11] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[23:30:30] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[23:35:34] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:38:21] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:46:46] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[23:47:08] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:58:31] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[23:59:10] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
Wednesday, September 4th, 2013
[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! has joined #mythtv
[00:55:53] davidshay (davidshay!~davidshay@ 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@ has quit (Quit: davidshay)
[02:29:06] _nyloc_ (_nyloc_! has joined #mythtv
[02:33:03] nyloc (nyloc! 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! has joined #mythtv
[03:05:17] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[03:05:17] knightr (knightr! has quit (Changing host)
[03:10:36] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:26:41] joki (joki! 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! 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! 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? . . . 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_! 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! has joined #mythtv
[05:38:21] xris (xris! 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! 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! 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! 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 '' 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! has joined #mythtv
[08:08:48] Merlin83b (Merlin83b! 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
[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 "" while a crid of "crid://" will become ""?
[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! has quit (Ping timeout: 240 seconds)
[10:31:21] dekarl (dekarl! 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 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! has joined #mythtv
[11:52:39] knightr (knightr! 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! 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! 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! 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! 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 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: . . . 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_! has joined #mythtv
[16:30:08] rsiebert (rsiebert! 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! has quit (Quit: Leaving)
[16:53:53] Tobbe5178 (Tobbe5178! 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! has joined #mythtv
[17:02:18] knightr (knightr! 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! 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! has joined #mythtv
[17:50:36] knightr (knightr! 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! has joined #mythtv
[17:54:40] knightr (knightr! has quit (Changing host)
[17:54:40] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[17:55:58] SteveGoodey (SteveGoodey!~steve@ 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! 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] (
[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 ... 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: . . . /352782.html , but I don't know enough to know what exactly "Descriptive Video Service"/"Audio Description" would mean

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