MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aloril_, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, Chutt, clever, coling, cotterpin, Cougar, dblain, dekarl, dturner, eharris, ElmerFudd, fetzerch, foobum, ghoti, ghoti_, Gibby, gregL, GreyFoxx, jams, jarle, jarryd, jheizer_, joe____, johanbr, joki, jpharvey, jst_, jwhite, jya, kc, kurre2, kwmonroe, laga_, MaverickTech, Merlin83b, moparisthebest, MythBuild, MythLogBot, nephyrin, neufeld, Nothing4You, nvzn, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert, seld, Sharky112065, skd5aner, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, toeb, tonsofpc1, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang4, XDS2010, xris, _charly_
Friday, October 25th, 2013, 00:24 UTC
[00:24:47] gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has joined #mythtv
[00:24:48] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[00:24:48] gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has quit (Changing host)
[00:26:02] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Quit: No Ping reply in 180 seconds.)
[00:26:19] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[00:31:53] skd5aner: gigem: AH! I just had one of those instances where a recording tried to steal my livetv tuner even though free ones were available. I'm sorry, but I'm not sure exactly how you had asked me to capture that event properly :(
[00:33:32] skd5aner: I just forgot what you needed me to collect for you to troubleshoot those instances... sorry
[00:33:59] skd5aner: they're so hard to actually replicate... darn
[01:16:20] neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[02:06:04] nyloc (nyloc!~quassel@p5B26FAA4.dip0.t-ipconnect.de) has joined #mythtv
[02:10:06] _nyloc_ (_nyloc_!~quassel@p5B26FCFE.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[02:30:51] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[02:31:57] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:59:55] rsiebert_ (rsiebert_!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[03:03:33] rsiebert (rsiebert!~quassel@g224250041.adsl.alicedsl.de) has quit (Ping timeout: 272 seconds)
[03:14:51] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[03:19:53] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 240 seconds)
[03:20:25] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[03:25:27] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 252 seconds)
[03:26:01] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[03:30:38] ghoti_ (ghoti_!~paul@scratch.it.ca) has quit (Ping timeout: 240 seconds)
[03:31:36] ghoti_ (ghoti_!~paul@scratch.it.ca) has joined #mythtv
[03:35:42] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv
[03:35:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:35:43] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host)
[03:39:11] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:40:50] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:44:30] wolfgang4 (wolfgang4!~wolfgang@ppp-88-217-29-111.dynamic.mnet-online.de) has joined #mythtv
[03:45:50] wolfgang3 (wolfgang3!~wolfgang@ppp-46-244-185-126.dynamic.mnet-online.de) has quit (Read error: Operation timed out)
[04:30:55] dblain (dblain!~dblain@mythtv/developer/dblain) has quit ()
[04:36:34] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[04:55:32] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv
[04:55:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:55:33] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host)
[05:24:47] Chutt_ (Chutt_!~ijr@2605:a000:1208:c084:28c4:8b4b:16ed:eea8) has quit (Quit: Leaving)
[06:00:13] SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv
[06:12:25] nyloc (nyloc!~quassel@p5B26FAA4.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[06:13:12] SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!)
[06:19:18] nyloc (nyloc!~quassel@p5B26FAA4.dip0.t-ipconnect.de) has joined #mythtv
[06:23:33] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[06:32:17] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv
[06:32:18] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:32:18] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host)
[06:45:57] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Ping timeout: 248 seconds)
[07:03:21] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv
[08:27:00] stuartm: I've forgotten who the go-to guy for smolt is – had a thought about storing some stats like re-schedule times in the db, then submitting the averages to smolt
[09:04:15] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 252 seconds)
[09:05:08] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[09:06:21] stuartm: jams: that was you, right?
[09:18:33] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[09:18:38] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Read error: Connection reset by peer)
[09:34:30] stuartm: dblain: any preference on where this RecStatusToString() method goes? Initially I was going to put it in the Myth class, but I thinking it's maybe better in the dvr class?
[09:36:22] stuartm: or maybe we return objects for all of the enum values as I originally suggested, with built-in toString methods?
[09:48:14] stuartm: might be able to macro/template the creation of those objects – most of the enums have associated toString() functions
[10:53:11] dblain (dblain!~dblain@mythtv/developer/dblain) has quit ()
[10:56:39] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:32:05] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[11:39:56] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[11:53:31] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[11:55:35] Nindustries (Nindustries!~Nindustri@unaffiliated/nindustries) has joined #mythtv
[11:56:12] Nindustries: Hi, is there any NAS distro supporting MythTV ? e.g. FreeNas (they dont support tuner drivers)
[12:00:52] wagnerrp: this is the development channel, you want #mythtv-users
[12:03:29] Nindustries_ (Nindustries_!~Nindustri@94-224-87-148.access.telenet.be) has joined #mythtv
[12:03:35] Nindustries_ (Nindustries_!~Nindustri@94-224-87-148.access.telenet.be) has quit (Client Quit)
[12:05:09] Nindustries (Nindustries!~Nindustri@unaffiliated/nindustries) has quit (Ping timeout: 272 seconds)
[12:06:05] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[12:08:56] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[12:14:02] stuartm: dblain: include is producing a file not found error, but the file is definitely there – LoadScriptFromFile – File not found: /usr/local/share/mythtv/html/js/utility.js"
[12:15:43] stuartm: ls -l /usr/local/share/mythtv/html/js/utility.js
[12:15:44] stuartm: -rw-r--r-- 1 gbee gbee 1011 Oct 25 13:14 /usr/local/share/mythtv/html/js/utility.js
[12:50:15] stuartm: gigem: under what circumstances does rsOtherShowing get used? Where I have both the HD and SD version of a channel, it indicates rsEarlierShowing instead of rsOtherShowing, I've a feeling that's wrong?
[12:55:52] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[12:56:13] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[12:56:28] sphery: stuartm: http://www.gossamer-threads.com/lists/mythtv/ . . . 14120#514120
[12:59:26] stuartm: so from the description it's broken, at least for me – if it's recording or will recording on the HD channel, the entry on the SD channel shows rsEarlierShowing instead of rsOtherShowing/Recording
[13:00:38] skd5aner: stuartm: good morning!
[13:00:49] stuartm: good afternoon
[13:01:05] skd5aner: :) That's right, 1 or 2 pm your time now?
[13:01:13] stuartm: 2:01
[13:01:42] stuartm: changes from this Sunday
[13:02:00] skd5aner: I think we're a week behind you for DST
[13:02:07] sphery: AIUI, when it's actively recording the showing on the HD, the status of the show on the SD channel will be rsOtherRecording (and the display may indicate rsOtherShowing)
[13:02:32] stuartm: sphery: one way to find out
[13:02:58] skd5aner: stuartm: you had asked a few days ago if my socket issues had creaped back up... I haven't seen the exact experience in about a week that we discussed before, but... almost without fail, mbe is segfaulting between 6–7am overnight, and I think it might be related
[13:03:17] sphery: gigem would be the best person to ask, though
[13:03:30] stuartm: sphery: nope, still indicates Earlier Showing even though the recording is in progress on the other channel
[13:03:42] skd5aner: stuartm: how can I tell if a core was dumped during the segfault that I might be able to provide?
[13:04:35] stuartm: skd5aner: strange, I was seeing a segfault in the early hours of the morning, core dump seem useless but suggested memory corruption, hasn't happened for a while though
[13:05:10] skd5aner: let me post the tail of the log(s), see if you have any pointers
[13:05:26] stuartm: skd5aner: dmesg or the backend log should show if a core was dumped, you'll also have a core with a recent modification date sitting in your backend users home directory
[13:06:04] skd5aner: ok, I don't think one was... although I just read how to try to ensure one would be next time
[13:06:57] sphery: stuartm: what's showing that status? mythweb? I'd guess it wasn't updated to handle the new statuses?
[13:07:55] stuartm: sphery: guide in mythfrontend, internal web server guide (services API provides raw enum value)
[13:08:18] sphery: not sure how it's supposed to work, then
[13:10:19] stuartm: maybe it only works if the callsign is the same ... easy enough to test
[13:11:03] stuartm: I had some other scheduling probs when I made the channum/callsign the same before, but ...
[13:11:53] skd5aner: stuartm: http://pastebin.com/FvRk92uC – anything useful out of this?
[13:13:04] stuartm: skd5aner: well it's again pointing at socket code when slaves are involved
[13:13:14] sphery: yeah, the channels won't be related if the callsign differs
[13:14:03] sphery: so that sounds like a good guess why you're not seeing it
[13:14:36] stuartm: sphery: well that's still not working, and worse, it means the HD channel isn't shown in the guide, so there's no indication that it's recording :/
[13:16:41] skd5aner: stuartm: fyi – I've see tne same issue ("earlier showing") when simultaneous HD and SD shows are airing
[13:16:57] skd5aner: *the
[13:17:50] stuartm: ouch, there's a problem with services too, with identical callsigns the services API is no longer returning some programs for the channel(s)
[13:18:11] skd5aner: stuartm: I'll try to do a few things related to my issues – 1, set up so a core will dump, and 2, run with -v sockets – any other verbose params you tihnk might be useful?
[13:18:23] stuartm: if they will record they aren't returned :/
[13:18:34] stuartm: skd5aner: -v network
[13:18:38] skd5aner: k
[13:18:41] stuartm: network, sockets
[13:18:52] skd5aner: s/sockets/socket
[13:18:57] skd5aner: but yea, will do – thanks
[13:20:09] skd5aner: so... I wonder if many other people run slaves backends? I wonder if my issue is a corner case, or if anyone running a slave would see similiar issues, it's just that not too many do??
[13:21:48] skd5aner: stuartm: I think I've heard others in the past suggest changing callsigns on SD and HD channels to the same callsign to avoid duplicative scheduling, which sporadically happens to me on occassion – so, if that's unadvisable, we might want to double check the wiki and other "systems of records" that might be giving that advice
[13:23:47] skd5aner: I keep mine unique
[13:23:55] stuartm: skd5aner: iirc if you give them the same channum they are treated as the same channel, so it might schedule it to record on the HD channel but it actually records on the SD channel – not sure what's meant to happen with identical callsigns
[13:24:11] jheizer: I think a lot of us stopped using slaves as network tuners became more popular.
[13:24:54] skd5aner: jheizer: probably... but the HD-PVR is perfect for slaves, because I can still have the STB attached directly to the TV and use if it needed
[13:25:44] jheizer: Yeah, that would be my one use case too. A second HD-PVR on my familyroom sat box.
[13:26:41] jheizer: As I do have one we use for our livetv use.
[13:28:32] jheizer: Haha, and now I find myself price checking a second one.
[13:30:55] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 272 seconds)
[13:31:18] stuartm: heh, an ambulance driver just pulled over someone to yell at them for not giving way
[13:31:57] stuartm: you'd thing if it was such an emergency they wouldn't be able to spare the time
[13:32:04] jheizer: wow
[13:32:19] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[13:33:30] stuartm: emergency services personal are obviously not immune to road rage
[14:02:59] sphery: same callsign tells the scheduler to treat the channels as equivalent (meaning you don't care which is used to record a show, even for "this channel" filter)
[14:03:33] sphery: the only thing same channum does is--when it's /also/ the same callsign--tells the UI (guide) to display the channel listing only once (instead of both channels right next to each other with identical content)
[14:04:11] sphery: and, in general, the advice is "only set the channels to the same callsign if you want them treated as equivalent for 'this channel' filtered rules"
[14:04:54] sphery: however there has been a longstanding bug reported where users claim (though we've never been able to reproduce it) that having 2 channels with different callsigns, but the same content results in 2 recordings at the same time
[14:05:20] sphery: (though I'm guessing they mean 2 channels with different callsigns on different Video Sources)
[14:06:03] sphery: and for those users--if that is the behavior they're seeing--the workarounds are a) remove the channel you don't want (i.e. the SDTV channel) or b) set the callsigns to the same
[14:08:58] skd5aner: stuartm: thanks – I got it running with the appropriate verbose options and I /think/ it'll also now dump a core should it segfault
[14:08:59] sphery: I don't use the same callsign for SDTV and HDTV versions of my channels--I just delete the SDTV channel because there's no benefit to keeping it since I have only one Video Source... For those with multiple Video Sources, keeping it may make some sense (if you'd really rather watch and SDTV version of some show than miss some recording--i.e. if you don't have enough capture devices on your good Video Sources), but whether to use the same ...
[14:09:05] sphery: ... callsign depends on how you want to handle "this channel" filtered rules
[14:09:14] skd5aner: stuartm: I'll keep you posted, thanks again :)
[14:11:50] stichnot: tonsofpcs: I finally got HDMI audio working on the ID41, so the setup is basically complete. At idle, the fan is still audible so I wouldn't want that in the bedroom. I tried unplugging the fan and playing back an HDPVR recording at 2x timestretch (the torture test), and at some point when I wasn't looking the computer shut down.
[14:12:02] stichnot: I'm trying it at 1x timestretch, and so far so good
[14:13:03] stichnot: It would probably be better if (1) I could figure out how to remove the plastic piece that holds the fan and covers the heatsink to improve radiative cooling, and (2) I could figure out how to disable 1 of the cores in the BIOS settings
[14:13:46] stichnot: I'm pretty sure it's the CPU overheating that causes a shutdown. When the GPU overheats, it usually slows down the GPU and leads to stuttering
[14:14:05] stichnot: The BIOS has an over/underclocking setting that I should try
[14:15:55] dblain: stuartm: My best guess is that it's trying to open the file read-write. I'll check the code to make sure it's opening it read-only
[14:18:27] dblain: Shows how bad my memory is... it's already opening it readonly
[14:23:07] skd5aner: stichnot: almost bought one of those a few months ago
[14:23:31] skd5aner: stichnot: let me know how it goes... I'm still looking for another cheap, quiet frontend for a bedroom
[14:24:47] Merlin83b: My bedroom FE would be great if it had an ION chipset. SD only though completely silent.
[14:29:13] dblain: stuartm: was that " at the end of the msg you sent me part of the log?
[14:30:57] dblain: assuming it is, you most likely have more than 1 space between the import and the filename. Guess I need to make that more robust (just wanted to keep the string processing to a min to keep performance up)
[14:31:31] stuartm: import "/js/utility.js";
[14:31:36] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[14:31:49] stuartm: but you're right, there is a stray " in the log
[14:32:02] dblain: Remove the ;
[14:32:26] stuartm: oops
[14:33:00] stuartm: thanks, sorry for wasting your time
[14:33:14] dblain: Should I add extra processing to allow for more variation or leave it to confuse another day?
[14:33:57] dblain: not a waste of time.
[14:35:07] stuartm: leave it, I might make the same mistake again, but at least I'll have a working example to compare to should that happen
[14:35:57] dblain: At a min I'm going to handle multple spaces before the filename. I know I like lining things up (to a fault!) :)
[14:42:25] stichnot: skd5aner: normal-speed HDPVR playback also shutdown. I'll try more things tonight/tomorrow.
[14:42:36] skd5aner: stichnot: bummer...
[14:43:06] stichnot: My ION-ITX-C boards are all fine with no fans, so I'm pretty sure this is doable
[14:43:18] skd5aner: stichnot: I looked a bunch of their models, I can't remember the one I was looking at, but the model that seemed ideal was no longer made/unavailable
[14:46:01] Merlin83b: http://www.asus.com/Motherboards/AT5IONTI would seems to be pretty ideal, but can't find it for sale anywhere.
[14:46:25] stichnot: yeah, the ION-ITX-C is ideal :(
[14:49:18] stuartm: dblain: if I remove the semi-colon I get this instead – "Error Loading QSP File: /usr/local/share/mythtv/html/tv/guide.qsp – (line 2) SyntaxError: Parse error"
[14:50:34] dblain: stuartm: The import is in a code block <% %> ?
[14:50:51] stuartm: yep, line 1 is <%
[14:51:14] dblain: My guess is that the js file has an error in it
[14:52:17] dblain: the import statement is replace with the actual js code before it's processed by the QtScript engine. So it would throw an error if the included file has issues.
[14:53:10] ** dblain just realized it's going to throw off all error line numbers and confuse the developer :( **
[14:53:40] stuartm: dblain: don't worry, the line numbers were already completely wrong
[14:54:10] stuartm: dblain: ok, removed some accidental whitespace from the js file and all is well
[14:54:35] stuartm: well, it's not, but it progresses a little further
[14:56:11] stuartm: ok, one more typo fixed and everything really is working well
[14:57:37] dblain: was it an error in the js file or something else?
[14:57:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[14:58:31] stuartm: something else, I'd made some other changes and mis-typed a variable name
[14:59:07] dblain: np. Was just about to commit my refinement and wanted to make sure I didn't need to fix something else.
[15:10:43] MythBuild: build #761 of master-linux-64bit-qt5 is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/761 blamelist: David Blain <dblain@mythtv.org >
[15:11:12] MythBuild: build #4553 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4553 blamelist: David Blain <dblain@mythtv.org >
[15:16:08] MythBuild: build #249 of master-f19–32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/249 blamelist: David Blain <dblain@mythtv.org >
[15:16:31] dblain: qt5 bit me... in meeting, will fix ASAP
[15:18:14] MythBuild: build #1145 of master-ubuntu-12_04-lts-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1145 blamelist: David Blain <dblain@mythtv.org >
[15:20:00] MythBuild: build #1128 of master-f18–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1128 blamelist: David Blain <dblain@mythtv.org >
[15:21:23] MythBuild: build #1320 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1320 blamelist: David Blain <dblain@mythtv.org >
[15:22:02] MythBuild: build #405 of master-f19–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/405 blamelist: David Blain <dblain@mythtv.org >
[15:22:10] MythBuild: build #1445 of master-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1445 blamelist: David Blain <dblain@mythtv.org >
[15:24:38] MythBuild: build #1134 of master-ubuntu-12_10–64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1134 blamelist: David Blain <dblain@mythtv.org >
[15:32:11] gigem: stuartm: The rsOther statuses are for display purposes only (the scheduler neither knows about them nor generates them. For mythfrontend, rsEarlierShowing is converted to the appropriate rsOther in the PI constructor used for pulling guide data. If you're using the services API, you'll either need to do the conversion yourself or make sure the services API uses the code that already does it.
[15:32:42] MythBuild: build #762 of master-linux-64bit-qt5 is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/762
[15:32:47] gigem: skd5aner: I think I sent you a patch that automatically turns on the desired logging. If you applied it, I think you just need to send me your master backend log.
[15:33:42] MythBuild: build #4554 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4554
[15:34:00] stuartm: gigem: ok ... seems like none of the frontend is using it atm, frontend guide and upcoming records also display 'Earlier Showing' instead of 'Other Showing'
[15:37:19] gigem: sphery: I believe the issue with duplicate recordings is with generics, in which case, they are different programs by definition if the callsigns differ.
[15:38:08] stuartm: services is also using the correct PI constructor ... I'll try to figure out where it's going wrong
[15:38:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:38:59] MythBuild: build #1146 of master-ubuntu-12_04-lts-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1146
[15:40:31] MythBuild: build #406 of master-f19–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/406
[15:40:49] MythBuild: build #1129 of master-f18–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1129
[15:41:02] stuartm: ah, and there's the cause of the vanishing programme bug, at the end of that constructor we overwrite the chanid of programs, so in the guide grid they are no longer parented to the correct channel
[15:41:28] MythBuild: build #250 of master-f19–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/250
[15:41:42] MythBuild: build #1446 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1446
[15:42:39] gigem: stuartm: I'd look at the guy who made the last PI constructor changes then. I wonder who that might be! :) Just kidding, but that might be a good place to check.
[15:45:22] MythBuild: build #1135 of master-ubuntu-12_10–64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1135
[15:46:25] stuartm: gigem: it's been this way for months, I've only just decided to do something about it :)
[15:47:37] MythBuild: build #1321 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1321
[15:49:35] gigem: sphery: I set HD and SD channels to the same callsign(*). I do so because I want a coherent EPG. My EPG has all of the SD channels at the beginning of the EPG with the HD channels at the end. If I deleted or hid the SD channels, I'd have a bunch of SD-only channels at the beginning and a bunch of HD-only channels at the end and I'd have to know which is which when looking for a channel. The way I have it,
[15:49:37] gigem: I can stay in the SD section and easily find all of my channels except for the very few really HD-only ones. *I use a custom filter that is on be default to prevent actual scheduling on SD channels when there is an HD version available.
[15:50:21] gigem: stuartm: It works in 0.27. I don't use master much, but will give it a try. I'm curious to see the new web stuff you've been working on anyway.
[15:51:39] stuartm: gigem: hmm, doesn't work on my 0.27 production machine either ... has to be something to do with my particular setup then
[15:53:32] skd5aner: gigem: I did apply it, but unfortunatley I cleared out the source since then... so I'll need to dig it up again :(
[15:53:33] stuartm: gigem: do you know anything about the 'stop recording' hack at the bottom of that constructor? It's also causing problems for the services API and besides which it really is a horrible hack
[15:56:33] skd5aner: gigem: found that patch – will re-apply for next time, thanks for the reminder
[15:57:33] skd5aner: stuartm: sorry, one more quick question – do you want me to run with --debug on for the network,socket stuff?
[15:58:23] stuartm: skd5aner: can't recall if it's actually necessary to get the detail we need, but it certainly can't hurt
[15:58:41] stuartm: assuming you've got enough disk space for the log
[16:00:29] stoffel (stoffel!~quassel@pD9E431E3.dip0.t-ipconnect.de) has joined #mythtv
[16:02:17] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[16:02:54] skd5aner: stuartm: I do now that I finally turned on some manual log rotation jobs
[16:03:15] dekarl1 (dekarl1!~dekarl@p4FCEEE3A.dip0.t-ipconnect.de) has joined #mythtv
[16:03:17] skd5aner: well, automated jobs I suppose, just not using logrotate itself
[16:04:36] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Ping timeout: 245 seconds)
[16:05:12] gigem: stuartm: I'd forgotten about that hack. Yes, it's ugly, but I don't think it can be removed until the underlying problem is fixed. In fact, the hack probably needs to be extended to include rsOtherTuning and rsOtherRecording.
[16:05:15] dekarl (dekarl!~dekarl@p4FE8411C.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds)
[16:09:39] stuartm: gigem: I was just contemplating alternative fixes e.g. could we iterate over the program list at the time we try to stop the recording to find the one that has matching title and startime with recStatus == rsTuning/rsRecording?
[16:10:09] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[16:10:40] stuartm: better still if we put that logic on the backend, so all existing clients will work
[16:13:48] skd5aner: The "stable" section on the main page of trac (http://code.mythtv.org) needs updated. It still points to 0.26 and the RC to 0.27
[16:13:57] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[16:14:05] stuartm: MainServer::HandleStopRecording() or MainServer::DoHandleStopRecording()
[16:14:07] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[16:15:02] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[16:15:25] stuartm: skd5aner: fixed, thanks
[16:15:50] skd5aner: np
[16:16:46] gigem: stuartm: You could do that, but they're still ugly hacks, just perhaps not quite as ugly. The real fix is to have/use a 'recordedid' or some such when/if sphery does his recorded schema changes. FYI, I'm going afk now for a while.
[16:17:08] brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 240 seconds)
[16:17:08] stuartm: gigem: true
[16:17:48] stuartm: I might go ahead and do it though, it would at least unbreak the services GetProgramGuide() and by extension the internal webserver guide
[16:18:05] brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv
[16:23:53] tonsofpcs: stuartm: dremel is the answer :-p (alternatively, bake the heatsink off and apply a better one with fresh thermal paste?)
[16:25:28] stuartm: either that wasn't aimed at me, or it's so far out of context that I just don't understand it
[16:26:06] brfransen (brfransen!~brfransen@64.179.169.226) has quit (Remote host closed the connection)
[16:28:42] brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv
[16:33:58] skd5aner: stuartm: btw, I see the same behavior as you with the "Previous Showing"
[16:34:05] skd5aner: on 0.27-fixes
[16:40:16] stichnot (stichnot!~stichnot@216.239.45.82) has joined #mythtv
[16:40:17] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:40:17] stichnot (stichnot!~stichnot@216.239.45.82) has quit (Changing host)
[16:43:06] stuartm: gigem: if I'm not mistaken, this should work – http://pastebin.com/mBjhxapm
[16:43:41] stuartm: umm, there should be a recording status check in there as well
[16:46:15] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv
[16:47:44] stuartm: http://pastebin.com/FdjDiq6K
[16:49:31] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[16:49:48] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[16:50:50] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[16:51:07] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[16:52:40] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv
[16:55:55] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[16:55:55] peper03_ is now known as peper03
[17:52:06] stoffel (stoffel!~quassel@pD9E431E3.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[17:55:26] guest42143 (guest42143!~neon@109.67.200.214) has quit (Read error: Connection reset by peer)
[18:34:53] rsiebert_ (rsiebert_!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:36:30] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[18:36:43] stoffel (stoffel!~quassel@pD9E41F12.dip0.t-ipconnect.de) has joined #mythtv
[18:36:51] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has left #mythtv ()
[18:42:08] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:42:15] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[18:44:19] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:44:26] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[18:44:28] gigem: stuartm: Your patch looks like it should work in the masterbackend. I'd be very, very, very wary, though, of calling LoadFromScheduler() in a slave backend. I think it will work if the changes you added are only done in the master since any slave will be given the correct chanid.
[18:45:15] stuartm: gigem: k
[18:47:31] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[18:51:05] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[18:51:53] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:53:17] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[18:57:30] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[18:57:37] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[19:03:34] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Quit: warped_)
[19:16:25] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[19:16:32] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[19:20:56] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has quit (Remote host closed the connection)
[19:21:03] rsiebert (rsiebert!~quassel@g224249182.adsl.alicedsl.de) has joined #mythtv
[19:26:06] stichnot: gigem, sphery, stuartm: If your DefaultTVChannel doesn't actually exist, the EPG starting channel ends up being the first channel in the list. If I change GuideGrid::fillChannelInfos() to call FindChannel with exact=false, it uses a string prefix based matching, so "3" maps to "300" but I'd prefer it to use numerical matching instead. I can make that happen, but I was wondering what would...
[19:26:08] stichnot: ...be the best behavior if the ChannelOrdering setting is "callsign" rather than "channum".
[19:28:04] dekarl1 is now known as dekarl
[19:29:45] stoffel (stoffel!~quassel@pD9E41F12.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[19:59:45] tonsofpcs: stuartm: sorry, you're right, it was for stichnot
[19:59:55] tonsofpcs: stichnot: dremel is the answer :-p (alternatively, bake the heatsink off and apply a better one with fresh thermal paste?)
[20:06:41] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone)
[20:08:51] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[20:14:37] joki (joki!~joki@p548628B8.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[20:19:27] joki (joki!~joki@p5486279A.dip0.t-ipconnect.de) has joined #mythtv
[20:28:27] stichnot: tonsofpcs: better answer is to spend more than 10 seconds looking for the fasteners :) Getting the machine booting properly and audio working was higher priority
[20:29:25] stichnot: Bringing a new frontend online reminds me what a pain it is to fine-tune the settings, keybindings, etc. I wish there were a button to clone from an existing frontend
[20:30:30] stichnot: also, as I used mythweb to compare settings and keybindings, it amazes me how much clutter from previous releases is lying around
[20:31:26] stichnot: regarding the fan noise, likely it's all for naught since my in-laws probably don't hear so well anyway...
[20:34:39] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[20:34:51] tonsofpcs: stichnot: yea. I've had people at work ask about getting a setup like I have and it really isn't worth the hassle for most of them. I kinda want to figure out a way to modify mythbuntu to have an install script that autodetects specific hardware and autoconfigures it for them so I can just give them a disc and tell them what hardware to buy and it magically works
[20:34:58] jheizer: I believe I've done a select/insert on the settings table to clone to a new FE before w/o issue.
[20:38:19] stichnot: tonsofpcs: I'm sure it would help a lot if I upgraded from 10.04, but this is a production environment with 4 net-booting frontends so I don't take upgrading lightly
[20:39:55] stichnot: When I moved from Fedora to 10.04 LTS, I spent about two weeks of late-night drills and note-taking using a spare machine that mocked my backend, before finally taking the plunge
[20:40:53] stichnot: so maybe in a year I'll try again with 14.04 LTS
[20:40:56] jheizer: Man, if you used ltsp-build-client to create your netboots, it is a total mess in later releases. I went back to local installs when I did my production upgrade as I could not get it working quickly
[20:41:52] stichnot: It's possible I used some ltsp-build-client recipe, taking from a web page that no longer exists, and that has put me off from considering 12.04
[20:42:19] tonsofpcs: stichnot: yea. I'm not sure what I'm running... I know it's 0.25 with an 'engineering modification' to fix an issue I found...
[20:42:47] jheizer: ltsp-build-client made it so damn easy. If I ever try again I am going to host the PXE stuff in a KVM so it can be completely independent from everything else.
[20:43:24] stichnot: yes, my notes say http://www.mythbuntu.org/wiki/network-boot-mythbuntu-diskless and ltsp-build-client, and that web page no longer exists
[20:43:53] jheizer: Yeah, before it was like sudo ltsp-build-client --mythbuntu --mythbuntu-user-credentials="your-user-id-here:your-password-here"
[20:44:11] jheizer: But the mythbuntu template has been removed and standard ubuntu didn't seem to work for me as well.
[20:44:23] dekarl: oh, is that coming back? setting up a netboot client on mythbuntu is a mess :(
[20:44:28] jheizer: Note though that this was all a year or so ago so may be working now. Just a heads up.
[20:45:00] dekarl: once upon a time you could enable netboot services in mythbuntu-control-centre
[20:45:29] jheizer: I ended up having a 60gb SSD pull out so I still got to keep a silent FE.
[20:46:19] stichnot: The biggest pain point with my current netboot setup is that if the server reboots, the clients ultimately lose connection to their network filesystem and have to be rebooted
[20:46:39] natanojl: gigem: You'd be wary of calling LoadFromScheduler() in a slave backend in that particular case or in general?
[20:46:59] jheizer: stichnot, yeah mine always did that too
[20:47:12] stichnot: Before netbooting, all my frontends ran off an 8GB USB stick :)
[20:48:53] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[20:50:05] jheizer: I think I stopped that and went to netboot when more meta images became popular and was slow, but that was a while ago. Still miss my pxe setup.
[20:57:00] warped_: Evening * Forgive me this question but I have 4 mythtv installations I'm supporting. Those users (and their investments) were encouraged to MythTV by me. All are suffering from #11882. What is Your advice to tell them regarding future in respect 11882 (I mean mainly timeline).
[20:57:00] ** MythLogBot http://code.mythtv.org/trac/ticket/11882 **
[21:03:28] tonsofpcs (tonsofpcs!~tonsofpcs@rivendell/member/tonsofpcs) has quit (Ping timeout: 240 seconds)
[21:04:21] stichnot: warped_: I'm hoping to look deeper over the weekend, but of course there are never guarantees on finding the right fix...
[21:04:49] tonsspace (tonsspace!c6e4c898@rivendell/member/tonsofpcs) has joined #mythtv
[21:05:04] tonsspace: apparently my irssi server died...
[21:05:18] stichnot: In theory, it should be made easier by the fact that the recorder has identified the very first frame as a keyframe, so there's no guessing on which frame to trace through the ffmpeg code
[21:09:14] warped_: stichnot: thx for this. You are saving my face!. You know – I actively marketed/encourage those ppl to mythtv promising then solution blowing anything on market. They recognised this and subscribed to not cheap SAT packets. Now some expensive channels are no-go fgor them and they (beig non technical) are asking me every few days do I have solution for "my great system". I was able to successfully explain that issue was triggered by SAT provi
[21:09:14] warped_: - but argument that it works with regular STBs is hard to counter...
[21:11:06] tonsofpcs (tonsofpcs!~mythbuntu@rivendell/member/tonsofpcs) has joined #mythtv
[21:12:41] tonsspace (tonsspace!c6e4c898@rivendell/member/tonsofpcs) has quit (Ping timeout: 250 seconds)
[21:14:06] skd5aner: warped_: I would find it hard to recommend mythtv to my non-technical friends and family, let alone something that sounds like a business... that would terrify me to support. I'd have to have some super kung-fu development skills and knowledge of the entire codebase to feel comfortable enough with that proposition
[21:14:28] warped_: stichnot: I saw in logs You are setup netbooted FE based on ZOTAC ION2. What netboot method You choose?
[21:19:24] stichnot: warped_: I don't know enough about all the netbooting options to answer effectively, but I use PXE booting and an ltsp image
[21:21:14] warped_: skd5aner: agree. Whole thing started when I demoed them my system. They were IMPRESSED (no, it is not that I'm so clever. it was mythtv). During last year I was able to manage all their issues myself (oh I'm not so clever – it was more OS/environment issues + mythtv code quality what allows me to go with this route). Unfortunately 11882 touches core function of mythtv and unfortunately it is for expansive paytv channels. As it is about H264
[21:21:14] warped_: learning curve kills me... Thats why asked about sort of help :-)
[21:21:31] tonsofpc1 (tonsofpc1!~tonsofpcs@cpe-72-230-192-8.stny.res.rr.com) has joined #mythtv
[21:24:13] stichnot: warped_: also, it's not clear to me whether the Zotac ZBox ID41 is ION1 or ION2
[21:26:56] warped_: stichnot: I see. IIRC it is ION2 as CPU is D525 and GPU is discrete GT216. Excellent as (compared to ION1) it has dvix hw decode. Also this is generally nice piece of HW :-)
[21:28:49] stichnot: I was also happy that it costs less than IONITX-C plus a case, but I'm less happy about the fan noise :)
[21:32:30] warped_: stichnot: yes. IMHO at end of day noise is major factor distinguishing all those variants of small-factor FE. Ideal is solution with passive radiator. I was able to cheaply buy ION1 – but now -if anybody will give me chance- I will pay additionally to have fan-less FE. Anyway – ION1[2] rocks for diskless FE.
[21:35:23] warped_: stichnot: I asked about netboot option You choose as I was experimenting with PXE with home in RAMFS vs. NFS. Initial difference is not so high but difference in overall "predictability" of FE user response times is really high in favour of RAMFS.
[21:39:14] cdev (cdev!~dblain@2600:1000:b01e:a89a::103) has joined #mythtv
[21:39:27] stichnot: I never tried ramfs, but NFS on a gigabit network seems pretty responsive and predictable for me. NFS gives a small advantage of precached preview images across reboots.
[21:47:52] cotterpin (cotterpin!~hp-mini@101.98.103.43) has joined #mythtv
[21:49:10] warped_: stichnot: right. I'm trying to balance speed-persistance by saving precached images by mounting them in rams (via squashfs). Sure – it needs additional download at boot (mythmediastream theme cache has 130M) – but as soon as FE is booted all stays in RAM (I'm using S3 SuspendToRAM). FE needs to be rebooted mainly for maintenance (yeah – I'm killing mythfrontend before sleep and restarting it after resume :-)) ). Fortunately all this takes
[21:49:10] warped_: shorter that CFL warming/ignition on my Sharp TV). Not that I'm trying evangelise particular solution – rather I'm surprised how such solution can nicely work on weak ION1...
[21:50:23] jheizer: My machine FE is an ION1 asus board and still amazed how nice a FE it is and totally fanless.
[21:51:31] warped_: jheizer: exactly. BTW: thx for excellent work with Mythmobile. I'm using this almost daily.
[21:51:38] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[21:51:50] jheizer: Ha, nice. I have a user! lol
[21:54:35] cotterpin: info
[21:55:21] warped_: Hmm – I think You are underestimating userbase. App is really nice. I especially I like cleaness and simplicity – this is really important for new, non-techie users.
[21:59:04] jheizer_ (jheizer_!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[21:59:33] jheizer_: In case this didn't go through as I dropped connection <jheizer> That's my goal. I haven't really had much time to work on it lately. No real idea what the user base it as the last update had no responses to it until a few days ago.
[21:59:58] jheizer_: I don't really use it at the moment, but attempting to continue development when I can.
[22:00:41] jheizer_: At a minimum I will say it will continue to function. haha
[22:00:51] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[22:01:43] warped_: jheizer: sorry. I know feedback aspect is important for keeping motivation...You see I'm trying now to do what I should do some time ago. Sorry for this!
[22:02:23] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 272 seconds)
[22:02:51] cotterpin (cotterpin!~hp-mini@101.98.103.43) has left #mythtv ()
[22:02:56] jheizer_: No problem at all and I appreciate it. The original goal was for my wife to use it while feeding out baby at night. Now that time is over we don't really use it. Though when the kid gets older I can imagine it being much more useful.
[22:03:42] jheizer_: Integrating the new gallery is going to give it a boost in use to I think when people visit.
[22:05:35] warped_: btw: this is sad: I'm fighting with my MacBook after OS upgrade. Spent 2h on recover from failed OS upgrade and now I see all users DB is corrupted. Gee, product with premium price shouldn't have such post-upgrade issues at all!
[22:06:59] wagnerrp: stuartm: you mean a full reschedule versus a single-rule reschedule?
[22:07:09] jheizer_: Don't tell em that... I just pulled out an old Mac Mini that I used for some development work years ago then tossed in the corner. Going from 10.6 to 10.9 right now to going to maybe turn it into a rarely used FE.
[22:09:59] wagnerrp: gigem: you about?
[22:12:51] wagnerrp: anyway, a query stuartm had earlier about scheduler run times
[22:13:22] wagnerrp: i put some code in smolt a long time ago to capture and report times listed in the logs
[22:13:50] wagnerrp: are full reschedules and rule reschedules logged the same?
[22:14:17] warped_: Yes. Basically I see results of different personality of Tim Cook and Steve Jobs. When they were in tandem – it was dream team: Steve has vision; Tim perfectly executes it with given KPIs. If Tim was too 'effective' in any area – Steve was watchdog. Now lack of watchdog causes Tim is going with extreme with his paradigm of good COO: maximise measurable KPI. This is typical when COO becomes CEO. Unfortunately this means SERIOUS problems for
[22:14:17] warped_: company in long term!
[22:19:46] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds)
[22:34:30] gigem: natanojl: (I hope you check the logs) If LoadFromScheduler() is called in the master, it uses the direct pointer to the scheduler, otherwise, it makes a synchronous call to the master using the Myth protocol. Someone who knows the network/protocol parts better than me can correct, but I think only syncrhonous call a backend can make to another backend is master to slave. Any slave to master communication
[22:34:31] gigem: that isn't a synchronous response to the master must be sent asynchronously.
[22:39:19] gigem: wagnerrp: I'm here. The log lines with "Reschedule requested for..." say why a reschedule occurred. for version <= 0.25, id = -1 was for full, 0 was for minimal and any other value was for that recordid. For later versions, MATCH 0 is for full, MATCH anything else is for that recordid and PLACE is for minimal. Version 0.27 (I think) also introduced CHECK type reschedules to make the PLACE type even more
[22:39:21] gigem: minimal.
[22:40:03] cotterpin (cotterpin!~hp-mini@101.98.103.43) has joined #mythtv
[22:40:05] wagnerrp: ok. i'm just doing a blind regular expression for the schedule finished line
[22:40:12] wagnerrp: i'm not doing any back referencing for type
[22:41:06] wagnerrp: the current method is non-functional now anyway, since it pulls those records from the database logs, which are no longer performed by default
[22:41:28] cotterpin: warped_: can you provide a bad recording in mytharchive native format ?
[22:42:41] cotterpin: warped_: because (here) the re-recorded "bad file" plays back with -O FFMPEGTS
[22:44:53] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 248 seconds)
[22:50:24] warped_: cotterpin: this will be not easy for me as all FEs I have are diskless ION1 without compiled mytharchive. Including mytharchive will be not 1min task as it needs some dependencies and I don't have them for keeping image small (full OS+FE is 130M now). May I provide You samples in naive (HDD) format?
[22:52:19] warped_: cotterpin: stichnot was already insightful and discover discrepancies between FFMPEG key fares identification algo and mythtv's algo.
[22:52:39] warped_: s/fares/frames/
[22:55:43] cotterpin: warped_: mythtv's finds/identifies some KF before the stream is valid PSI/PAT/PMT but I think it is stream/codec/probing identification problem.
[22:58:06] cotterpin: warped_: Mytharchive is a very good way to import a recording (into another system) that bypasses all the mpegts stuff. Because when I record your file(s) they play okay with -O FFMPEGTS
[22:58:22] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[22:58:52] cotterpin: warped_: but you did not have success with -O FFMPEGTS right ?
[23:01:20] warped_: cotterpin: I'm not sure. stichnot provided patch in #11882 which allows to work ok for scenario when user tunes from good channel to 'bad' channel. For me this proves issue is within recorder – not player. I think it is not stream/codec/probing identification problem but rather mythtv not enough flexibility with dealing with 'not so frequent' H264 coding schemes...
[23:01:20] ** MythLogBot http://code.mythtv.org/trac/ticket/11882 **
[23:07:37] stichnot: warped_: I don't think it necessarily points to a recorder versus ffmpeg problem. It just says that the recorder's h.264 parser is identifying keyframes that ffmpeg's parser is not identifying, or perhaps mythtv's code isn't interpreting the ffmpeg parser's results properly.
[23:08:28] stichnot: Basically, the player is looking through the entire recording without finding a keyframe, even though the recorder has identified lots of keyframes.
[23:09:22] stichnot: I don't have a good explanation for the different behavior when transitioning between Live TV recordings, but there could just be a different code path coming into play for live TV that also fails to identify a keyframe.
[23:18:16] warped_: stichnot: I know too low to say something valid but I think we can say issue is about discrepancy between keyframe identification in player and recorder. Now tolerance comes into picture: I think if player will be highly tolerant – then even bad recorder will work OK as recorder errors with KF ident will be 'covered' by player tolerance. In such case recorder issue will be masked by player capabilities (as rec. samples in 11882 plays OK in
[23:18:17] warped_: mplayer/VLC). But at end of day root cause is within recorder...Just my 0.02$
[23:21:19] cotterpin: warped_: but your bad file recorded into my system has all KF identified..your files do start badly, the PAT/PMT are not together at start.
[23:23:02] cotterpin: warped_: I tried copying the first PMT packet & putting it on the beginning of file so it was PMT/PAT/etc..still did not work.
[23:24:29] cotterpin: warped_: the recorder can be blamed for messing up the file starts..but the file are still valid ts files.
[23:28:43] stichnot: Normal playback works just fine for ffmpeg, but mythtv wants to skip over all initial non-keyframes to avoid pixelation. This is where it fails to explicitly detect keyframes.
[23:31:37] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Quit: warped_)
[23:33:51] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[23:34:34] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv
[23:36:07] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:39:43] warped_: stichnot: thx for clarification. For me this exactly matches hypothesis I 'had' for my systems.
[23:40:50] cdev (cdev!~dblain@2600:1000:b01e:a89a::103) has quit (Ping timeout: 245 seconds)
[23:58:43] warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Quit: warped_)

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