MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (78):

Anssi, anykey_, Beirdo, brfransen, cesman, coling, Cougar, dekarl, ElmerFudd, fetzerch, foobum, GreyFoxx, IReboot, joe___, joki, jpabq, jpabq_, jpharvey, kurre2, kwmonroe, mrand, MythLogBot, neufeld_AFK, Peps, poptix, purserj, Seeker`, seld_, skd5aner, sphery, sraue, sutula, Tobbe5178, wolfgang1, xavierh_, xris, _charly_, aloril, Captain_Murdoch, Chutt, dblain, ghoti, gregL, J-e-f-f-A, jams, jarle, jarryd, jheizer, jst, jwhite, Kevin`, laga, MythBuild, Peitolm, petefunk, rhpot1991, superm1, tgm4883, tonsofpcs, tris, Vernon_at_work_, wagnerrp, XDS2010_, kc, clever, rsiebert, Sharky-Sleep, knightr_, danielk22, natanojl, sl1ce, MaverickTech, amessina, NightMonkey, garybuhrmaster, f33dMB, jya, andreaz

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229

Error at /usr/share/beirdobot/web/includes/utils.php, line 229:
Undefined variable $query


Details:
    datetime:  2025-10-19 10:53:35 (UTC)
    errornum:  2
  error type:  Warning
error string:  Undefined variable $query
    filename:  /usr/share/beirdobot/web/includes/utils.php
  error line:  229
