MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (74):

aca20031, aloril, amessina, Anssi, Beirdo_, bobweaver, brfransen, cesman, Chutt, clever, cocoa117, coling, Cougar, danielk221, dblain, dekarl, ElmerFudd, ephemer0l, fetzerch, foobum, foxbuntu`, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams_, jarle, jarryd, jheizer, joe_____, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, kormoc, KungFuJesus, kurre2, kwmonroe, laga, moparisthebest, mrand, MythBuild, MythLogBot, neufeld, peper03, poptix, purserj, rhpot1991, rsiebert_, seld, Sharky112065, skd5aner, SmallR2002, sphery, sraue, stuartm, superm1, tgm4883, Tobbe5178, tonsofpcs, tris, unforgiven512, wagnerrp, wahrhaft_, whoDat_, wolfgang2, XDS2010_, xris, _charly_, _nyloc_
Friday, June 14th, 2013, 00:36 UTC
[00:36:33] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[00:37:33] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[00:42:58] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[00:49:34] gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:3::36) has quit (Remote host closed the connection)
[01:14:19] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:08:50] _nyloc_ (_nyloc_!~quassel@p4FE4C923.dip0.t-ipconnect.de) has joined #mythtv
[02:11:04] nyloc (nyloc!~quassel@p4FE4C42B.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[02:46:19] peper03 (peper03!~peper03@port-92-203-106-1.dynamic.qsc.de) has quit (Ping timeout: 260 seconds)
[02:47:57] peper03 (peper03!~peper03@port-92-203-16-151.dynamic.qsc.de) has joined #mythtv
[03:30:41] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[03:32:20] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:45:30] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Read error: Connection reset by peer)
[03:48:55] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[03:54:46] joki (joki!~joki@p54865414.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[04:00:13] joki (joki!~joki@p5486563D.dip0.t-ipconnect.de) has joined #mythtv
[04:10:22] stichnot (stichnot!~stichnot@adsl-69-110-157-184.dsl.pltn13.pacbell.net) has joined #mythtv
[04:10:22] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:10:22] stichnot (stichnot!~stichnot@adsl-69-110-157-184.dsl.pltn13.pacbell.net) has quit (Changing host)
[05:03:26] MythBuild: build #165 of master-linux-64bit-qt5 is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/165 blamelist: Chris Pinkham <cpinkham@mythtv.org >
[05:14:11] cocoa117 (cocoa117!~cocoa117@78.129.168.246) has joined #mythtv
[05:34:16] MythBuild: build #166 of master-linux-64bit-qt5 is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . 5/builds/166
[06:10:35] SteveGoodey (SteveGoodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has joined #mythtv
[06:10:53] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[06:11:35] peper03 (peper03!~peper03@port-92-203-16-151.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[06:24:58] SteveGoodey (SteveGoodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!)
[07:05:20] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has joined #mythtv
[07:27:39] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has quit (Quit: Verlassend)
[08:53:15] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has joined #mythtv
[09:55:28] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[10:05:29] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[10:08:29] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has joined #mythtv
[10:47:36] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[11:31:32] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[12:44:20] exoon_ (exoon_!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has joined #mythtv
[12:45:54] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[12:46:59] exoon (exoon!~exoon@p4FD38325.dip0.t-ipconnect.de) has quit (Ping timeout: 268 seconds)
[12:48:10] exoon_ (exoon_!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has quit (Client Quit)
[12:49:40] exoon (exoon!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has joined #mythtv
[12:55:44] exoon (exoon!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[12:57:24] exoon (exoon!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has joined #mythtv
[13:06:13] exoon (exoon!~exoon@p4FD3A2DB.dip0.t-ipconnect.de) has quit (Quit: Verlassend)
[13:10:36] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Read error: Operation timed out)
[13:10:56] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[13:14:24] moparisthebest_ is now known as moparisthebest
[13:16:42] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[13:19:44] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[14:00:29] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Read error: Connection reset by peer)
[15:23:48] stichnot (stichnot!~stichnot@107.228.23.115) has joined #mythtv
[15:23:48] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:23:48] stichnot (stichnot!~stichnot@107.228.23.115) has quit (Changing host)
[15:33:41] gigem: stuartm (or anyone): Would you be up for running another scheduler test? It can all be done with --testsched, so you won't need to touch your production backend. I'd hoped skd5aner would get me his database, but he's been incommunicado for the last week.
[15:47:07] jpabq: gigem: what do you need?
[15:47:30] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (*.net *.split)
[15:47:30] aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has quit (*.net *.split)
[15:47:30] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (*.net *.split)
[15:47:31] jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has quit (*.net *.split)
[15:47:45] rhpot199` (rhpot199`!~rhpot1991@2001:4968:202:3:7154:3f78:c23c:5d18) has joined #mythtv
[15:47:56] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[15:50:44] jpabq: gigem: my backend is reasonably fast, but I have a ton of 'People' recording rules, so the scheduler does have to work a bit.
[15:51:04] gigem: jpabq: Run mythbackend --testsched a few times and note the total and "place" schedule times. Apply a patch and rerun --testsched. To have any chance of showing a significant improvement, your current place times would need to at least a few seconds. For comparison, skd5aner's were in the range of 40 seconds or more.
[15:52:23] gigem: jpabq: What is the current place time in your "Scheduled n items in" entries in your backend logs.
[15:52:24] jpabq: Speculative scheduled 1859 items in 9.4 = 7.97 match + 0.58 check + 0.82 place
[15:53:22] gigem: jpabq: That's too fast! You'd probably only see a 0.1 second improvement at best.
[15:54:01] jpabq: Okay.
[15:54:11] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Excess Flood)
[15:54:13] gigem: Thanks for offering, though.
[15:54:28] aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has joined #mythtv
[15:54:51] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[15:55:45] jpabq: gigem: I have an unused atom box on a shelf. It would take a while, but I could do an install on it and copy my DB over to it...
[16:02:40] stichnot (stichnot!~stichnot@216.239.45.94) has joined #mythtv
[16:02:40] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:02:40] stichnot (stichnot!~stichnot@216.239.45.94) has quit (Changing host)
[16:02:49] gigem: jpabq: Thanks, but don't bother right now. I could probably kluge up some sort of torture test myself if I have to.
[16:03:18] stuartm: gigem: my place is only 0.89 atm, partly because I've fewer upcoming recordings, there's not a lot worth recording in the summer
[16:05:00] gigem: stuartm: Same here. I'm going to see if adding an All rule for "Paid Programming" might slow me down enough to get useful results.
[16:06:11] stuartm: "Poll took an unusually long time 23809384 ms" << Either that's actually µs, or it took 6 hours ...
[16:06:28] stuartm: could also be an uninitialised variable
[16:08:59] gigem: I'd go with a timer variable corrupted because of another bug.
[16:09:21] rsiebert_ (rsiebert_!~quassel@g229055098.adsl.alicedsl.de) has joined #mythtv
[16:09:28] stuartm: sphery: even in µs that's 23.8 seconds, I'd hardly categorise that as "MythTV just gives up", 24 seconds without data from the hardware is one huge discontinuity, at what point _should_ we give up?
[16:10:28] stuartm: gigem: that's definitely where I'd start looking if it is indeed meant to be ms
[16:10:49] gigem: Ooh, sorry I misread that message for the TFW took a long time message. Yeah, probably us instead of ms.
[16:12:13] rsiebert (rsiebert!~quassel@g231186021.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds)
[16:19:39] sphery: stuartm: yeah, there's only so much we can (should) do when we're faced with broken hardware/drivers/system
[16:20:56] sphery: no idea if we're taking too long to poll because we're unable to write a full buffer or if it's actually the card/drivers failing or ..., but when we have 23s of nothing, not much we can do
[16:21:12] sphery: other than mark it as a failed recording and try again on a rerun or whatever
[16:22:45] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[16:23:58] stuartm: we should be rescheduling if a recording is marked as failed, but danielk22 recently said that functionality was never added
[16:24:45] sphery: I'm pretty sure if a recording is marked as /failed/, we do... if a recording is marked as corrupt or with discontinuity or whatever danielk22 added, we aren't
[16:25:22] stuartm: ah, well maybe that's the case
[16:25:38] sphery: I think we've had failed recordings since at least 0.13 or so... And I would say that giving up before the scheduled end time is a failure versus a discontinuity.
[16:26:13] stuartm: I've had my fair share of zero byte recordings, which should trigger a reschedule but haven't done so, maybe because we're not treating them as failed
[16:27:41] stuartm: especially if 'failed' means the recorder ended prematurely, which it never seems to do in my case, the backend thinks it's recording right up to the scheduled end, but it wasn't getting any data
[16:28:40] stuartm: in some cases it never even managed to tune (had a few like this recently after they moved some channels and again after builders knocked my sat dish off axis
[16:30:20] gigem: stuartm: There was a bug I fixed last week that could have caused recordings stuck in rsTuning to not be rsFailed quickly. Ironically, it's on my TODO list to backport that and another small fix to 0.26 today.
[16:31:32] sphery: yeah, I don't think we ever marked "started properly but never got data" (or "started properly but stopped getting data before the end") recordings as failed, but probably should
[16:31:59] gigem: Agreed.
[16:32:08] gigem: Lunch time. AFK for a while.
[16:39:52] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[16:52:00] danielk22: sphery: I believe damaged recordings do get re-recorded, as long as the alternate showing happens after the current recording finishes... i.e. we don't try to grab a 1hr timeshifted program if the current 2hr program shows some issues in the first hour. Maybe I was speaking to a specific edge case like that?
[16:52:32] rhpot199` is now known as rhpot1991
[16:52:52] rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:7154:3f78:c23c:5d18) has quit (Changing host)
[16:52:52] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv
[16:55:28] stichnot: My experience is that failed recordings usually re-record, though that has only been true for the last year or two
[17:02:07] peper03 (peper03!~peper03@port-92-203-61-59.dynamic.qsc.de) has joined #mythtv
[17:17:53] sphery: danielk22: yeah, I think stuartm was just saying that setting the status to damaged doesn't actually trigger a scheduler run to reschedule, so it relies on something else (another recording starting/recording being deleted/rule being created/...) to trigger a reschedule.
[17:18:23] sphery: stichnot: I think you're talking about the damaged recordings, not truly "changing status to rsFailed"
[17:20:39] danielk22: That's probably true. It's a one line change to add that functionality if anyone is interested.. I believe just finding where to add that line and the exact form of the reschedule call is what is involved.
[17:25:19] cocoa117 (cocoa117!~cocoa117@78.129.168.246) has quit (Ping timeout: 252 seconds)
[17:29:26] stoffel (stoffel!~quassel@pD9E42732.dip0.t-ipconnect.de) has joined #mythtv
[17:30:55] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv
[17:30:56] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host)
[17:30:56] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:35:23] peper03: On a somewhat related note, I noticed that recordings don't seem to marked as invalid when there's no space left on the drive. There was an entry in the backend log as it ran out of space but it carried on for the next day or so merrily maintaining that everything was recording successfully.
[17:35:53] peper03: It was even showing the (presumably) correct filesizes in MythFrontend even though the actual filesize was 0.
[17:36:15] peper03: This was 0.26-fixes, in case anything's been changed in master.
[17:40:11] sphery: peper03: You mean no space left on the file system with the DB data (and/or /tmp file system)? If there's no space left on the recordings file system, MythTV should expire recordings to make room--unless you disabled expiration on every recording on that drive, in which case it should notice (and shouldn't be able to figure out the "correct" file size because it will see the write errors and know there's a problem).
[17:41:07] sphery: I don't see how it could think it's writing data if it's not--and I think we get the file size with a file system call, rather than summing up what we think we write.
[17:43:51] cocoa117 (cocoa117!~cocoa117@111.192.137.98) has joined #mythtv
[17:45:08] stichnot: sphery: in my case, it's when the HD-PVR flakes and gives a zero-byte recording. I'm not sure whether that's "failed" or "damaged".
[17:45:52] stichnot: Possibly the same for the HDHR, but it's hard for me to say since the HDHR is almost 100% reliable
[17:47:13] peper03: sphery: I mean on the recordings file system. I didn't investigate too much as I was away at the time and logged in remotely via a very slow connection. I only noticed it because several preview thumbnails were black.
[17:47:56] peper03: I would imagine that some part of the backend knew it couldn't write but that information wasn't making it back through the chain.
[17:49:48] peper03: And yes, auto expire is turned off. I use it occasionally but in general most of the stuff that gets recorded is stuff I really want to watch.
[17:53:31] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds)
[18:00:41] peper03: ThreadedFileWriter reports 'No space left on device' immediately for each new recording but that doesn't seem to be passed back as the 'Finished recording' trace doesn't appear until the time the recording was due to stop. Then the scheduler updates the recording from Recording to Recorded.
[18:07:39] sphery: stichnot: yeah, I don't think we've ever marked those as failed because they started ok--we just never got any data. So danielk22's new damaged recording code is probably picking it up, and then a later reschedule finds a later showing of it and re-records.
[18:09:19] sphery: peper03: that's another "started properly" case... I though we had code that noticed when we couldn't write, but I guess not. Still think the file size should be shown as 0, though--I'm nearly positive we don't sum up what we think we're writing but we ask for the file size directly from the file system.
[18:09:25] jpabq: stichnot: Are you running 0.26 or master? I don't think I backported it, but I added signalmonitor time-outs to master such that if the HD-PVR (etc) does not get a 'lock', Myth will mark it as failed and schedule another showing if one exists.
[18:10:42] stichnot: jpabq: that could be what's happening here. I only run Master.
[18:13:48] peper03: sphery: What's the definition of 'started properly'? I haven't looked into any of the code so I'm just looking at this from a user's point of view (with a hint of programmer's intuition). Going off the observed behaviour, I'd guess that 'started properly' just means Myth could tune to the channel.
[18:16:11] peper03: I suppose it's possible that a new file could be created even if there's no space. I've never tried it.
[18:20:40] SteveGoodey (SteveGoodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has joined #mythtv
[18:26:04] SteveGoodey (SteveGoodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!)
[18:28:33] sphery: peper03: AIUI, started properly means we got past the signal monitor and started the recording with the appropriate API commands for the device and didn't receive any errors from the device.
[18:29:07] sphery: I'm definitely not an expert in the recorder code, though--I'm far from a good beginner at that code, actually.
[18:29:22] peper03: sphery: Ok, so just receiving side then. That would tally.
[18:30:36] sphery: and, fwiw, the case of no space and every single recording has been explicitly marked to disallow autoexpire isn't a well-tested case since we don't allow disabling autoexpire (it's always on for MythTV, but individual recordings can be marked to not expire)
[18:31:12] sphery: I know we don't handle it well, but I thought everything fell apart at the point we got the no space error
[18:31:52] peper03: Yeah, it doesn't surprise me that it's not been well tested. Just, like you say, that it doesn't fall apart.
[18:32:14] sphery: seems we need better code--to either expire, anyway, or at least mark the current recording as failed
[18:32:57] peper03: I don't remember exactly how I set it up but I was fairly sure there was a setting to disable autoexpire automatically. I certainly don't disable it manually.
[18:33:27] sphery: (of course, users will then say, "but why didn't you try again on my other file system(s) because one of my 12 file systems actually had space" even though 4 other recordings were happening on that drive at the same time)
[18:33:42] sphery: because, of course, regardless of how broken their configuration is, mythtv should "just keep trying"
[18:34:46] sphery: peper03: there used to be a setting that set the default for whether to allow autoexpire when creating new recording rules, now it's set by the recording rule template... but autoexpire itself is /still/ enabled--just told not to allow it for that recording
[18:35:00] sphery: we expect you'll either have free space or /some/ expirable recordings on the file system
[18:35:22] peper03: Of course :) My setup is fairly basic. I have one drive for DB and videos and one for recordings. It was entirely my fault that it ran out of space but I was just surprised at the behaviour.
[18:36:03] sphery: (I mark all my movie recordings to allow auto-expire and my TV shows--most of which are serials that require seeing them all and in order--to disallow expiration, but I still have a good 2.x TB of expirable recordings of my 11.x TB total)
[18:36:39] peper03: I have a 500GB drive for all my recordings :)
[18:36:44] sphery: but, yeah, we should handle it better... just needs someone to take the time to go through the edge cases (even unexpected ones)
[18:53:33] taylorr: jpabq, stichnot: when mythbackend starts does it call the channel change command to tune to the default channel? the reason I ask is that my backend crashed at the start of a recording and when it restarted it changed the channel to record and also changed to the default at the same time
[19:00:47] dekarl (dekarl!~dekarl@p4FE85237.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)
[19:02:19] dekarl (dekarl!~dekarl@p4FE855F5.dip0.t-ipconnect.de) has joined #mythtv
[19:28:04] taylorr: jpabq, stichnot: so one theory I have about the zero-byte recordings is that a segfault occurs before data is written to the drive at the start of a recording then mythbackend restarts and tuning fails because the recording channel and the start channel run the channel change script at the same time
[19:29:13] taylorr: I really don't understand why we would want to tune during mythbackend startup for an hdpvr
[19:46:15] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[20:04:15] Steve-Goodey (Steve-Goodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has joined #mythtv
[20:19:38] stichnot: taylorr: I recently saw a "failure to tune" message at the beginning of the mythbackend log (where the failure was due to a wedged hdpvr), so I think for whatever reason it does probe the hdpvr in that way
[20:19:45] stoffel (stoffel!~quassel@pD9E42732.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[20:20:34] stichnot: If you believe http://www.mythtv.org/wiki/Hauppauge_HD-PVR , "If you don't care about channel changes, you can set it to /bin/true, but there absolutely must be a channel change script defined."
[20:21:00] neufeld: My tuning script uses flock to make sure it doesn't have multiple simultaneous invocations.
[20:23:57] stichnot: taylorr: fwiw, when my hdpvr wedges, every recording is zero bytes, within the same mythbackend process.
[20:34:06] stichnot: neufeld: re hdpvr captions. I added a test REC_STARTED_WRITING event that triggers the caption script, and modified the recording end script to not use -delay/-startat for ccextractor. After checking a few test recordings, it looks like REC_STARTED_WRITING is coming about 9.5 seconds after REC_STARTED, and the srt synchronization seems accurate within about 1 second. So this looks promising.
[20:39:04] neufeld: stichnot: that's good. I note, however, that a configurable bias might be helpful because we don't know what the difference in latency is between {cable signal}->{STB}->{component outputs}->{HD-PVR encoder}-> OUT1 vs. {cable signal}->{STB}->{composite outputs}->{PVR-xxx VBI scanner}-> OUT2
[20:39:42] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[20:39:48] stichnot: Yeah, for an external script like this, I would definitely keep the configurable bias.
[20:40:25] stichnot: If the captions were somehow muxed into the recording, I guess that would probably be part of the configuration settings.
[20:41:57] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has joined #mythtv
[20:41:57] NightMonkey (NightMonkey!~NightrMon@64.124.185.45) has quit (Changing host)
[20:41:57] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[20:41:57] neufeld: Right. Was it you who was talking about adding a subtitle sync option, similar to the audio sync, adjustable at playback time?
[20:44:32] stichnot: yeah, it's already there in master :)
[20:44:45] stichnot: for srt subtitles only
[20:44:54] neufeld: cool
[20:52:19] stichnot: neufeld: if you have the time/ability to have a look, patch for Master is http://pastebin.com/9Bex4xKv . It only handles the HD-PVR, and the event name is likely to change, but otherwise it should be good.
[20:58:01] neufeld: stichnot: the patch looks reasonable to me, but then I'm not a MythTV developer, so that's not a sign-off on the patch.
[21:02:45] stichnot: neufeld: you're the hdpvr caption script developer :) I meant if you wanted to test the patch in your environment and see if you also observe consistent synchronization without the need to wait for the recording to complete and probe the recording and vbi lengths
[21:05:04] neufeld: stichnot: ahh. I'll put it on my list of things to try out. I can actually poke at the box a bit more than usual these days as my wife is out of the country and her shows are in reruns, so if I cause weirdness it's not a disaster.
[21:07:52] stichnot: My plan would be to modify my script to write the .srt file directly to the recording directory in real time, and then modify the srt reader to be able to deal with a growing srt file for in-progress recordings and live TV.
[21:11:40] neufeld: right, I recall you mentioning that. That would cover almost all annoyances with captions on HD-PVR. The only remaining one I can think of is the issue with an HD-PVR reset causing the PTS values to reset, making the captions suddenly start over.
[21:16:49] danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv ()
[21:30:32] Steve-Goodey (Steve-Goodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!)
[21:42:57] Steve-Goodey (Steve-Goodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has joined #mythtv
[21:49:06] Steve-Goodey (Steve-Goodey!~steve@host86-144-4-103.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:08:33] pitz (pitz!~pitz@216.197.225.42) has quit (Ping timeout: 248 seconds)
[22:15:14] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:21:43] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Ping timeout: 268 seconds)
[22:34:14] stichnot: neufeld: I recall from #11326 that the PTS reset problem could be dealt with by generated a frame-based .srt file instead of timecode-based, but I don't remember why frame-based was impractical. Does it become practical under this new way of generating caption files?
[22:34:14] ** MythLogBot http://code.mythtv.org/trac/ticket/11326 **
[22:34:53] tonsofpcs: frame-based in that it uses a frame counter or ?
[22:36:55] stichnot: yes, in the frame-based mode, captions timings are with respect to the frame number in the recording (starting from zero)
[22:38:14] tonsofpcs: and timecode base is relative to timecode that comes in with the stream, not regenerated timecode?
[22:38:59] stichnot: right, the PTS value in the original stream.
[22:42:49] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-))
[22:44:13] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer)
[22:46:56] neufeld: stichnot: I think the issue was that that wouldn't be a .srt file anymore if you changed the time in the file dropped on disc. It might work if it were converted internal to the player, but there were questions about where to do it.
[22:56:53] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv
[23:30:47] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 268 seconds)
[23:43:03] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv
[23:43:48] stichnot (stichnot!~stichnot@107.229.190.174) has joined #mythtv
[23:43:48] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:43:48] stichnot (stichnot!~stichnot@107.229.190.174) has quit (Changing host)

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