MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (76):

alan`, aloril, Anssi, anykey_, Beirdo, brfransen, Captain_Murdoch, cesman, Chutt, clever, coling, Cougar, danielk222, dblain, dekarl, ElmerFudd, fetzerch, foobum, ghoti, gregL, GreyFoxx, Heikki_, J-e-f-f-A, jams, jarle, jarryd, jhall_, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, jya_, Kevin`, kurre2, kwmonroe, laga, mad_enz, mrand, MythBuild, MythLogBot, natanojl_, neufeld, Peitolm, peper03, Peps, petefunk_, poptix, purserj, rsiebert, Seeker`, seld, Sharky-Sleep, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, superm1, TandyUK, taylorr, tgm4883, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010_, xris, _charly_
Saturday, February 16th, 2013, 00:12 UTC
[00:12:17] natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 248 seconds)
[00:20:15] stichnot: taylorr: so you think the player is losing count of frames? If it were just a matter of reordered frames, I would expect a random variance rather than a continual drift.
[00:26:43] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[00:58:46] taylorr: stichnot: yes, losing frame counts would be my first guess
[01:03:09] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[01:03:24] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Client Quit)
[02:00:05] jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Read error: Operation timed out)
[02:04:49] jst (jst!~quassel@nat/mozilla/x-rvamxvwigrlkthju) has joined #mythtv
[02:05:24] joki (joki!~joki@p548640D9.dip.t-dialin.net) has quit (Ping timeout: 248 seconds)
[02:06:25] joki (joki!~joki@p54863499.dip.t-dialin.net) has joined #mythtv
[02:22:52] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:47:55] drussell_ (drussell_!~drussell@d50-93-49-135.abhsia.telus.net) has quit (Remote host closed the connection)
[03:49:54] peper03 (peper03!~richard@port-92-203-0-142.dynamic.qsc.de) has quit (Ping timeout: 264 seconds)
[03:51:09] peper03 (peper03!~peper03@port-92-203-15-55.dynamic.qsc.de) has joined #mythtv
[04:08:33] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[04:09:54] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:52:11] stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv
[04:52:11] stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host)
[04:52:11] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[05:32:59] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has joined #mythtv
[05:55:21] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv
[06:33:44] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has quit (Read error: No route to host)
[06:34:43] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has joined #mythtv
[08:15:49] SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv
[08:45:56] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has quit (Quit: Leaving)
[09:05:09] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[09:23:21] SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!)
[10:25:51] Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv
[10:42:32] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[10:42:34] SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv
[10:45:09] 16WAAF6ED (16WAAF6ED!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv
[11:17:45] jya: gigem: is the error you are seeing in the compilation of lirc_client.c ?
[11:17:48] jya: it fails here too
[11:18:03] jya: something to do with variable length array
[11:18:33] jya: or maybe it's just because I've resync ffmpeg and I get new compiler flag causing this error
[11:27:58] natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:39:52] jya: anyone else having issue compiling myth master, get error with freetype: http://pastebin.com/sc2GXg5T
[11:41:36] jya: amazing.. I googled that error, and it already has found that pastebin, google had already indexed it
[11:41:58] Seeker`: wow
[11:42:57] dekarl: jya did not happen with the deb packaging on latest master
[11:44:58] jya: trying to compile 0.26 and see if i'm getting that error too
[11:45:58] SteveGoodey: jya: google has you monitored!
[11:46:18] jya: it probably recognised the brilliance of my contributions :)
[11:47:21] jya: ah same error in 0.26
[11:47:28] jya: something to do with my machine then
[11:48:44] Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv
[11:49:13] jpharvey: Just recompiled with latest master code and backed seems to exit now. The message after Mythbacked exiting is from Bonjour. I wonder if the netstream sorting out has fixed the backed exit problem as well?
[11:50:42] jya: it's very likely the conflict in name caused various issues.. you could never tell which constructor/destructor was going to be called
[11:52:30] jya: oh well, re-installing the freetype-devel package fixed my compilation issues
[11:53:32] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Remote host closed the connection)
[12:03:21] Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has quit (Quit: Wolfgang2)
[12:08:36] jya: stuarta: can you re-set a buildbot for the branch devel/resync-ffmpeg ?
[12:12:20] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[12:12:50] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Remote host closed the connection)
[12:25:38] stuartm: danielk222: 3733544b released rwlock before calling safe_read, but DVDRingBuffer::safe_read() and others weren't updated to reacquire any locks – is safe_read supposed to be free of rwlock usage?
[12:27:46] stuartm: maybe I should explain where I'm going with this – DVDRingBuffer::safe_read() returns -1 on error, this isn't handled in RingBuffer::run() so we just get stuck, it seems the correct mechanism is to increment numfailures on each failed read which would eventually exit gracefully but incrementing numfailures requires the rwlock
[12:29:50] stuartm: then again FileRingBuffer::safe_read() doesn't hold any locks when incrementing numfailures which conflicts with the documentation which states that rwlock must be held
[12:36:35] peper03: stuartm: At least for DVDRingBuffer, we don't use read-ahead, so DVDRingBuffer::safe_read() should not be called by RingBuffer::run(). There's even an error message if it detects that the read ahead thread is running.
[12:38:42] stuartm: peper03: heh, guess I took a wrong turn
[12:39:14] peper03: stuartm: Not difficult :)
[12:40:31] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[12:40:40] peper03: "You are in a twisty maze of passages, all alike". North. "You are in a twisty maze of passages, all alike". West. "You are in a twisty maze of passages, all alike"
[12:41:57] stuartm: I think I'll have to somehow induce this problem and grab a trace to figure out where we get stuck
[12:42:47] peper03: Something locking up?
[12:42:58] stuartm: still, either the documentation or the usage of numfailures is incorrect, at least in FileRingBuffer
[12:43:48] stuartm: peper03: we can get stuck in a 'Waiting 100ms for decoder to pause' loop if reads start failing
[12:45:42] peper03: Ah, that. Yes, I've seen that quite a few times. I think I can reproduce it quite well on one of my DVDs. Never got round to looking at it more closely.
[12:49:49] stuartm: as a type of issue it's not unique, all sorts of problems can occur if you encounter decoding/ringbuffer errors even with recordings/livetv, the error handling has rotted pretty badly over the years as the focus has always been on fixing the initial problem rather than making sure we fail (or retry) gracefully
[12:50:05] stuartm: it almost never gets tested for regressions
[12:52:23] peper03: On this DVD, all I have to do is skip forward over the initial studio ident. Playback stops at 24 of 24 seconds. If I then hit 'escape', I get the 'Waiting 100ms for decoder...' message.
[12:57:35] peper03: Interestingly, I only seem to get it on 0.26-fixes. I can't seem to reproduce it on master.
[13:04:28] peper03: stuartm: In case it helps, here's a backtrace from 0.26-fixes – http://pastebin.com/xy4NKyYj
[13:06:18] peper03: It's a bit hit-and-miss as it doesn't have all the symbols, but it appears that thread 33 is the culprit. AudioPlayer::AddAudioData calls AudioOutputBase::Drain(), which in turn is sitting in a loop called sleep() and obviously never stopping.
[13:08:44] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[13:09:52] peper03: With no 'abort' mechanism, it's going to be hard for MythPlayer::PauseDecoder to do anything other than wait. Or is there an abort mechanism?
[13:11:38] peper03: Hmm. 'sitting in a loop *calling* sleep()'.
[13:16:47] jya: I've pushed a new branch: devel/resync-ffmpeg… Feel free to test… Has a few issues on my mac with anything non-h264… i get Player(0): Video is 30 frames behind audio (too slow), dropping frame to catch up. and only see the first frame
[13:17:18] jya: that's a resync to ffmpeg release/1.1 branch
[13:18:28] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 245 seconds)
[13:20:03] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[13:20:03] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[13:20:03] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[13:22:27] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[13:22:51] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Ping timeout: 260 seconds)
[13:26:33] Sharky112065 is now known as Sharky-Sleep
[13:52:40] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[14:00:46] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has joined #mythtv
[14:08:14] SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!)
[14:08:56] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Read error: Operation timed out)
[14:45:37] Goga777 (Goga777!~Goga777@128-71-11-144.broadband.corbina.ru) has quit (Quit: Leaving)
[14:53:35] stichnot: stuartm: it looks like a05b4d48da71f1e65f01cde7693d539644635d5e causes video library rescan to fail to find any videos, thus wiping out the library :(
[14:53:59] stichnot: luckily this only happened on my dev system
[14:58:31] stuartm: wtf?
[15:01:01] stuartm: stichnot: reverting that commit fixes it?
[15:03:07] stichnot: it seems so, I'll try un-reverting it...
[15:04:36] stichnot: "The video scan found no files, have you configured a video storage group?"
[15:05:52] stichnot: but I also have some configuration error from when I copied the DB from the production system to the dev system, because after that popup (and whenever I previously did a rescan), I get a popup "Failed to Scan SG Video Host: stichnot-glaptop-orig"
[15:07:41] stichnot: If I "delete from storagegroup where hostname='stichnot-glaptop-orig'", will I mess everything up? I'm wary of the id column.
[15:09:47] stuartm: I don't know
[15:10:04] stichnot: oh well, might as well try...
[15:11:02] stuartm: stichnot: that error is only shown for offline slaves and it has nothing to do with whether files are or are not found
[15:12:18] stichnot: OK. I cleaned out all the non-local SGs (which shouldn't have been there in the first place), same failure to rescan. I'll try to narrow down which specific change in the commit seems to be responsible.
[15:12:43] stuartm: see RemoteGetActiveBackends() in remoteutil.cpp
[15:13:46] stuartm: videoscan.cpp ln 474 is where that error is produced and it's shown for all SG hosts which are not 'available' according to the backend
[15:14:30] stichnot: ok, I think that's just a red herring then.
[15:16:34] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Quit: leaving)
[15:22:24] danielk222: stuartm: safe_read should be free of rwlock twiddling, but the whole thing is under a rwlock.lockForRead(); so safe_read can read, but not update variables protected by rwlock.
[15:23:06] danielk222: rbwlock is released before safe_read, rbwlock != rwlock
[15:23:27] danielk222: those locks could probably be better named..
[15:24:38] stuartm: danielk222: so it is, I confused those too :)
[15:25:39] danielk222: stuartm: incrementing numfailures in safe_read is allowed per the documentation, see "note 1" in ringbuffer.h
[15:26:16] stuartm: danielk222: yeah just noted that, sorry for the noise
[15:26:33] stuartm: getting it all wrong today ;)
[15:27:31] stuartm: stichnot: I'm looking at the two (or three) places that that commit might have affected video scanning behaviour, so far I cannot see how it could possibly explain a complete failure to find any files :/
[15:28:46] stichnot: stuartm: I'm getting really strange results as I try to back out the changes one by one. could be a race condition, could be a misconfiguration of some sort on my end... I'll figure it out.
[15:29:16] 16WAAF6ED (16WAAF6ED!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[15:29:25] danielk222: I wish the ring buffers used a deque of buffers like the threaded file writer does, protecting the data is so much simpler that way then when two threads are using the same block of memory.
[15:30:09] stuartm: the changes in storagegroup.cpp and dirscan.cpp would be the most likely, they are the only ones that I can see that would be invoked for a video scan
[15:30:22] taylorr: stichnot: with latest master my dev system can not scan videos any more... and I even nuked the database and started from scratch
[15:30:58] stichnot: taylorr: try backing out a05b4d48da71f1e65f01cde7693d539644635d5e for now
[15:33:32] stuartm: hmm, I wonder if QDir sets default filters of QDir::AllEntries
[15:37:15] stuartm: stichnot: try this – http://pastebin.com/eKA1dWLy
[15:37:20] taylorr: yep that fixed it
[15:38:30] stuartm: taylorr: that was quick!
[15:38:39] stuartm: oh, reverting you mean?
[15:38:48] taylorr: yes, reverting worked :)
[15:40:08] stuartm: can you try the patch?
[15:44:51] stichnot: stuartm: I think there are some whitespace errors in the patch, apparently I'm too tired to work them out manually
[15:47:36] stichnot: stuartm: ok, that patch fixes it
[15:48:26] stichnot: ok back to the mythcommflag --rebuild issue :)
[15:50:19] stichnot: stuartm: thanks for finding it. also for finally getting me to clean up the SGs on my dev system :)
[15:52:10] taylorr: stuartm: your patch fixed the problem here
[15:56:45] stuartm: thanks guys, and sorry for the inconvience, wasn't exactly the behaviour I expected there from reading the documentation etc
[15:58:05] stichnot: btw, I noticed this log message when doing a video rescan: buildFileList directory = /share/Movies/dvd
[15:58:18] stichnot: followed by errors scanning that bogus directory
[15:58:39] stuartm: stichnot: local directory?
[15:58:52] stichnot: seems like for that one, it's failing to prepend the installation directory
[15:59:03] stichnot: I have never had a /share directory on any system
[15:59:27] stuartm: I'm planning on removing the local directory support, just as soon as I can figure out what might need to be done first, e.g. applying the remote DVD playback patch
[15:59:36] stichnot: libs/libmythmetadata/globals.cpp:const QString DEFAULT_VIDEOSTARTUP_DIR = "/share/Movies/dvd";
[16:03:38] stichnot: ah, so this is an artifact of local directory support on a non-Q_OS_MAC system?
[16:07:09] stuartm: yep
[16:08:46] wagnerrp: stuartm: don't spend too much time trying to fix the existing file scanner
[16:09:07] wagnerrp: i've got the replacement mostly written, just trying to figure out the best way to migrate content over to the new tables
[16:11:30] Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv
[16:16:17] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me)
[16:18:33] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv
[16:46:48] gigem: jya: No, the lirc problem I'm having is not related to Myth at all. I have a somewhat common MCE compatible remote and receiver. Even Jarod Wilson claimed to have the same remote/receiver at one time. Linux recognizes it and receives data from it just fine, but neither the kernel built-in rc6 decoder nor lirc can proprely decode the received data.
[16:56:26] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[17:16:01] stichnot: taylorr: fyi, jya's ffmpeg 1.1 branch doesn't change the mythcommflag --rebuild result on the hdpvr sample.
[17:16:54] danielk222: jya does the mythtv ffmpeg 1.1 branch revert to the ffmpeg mpegts, or is that a separate porting step?
[17:35:13] Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!)
[17:35:25] Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv
[17:41:24] taylorr: stichnot: probably in our code then which does the parsing and frame counting
[17:41:54] taylorr: stichnot: have you got debug output working yet for mythcommflag?
[17:45:02] gigem: danielk222: I'm looking at my timestamp discontinuity problem again. Do you remember what command you guys suggested to parse the mpeg-ts? I tried "dvbsnoop -s ts" on a recording I know had a discontinuity, but it didn't show anything. Were you able to get Michael Krufky's libdvbtee to compile. I tried yesterday, but it seemed to want a version of libdvbpsi that I couldn't find.
[17:46:50] taylorr: gigem: the latest ffmpeg has added a bunch of new features for ffprobe... what info are you trying to get from your video?
[17:50:50] gigem: taylorr: As I recall, there are two different types of discontinuities that can be flagged. I know of one dealing with the continuity counter, but can't find anything about the other one. The problem is I have some channels that semi-frequently have discontinuities in pts/dts. danielk222's recording quality checks treat these as gaps and mark the recordings as damaged. I'm trying to better handle
[17:50:51] gigem: "intended" discontinuities, so the recordings don't get marked as damaged.
[17:53:14] danielk222: gigem: Someone posted in here that your samples did have the pts/dts discontinuity flag set. I thought it was you, but I guess not :)
[17:53:21] taylorr: gigem: ah, do you know if ffmpeg exposes any of those fields in AVPacket or AVFrame? If so, ffprobe can probably display what you need
[17:55:13] gigem: danielk222: Yes, it was me, but I can't remember now how I determined it. taylorr: I've looked, but all I've found is how to determine continuity counter discontinuities, which I already know about.
[17:56:33] taylorr: gigem: wonder if it's something flagged in a PCR packet
[17:57:21] danielk222: It is part of the ADF
[17:58:26] danielk222: It is telling you there is either an expected cc discontinuity or PCR discontinuity.
[17:59:33] nephyrin (nephyrin!~neph@nat/mozilla/x-wycadlmgqajvtzcu) has quit (Ping timeout: 252 seconds)
[17:59:44] taylorr: danielk22: adaptation field?
[18:00:12] gigem: taylorr: I'm not familiar with that one, nor am I really all that familiar with any of them. Besided trying to fix the problem, this is also a learning exercise. danielk222: the current samples I have don't have any cc discontinuities detected and don't have any indicated in the adf.
[18:00:51] danielk222: libavformat/mpegts.c: is_discontinuity = has_adaptation
[18:01:27] wagnerrp: is a "+=" or "++" operation thread safe?
[18:01:36] gigem: danielk222: I've added a comparable check for that, but it's not triggering.
[18:02:12] gigem: I'm going for lunch now, but will check back later.
[18:02:12] danielk222: wagnerrp: iff the variable is under a lock is a QAtomicInt
[18:02:18] taylorr: gigem: take a look at http://en.wikipedia.org/wiki/MPEG_transport_stream &ndas h; looks like there is an "Adaptation field exist" field in the header and it also has the adaptation field definition which includes "Discontinuity indicator"
[18:02:57] danielk222: gigem: You will need to modify mpegts-mythtv.c we don't use the ffmpeg one currently.
[18:11:28] dekarl (dekarl!~dekarl@p4FCEF8F0.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[18:12:50] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[18:16:21] dekarl (dekarl!~dekarl@p4FE84D95.dip.t-dialin.net) has joined #mythtv
[18:19:45] stichnot: taylorr: I have to run off for now. I haven't yet looked at the mythcommflag logging nonsense.
[18:20:11] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[18:21:41] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[18:29:11] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me)
[18:32:35] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[18:35:11] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[19:25:24] Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Ping timeout: 248 seconds)
[19:34:14] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[19:35:43] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv
[19:38:37] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 246 seconds)
[19:39:02] kth1 (kth1!~kth@178.142.92.0) has joined #mythtv
[19:40:39] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[19:41:30] kth (kth!~kth@unaffiliated/kth) has quit (Ping timeout: 256 seconds)
[19:42:24] gigem: taylorr, danielk222: I looked at that page a lot yesterday. I know we use our own mpegts-mythtv.c, but havne't need to change it yet. What I tried so far is to add a TSPacket::IsDiscontinuity() method and have DTVRecorder call it and log any discontinuities it sees. It hasn't triggered on any of my recent tests even though every recording I try on TNT (and most other TW channels) have 2, 3 or more pts/dts
[19:42:27] gigem: discontinuties per hour. I re-ran dvbsnoop on an old bad-timing.mpg sample I saved from September and it had a couple of cases where the discontinuity indicator was set. I think that's the case that made me earlier declare the discontinuities were marked. I'm running dvbsnoop on my latest TNT sample which has pts/dts discontinuities, but so far, there are no cases where the discontinuity indicator is set.
[19:46:22] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[19:50:42] kc (kc!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has joined #mythtv
[19:50:42] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[19:50:42] kc (kc!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has quit (Changing host)
[19:58:11] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[20:03:04] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:16:29] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Remote host closed the connection)
[20:32:16] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me)
[20:33:25] kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv
[20:34:27] neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
[20:49:07] neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[21:00:45] rsiebert (rsiebert!~quassel@g226063073.adsl.alicedsl.de) has joined #mythtv
[21:03:29] rsiebert_ (rsiebert_!~quassel@g225061005.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[21:04:59] jya: danielk222: the ffmpeg resync branch has only touch ffmpeg itself. nothing has been changed and it is still using our own mpegts code… Not sure how we could go back to the ffmpeg one, it seems to miss most of our subtitle handling
[21:23:19] kth1 (kth1!~kth@178.142.92.0) has quit (Read error: Connection reset by peer)
[21:30:17] danielk222: jya: Yeah, it misses that.. but that is actually easily added back. It is the handling of stream changes that the ffmpeg mpegts had difficulty with. From what you've been mentioning in IRC it sounds like that has potentially been addressed in 1.1
[21:31:21] jya: i guess it may be easier to port our changes to the new mpegts code and get them to incorporate them so we don't have a need to patch stuff like we do
[21:31:36] jya: in the mean time, lots of videos don't play anymore… only see the first frame.
[21:31:54] jya: need to investigate… but it's a beautiful day today and my kids want to go to the beach
[21:33:59] danielk222: jya: I tried to get the caption stuff in ffmpeg a while back but the objection was that we set aside a few KB for captions. I couldn't get dynamically allocated stuff to work because of the complex dynamics of private and public avframes.
[21:34:36] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[21:38:03] jya: here is the list of all the warning i get when compiling with latest clang
[21:38:05] jya: http://pastebin.com/DELhz2Q1
[21:40:14] Peps (Peps!~MiNT@li186-230.members.linode.com) has quit (Ping timeout: 252 seconds)
[21:40:17] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[21:40:36] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[21:40:36] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[21:40:36] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[21:43:35] Peps (Peps!~MiNT@li186-230.members.linode.com) has joined #mythtv
[21:45:18] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[21:47:43] gigem: danielk222: dvbsnoop finished on my recent sample and none of the packets had the discontinuity indicator set. Although, there is apparently one missed packet where the cc jumped from 12 to 14 at about the 50-minute mark. I played the entire 1-hour program with mplayer and it didn't report anything suspecious except for the same cc jump. In addition, the difference between the first and last timestamps
[21:47:44] gigem: reported by mplayer was exactly what it should be — 3615 seconds. I think the recent rash of damaged recordings I have are due to something different, possibly a subtle decode or logic error on our part. http://pastebin.com/5XG3MNnG contains the relevant backend log from my most recent sample. I added the '###' parts to make the relevant entries easier to find. It's strange that 5 gaps are logged by the
[21:47:47] gigem: recorder, but only 3 are reported at the end. I guess you merge some together, but I haven't looked at that logic yet. Anyway, does that log give you any ideas.
[21:47:57] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:59:46] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[22:00:35] danielk222: gigem: The three at the end are not surprising, it has combined two contiguous gaps.
[22:11:15] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Leaving)
[22:12:51] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[22:13:54] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has joined #mythtv
[22:14:56] peper03: Comments on an initial attempt to add support for 'private stream 2' (DVDNAV) packets to FFMPEG? http://pastebin.com/NJdThMPr
[22:15:32] peper03: The diff looks like it changes more than it does. Most of it is just indenting a block of code.
[22:17:34] peper03: It appears that 'sofdec' files contain the same packets, though almost certainly with different contents. Part of the code I removed looks for the string 'Sofdec' in the packet to help determine the format. I'll have to see if I can add that check back in somehow and still return the data to the user.
[22:20:06] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[22:24:43] gigem: danielk222: Upon further review, it looks to be a Verizon problem and not ours. I actually watched the relevant parts of the recording and the gaps corresponded exactly to local commercial inserted by Verizon. I dobut there's anything we can do about that. Strangely, while mplayer reported aspect ratio changes at the beginning and end of the breaks, it's timestamps remains consistent.
[22:34:48] jpabq: Does valgrind understand "delete this;" ? I am looking at #11352 , and not seeing the problem. I believe that valgrind is complaining about an object that deletes itself.
[22:34:48] ** MythLogBot http://code.mythtv.org/trac/ticket/11352 **
[22:37:01] clever: jpabq: is it a QObject?
[22:40:06] jpabq: clever: It is based off of "class MBASE_PUBLIC ReferenceCounter". It is a reference counting object, that deletes itself when the count falls to zero
[22:40:29] clever: ah, dont know then
[22:41:10] jpabq: does valgrind have problems with QObject?
[22:41:25] clever: not that i know of, but QObject has a deleteLater() function
[22:41:38] clever: which will schedule it to be deleted when you get back to the qt event loop
[22:43:36] jpabq: I could see how valgrind would get confused by that, as well.
[22:44:50] clever: in that case, it wouldnt be deleting itself, just putting it into an array and deleting it at a later time
[22:49:24] jpabq: I am not sure I see the point of deleteLater. Is it a performance thing? The app would have no control of when it was actually deleted, right?
[23:05:33] clever: its because you may still have references to the object in your function
[23:05:52] clever: and it cant be certain youve stopped referencing it, until you return all the way back to the event loop
[23:07:04] entropy_number_9 (entropy_number_9!~entropy@c-71-236-27-72.hsd1.ga.comcast.net) has joined #mythtv
[23:09:48] stoffel (stoffel!~quassel@pD9E42BBB.dip.t-dialin.net) has quit (Remote host closed the connection)
[23:10:04] entropy_number_9 (entropy_number_9!~entropy@c-71-236-27-72.hsd1.ga.comcast.net) has quit (Quit: entropy_number_9)
[23:16:57] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[23:21:48] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:30:01] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[23:42:59] jpabq: I think i have found an extra "im->IncrRef();" in mythpainter.
[23:44:08] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:44:11] wagnerrp: that's very likely
[23:44:43] wagnerrp: i noticed something was calling increasingly higher reference counts a week or so ago when i was running something verbose
[23:52:34] Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[23:55:04] jpabq: Guess not, I just didn't follow it through far enough.

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