Thursday, January 3rd, 2013, 00:01 UTC
[00:01:52] Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer)
[00:02:41] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[00:36:16] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[00:36:35] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[00:36:35] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[00:36:35] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[00:38:20] garybuhrmaster (garybuhrmaster!~gtb@128.3.3.159) has left #mythtv ()
[00:43:10] Chutt: amd's waaaay behind on perf/watt
[00:43:40] Chutt: they're not even close to competitive, intel's 2 generations ahead on transistor size
[00:44:00] joki (joki!~joki@p54865A9A.dip.t-dialin.net) has quit (Ping timeout: 264 seconds)
[00:45:38] joki (joki!~joki@p5486598B.dip.t-dialin.net) has joined #mythtv
[00:49:20] stuartm: hmm, are they now offering something in the ~40W range, I've not been shopping for a long time and when I was they either offered very high performance but TDP to match or low TDP but lousy performance (Atom etc), they seemed happy to leave the middle ground of reasonable performance, reasonable price and reasonable power consumption to AMD
[00:52:29] stuartm: fwiw, google answered the question
[01:04:11] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[01:07:44] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Read error: Connection reset by peer)
[01:07:53] zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv
[01:07:53] zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host)
[01:07:53] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[01:20:30] dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv
[01:23:21] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:26:13] stichnot (stichnot!~stichnot@207.198.105.19) has joined #mythtv
[01:26:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:26:14] stichnot (stichnot!~stichnot@207.198.105.19) has quit (Changing host)
[01:28:28] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[01:29:32] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[01:30:42] jheizer_laptop: Someone familiar with the Services API and/or UTC change, did the datetimes being returned from the service change with .26?
[01:31:57] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 265 seconds)
[01:44:31] gigem: garybuhrmaster: (In case you read the logs) It was the performance / dollar that I used to value before I had the motherboard problems and a rash of instability. While the Intel systems I've built since haven't been perfect, they've been considerably better. Perhaps I should just stick with what's been working (Intel) for me. I was hoping to get a quad-core CPU, motherboard and memory for not much more
[01:44:33] gigem: than $200, though, and most Intel quads are about that much already. Guess I need to start watching the Fry's, MicroCenter, Newegg, etc. ads again and jump when I see a good deal.
[01:47:27] gigem: stichnot: I'm afraid the latest patch makes me sad again. With it, the duration only updates every 3 seconds or so. For example, pause at 0:10:00 of 2:00:00 and it will update to 0:10:00 of 2:00:03 after 3 seconds then of 2:00:06 after 6 seconds.
[01:55:52] jheizer_laptop: oh, I guess I have problems from upgrading to .26. I assumed it was a change that I had to account for in my web app
[02:00:50] skd5aner: gigem: better yet.... http://camelcamelcamel.com and/or http://camelegg.com
[02:01:04] skd5aner: let it do the monitoring for you
[02:11:03] stichnot (stichnot!~stichnot@ppp-68-126-151-206.dsl.pltn13.pacbell.net) has joined #mythtv
[02:11:03] stichnot (stichnot!~stichnot@ppp-68-126-151-206.dsl.pltn13.pacbell.net) has quit (Changing host)
[02:11:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:11:16] gigem: skd5aner: Cool! I usually check Newegg's sales frequently, but the others not so much.
[02:11:44] stichnot: gigem: that's what I get for not testing it first. I'll get back to you in a few hours.
[02:12:36] skd5aner: gigem: I've started going pretty heavily with amazon as my first choice... particularly since I get free 2 day shipping, and there are two distribution centers within 15 miles of my house... so I usually get them faster anyway, and their prices are generally consistent with newegg...
[02:13:03] skd5aner: in fact, I see newegg offering sales very frequently because amazon has undercut them – usually via a discount code directly on the product's page to match the amazon price
[02:13:38] jheizer_laptop: I have noticed the same too
[02:13:46] skd5aner: newegg distributes either from California or Memphis, both are 2–5 days ground from me
[02:14:02] jheizer_laptop: I use to always order newegg no matter what but bought a lot more from amazon and eventually bought prime this past year
[02:14:06] skd5aner: that said, I still generally check both
[02:14:43] jheizer_laptop: I actually have a tablet and laptop on the way from TN to IL from amazon right now
[02:14:54] jheizer_laptop: 2 day prime is addicting...
[02:15:06] skd5aner: jheizer_laptop: same... newegg was the defacto... sure beats the old days though of actually shopping around for any store with the lowest price
[02:15:35] jheizer_laptop: skd5aner: yeah now between those 2 I am happy with the price
[02:15:51] skd5aner: jheizer_laptop: very. South Park made fun of it sometime in the last year or so... where people were forgetting what the UPS man was bringing them from Amazon...
[02:16:14] jheizer_laptop: Hahaha I got that this year a few times
[02:16:14] skd5aner: I quickly realized that I'm the same way – I have to open the box now to be like "oh yea, that's what I ordered" :P
[02:16:35] jheizer_laptop: between finishing my basement, having a baby, christmas, etc I always had all kinds of unrelated things showing up
[02:17:13] skd5aner: yea, same here... baby, christmas, home DIY, electronics, car parts, household goods...
[02:18:18] jheizer_laptop: I tried to play # of orders fight with a friend last week
[02:18:32] jheizer_laptop: His 87 orders beat my 66. lol (2012 total)
[02:19:32] skd5aner: hmmm, now I'm curious – is there an easy way to see the sum?
[02:19:42] jheizer_laptop: order history
[02:19:48] jheizer_laptop: drop down select 2012
[02:19:58] jheizer_laptop: top left has # orders in 2012
[02:20:54] skd5aner: 55, but that only counts orders – not individual items
[02:21:02] jheizer_laptop: yeah
[02:21:21] jheizer_laptop: yeah I was curious items too
[02:21:29] jheizer_laptop: but seemed like too much effort
[02:21:47] jheizer_laptop: all I know is I spent WAY too much $ with them
[02:22:47] jheizer_laptop: hmm, I think I may "release" my web frontend today
[02:23:26] jheizer_laptop: meant to 2 weeks ago. Had my laptop die. Then my myth MBE OS drive. Then wife's desktop....
[02:23:37] skd5aner: less than you likely would have spent elsewhere for the same items, + time + tax + gas
[02:23:52] jheizer_laptop: oh yeah, more just amazing how much stuff
[02:25:32] jheizer_laptop: I may know of a tablet friendly web frontend that is new baby wife approved. ;-)
[02:25:55] skd5aner: glad to see you putting in all the effort to build it
[02:26:28] jheizer_laptop: trying
[02:27:35] jheizer_laptop: been using myth ~9 years
[02:27:42] jheizer_laptop: time to give something useful back
[02:28:07] skd5aner: 9 years here also
[02:28:21] jheizer_laptop: I did start writing a native windows FE a long time ago that could use the std themes at the time but then the window ports came our along with the new ui
[02:28:24] jheizer_laptop: so I dropped that
[02:30:31] jheizer_laptop: Hopefully it being .net does not scare everyone off
[02:30:41] jheizer_laptop: easy enough to setup/install
[02:31:18] jheizer_laptop: Next goal point is livetv
[02:33:28] crankharder (crankharder!~crankhard@ip68-98-153-131.dc.dc.cox.net) has joined #mythtv
[02:33:31] crankharder (crankharder!~crankhard@ip68-98-153-131.dc.dc.cox.net) has left #mythtv ()
[02:34:05] jheizer_laptop: ugh win8 is pissing me off
[03:17:07] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[03:19:04] danielk22: jheizer_laptop: I think there was maybe one call that changed with UTC. The service API was already working in UTC when initially released in 0.25, there were just a couple bugs that needed fixing (that particular service class's API version was incremented so it would be possible to support both 0.25 and 0.26 at the same time.)
[03:20:21] jheizer_laptop: danielk22: Thanks. It ended up I had to truncate and reload my guide data. I didn't notice it was all messed up after restoring my system and upgrading to .26 as I do not have a frontend online yet.
[03:21:38] jheizer_laptop: Is that the <ProgramGuide version="1.0" ?
[03:22:26] danielk22: I don't think so, I believe it was some auxiliary API that changed.
[03:22:40] jheizer_laptop: Only one I may have noticed was different than what I had working already was the guide data. But I can't say i ever checked it as I am only displaying what is on now as a test. Haven't been in the mood to write the full guide support
[03:22:42] jheizer_laptop: ah ok
[03:41:17] jheizer_laptop: Not sure if anyone cares or it is a big deal but the channel icon takes lower case url parameters while the same parameters in other places start with a capitol letter.
[03:41:23] jheizer_laptop: ex width vs Width
[03:43:34] jheizer_laptop: If some one can confirm I'll update the wiki
[03:43:39] jheizer_laptop: ex: http://10.0.0.197:6544/Guide/GetChannelIcon?C . . . mp;height=60
[03:44:47] jheizer_laptop: actually, it ignores the lower case version
[03:54:43] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[04:01:27] IReboot (IReboot!~doug@CPE001fc65acdff-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Ping timeout: 276 seconds)
[04:09:29] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:15:28] dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat)
[04:22:34] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 240 seconds)
[04:39:42] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 255 seconds)
[04:47:29] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[04:48:36] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:53:27] sraue_ (sraue_!~stephan@178-191-214-242.adsl.highway.telekom.at) has joined #mythtv
[05:20:35] stichnot: gigem: looks like the problem is that the reported frame rate was off by a factor of 1000. video_frame_rate is frames per second (e.g. 29.97), while m_frameRate is frames per 1000 seconds (e.g. 29970). This made the frame interval appear close to 0, looking like no time was elapsing until the next seektable update.
[05:21:26] stichnot: Anyway, I will go ahead and commit the fix, and tweak it later as needed.
[05:23:45] gigem: stichnot: Okay.
[05:28:36] gigem: skd5aner: For me, the sales tax with Amazon often outweighs any price advantage they have over Newegg. Microcenter is the one to watch. They're usually higher on most things, but somteimes have killer deals on select CPUs. I got the one in my development system for about $60 less than Newegg and Amazon.
[05:35:30] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[05:36:28] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[05:40:55] gigem: skd5aner: Like the Core i5 3570K that is currently $50 less than Amazon and Newegg. Damn, I'm going to be sorely tempted tomorrow.
[05:49:04] stichnot: gigem: Thanks again for the help with testing. Let me know if you find any more anomalies.
[06:19:16] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 248 seconds)
[06:24:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds)
[06:31:56] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv
[06:34:47] stichnot (stichnot!~stichnot@ppp-68-126-151-206.dsl.pltn13.pacbell.net) has joined #mythtv
[06:34:47] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:34:47] stichnot (stichnot!~stichnot@ppp-68-126-151-206.dsl.pltn13.pacbell.net) has quit (Changing host)
[06:39:21] rsiebert (rsiebert!~quassel@g225055002.adsl.alicedsl.de) has joined #mythtv
[06:42:13] rsiebert_ (rsiebert_!~quassel@g225056035.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds)
[06:57:00] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit)
[07:03:15] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[07:15:47] f33dMB (f33dMB!~f33dMB@li100-62.members.linode.com) has joined #mythtv
[08:15:09] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[08:15:26] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[09:04:41] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:3114:c07d:be5a:4761) has joined #mythtv
[09:14:23] stoffel (stoffel!~quassel@pD9E42236.dip.t-dialin.net) has joined #mythtv
[10:03:09] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Remote host closed the connection)
[11:26:15] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:51:41] stoffel (stoffel!~quassel@pD9E42236.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[11:58:14] Sharky112065 is now known as Sharky-Sleep
[12:38:15] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv
[12:39:57] IReboot (IReboot!~doug@99.234.135.176) has joined #mythtv
[12:41:21] soa2ii (soa2ii!~quassel@2001:4d88:1ffc:464::1) has joined #mythtv
[12:41:31] soa2ii (soa2ii!~quassel@2001:4d88:1ffc:464::1) has left #mythtv ("http://quassel-irc.org - Chat comfortably. Anywhere.")
[12:41:59] IReboot (IReboot!~doug@99.234.135.176) has quit (Remote host closed the connection)
[12:44:34] IReboot (IReboot!~doug@CPE001fc65acdff-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:38:42] stichnot: taylorr: I was looking into the problem where mythcommflag --rebuild on an h.264 (HDPVR) recording identifies a lot more keyframes than the recorder.
[13:38:56] stichnot: My understanding is that we want only IDR frames.
[13:39:28] stichnot: I think the AvFormatDecoder constructor should be calling m_h264_parser->use_I_forKeyframes(false).
[13:40:17] stichnot: This is done in MpegRecorder::OpenV4L2DeviceAsInput(void).
[13:41:08] stichnot: When I do that in the current code, and compare the results of mythcommflag --rebuild against the recorder, there are two discrepancies.
[13:42:38] stichnot: First, the initial non-zero keyframe number is different, e.g. the recorder starts at frame 125 while mythcommflag starts at 96.
[13:43:28] stichnot: Second, the mythcommflag keyframe distance seems to be roughly 1 frame less than the recorder (and the recorder seems to be always exactly 128).
[13:45:08] stichnot: The file offsets for keyframes seem to match up exactly (despite the differences in frame numbers), which I guess is a good sign.
[13:46:43] stichnot: Are there any tools that can independently verify the seektable? i.e. produce a list of all IDR keyframes and their file positions
[13:46:49] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[13:48:01] stichnot: neufeld_AFK: ^^^
[13:49:30] sraue_ is now known as sraue
[13:49:33] sraue (sraue!~stephan@178-191-214-242.adsl.highway.telekom.at) has quit (Changing host)
[13:49:33] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[14:18:18] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[14:35:17] zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv
[14:35:17] zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host)
[14:35:17] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[14:36:00] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[14:44:36] neufeld_AFK is now known as neufeld
[14:44:51] neufeld: stichnot: I've got my transcoding working, with an ffmpeg keyframe extractor
[14:45:29] neufeld: stichnot: jumps look correct, I don't get the severe image ghosting you see when you arrive on a non-keyframe.
[14:46:23] neufeld: stichnot: you need a recent version of ffmpeg. 1.0 works, 0.8.4 doesn't (it appears to work, but returns 0 for the start pos of all frames). Even earlier versions don't support the invocation syntax.
[14:46:50] neufeld: I use: ffmpeg -y -nostats -i <H264_transport_stream_file> -vf showinfo -f null -
[14:47:11] neufeld: then I parse out against: if ( /.* n:(\d+) .* pos:(\d+) .* iskey:1 .*/ )
[14:47:41] neufeld: These go into the seektable as VALUES(chanid, starttime, $1, $2, 9)
[14:48:22] neufeld: stichnot: I haven't completely cleaned up the script for general use to send to the wiki yet, but I can send it to you if you want to see it in context.
[14:50:35] danielk22: stuartm: Do you know if we are using the concurrency checking part of coverty? If not is it available to us?
[14:51:52] stichnot: neufeld: not thrilled about the idea of upgrading ffmpeg :)
[14:52:14] stichnot: neufeld: are you running master?
[14:52:21] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[14:52:22] stichnot: mythtv master, that is
[14:52:35] neufeld: stichnot: Yeah, I use an external offload engine. I don't muck with the ffmpeg on the backend, but my transcoding script has the ability to ssh elsewhere and use the ffmpeg installed there. That's what I use here.
[14:52:40] danielk22: stichnot: jya upgraded us to 1.0, so we should already be there in master..
[14:53:09] stichnot: danielk22: cool, good point
[14:53:55] neufeld: I don't chase checkins, it's our only means of watching TV, so upgrades to hardware or software are planned weeks in advance and executed carefully. I'm at DB schema 1299.
[14:54:53] danielk22: stuartm: I'm looking at Intel Inspector XE 2013. It has concurrency analysis and is free for non-commercial use.
[14:55:12] danielk22: I don't know if it can generate a web page though..
[14:57:01] stichnot: neufeld: ok, then I won't ask you to try a patch. I'm wondering whether your script's results more closely match the recorder's seektable, or the seektable from a patched version of mythcommflag.
[14:57:24] neufeld: stichnot: I suppose I don't have to convert to transport streams anymore. I used to do that because mythcommflag --rebuild refused to run on straight H.264 program streams, so my script runs it through the annexb filter to generate a transport stream. But now that I'm using ffmpeg to extract the keyframes, maybe I don't need that step. I'll have to try that out.
[14:58:20] neufeld: stichnot: in the 0.25.2 mythcommflag, the keyframes are all there, and with exactly the correct position. The problem is, other frames are also intercalated into the list, and those aren't keyframes. That is, mythcommflag produces a superset of the ffmpeg script data.
[14:59:03] stuartm: danielk22: the Coverity Scan FAQ lists concurrency issues, although those would be found through SA rather than any runtime analysis – http://scan.coverity.com/faq.html#what-types-of-issues-tool-find
[15:00:04] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[15:00:27] neufeld: stichnot: I can try patches if you need them. mythcommflag runs over the network, and I have all manner of patched up binaries on my main desktop which I use for debug builds and so forth, running mythcommflag under gdb, all without interfering with the machine in the basement. Of course, patches that require a different DB schema would be a problem in this model...
[15:00:33] stuartm: Also mentions concurrency and concurrent data access violations in – http://www.coverity.com/library/pdf/coverity- . . . y-report.pdf
[15:02:00] stuartm: I can't actually remember seeing errors relating to concurrency in the report though :(
[15:02:06] danielk22: stuartm: Hmm, if they have only found 31 data races they can't be detecting the majority of them...
[15:02:48] danielk22: I could probably find that many in an afternoon reading the code :)
[15:02:51] stichnot: neufeld: here is the mythcommflag patch: http://pastebin.com/Fa6kK5PY
[15:03:34] stuartm: danielk22: that PDF doesn't relate to our code :)
[15:03:52] stuartm: it's the kernel !!
[15:04:03] stuartm: a 2.6 kernel anyway
[15:05:09] stichnot: neufeld: from what you're describing, it sounds like the keyframes identified by mythcommflag (after removing the non-IDR frames which my patch is supposed to do) are closer to reality than those identified by the recorder.
[15:05:33] danielk22: heh, ok so now we just have to find an example in our report to know what to look for...
[15:05:39] stuartm: danielk22: the developer FAQ for scan hints that some projects may be granted access to 'advanced features and additional tools', but it's only mentioned as an aside in a bit talking about NDAs
[15:06:04] danielk22: do we have a contact at coverty to ask?
[15:07:38] neufeld: stichnot: OK, I've installed your patched version on my testing machine. I'll back up my seek table and test the patch.
[15:07:52] stichnot: neufeld: thanks.
[15:08:19] stuartm: not a direct contact no, since it was originally Eric Sharkey who set it up, I've never had contact with anyone at Coverity – we could try scan-admin@coverity.com
[15:08:47] stichnot: neufeld: "mythffmpeg -y nostats -i /storage2/recordings/3175_20130103132900.mpg -vf showinfo -f null -" doesn't work. :( "[NULL @ 0x97fa500] Unable to find a suitable output format for 'nostats'" / "nostats: Invalid argument"
[15:09:41] danielk22: stuartm: http://stackoverflow.com/questions/2444787/wh . . . ou-recommend <-- sounds like someone else running coverty and not seeing concurrency issues reported, but again maybe the checks just aren't enabled.
[15:09:57] stuartm: alternatively I seem to remember a coverity guy sending an email to the -dev list not long after we were set up with an account, he was noting that we'd ignored all ffmpeg errors and explained how to set it up so to permanently ignore external code from the analysis
[15:10:06] danielk22: stuartm: I'm sure checking for concurrency bugs slows down the scan quite a bit.
[15:11:35] stuartm: danielk22: yeah, it's already pretty slow :)
[15:11:44] stuartm: They also have a forum – https://communities.coverity.com/welcome
[15:12:26] neufeld: stichnot: you missed the '-' ahead of nostats
[15:12:54] stuartm: fwiw, obtaining information on features and usage is difficult, they seem to keep manuals etc under lock and key for paying customers
[15:13:19] stichnot: d'oh! thanks.
[15:13:42] stuartm: The open source sub-forum – https://communities.coverity.com/community/sc . . . rce)/content
[15:23:07] danielk22: stuartm: The Open Source forum seems a bit empty and the threads I found in the overall forum weren't helpful. I've e-mailed the scan-admin address with some questions...
[15:25:28] stuartm: yeah, the open source forum seems a bit dead, but then like a lot of things about SCAN, they don't advertise it at all, I found it by accident
[15:29:39] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 248 seconds)
[15:32:00] danielk22: Looking at the Intel stuff it looks like it is dynamic analysis only + you actually need to use the 2011 version to get the GUI.
[15:36:55] garybuhrmaster (garybuhrmaster!~gtb@128.3.3.159) has joined #mythtv
[15:40:33] garybuhrmaster: gigem: (yes, I review the logs). With few exceptions Micro Center has the lowest prices on CPUs (that *normal people* can get). The disadvantage is that they only sell the CPUs in the store itself as the loss leader for the up-sell, and they recently closed the store near me :-( due to rent going sky high.
[15:41:22] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[15:42:37] stichnot: neufeld: it does look like the mythcommflag output more closely matches the mythffmpeg output. However, in my 30-minute test recording, there is a slight drift in which mythffmpeg identifies the last keyframe as n:114400 but mythcommflag says 11436. I wonder if you see anything similar.
[15:44:54] stichnot: sorry, that should have read 114364 for mythcommflag
[15:45:42] stuartm: sphery, wagnerrp: http://www.theregister.co.uk/2013/01/03/windows_media_center/
[15:46:43] stuartm: mce2xml is dead in Europe at least :)
[15:47:14] sphery: wow... wonder if they're cracking down because of that
[15:47:50] sphery: wagnerrp just had to revert some changes to the wiki talking about how to make mce2xml work, yesterday
[15:48:00] stuartm: maybe not, as the article notes we have pretty decent EIT coverage in europe so it may just be a cost cutting measure
[15:48:47] stuartm: although as it also points out, that isn't available to those using capture from cable etc
[15:49:17] sphery: might be that they're planning to shift those users over to XBL--they've really put a lot into making Live the go-to place for content (and now that it's a portal for Win 8/Win Phone 8/Xbox...)
[15:52:28] sphery: Did you also see the articles about Intel's STB aspirations--and how they're being crushed by the content owners. Intel wanted to "unbundle" shows--so you could subscribe to individual shows (i.e. The Walking Dead, instead of all of AMC)--or, at minimum, make a la carte channel selection (without having to get useless channels to get ones you wanted), but it seems they may not be able to get that to happen. (And, it seems their whole purpose ...
[15:52:34] sphery: ... in building the STB was because Apple/Google didn't do it right, because they didn't offer this--where they didn't for the same reason.)
[15:53:12] stuartm: time shifted broadcast TV does get in the way of those content domination plans of MS/Apple and Amazon :)
[15:54:03] sphery: hehe, yeah... though they had tried to allow it, they may end up better off now that the content producers forbade it
[15:54:52] stuartm: sphery: I hadn't read those articles no, I can see why broadcasters would hate the idea that after watching their big draw shows users wouldn't automatically sit through their crap stuff because they are too lazy to find the remote
[15:55:53] sphery: yeah--let alone the "how am I going to sell <useless> channel if I can't force it on viewers as a consequence of getting my best channel"
[15:56:07] danielk22: I'm sure somebody just dropped the ball over a Microsoft. If it were planned it would have been announced ahead of time.
[15:57:13] sphery: that would make sense--but it's pretty amazing it's been that way for 3 days, now, and isn't fixed
[15:59:16] garybuhrmaster: sphery: Not if the person that dropped the ball now needs corp. lawyers to renegotiate a contract (during the new years vacation period for anyone with a JD at the end of their business card).
[15:59:33] neufeld: stichnot: I'm seeing a drift too. Just characterizing it now. It may not be important, I'll check the effect on playback. I'll have better conclusions on the drift in a few minutes.
[16:00:04] stuartm: could be that simple, although the mention that it also stopped in early December for Irish users leaves room for doubt
[16:02:13] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[16:02:54] stuartm: I can't honestly believe that Red Bee or whoever was providing that data to MS wouldn't have tried to contact them before the contract ended, although like all screwups it may simply be the case that their contact at MS (let's call him Bob) had retired and their emails were going to an unmonitored inbox, phone calls to a disconnected extension
[16:03:18] garybuhrmaster: stuartm: If you wanted coverity docs, you could sign up for the free download of coverity, and go to the docs subdirectory (or at least I think that is where they were placed). Of course, that would result in a regular "Would you like to purchase" email/phone_call.
[16:05:53] stichnot: neufeld: thanks. It would be good to know which of the 3 (if any) is accurate. My money is on ffmpeg...
[16:05:55] garybuhrmaster: stuart: re: MS EPG. Occam's razor. I am going with the simple incompetence theory.
[16:07:44] wagnerrp: stuartm: i was under the impression it was only XP MCE using the old protocol
[16:09:44] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[16:09:51] stuartm: the article says that W7 is only unaffected since it's able to use EIT instead
[16:10:33] stuartm: but I've not read beyond that article, so maybe the journo got the facts wrong
[16:12:35] neufeld: stichnot: I'm going to use the ffmpeg results as authoritative for the purposes of this description-- The first and second keyframes agree exactly. Then the patched mythcommflag drops a frame number somewhere between the keyframes at 52 and 77 (the latter of which mythcommflag reports as frame 76). The next lost frame occurs between keyframes at 2511 (reported as 2510) and 2560 (reported as 2558). The next lost
[16:12:36] neufeld: frame occurs between keyframes at 17575 (17573) and 17650 (17647). By the end of the recording, mythcommflag has lost 6 frames out of 74736 total frames (including non-keyframes) in the file.
[16:12:42] neufeld: stichnot: going to check playback now
[16:15:15] garybuhrmaster: stuartm: The Register getting something wrong? Say it ain't so......
[16:15:22] stuartm: heh
[16:16:48] wagnerrp: http://thedigitallifestyle.com/w/index.php/20 . . . eturn-again/
[16:17:16] dekarl: stuartm, re #9197 I'm looking at local cable (more services in the clear since yesterday) and shorteventdescription is left(x, eventdescription) for some services. Is that what the ticket is about? Or is the ticket about the description being split with the beginning in the short event descriptor and the ending being in the descripton?
[16:17:16] ** MythLogBot http://code.mythtv.org/trac/ticket/9197 **
[16:17:53] wagnerrp: seems thereg is overreacting
[16:18:01] wagnerrp: and this has happened before
[16:18:37] stichnot: neufeld: if mythcommflag --rebuild is dropping a few frames, then I would predict that seeking to later keyframes in e.g. the cutlist editor would be relatively slow compared to keyframes at the beginning.
[16:19:04] neufeld: stichnot: I don't know exactly how these frame numbers are used, but I suspect this drift isn't a big deal. The jump picks a key frame near the nominal target of the jump, based on 'n'. It doesn't care what the exact 'n' is, just that it's the nearest to the target time. The seek pos is correct, so it'll still display correctly.
[16:19:19] neufeld: stichnot: OK, playback looks just fine. Much better than before the patch.
[16:19:52] neufeld: I'll test your cutlist editor theory
[16:20:18] dekarl: wagnerrp: but the story sells ads :)
[16:22:06] stuartm: dekarl: the short event descriptor isn't clearly defined but it's basically a short description field, I guess so guides can show a short description in the EPG and a longer one when you select the programme – the problem is that an assumption was made that the short event descriptor contains the episode name instead of a description, since this is how it's used on some networks
[16:22:13] dekarl: re MCE donationware, do I have to be a paypal customer to complain about TOS violation of a vendor so paypal can seize the account?
[16:23:01] neufeld: stichnot: can't say I see any lag in keyframe seeking in the cutlist editor using the new mythcommflag seek table. It appears to me to be doing as good a job as the ffmpeg scripting I wrote.
[16:23:02] dekarl: stuartm: aye, works well for some of the services I see over here, others have a copy of the first part of the full description
[16:23:10] stuartm: if you take a description which can be up to 255 characters long and try to shove it into the subtitle field not only does it get truncated, but it's all wrong
[16:23:44] stuartm: subtitle column is 128 char long
[16:23:44] dekarl: I'm wondering if a logic like "drop the short event description if it matches the len(short) first characters of the long event description" would solve the issue
[16:24:17] dekarl: for the services I see on german cable it would work
[16:24:27] stuartm: dekarl: I think network specific fixups are the only proper fix, we can't assume that the short description is the same thing as the subtitle (episode name)
[16:25:36] stuartm: so in the UK it's safe to put the short descriptor content in the subtitle field, since it's used here for the episode title and nothing else, but for Danish cable we'd put nothing in the subtitle field and ignore the short descriptor
[16:26:01] gigem: stichnot: You're welcome, and thanks for finally fixing the annoying postition/duration display issues.
[16:26:41] dekarl: aye, specific fixups sounds like the safe way. other services have (in that order as the time of broadcast approaches) a) no description b) a short description in the description c) the same short description in the short description d) the same short description in the short description and a new long description in the description.
[16:26:59] stuartm: dekarl: I don't think it's so simple as the short decriptor is the first x characters of the long form, that might apply where you are but it's not going to be universal
[16:27:44] Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv
[16:28:07] dekarl: so lets pretend I'd add some fixups, what would the generic case be? Put the description in the description. Long replacing short?
[16:28:48] gigem: garybuhrmaster: The MicroCenter near me is still going strong, which is actually a bit surprising as there are two Fry's within 6 miles of it.
[16:29:17] stuartm: dekarl: yeah, long descriptor preferred for description, but falling back to the short if that's all there is
[16:29:34] stuartm: nothing at all into the subtitle
[16:32:20] dekarl: exactly. episode title only being populated by a generic fixup hinting at the short event descriptor or a specific fixup that scrapes it from the description
[16:35:30] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Read error: Connection reset by peer)
[16:36:23] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv
[16:37:01] stichnot: neufeld: are you using Doug Vaughn's lossless cut tool, or rolling your own?
[16:37:33] neufeld: stichnot: I've written my own, variation on the H264 transcoder on the wiki.
[16:37:33] natanojl: sphery: Is it ok if I grab #11081 from you?
[16:37:33] ** MythLogBot http://code.mythtv.org/trac/ticket/11081 **
[16:37:45] neufeld: stichnot: mine's not lossless, so I can do some new tricks.
[16:38:10] neufeld: stichnot: my favourite feature: exact cut points, it doesn't round to the next keyframe, which in a HD-PVR recording could be 3 seconds away.
[16:39:04] neufeld: stichnot: I incorporated mkvmerge, I got that idea from reading Doug's code. That's how I get the exact cuts.
[16:39:49] sphery: natanojl: please do... that only got assigned to me since it's in the Contributed Scripts & Apps component, and you're a much better candidate for fixing it. Feel free to change component, too, if there's a better one.
[16:40:00] sphery: and thanks
[16:40:28] ** sphery admits he's far enough behind on tickets he didn't realize that one existed, let alone got assigned to him **
[16:40:43] natanojl: sphery: :)
[16:41:43] stichnot: neufeld: ok. I haven't looked closely at Doug's code. I'm wondering if the mythcommflag fix will benefit/fix both approaches.
[16:42:08] neufeld: stichnot: I get the cutlist, figure out times from that, transcode it with ffmpeg but with a force-keyframes argument to put in extra keyframes exactly at the cut points, then mkvmerge clips out the cuts without having to round anything off. Then through annexb to make a transport stream (I think mytharchive requires a TS), fix seek table, fix .srt file, update database, and done.
[16:43:13] neufeld: stichnot: don't know whether that will help him. mkvmerge always rounds to the next true keyframe when cutting. Better to ask him, I guess.
[16:43:54] ** neufeld goes to buy lunch **
[16:43:57] neufeld is now known as neufeld_AFK
[16:44:12] IReboot: stichnot: It is interesting that you mention some "drift" as some Lossless Cut users have reported slight lip sync issues with lossless cut recordings with durations of 2hr+
[16:46:50] IReboot: stichnot: One other thing I was hoping that with the recent changes in the v0.27 seek table that Lossless Cut would be able to handle the x264 HDHomeRun recordings with variable frame rates. Using the added time codes and not doing a calculation when that data exists.
[16:51:11] stichnot: IReboot: how does variable frame rates come into play?
[16:53:47] IReboot: stichnot: That was my conclusion from reading the mailing list discussion of why Lossless Cut (mkvmerge) works on HDHomerun recordings from some TV stations and not from others.
[16:57:18] stichnot: IReboot: the changes to the seek table only involve adding duration information, which is only used for position/duration display and seeking, so I can't think of a way it could affect lossless cut. :(
[16:59:32] stichnot: however, a couple of legitimate bugs have been uncovered and fixed, so who knows...
[17:00:03] stichnot: Does the audio drift happen gradually, or only at splice points?
[17:02:19] IReboot: stichnot: The drifting that I have seen is so slight that it may be gradual or at a cut point. You just notice it an know that that it was in-sync to start with.
[17:03:06] danielk22: wagnerrp: Can you take a look at 86d35376 ? It introduced a dereference of an uninitialized iterator to DeleteThread::run(void
[17:03:47] danielk22: AFAICT The old code was correct.
[17:04:15] danielk22: except maybe in calling delete rather than downref
[17:04:46] stichnot: natanojl: thanks for grabbing that ticket. It probably should have been originally assigned to me or danielk22.
[17:07:37] natanojl: stichnot: you're welcome
[17:10:42] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[17:26:36] danielk22: wagnerrp: I've pushed a fix for [86d35376] to master, but can you check it and take care of backporting it?
[17:26:53] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[17:27:20] wagnerrp: will do, note that code is only so far used in mythmediaserver
[17:27:28] wagnerrp: mythbackend still uses the old code
[17:28:01] danielk22: wagnerrp: Is the same code likely to be broken in the old code?
[17:28:19] wagnerrp: could be, probably not
[17:28:39] wagnerrp: haven't yet looked at specifically what you're referring to
[17:31:16] wagnerrp: basically, it was the delete thread rewritten to be ignorant of programs or the scheduler, since it is in libmythproto and doesn't have access to that information
[17:31:23] danielk22: BTW I found another set of problems with the termination conditions. Neither gCoreContext nor m_run are atomic or protected by a synchronization primitive. So C++ is under no oblication to check them each time through the loop. This means "while (gCoreContext && m_run) { ... }" can be optimized to "if (gCoreContext && m_run) while (true) { ... }"
[17:31:55] wagnerrp: the idea is that mythbackend would be changed to wrap it and include the necessary code to delete the metadata along with the file
[17:33:14] danielk22: This http://pastebin.ca/2299096 should fix the m_run usage and make the thread terminate faster. But we should eliminate the gCoreContext check and just make sure the thread is terminated before the context is deleted.
[17:33:56] wagnerrp: i believe i was just duplicating the behavior i saw in some other thread when i wrote that
[17:34:33] danielk22: yeah, it's probably broken there too. I only looked at this code because cppcheck caught the null interator dereference as an error.
[17:37:36] SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has joined #mythtv
[17:39:08] danielk22: wagnerrp: Actually, the code there is very different. It's too complicated for what it does, but it doesn't appear to have this bug.
[17:40:14] danielk22: wagnerrp: Where is the DeleteThread managed? i.e. who calls DeleteThread start() & stop() ?
[17:43:15] wagnerrp: http://code.mythtv.org/cgit/mythtv/tree/mytht . . . ler.cpp#n158
[17:45:27] danielk22: looks like Stop() is never called :(
[17:45:43] danielk22: It's a segfault just waiting to happen...
[17:46:31] danielk22: Can we just relay the myth services delete calls through to the backend and avoid this class altogether?
[17:47:00] wagnerrp: if we're running the backend, there's no reason to be running this
[17:47:00] stichnot (stichnot!stichnot@nat/google/x-kuyirnyuzjqdehkw) has joined #mythtv
[17:47:01] stichnot (stichnot!stichnot@nat/google/x-kuyirnyuzjqdehkw) has quit (Changing host)
[17:47:01] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:47:56] danielk22: I'm confused. There is always a backend somewhere in a MythTV system.
[17:48:31] wagnerrp: mythmediaserver is for when you want to access content from a machine with no tuners
[17:49:36] danielk22: So it has visitbility to some file system that no backend can see?
[17:50:20] wagnerrp: correct
[17:51:24] wagnerrp: although as mentioned, i intend to eventually replace mainserver.cpp by similar handlers, and this (wrapped with some additional functionality) would be the backend's delete thread
[17:51:31] danielk22: Ok, so then we just need to make DeleteThread a singleton managed by mythmediaserver.
[17:54:01] danielk22: wagnerrp: Understood. I'm just concerned about the lifetime management of the thread at the moment.
[17:54:16] wagnerrp: would probably be better to make it managed by FileServerHandler
[17:55:40] wagnerrp: which is in turn managed by MythSocketManager
[17:56:11] wagnerrp: which is managed by mythmediaserver
[17:56:17] danielk22: As long as it gets constructed after MythContext and destructed before the context is then the patch I put on pastebin.ca should fix the only other issue (m_run synchronization between threads).
[17:56:46] wagnerrp: all of the handlers get registered to the socketmanager
[17:56:53] wagnerrp: which automatically clears them out in its destructor
[17:56:56] wagnerrp: http://code.mythtv.org/cgit/mythtv/tree/mytht . . . ager.cpp#n69
[17:58:05] danielk22: So FileServerHandler is long lived?
[17:58:12] wagnerrp: yes
[17:58:22] danielk22: And only a single instance?
[17:58:25] wagnerrp: for the duration of the application, yes
[17:58:54] danielk22: Cool, then it should be easy to just make it own the DeleteThread.
[18:00:43] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:3114:c07d:be5a:4761) has quit (Read error: Connection reset by peer)
[18:03:38] skd5aner: neufeld_AFK: are you willing ot share your transcoding tool/scripts?
[18:03:59] neufeld_AFK is now known as neufeld
[18:04:37] neufeld: skd5aner: yes, I just need to clean it up a bit. It's a new version of http://www.mythtv.org/wiki/Transcoding_Preserving_Captions
[18:06:20] neufeld: skd5aner: right now, I can use it to apply cutlists to PVR-500 / HDHomerun3 / HD-PVR recordings, with exact cut point fidelity, not limited by keyframe position. I transcode to high profile, and reduce filesize. The resulting .mkv files can be used by mytharchive after a few tweaks to its scripts.
[18:06:56] neufeld: skd5aner: the recordings have closed caption data available in .srt files, assuming you've used my HD-PVR CC trick.
[18:08:47] stichnot: skd5aner: sorry, you're probably not going to like the resolution of 10623...
[18:09:18] skd5aner: I love IReboot's lossless, for some things, but I'm really craving something that can transcode the video while perserving the audio (or transcoding it too) – nuvexport has just suffered too much bit rot to keep up :/
[18:11:00] skd5aner: neufeld: that exact keyframe position is such a cool thing... it's my only "complaint" of RDV's lossless cut... but it's not really a complaint, I just with the limitation wasn't there – cool to see you were able to work around it!
[18:12:05] skd5aner: I was trying to cut music videos the other day, with lossless... well – with an HD-PVR, 3 seconds +/- makes a HUGE different when you are trying to cut a clip (i.e., music video) out of a recording
[18:12:09] skd5aner: exact frame really matters
[18:12:31] skd5aner: s/different/difference
[18:12:48] skd5aner: #10623
[18:12:48] ** MythLogBot http://code.mythtv.org/trac/ticket/10623 **
[18:14:28] skd5aner: stichnot: well... it is what it is... I appreciate you putting all the effort in to looking at it. Durations have been wonky every single release for years in some way. Usually because a fix in one version would be a regression for a different version or ffmpeg sync...
[18:15:52] skd5aner: stichnot: as far as new recordings, I am seeing a weird case with my CBS recordings where the current position seems to be behind the actual position... it says it's an hour long recording, but it might reflect that I'm only 45 minutes in to watching a recording when I'm really 58 minutes in
[18:16:24] stichnot: skd5aner: are they variable framerate recordings?
[18:16:31] skd5aner: stichnot: is that already reported somewhere?
[18:16:55] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[18:17:46] stichnot: skd5aner: it sounds similar to what gigem was experiencing. But are you talking about new recordings made within the past 2 days by Master code?
[18:17:50] skd5aner: stichnot: I don't know, honestly – I haven't looked at it too hard – I notice it on all my primetime hour long recordings on CBS... QAM via HDHR or HD5000 tuners
[18:18:04] skd5aner: stichnot: .26-fixes – not running master
[18:19:25] stichnot: skd5aner: that sounds like the same as gigem's recordings. CBS is 1080i, 30fps, and maybe commercials are being inserted at 720p, 60fps.
[18:19:41] skd5aner: Total recording length is reflected correctly, it's watch time that is "slower" than what it should be
[18:20:09] skd5aner: stichnot: yea... If you want I could try and submit a sample somehow – might be hard to get a whole recording to you however
[18:20:51] skd5aner: I don't seem to notice it on NBC, which I think is also 1080i, and I don't think I've seen it on other networks either
[18:22:23] skd5aner: neufeld: well – would love to give it a test sometime... let me know when you'd like some more eyes on it. I don't need the CC data, but it's cool you've got support for that
[18:24:02] dekarl (dekarl!~dekarl@p4FCEF7D9.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[18:26:13] neufeld: skd5aner: I'll try to get it into the wiki today. I'll ping you here when it's available.
[18:27:49] dekarl (dekarl!~dekarl@p4FE8556F.dip.t-dialin.net) has joined #mythtv
[18:28:05] stichnot: skd5aner: For 0.26 recordings, total length comes from the recordedmarkup table, and is produced by the recorder at the end of the recording. Current position is calculated as frame number/video_frame_rate. This gets weird when video_frame_rate changes.
[18:29:39] stichnot: skd5aner: As far as testing goes, I think I'd prefer to just look at recordings from 0.27 / master. Not much I can do about 0.26 and earlier since the total fix includes a protocol change.
[18:37:43] stichnot: IReboot: hopefully bullets 2 and 3 of http://www.mythtv.org/wiki/Lossless_Cut#Known_Limitations are resolved (at least in Master)
[18:38:25] bas-t: I just upgraded from fixes/0.26 to master head today, brand new db. Now, while playing livetv (HD) on my frontends it stutters. Not extreme but quite irritating to me. It doesn't stutter at all while on fixes/0.26. In fact it plays very smooth while using fixes/0.26. I did not test playback of recordings yet, so I don't know if it is an issue of livetv. I want to help improve mythtv, by testing that is, I'm not a coder. My questions: A: i
[18:38:25] bas-t: s this a known issue? If not, B: how can I improve the info that you need for debugging or a bugreport? (like loglevel or hw info, etc)
[18:38:27] IReboot: stichnot: I will update the wiki to that effect.
[18:39:43] stichnot: IReboot: but please verify first :)
[18:40:35] stichnot: bas-t: what is the network connection between the frontend and backend?
[18:40:52] bas-t: same as ever 100 Mb
[18:42:20] bas-t: I reverted to fixes/0.26 and it plays GOOD again
[18:42:50] MythBuild: build #3323 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3323 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:43:08] stuartm: tsk
[18:43:11] stuartm: ;)
[18:43:14] MythBuild: build #90 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . ng/builds/90 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:44:03] bas-t: No changes whatsoever to backend or frontend, except reverting to fixes/0.26
[18:44:26] stichnot: bas-t: I haven't noticed special problems with my gigabit-connected frontends, but I do see some of this with my laptop over wireless. There may have been changes in file seek behavior in 0.26 that cause more network traffic.
[18:44:29] natanojl: stupid me, forgot the header file
[18:44:50] stichnot: tsk on me for those mythplayer.cpp warnings above
[18:45:48] bas-t: stichnot: i'm on a wired connection
[18:45:54] MythBuild: build #297 of master-f17–32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/297 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:47:13] stichnot: bas-t: but you're slower than my gigabit connection where I don't see the problem. Note that I don't have any real evidence yet to support this idea.
[18:48:11] MythBuild: build #225 of master-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/225 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:49:12] stichnot: danielk22: what would be the best logging options to compare the amount of seeking between master and 0.26?
[18:50:06] stichnot: bas-t: also, when testing live TV, make sure to first pause a few seconds so you're not too close to realtime, which can also lead to stuttering.
[18:50:18] danielk22: "-v file --loglevel debug" would probably do it
[18:50:58] stichnot: bas-t: also useful if you can verify whether there's a difference between watching Live TV and watching an in-progress recording.
[18:51:08] bas-t: stichnot: I did. The stream can not be the problem, it is really fast enough for a single HD connection. (like 6GB/Hr max) Could it not be a change in the ffmpeg code?
[18:51:24] bas-t: Will do
[18:51:51] MythBuild: build #4491 of master-linux-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4491 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:52:07] stichnot: bas-t: I'm wondering if it could be a change in the way ffmpeg seeks around the file (which gets translated to relatively high latency network accesses)
[18:52:33] bas-t: yeah, that's my guess too
[18:52:49] bas-t: but I don't want to be cocky
[18:53:08] stichnot: bas-t: this investigation is on my to-do list, so I appreciate your help, especially when you can easily switch between master and 0.26
[18:53:08] bas-t: After all, I'm not a coder
[18:53:44] bas-t: I'm working on that right now, I'm ahead of you
[18:53:47] stichnot: bas-t: also verify whether the problem shows up with fully recorded programs.
[18:54:18] IReboot: stichnot: Is it intended that the subtitle duration fix will be applied to the earlier Myth versions than just Master at sometime? I want my wiki wording to be accurate.
[18:54:31] stichnot: I
[18:54:34] bas-t: I will, once i am ready changing quickly from stable to testing
[18:54:55] stichnot: IReboot: I suspect yes, but natanojl will know better
[18:55:23] IReboot: natanojl: See my question above ^^
[18:55:43] natanojl: stichnot: IReboot: I was planning on fixing it for 0.26 and 0.25 as well
[18:55:56] IReboot: natanojl: thanks
[18:56:21] natanojl: if the darn thing will build that is :)
[18:58:12] MythBuild: build #512 of master-linux-64bit-icc is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/512 blamelist: Jonatan Lindblad <jlindblad@mythtv.org >
[18:58:57] bas-t: stichnot: I'll finish my quick switching routine tonight, will get back at you tomorrow. So good night for now, and lets solve this in the coming few days.
[18:59:14] stichnot: bas-t: thanks.
[18:59:28] bas-t: you're most welcome
[18:59:52] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit)
[19:03:37] MythBuild: build #3324 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3324
[19:04:10] natanojl: sweet
[19:07:37] MythBuild: build #298 of master-f17–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/298
[19:09:42] MythBuild: build #4492 of master-linux-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4492
[19:09:51] MythBuild: build #226 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/226
[19:10:59] MythBuild: build #91 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . ng/builds/91
[19:16:01] MythBuild: build #513 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/513
[19:17:32] Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has quit (Quit: Wolfgang2)
[19:21:42] ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has joined #mythtv
[19:28:49] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Read error: Connection reset by peer)
[19:29:05] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv
[19:40:59] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[19:47:48] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[20:24:09] IReboot: stichnot: Just so you know that for ticket #11322 both srt and vobsub subtitles added to a mkv container by Lossless Cut (mkvmerge) are properly recognized by the Internal player for 0.25 and higher. I am not sure what produced that user's mkv video but this may not be a MythTV issue.
[20:24:09] ** MythLogBot http://code.mythtv.org/trac/ticket/11322 **
[20:29:36] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (Ping timeout: 245 seconds)
[20:38:33] neufeld: When people look at my transcoding script and wonder why I didn't use IReboot's trick to embed the srt into the .mkv file, the reason is that I am converting the file to a transport stream so that mythcommflag is willing to rebuild it, and ffmpeg strips srt streams in the annexb filter. I logged a bug report about that to ffmpeg, but it was closed on the grounds that nobody has proven to them that it is legal for a
[20:38:33] neufeld: srt stream to exist inside an H.264 transport stream. Unless I can find such a beast and get a patch to ffmpeg, I have to stick with separate .srt files.
[21:05:59] neufeld: skd5aner: OK, I've updated the wiki with my new cutting script. http://www.mythtv.org/wiki/Transcoding_Preserving_Captions
[21:09:46] dekarl: neufeld: by "mythcommflag is willing to rebuild it" you are referring to the seek table? Might be an idea to "just" allow building a seek table for mkv then ;)
[21:13:54] neufeld: dekarl: correct. When I first started the script, in 0.24, a H.264 program stream .mkv file was not indexed. I don't know if the situation has improved. It actually got worse with 0.25.2, but stichnot supplied me with a patch today that fixes that issue. I'm interested to see if I can skip the annexb TS step. That might break mytharchive, though, which looks for mpegts when making DVDs from the cut files.
[21:15:59] monkeypet (monkeypet!~monkeypet@c-24-6-135-62.hsd1.ca.comcast.net) has quit (Quit: BitchX-1.2c01-svn -- just do it.)
[21:21:47] dekarl: I'm thinking about using more matroska as its more feature complete compared to e.g. mpeg program streams where you lose the audio tracks language when running lossless mpeg2 transcode (or dvd ripping with vob copy). or mpeg2 program streams that lose chapters compared to the original disks (think vobcopy)
[21:22:06] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Quit: Leaving)
[21:28:57] dekarl: neufeld, mkvmerge seems to create its own cueing/seeking data so you should get away with clearing out the mythtv seek table
[21:31:03] neufeld: dekarl: I like the seek table because I actually sometimes use the cutlist editor during playback to jump around a bit. Would that still work without the entries in the recordedseek table?
[21:32:11] dekarl: thats a good question
[21:35:31] neufeld: Basically, I wanted the result to look just like the original recording. You can still edit a cutlist on the new recording, toggle closed captions, seek back and forth, etc.
[21:37:22] dekarl: just trying it now "mythtranscode --video --infile Harry_Potter_and_the_Deathly_Hallows_Part_1.mkv --buildindex"
[21:37:57] dekarl: if you put the file in place of a recording you can leave out the "--video"
[21:41:03] neufeld: dekarl: I'll be doing some tests with my script later. Tonight or tomorrow. I'll see what happens when I skip the TS step, can I still make DVDs, and does the rebuild work with stichnot's patch, or do I still need to use ffmpeg?
[21:52:07] dekarl: i'll have to test with the lasted master again, but as of yesterday the above actualy breaks seeking (though it allows you to get into the cutlist editor)
[21:53:55] neufeld: dekarl: is it the issue with weird ghosting after a seek? Heavy artefacting? If so, it's because the rebuild is inserting non-keyframes into the recordedseek table, so playback is nonsensical until it encounters the next true keyframe. That's what stichnot's patch fixes.
[21:55:22] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[21:57:24] dekarl: neufeld: no, its the issue with the player exiting :)
[21:58:08] neufeld: dekarl: that's going to reduce the enjoyment
[21:58:33] dekarl: but you can jump around in the editor, its just that the picture doesn't change
[21:58:49] dekarl: you can't have everything :D
[22:00:43] neufeld: inspirational words to live by
[22:01:22] ** neufeld notes that supper time has arrived **
[22:01:25] neufeld is now known as neufeld_AFK
[22:05:49] stichnot: neufeld_AFK: the patch I gave you earlier, I later committed to master/0.26/0.25
[22:06:46] dekarl: stichnot: I'm on afa03f2 ~commit to early
[22:06:54] dekarl: hmm, ~9 commits to early
[22:09:18] stichnot: dekarl: I'm not fully familiar with all the context here, but what do you mean by "the issue with the player exiting"?
[22:10:28] dekarl: I build a seektable for a h.264 bluray rip in matroska with mythtranscode --rebuild, when I tried to jump in the player I was kicked out to the menu
[22:10:30] stichnot: I ask because I've seen issues where the deletemap tracker gets confused after an editing session, causing the player to exit after exiting the editing session.
[22:10:58] dekarl: hmm, I just started playing, hit skip and was back at the menu
[22:11:15] dekarl: lets do something crazy and peek at the logfile
[22:11:24] stichnot: I see
[22:13:26] stichnot: I have been advised in the past that building a seektable for an mkv file is a BAD IDEA, but I never investigated
[22:14:40] dekarl: http://paste.ubuntu.com/1493388/
[22:15:53] dekarl: hmmm -541478725 is AVERROR_EOF
[22:17:34] SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:18:50] dekarl: I did not understand the "use cutlist editor after losslessly cutting" use case, so I'm not sure what the mythtv internal seektable is good for in that case (as seeking works well)
[22:20:31] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[22:22:04] stichnot: dekarl: The deletemap contains a "tracker" so that the player can quickly determine when it reaches the next cut region. See TrackerWantsToJump(). It has nothing to do with the seektable, but is an instance of the player weirdly exiting.
[22:24:08] stichnot: IReboot: for 11322 I'm guessing that there might be a problem with our use of ffmpeg in finding the right stream ID based on the user selection. This kind of error has occurred in the past.
[22:24:34] dekarl: hmm, is that "I want to jump to xxx, if that is within a cut give me yyy the first frame that is not cut after it"?
[22:27:18] stichnot: more like "is the next frame to be played within the next cut region?" If you skip around, the tracker is supposed to be reset/recomputed, but it probably isn't after leaving the editor
[22:27:40] stichnot: there may also be problems when doing high-speed ff/rew
[22:27:44] stichnot: another thing on my list
[22:29:12] stichnot: there's a whole other layer of code that deals with translations between "relative" (cutlist-adjusted) and "absolute" (non cutlist-adjusted) frames and timestamps
[22:37:17] dekarl: I just took a look, and just saw dragons ;) (an entirely new area of the code for me)
[22:45:06] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv
[23:09:47] jya: i had a play with an apple TV 2 the last few days while staying at a friend (no mythtv available). jailbroken it, install xbmc… i have to say xbmc does its job very nicely. Adding videos and retrieving the proper metadata was a breath. it works first go. didn't have to mess with any of the file name for it to work.. best thing was the ability to automatically retrieve subtitles.. it works brilliantly… we really have to up our game there i think
[23:09:58] jya: oh, and Happy New Year to everybody!
[23:11:57] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Remote host closed the connection)
[23:12:54] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Connection reset by peer)
[23:13:58] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[23:19:51] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[23:30:31] andreaz (andreaz!~andre_000@p4FE64A84.dip.t-dialin.net) has joined #mythtv
[23:41:07] Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Remote host closed the connection)
[23:43:14] jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds)
[23:46:06] wagnerrp: the other usability issues not withstanding, i don't believe subtitle grabbing is actually something we can support
[23:46:14] wagnerrp: i don't think that's something that can be legally distributed
[23:47:54] jya: wagnerrp: why not ? they have a few plugins, one of them being supplied with xbmc itself. They retrieve the subtitles from web site like opensubtitle.org or something like that
[23:49:00] wagnerrp: i would think the script is something that would fall under copyright
[23:49:31] jya: in any case, we should just copy what they've done to match file name to actual movie name. because out of the library my mate had (about 76 files), it didn't make a single mistake and at no time did it prompt the user to select something
[23:50:07] jya: opensubtitles.org seems to be user supplied subtitles...
[23:50:41] dekarl: user supplied subtitles that are matched to scene releases...
[23:50:45] jya: where those users get the data I'm not sure :)
[23:51:04] wagnerrp: well they're all user supplied, because unless you're talking about closed captioning, there is no such thing as text-based subtitles
[23:51:05] jya: let say that I don't wish to know :)
[23:51:17] wagnerrp: i'm saying the script itself is copyrighted
[23:51:27] jya: and?
[23:51:31] wagnerrp: and they're not allowed to distribute the script, even if they manually typed it out by hand
[23:51:54] dekarl: just hit any of the titles on opensubtitles.org and notice that in the lower section it clearly mentions the release that matches to this subtitle
[23:52:20] jya: by that logic we shouldn't have most of the feature we have in myth, everything would be copright… fanart etc… all of those are mostly still of the movie: that's under copyright
[23:52:20] wagnerrp: and there is that... which you would have to match to a specific "release" due to timing issues
[23:52:51] jya: wagnerrp: xbmc has an easy setting to put a time offset on the subtitle display.. so making it sync is rather easy
[23:54:23] jya: wagnerrp: if you want to go down the it's copyright-blah stuff. Then I vote to follow that logic completely, and remove all metadata related items
[23:54:24] wagnerrp: in theory, all the fanart is supposed to be user created... of course that's often not the case, especially with things like promotional posters
[23:54:44] jya: wagnerrp: I'm yet to see a fanart that isn't the actual official one
[23:55:06] wagnerrp: but in terms of subtitles, it would be a user made translation
[23:55:48] jya: wagnerrp: i watched a russian movie that only had a russian release… There was a subtitle, it stated at the beginning the name of the person who created it, and signed with opensubtitles.org
[23:55:57] jya: so there is user created content for sure
[23:55:58] wagnerrp: i just know subtitle downloading has been brought up in years previous
[23:56:03] wagnerrp: and always shot down due to concerns of legality
[23:56:51] jya: gosh, you have to be courageous to translate an entire movie like that… must be a lot of work

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