:: #mythtv

Daily chat history

Current users (87):

abqjp, aloril, andreax, Anduin, Andy50, Anssi, anykey_, beata, brfransen, Captain_Murdoch, Chutt, clever, coling, Computer_Czar, Cougar, dagar, danielk22, Dave123, Dave123-road, dlblog, eharris, Elv13, f33dMB, FinnTux, foxbuntu, frankster, ghoti, Gibby, gigem, gregL, GreyFoxx, highzeth, hobiga, iamlindoro, ikonia, j-rod|afk, jams, jannau, jarle, jcarlos, JEDIDIAH__, joe_, jpabq, jpabq-, jstenback, justinh, jwhite, kc, knightr, kormoc, kurre, kwmonroe, laga, len, mag0o, markk, MavT, mike|2, morgan, mrand, MythBuild, MythLogBot, M|ckael_, okolsi, PointyPumper, poptix, purserj, reynaldo, sailerboy, Seeker`, simonckenyon, skd5aner, Snow-Man, sphery, sunkan, sutula, taylorr, tgm4883, tomimo, tris, Unhelpful, wahrhaft, weta, xris, xxtjaxx, ybot, _charly_
Saturday, May 7th, 2011, 00:04 UTC
[00:04:31] jya: damn ; I git checkout fixes/0.24 ; now I can go back to master ;keeps telling me that there are untracked working tree file that would be overwritten
[00:06:03] wagnerrp: try 'git status'
[00:48:44] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:49:10] davide_ (davide_! has joined #mythtv
[00:49:11] davide_ (davide_! has quit (Changing host)
[00:49:11] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[01:34:09] sphery: danielk22: I put on my system, today (basically the same as the one on the -users list), and it does seem to prevent the at-the-recording-change playback pauses
[01:34:48] sphery: it may be that CalcReadAheadThresh() just needs some modifications
[01:47:48] markk (markk! has quit (Ping timeout: 252 seconds)
[01:52:21] brfransen (brfransen!~brfransen@ has joined #mythtv
[02:00:18] markk (markk! has joined #mythtv
[02:17:26] taylorr: jpabq: did you try the ringbuffer.cpp patch mentioned on the -users that forces the readblocksize to 512KB?
[02:18:06] sphery: taylorr: that's the one I was mentioned above...
[02:18:12] taylorr: it seems to eliminate the pauses for the user and sphery
[02:18:29] danielk22: sphery: ok, I have an idea for the fix for that would fix the NFS over tcp problem as well, but I may need to subject you to a patch that prints out a bunch of statistics first...
[02:18:54] sphery: oh, I see you noticed :)  — jpabq- test patch is available at
[02:18:58] taylorr: sphery: it still doesn't make sense to me – seems the larger size the readblocksize becomes the severity of the pause problem increases
[02:18:59] ThisNewGuy (ThisNewGuy! has left #mythtv ()
[02:19:18] taylorr: wonder if there is a locking issue going on
[02:19:20] sphery: danielk22: no problem, happy to test
[02:19:58] wylie (wylie! has quit (Quit: wylie)
[02:20:17] taylorr: danielk22: do you have any ideas why a higher readblocksize in ringbuffer.cpp would make the pause problem worse?
[02:21:45] danielk22: taylorr: I think the patch actually forces a higher readblocksize, not a lower one. This will make seeks slower, but it should increase throughput.
[02:21:46] taylorr: basically the libav libraries are reading the data from the ringbuffer – I assume it's in a separate thread and not in the UI thread
[02:22:22] taylorr: danielk22: actually using the code without the patch you'll see readblocksizes go well beyond 512KB
[02:23:12] danielk22: taylorr: yes, but my assumption is they are shrinking quickly when this happens..
[02:23:43] taylorr: yes not sure it a higher readblocksize correlates to the pauses or not
[02:24:52] taylorr: but in light of the fact that we have plenty of decoded frames available for video output why would the ringbuffer process cause any issues with playback
[02:24:54] danielk22: taylorr: both too high and too low a readblocksize can cause pauses, the first because the buffer empties while we're reading and the second because throughput is just too low..
[02:25:18] taylorr: but I'm not seeing that happening
[02:25:26] danielk22: taylorr: that doesn't really make sense to me, are we sure there are plenty of decoded frames?
[02:26:36] taylorr: yes, when a pause happens it will usually start dropping multiple frames with in a few milliseconds
[02:26:56] danielk22: taylorr: have you tried the patch? It's possible you are experiencing something different..
[02:27:12] taylorr: basically we hang in videooutput::Show
[02:28:11] taylorr: danielk22: I'm the one who created the original patch and the new one just forces to 512KB – my original patch helped myself and jpabq a lot but not total elimination – sounds like the fixes 512KB works even better
[02:29:16] danielk22: taylorr: what's your video output method?
[02:29:22] taylorr: VDPAU
[02:29:39] taylorr: sphery: are you using VDPAU?
[02:31:30] sphery: taylorr: I have been flipping around tonight, but was using ffmpeg/opengl for most of the testing tonight (and was using Xv before tonight--I just installed the GT220. If you think it could make a difference, I can try Xv, again.)
[02:32:10] taylorr: just curious if you saw the pauses with non-vdpau output methods
[02:32:32] sphery: yeah, all my experience with them was on ffmpeg/Xv (since that's all my 7200 could handle)
[02:33:11] sphery: (well, it handled OpenGL at 1x, but couldn't do >= 1.25x, and I typically use 1.5x or 1.75x timestretch)
[02:33:19] sailerboy (sailerboy! has quit (Read error: Operation timed out)
[02:34:18] taylorr: danielk22: I'm not sure if the stall happens in Show – I've seen the playback stall for upto 300ms between displaying frames
[02:34:32] danielk22: taylorr: the only thing that I can see causing a pause in the vdpau Show() is the grabbing of m_lock. If you can add some VERBOSE's and track down the line where it is pausing in Show() that would confirm/deny.
[02:35:20] taylorr: will do
[02:36:08] danielk22: taylorr: Then it could be Show() just isn't called for a while, there could be multiple causes for that. But if it is stalling in Show() and we can isolate it that would be great.
[02:36:49] taylorr: ok, I'll see if it correlates and let you know
[02:37:55] danielk22: videooutbase.cpp documents a simplified video loop following the text "In the displaying thread" it can be helpful in understanding what each method in videoout does..
[02:39:55] danielk22: taylorr: I assume you are not seeing "Waited XXXms for video buffers ..." messages, correct?
[02:45:53] taylorr: danielk22: only after the pause occurs and we drop every frames try to get the video back in sync with the audio :)
[02:51:06] danielk22: taylorr: k, we really need to track down where the pause starts.. from your description it sounds like we're really dealing with some kind of lock contention. the ringbuffer stuff may just be a red herring (changes timing slightly, making the problem go away from some and re-appear for others).
[02:51:50] danielk22: or it may be where the lock contention is centered, we don't have enough data yet.
[02:57:59] taylorr: danielk22: it's not the m_lock
[03:01:12] danielk22: taylorr: is the pause withing the Show() ?
[03:03:57] sphery: danielk22: Speaking of that message (or the "Waited 100ms for video frames from decoder" one), did you see  ? I'm not sure if he found something or if he's just misunderstanding the point of the code. (Granted, this is the guy who, when Beirdo asked him to submit tickets for all the "bugs" he keeps saying he's fixed in his own build, said he can't be bothered to take the time to ...
[03:04:03] sphery: ... help anyone else-- --but if it's not working how it's supposed to, I figured it's probably worth looking into.)
[03:10:55] danielk22: sphery: Heh. He was right, but I fixed that in trunk when I was looking into my pausing issue earlier this week..
[03:12:45] danielk22: But it's just the debugging, it doesn't have anything to do with the problem.
[03:17:34] danielk22: sphery: I may have a new lead on #9704.. I ran master instead of mythtv-rec2 in the last 24 hours and I started seeing dozens of mythcommflag processes running simultaneously on the same recording.. that plus the "INSERT INTO recordedmarkup " error message on the ticket makes me think that perhaps the jobqueue/commflag code in master is broken somehow.
[03:19:18] danielk22: sphery: heh, don't know why I addressed that to you :)
[03:30:18] xris (xris!~xris@mythtv/developer/xris) has left #mythtv ()
[03:30:31] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[03:31:44] sphery: heh, well, I'm still interested in hearing about progress.  :)
[03:32:15] sphery: and thanks for looking at (and for already having fixed) the logging thing
[03:41:25] Computer_Czar (Computer_Czar!~Unknown@ has quit (Ping timeout: 240 seconds)
[03:59:13] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[04:01:10] sphery: danielk22: OK, now I'm thinking your timing theory may be a good one--I just got a tiny pause (even with the patch) when a new recordings started. (This time I'm using VDPAU, though.)
[04:15:36] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[04:45:47] Computer_Czar (Computer_Czar!~Unknown@ has joined #mythtv
[04:48:58] wagnerrp: question about the backend setup
[04:49:08] wagnerrp: is that intended to be available from all backends? or just the master?
[05:49:11] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[06:06:43] j-rod|afk is now known as j-rod
[06:07:45] j-rod is now known as j-rod|afk
[07:01:52] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[07:02:13] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has quit (Read error: Operation timed out)
[07:05:40] GreyFoxx (GreyFoxx! has joined #mythtv
[07:15:15] GreyFoxx (GreyFoxx! has quit (Ping timeout: 264 seconds)
[07:15:53] GreyFoxx (GreyFoxx! has joined #mythtv
[07:16:22] stoffel (stoffel! has joined #mythtv
[07:25:21] natanojl (natanojl! has joined #mythtv
[07:44:38] len (len! has quit (Remote host closed the connection)
[08:20:30] morgan (morgan! has joined #mythtv
[08:20:59] morgan: got mythtv installed and configured, but when I "watch tv" it crashes out of X. Is this a common prob with a solution?
[08:35:39] eharris (eharris! has quit (Ping timeout: 240 seconds)
[08:37:34] eharris (eharris! has joined #mythtv
[08:42:20] stoffel (stoffel! has quit (Ping timeout: 276 seconds)
[09:02:31] morgan (morgan! has quit (Read error: Connection timed out)
[09:03:26] morgan (morgan! has joined #mythtv
[09:34:35] stuartm_: sounds like a video driver or X bug, but you should ask for help over in #mythtv-users
[09:34:57] stuartm_: morgan: or if using ubuntu – #mythtv-ubuntu
[09:36:19] stuartm_: err, #ubuntu-mythtv
[09:48:11] markk (markk! has quit (Ping timeout: 276 seconds)
[10:04:18] markk (markk! has joined #mythtv
[10:05:03] mike|2 (mike|2! has quit (Remote host closed the connection)
[10:05:50] mike|2 (mike|2! has joined #mythtv
[10:08:24] morgan (morgan! has quit (Read error: Connection timed out)
[10:08:59] morgan (morgan! has joined #mythtv
[10:36:19] eharris (eharris! has quit (Read error: Operation timed out)
[10:38:34] eharris (eharris! has joined #mythtv
[10:48:39] SteveGoodey (SteveGoodey! has joined #mythtv
[10:51:37] stoffel (stoffel! has joined #mythtv
[10:58:38] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[11:20:57] Captain_Murdoch: wagnerrp, right now it's available everywhere. the intended goal is something along the lines of this: all setup is done via master server. if you want to setup a slave, you start it up, hit it with a web browser, tell it which master to use (from a dropdown list or manually), and then configure everything else from the master web setup. since we have to support remote control of the things like the channel scanner, tuner dis
[11:20:58] Captain_Murdoch: covery, etc. there's not much reason to require going to each backend to do that configuring, you should be able to configure all backends from one interface. so, once a slave is setup, the only setup ability you should have on that slave is to change the master that it talks to or to make it the/a master.
[11:28:15] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 252 seconds)
[11:57:10] stuartm_: redirection from the slave ip to the master could be done automatically once the master address has been configured, so it would be seamless for the user
[11:57:14] stuartm_ is now known as stuartm
[13:05:18] sailerboy (sailerboy! has joined #mythtv
[13:06:59] frankster (frankster!574b8dc4@gateway/web/freenode/ip. has joined #mythtv
[13:25:12] stoffel (stoffel! has quit (Remote host closed the connection)
[14:10:27] andreax (andreax! has quit (Ping timeout: 240 seconds)
[14:11:15] andreax (andreax! has joined #mythtv
[15:01:08] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[15:05:06] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[15:05:48] frankster: Im thinking i might try and add a site to mythnetvision. any tips / advice / suggestions where to start?
[15:14:51] SteveGoodey (SteveGoodey! has joined #mythtv
[15:16:10] jpabq: taylorr, sphery, I tried that "kb512" patch and it did not help — may have even been worse.
[15:26:38] sphery: jpabq: yeah, I noticed issues, later in the evening when I had switched to vdpau. Don't know if the switch was relevant or if it was just a timing difference or what.
[15:36:38] wagnerrp: Captain_Murdoch: what about something like the jobqueue, where all configuration will now be done by the scheduler on the master backend?
[15:40:24] wagnerrp: frankster: i would check to see if they have an rss feed you can plug directly into mnv
[15:42:27] sphery: frankster: and +
[15:55:11] jarle (jarle! has quit (Ping timeout: 248 seconds)
[16:07:25] jarle (jarle! has joined #mythtv
[16:24:48] frankster: thanks for the links
[16:32:19] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[16:50:18] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[16:50:44] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[18:52:33] SteveGoodey (SteveGoodey! has joined #mythtv
[19:05:53] eharris (eharris! has quit (Ping timeout: 276 seconds)
[19:06:55] eharris (eharris! has joined #mythtv
[19:35:39] shihan (shihan! has joined #mythtv
[19:35:51] shihan (shihan! has left #mythtv ()
[19:41:48] hobiga (hobiga!~hobiga@ has joined #mythtv
[19:47:31] len (len! has joined #mythtv
[19:48:00] Beirdo: jya: I'm gonna chase that PPC compile issue, see if I can't get a patch that would help
[19:48:13] Beirdo: since I have the platform available
[20:56:13] Elv13 (Elv13!~lepagee@ has joined #mythtv
[21:06:27] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[21:21:18] jya: Beirdo: that would be nice thanks... If I remember correctly someone made a change to aoutil and removed (or added) the call to bswap.. My memory is fuzzy now
[21:22:20] Beirdo: it seems to be something missing in configure
[21:22:43] Beirdo: HAVE_BYTESWAP_H wasn't being set
[21:22:55] Beirdo: working through other related issues
[21:23:02] jya: . . . tpututil.cpp
[21:23:39] jya: . . . tpututil.cpp
[21:23:55] jya: everyone seemed to have a go at this :)
[21:25:31] Beirdo: compiling on this box is SOOO slow compared to the i7 :)
[21:26:50] jya: I can imagine... especially the first compile..
[21:27:11] jya: first compile feel slow everywhere even... good 30 minutes in my VMWare
[21:27:48] Beirdo: yeah, thank goodness for ccache
[21:29:12] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[21:50:17] jya: Beirdo: talking about ccache ; I've noticed something very weird... In libmythfreesurround/freesurround.h there is a constant defined for the buffer size.
[21:51:05] jya: If I change it from 8192 to 16384; recompile: I can see that all the files depending on that constant are recompiled (in particular freesurround.cpp and audiooutputbase.cpp)
[21:51:19] jya: running the resulting code works fine.
[21:51:27] jya: now I do make clean ; make
[21:51:54] jya: run the code: the audio gets interrupted with silence every few .5s (or about)
[21:52:06] jya: not sure what's going on
[21:52:51] Beirdo: dunno. Sometimes a make distclean can help. I think qmake may be failing us at times in regenerating dependencies or something
[21:53:51] Beirdo: I've noticed occasional oddities, but haven't bothered tracing down what the true issues are
[22:01:19] jya: tad annoying when you can't guarantee the result of a compile...
[22:01:54] Beirdo: well, if it's a totally clean compile, you can
[22:02:07] Beirdo: it's the non-clean ones that are the issue
[22:02:22] Beirdo: at least in my experience
[23:19:46] pheld (pheld! has quit (Quit: Leaving.)
[23:34:08] natanojl (natanojl! has quit (Ping timeout: 276 seconds)

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