| Thursday, May 19th, 2011, 00:01 UTC | ||
| [00:01:02] | wagnerrp: | if theres not an existing method, im sure i can find a way around it |
| [00:01:13] | markk: | to be honest, just go for it:) If there are performance issues, we can work out a way to optimise it – but it does sound like it could be cached for short periods at least? |
| [00:01:59] | wagnerrp: | the only problem i have with caching it locally is how do i destroy it when im done |
| [00:02:10] | wagnerrp: | of course i could just date it and not worry about it |
| [00:02:20] | wagnerrp: | if its older than X seconds, flush it and rebuild |
| [00:08:19] | markk: | wagnerrp: depending on how large it is, it's probably easiest to just leave as is. otherwise it's simple enough to add a basic 'housekeeping' method that gets called every so often during playback, or just use a qtimer to expire it. |
| [00:13:20] | markk: | danielk22, Captain_Murdoch: re dvd playback. Something I should have mentioned – most of my discs are stored as iso's. Hence as far as myth is concerned, there is only one file that is ever opened and given its size, it always uses a full ringbuffer with a read ahead thread. the dvd lib then handles all of the lower level stuff. |
| [00:14:45] | markk: | Is there a way to toggle the read ahead thread? i.e. don't use it on startup and when in menus but enable it for normal video. |
| [00:16:51] | Captain_Murdoch: | so is the readahead causing issues because the file is opened multiple times or because it's reading things it doesn't need to read? sorry if that was mentioned in scrollback, I had a machine reboot today and lost the scrollback. |
| [00:18:05] | wagnerrp: | http://irc.mythtv.org/ircLog/channel/4 |
| [00:21:27] | Captain_Murdoch: | markk, I think you could disable readahead on the FE by changing the 'true' on line 194 of mythiowrapper.cpp to 'false'. if that speeds things up, we could disable that if we're reading a remote .iso file. |
| [00:22:25] | markk: | Captain_Murdoch: I don't really know why it's causing the issue – but I'm assuming that it doesn't play well with the multiple random accesses the lib is making when in menus/still frames etc |
| [00:23:40] | markk: | Captain_Murdoch: that's what I tested with yesterday – and it has a huge impact on startup/menu navigation times but a negative impact on normal video playback (when moving across chapter/cell boundaries in a dvd) |
| [00:23:41] | Captain_Murdoch: | yeah, we could be delayed reading things we don't need when we seek around often. |
| [00:24:15] | Captain_Murdoch: | yeah, that'd make sense during normal playback. :| |
| [00:24:56] | Captain_Murdoch: | perhaps we put in a very very small delay before the readahead starts reading ahead. |
| [00:25:10] | Captain_Murdoch: | hackish though. don't like it.. :) |
| [00:25:11] | Captain_Murdoch: | :( |
| [00:25:40] | Captain_Murdoch: | but it's the same principle we use on the watch recordings screen to delay loading fanart if you're rapidly scrolling through recordings. |
| [00:28:23] | markk: | Captain_Murdoch: I also noticed that I get the same performance changes if I forced the use of a RemoteFile in mythiowrapper (i.e. faster startup, video issues) even though it was still using a read ahead thread. |
| [00:28:54] | Captain_Murdoch: | I think your issue is probably the FE readahead, not the BE readahead. if you use RemoteFile, you don't have a FE readahead. |
| [00:30:00] | Captain_Murdoch: | could be both, but if you use RB in mythiowrapper, you have 2 readaheads, but one is local to the BE. the FE readahead going over mythproto is probably limiting since we could be waiting on data to return from the BE when a request comes in from the FE to seek to another location and read there. |
| [00:30:18] | Captain_Murdoch: | it's just ms we're talking about, but with hundreds of seeks occurring, they add up. |
| [00:31:23] | markk: | is there no way to pause readahead and switch to direct reads? |
| [00:32:04] | Captain_Murdoch: | not sure, I'm looking at the code now. if so, I'm not sure how we'd hook into that without modifying libdvdnav as well. |
| [00:32:31] | Captain_Murdoch: | the readahead code got changed a bit a while back I thought, so I'm trying to refresh memory. |
| [00:34:26] | markk: | I think I can handle the switching it on/off by extending the file open callback in mythiowrapper – so that the player is aware of the ringbuffer being uses by the lib. |
| [00:34:50] | markk: | I wonder if it's just a case of maybe increasing the buffer size somewhere for the non-readahead case... |
| [00:35:17] | Captain_Murdoch: | hmm, could be we're limiting it in RingBuffer::CalcReadAheadThreshold(). we have a var in there called 'secs_min' which is set to 0.25 and the comment says to disallow reads until we have that much data read ahead. |
| [00:35:58] | Captain_Murdoch: | so after a seek we need to read what it thinks is 0.25 seconds worth of data before the read can suceed. |
| [00:37:03] | Captain_Murdoch: | perhaps try tweaking that to see if it affects your situation. if so, it gives us something to go on. turn on VB_FILE debugging to see the numbers that method comes up with. if we're having to read a few hundred KB every time we seek to read in a few bytes, it could slow things down quite a bit. |
| [00:37:08] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [00:38:00] | Captain_Murdoch: | shouldn't be that large on the BE, but depending on how that interacts with our block size, it could be multiple request/replies over mythproto. |
| [00:39:12] | markk: | Captain_Murdoch: thanks – and presumably we could dynamically adjust that 0.25 if in a menu etc (i.e. lower it) ? (yeah – I see it gets changed when changing speed) |
| [00:47:22] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [00:47:49] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:25:27] | taylorr: | markk: maybe going out on a limb but is there any possibility of a relation between the ringbuffer performance issues you see with dvd/bluray and the playback pauses people are experiencing |
| [01:31:05] | markk: | taylorr: it's a possibility but maybe not the most likely candidate. for dvd/bluray the issue is around the menus/interactive stuff which probably aren't best suited to a readahead thread. for normal video/recording playback, the readahead thread and associated buffering should be hiding any intermittent network issues. though I think there was some discussion a week or so ago whether the guestimates of certain parameters were accurate for al |
| [01:31:05] | markk: | l situations. |
| [01:34:14] | taylorr: | markk: I might look at it some more tonight – it's hard to nail down where it's stalling |
| [02:13:34] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [02:33:09] | taylorr: | markk: the playback pauses caused by backend activity (starting recording, etc) is in qapp->ProcessEvents in tv_play.ccp::PlaybackLoop |
| [02:34:37] | taylorr: | anyone, where is code for qapp->processEvents()? |
| [02:41:44] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [02:44:46] | clever: | taylorr: thats part of the qt core |
| [02:47:25] | taylorr: | right, trying to figure out how to debug why a processEvents is taking so long |
| [02:50:34] | clever: | taylorr: is it being given an argument? |
| [02:51:06] | clever: | if i remember correctly, ProcessEvents will check the event queue and run any handlers it needs to |
| [02:51:56] | taylorr: | no args |
| [02:52:50] | clever: | taylorr: it should check for (and handle all events) and then return |
| [02:53:05] | clever: | stack tracing may show what else it calls |
| [02:59:24] | Captain_Murdoch: | taylorr, yeah, you may need to setup a timer and assert to trigger a fault so you can get a backtrace of what's going on when that call takes too long to execute. |
| [03:00:03] | Captain_Murdoch: | it's probably in one of our ::customEvent() methods somewhere. |
| [03:00:26] | Captain_Murdoch: | but if it's caused by backend activity, can you see that with "-v network,extra" to see what is being sent to the FE? |
| [03:00:43] | Captain_Murdoch: | or have you been there, done that. :| |
| [03:01:34] | clever: | gdb might also be able to break the next time it leaves qt and re-enters myth |
| [03:01:41] | markk: | taylorr: qapp->processEvents will iterate through any queued events and try to get them processed. during playback, events will either be filtered in the TV object or MythMainWindow (just like that event logging stuff we had a few days back) |
| [03:02:28] | taylorr: | markk: I'm not seeing any events from your debug code you sent me |
| [03:03:19] | clever: | taylorr: ive also got a patch to log every signal/slot fired in the entire app |
| [03:03:41] | taylorr: | Captain_Murdoch: it is caused by backend activity – I'll run with those verbose flags and see if I can see what's happening |
| [03:04:10] | clever: | taylorr: if you print a flag before and after calling ProcessEvents, you can then grep for that in the logs |
| [03:04:15] | clever: | and see what happens in the middle |
| [03:05:09] | Beirdo: | clever: that would likely slow things down even more |
| [03:05:11] | taylorr: | clever: yes, I've already placed prints around all the processEvents |
| [03:05:45] | clever: | Beirdo: i dont notice the drop in performance here |
| [03:05:56] | clever: | though with proper integration, it would only run with -v signals |
| [03:06:13] | clever: | my current patch cant check that, so it always sets the hook and tries to VERBOSE it out |
| [03:11:18] | taylorr: | clever: can you post the patch? |
| [03:11:49] | clever: | let me find it real quick |
| [03:15:05] | clever: | taylorr: http://ext.earthtools.ca/download/signalspy.patch |
| [03:15:17] | clever: | uncomment the call to init_spy() and ah yeah, might need a patch to verbose also |
| [03:15:30] | clever: | VERBOSE(VB_TRACE isnt official |
| [03:16:37] | clever: | patch file updated |
| [03:18:53] | taylorr: | clever: thanks, I'll have a look probably tomorrow |
| [03:19:25] | clever: | its a fairly old patch, but i dont see any reason for it to need updating, it doesnt call very much in myth |
| [03:19:35] | taylorr: | Captain_Murdoch: any chance you could help with a timer with assert to get a stack trace |
| [03:19:51] | taylorr: | I think this is getting impossible to debug with just verbose statements |
| [03:22:02] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:27:15] | Captain_Murdoch: | taylorr, yeah, give me a few minutes to work up a sample patch. |
| [03:29:37] | taylorr: | Captain_Murdoch: the qapp->processEvents that gets called during playback is in TV::PlaybackLoop in tv_play.cpp |
| [03:31:04] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:43:03] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:53:33] | Captain_Murdoch: | taylorr, I was trying a patch, but when it didn't work, it got me thinking... if the main thread is hung, I don't think the timer will get a chance to fire so we can't assert to get the backtrace. |
| [03:56:05] | taylorr: | Captain_Murdoch: it's stalling in the UI thread – not sure if that's what you consider the main thread or not |
| [03:57:15] | Captain_Murdoch: | yeah, should have said UI. I think the timer would be firing in the UI thread, so it wouldn't get a chance to fire if the UI thead is hung processing an event somewhere. did the -v network,extra give any clue? |
| [03:58:28] | taylorr: | Captain_Murdoch: it's a long stall (ie. 100ms) not a permanent hang |
| [03:58:51] | taylorr: | I haven't ran with -v network,extra (I had some other ideas already queue:) |
| [03:59:23] | Captain_Murdoch: | right, but the timer wouldn't be able to fire in the UI thread until after the current code was done executing (ie, after processevents was done). |
| [03:59:42] | Captain_Murdoch: | the timer doesn't preempt TTBOMK. |
| [04:00:15] | clever: | you would have to try a non-qt timer, one that fires SIGALRM |
| [04:00:48] | Captain_Murdoch: | if it's a command coming in from the BE or a reply from a command to the BE, then -v network,extra will show you exactly what it was. |
| [04:01:04] | echosyp (echosyp!~jeff@75.111.181.197) has joined #mythtv | |
| [04:01:16] | echosyp is now known as spinull | |
| [04:01:49] | spinull: | im trying to decide if i should buy a few hdpvr's |
| [04:04:07] | taylorr: | Captain_Murdoch: I'll try with -v network,extra now |
| [04:08:46] | taylorr: | Captain_Murdoch: I got it captured |
| [04:08:53] | spinull (spinull!~jeff@75.111.181.197) has left #mythtv () | |
| [04:08:53] | taylorr: | let me pastebin it |
| [04:09:52] | taylorr: | http://www.pastebin.ca/2064018 |
| [04:10:18] | taylorr: | so processEvents is processing MythSocket calls which is very bad |
| [04:10:52] | taylorr: | markk: ^^^ |
| [04:12:58] | taylorr: | that qapp->processEvents took 106 msec to complete |
| [04:15:26] | Captain_Murdoch: | are either of those the checks for the file you were playing? |
| [04:24:20] | Captain_Murdoch: | taylorr, how are you starting playback? just scrolling down to a recording and hitting SELECT or are you going through a menu or ?? |
| [04:26:13] | clever: | that reminds me of a strange problem i have, starting playback thru lirc causes the primary thread to deadlock (it plays, but controls are dead) |
| [04:26:21] | clever: | starting it via the keyboard or telnet, it works fine |
| [04:27:05] | clever: | i should try getting a backtrace on the primary thread next time to see exactly where its stuck |
| [04:29:32] | kormoc is now known as kormoc_afk | |
| [04:33:55] | Captain_Murdoch: | taylorr, it sounds like something is triggering the playbackboxhelper's check availability code. what it is, I'm not sure. danielk22 might be able to help since that's mainly his helper code. |
| [04:34:24] | ** Captain_Murdoch has to get some ZZ's. ** | |
| [04:38:35] | markk: | taylorr: is that in the middle of playback? |
| [04:38:42] | taylorr: | markk: yes |
| [04:39:18] | taylorr: | Captain_Murdoch: thanks, time for sleep here too |
| [04:59:56] | kormoc_afk is now known as kormoc | |
| [05:03:45] | taylorr: | markk: it looks like the vdpau pauses are coincident with MythSocket accesses in another thread |
| [05:05:01] | taylorr: | I wonder if heavy network transfers could cause the hardware to stutter |
| [05:06:43] | taylorr: | markk: here is some debug output that shows the QUERY_FILETRANSFER events getting triggered around 16 seconds apart |
| [05:06:48] | taylorr: | http://www.pastebin.ca/2064031 |
| [05:07:27] | taylorr: | I'm wondering if we used to spread those calls out more evenly so it didn't cause any issues |
| [05:07:53] | markk: | taylorr: sorry – thought you'd gone to bed:) are those the main playback socket? |
| [05:08:05] | markk: | (the last pastebin that is) |
| [05:08:18] | taylorr: | markk: I would guess |
| [05:09:10] | taylorr: | seems like these bursts of socket traffic are always coincident with vdpau stuttering |
| [05:09:33] | taylorr: | wonder if these are the ringbuffer socket calls |
| [05:09:47] | taylorr: | if so, reading every 16 seconds seems insane |
| [05:11:11] | taylorr: | Captain_Murdoch: ^^^ when you awake could you look at the last pastebin I posted and see if you can determine what those MythSocket calls are for? |
| [05:14:06] | markk: | taylorr: something a little left of field – you could try and figure out the http:// address of the same file using the upnp server in the backend and play back directly with mythavtest , or maybe if you have nfs, try playing the file directly |
| [05:14:59] | markk: | would eliminate the myth network/ringbuffer code |
| [05:15:10] | taylorr: | markk: good idea |
| [05:15:15] | taylorr: | I'll give it a shot |
| [05:15:48] | markk: | and with mythavtest, you won't get the playbackbox potentially throwing out requests in the background |
| [05:16:17] | taylorr: | markk: I'm actually playing back via MythVideo for the VDPAU problem |
| [05:16:30] | taylorr: | so no playbackbox processing going on |
| [05:25:05] | markk: | taylorr, Captain_Murdoch: have been having trouble getting dvd's to playback in testing when using wireless lan. 54Mbs connection, situated about 12 inches from the router and mythfrontend cannot keep up (this is SD mpeg2!). played the same iso over an nfs mount and it doesn't skip a beat... |
| [05:27:36] | taylorr: | markk: hmmm, I wonder if the delays are causing the readblocksize to get shrunk |
| [05:28:02] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [05:29:36] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [05:31:19] | taylorr: | markk: in ringbuffer.cpp in CalcReadAheadThresh set readblocksize to always be KB512 or one of the other constants and see if it helps |
| [05:38:59] | Goga777 (Goga777!~Goga777@shpd-92-101-150-30.vologda.ru) has joined #mythtv | |
| [05:41:01] | taylorr: | markk: video with vdpau stuttering plays fine via samba |
| [05:42:04] | taylorr: | anyone know a linux program that continuously monitors network statistics using just the console |
| [05:42:34] | taylorr: | kormoc: ^^^ you might know this |
| [05:43:17] | kormoc: | taylorr, iptraf? |
| [05:43:35] | taylorr: | thanks, installing it now |
| [05:44:58] | markk: | taylorr: forcing readblock size makes a huge difference. plays smoothly with either 32 or 512. strange. |
| [05:45:09] | taylorr: | kormoc: it's working beautifully |
| [05:45:20] | ** kormoc tips his hat ** | |
| [05:45:54] | taylorr: | markk: yes, I've had good luck hard coding the size – it has helped lessen the degree of the stuttering/pauses |
| [05:56:00] | taylorr: | markk: the iptraf monitor shows the pauses only happening when network activity spikes |
| [05:56:25] | taylorr: | does the backend send all the ringbuffer transfers via port 6543? |
| [05:57:08] | taylorr: | it looks like we only send data approx every 15 seconds |
| [05:57:15] | taylorr: | so it's a huge spike |
| [06:02:44] | markk: | taylorr: is that mythsocket debug output with -v file ? |
| [06:03:10] | taylorr: | no, -v network,extra |
| [06:09:53] | Goga777 (Goga777!~Goga777@shpd-92-101-150-30.vologda.ru) has quit (Remote host closed the connection) | |
| [06:15:46] | taylorr: | markk: I don't get it – the read ahead buffer seems to go get tons of data at a time and infrequently |
| [06:16:37] | taylorr: | it's like it fills it up and then drains it way down over 15 seconds and then fills it back up |
| [06:16:43] | taylorr: | extremely bursty |
| [06:18:01] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [06:18:34] | andreax1 (andreax1!~andreaz@p57B92F5D.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [06:20:52] | markk: | taylorr: I don't see that here – watching a dvd I get 3–5 chunks per second. |
| [06:21:20] | markk: | to be honest, I'm more confused/frustrated than ever before. just chasing my tail. |
| [06:22:04] | taylorr: | markk: when using -v file,extra I'm only seeing RingBuf/safe_read messages about once every 15 seconds |
| [06:22:31] | markk: | what material is that? |
| [06:23:15] | taylorr: | h.264, 720p@60fps |
| [06:23:58] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has quit (Read error: Operation timed out) | |
| [06:24:45] | markk: | taylorr: so if you lower the readblocksize, does that 15s interval reduce? |
| [06:24:58] | taylorr: | no |
| [06:27:55] | taylorr: | markk: ok so the the read ahead buffer stops reading when used > fill_min and then it fills it up |
| [06:28:04] | markk: | taylorr: just tested h264 60fps 720p here – and still get 3–5 chunks per second |
| [06:28:06] | taylorr: | let me remove that and see if it helps |
| [06:29:32] | rickchristie1 (rickchristie1!~rick@ppp118-209-107-189.lns20.mel4.internode.on.net) has joined #mythtv | |
| [06:29:59] | rickchristie1: | join #mythtv-users |
| [06:31:02] | rickchristie1: | hey all can anyone here give me advice one channel tuning |
| [06:31:33] | Beirdo: | didn't work |
| [06:32:58] | markk: | taylorr: is the bitrate estimation for that file wrong? |
| [06:33:10] | taylorr: | dunno, let me check |
| [06:33:45] | rickchristie1: | ive got perfect reception in kaffiene but myth reception is crap |
| [06:34:14] | taylorr: | markk: yes, it's wrong |
| [06:34:20] | Beirdo: | rickchristie1: you are still in the wrong channel |
| [06:34:34] | taylorr: | markk: it's using 384 kbit/s |
| [06:34:38] | taylorr: | which is way off |
| [06:39:12] | taylorr: | ok, I'm really going to sleep now |
| [06:48:26] | jafa2 (jafa2!~jafa@c-98-234-217-27.hsd1.ca.comcast.net) has quit (Quit: Leaving) | |
| [06:51:58] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has joined #mythtv | |
| [07:14:11] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has quit (Ping timeout: 276 seconds) | |
| [07:52:58] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [07:59:58] | len (len!~quassel@184-97-168-55.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [08:08:50] | rickchristie1 (rickchristie1!~rick@ppp118-209-107-189.lns20.mel4.internode.on.net) has quit (Quit: Ex-Chat) | |
| [09:51:50] | Chutt (Chutt!~ijr@cpe-24-29-225-191.neo.res.rr.com) has quit (Read error: Operation timed out) | |
| [09:52:22] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has quit (Read error: Operation timed out) | |
| [09:53:32] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Read error: Operation timed out) | |
| [09:53:53] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [09:55:00] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Ping timeout: 240 seconds) | |
| [09:55:14] | Chutt (Chutt!~ijr@cpe-24-29-225-191.neo.res.rr.com) has joined #mythtv | |
| [09:55:28] | taylorr (taylorr!~taylorr@cpe-173-095-144-220.nc.res.rr.com) has joined #mythtv | |
| [09:55:28] | taylorr (taylorr!~taylorr@cpe-173-095-144-220.nc.res.rr.com) has quit (Changing host) | |
| [09:55:28] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [09:56:07] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 250 seconds) | |
| [10:05:03] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:06:00] | mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:26] | mike is now known as Guest42947 | |
| [10:08:36] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [10:08:54] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv | |
| [10:17:39] | aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 240 seconds) | |
| [10:30:23] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [11:02:56] | Unhelpful: | it's only been... 15hr since it was delivered back? :/ |
| [11:04:54] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has joined #mythtv | |
| [11:06:59] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [11:08:52] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 260 seconds) | |
| [11:26:40] | Goga777 (Goga777!~Goga777@shpd-95-53-186-6.vologda.ru) has joined #mythtv | |
| [11:27:02] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 276 seconds) | |
| [11:28:43] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [11:37:13] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 246 seconds) | |
| [11:37:39] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [11:46:19] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 246 seconds) | |
| [11:47:09] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [11:48:43] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [11:49:11] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [11:49:11] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [11:49:12] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [11:57:34] | martin___ (martin___!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [11:57:43] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Ping timeout: 240 seconds) | |
| [12:15:03] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 248 seconds) | |
| [12:16:09] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [12:20:09] | Goga777 (Goga777!~Goga777@shpd-95-53-186-6.vologda.ru) has quit (Remote host closed the connection) | |
| [12:23:52] | Dave123-road (Dave123-road!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving) | |
| [12:32:39] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 248 seconds) | |
| [12:35:03] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [12:47:08] | Captain_Murdoch: | taylorr, those query_filetransfers are the data blocks being requested by the FE and returned by the BE. |
| [12:48:07] | taylorr: | Captain_Murdoch: for the ringbuffer, right? |
| [12:49:16] | taylorr: | I'm not sure if you read the backlog from last night but I was seeing these bursts about once every 16 secs which is weird |
| [12:49:59] | taylorr: | it behaved like the buffer would fill up and then drain almost all the way before filling again |
| [12:50:52] | Captain_Murdoch: | taylorr, if you're using mythvideo to test this, then that's a whole 'nother set of code. I don't recall what mythvideo does as far as timers go. we might need the same sort of 'kill the fanart loading timers' patch that I posted for the watch recordings screen. |
| [12:50:55] | taylorr: | I also verified that the VDPAU specific stalls were coincident with this burst of network traffic |
| [12:51:48] | taylorr: | Captain_Murdoch: yes, mythvideo is different in that it doesn't have the playbackbox running but it should be quite the same otherwise |
| [12:52:10] | Captain_Murdoch: | taylorr, you can also test with mythavtest myth://StorageGroupName@MBEHostIP/relative/pa . . . ur/video.mpg |
| [12:52:19] | taylorr: | we have at leasts 2 sets of problems here, one specific to vdpau and another related to events be handled by the playbackbox |
| [12:53:00] | taylorr: | Captain_Murdoch: will test after I get back from an oil change |
| [12:54:17] | ** Captain_Murdoch was typing comments without reading replies becuase he was still reading scrollback. :) ** | |
| [12:55:30] | Captain_Murdoch: | I'd have to look over the ringbuffer code, I haven't got in there in depth in a while and I think we had some big changes. need to head to work now though. will try to look later today if I can find the time. |
| [12:55:42] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Quit: Leaving) | |
| [12:56:05] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has joined #mythtv | |
| [12:56:06] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-58-187.hr.hr.cox.net) has quit (Changing host) | |
| [12:56:06] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [13:09:15] | cattelan_away (cattelan_away!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv | |
| [13:09:29] | cattelan_away is now known as cattelan | |
| [13:18:56] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [13:25:31] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [13:25:31] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Client Quit) | |
| [13:25:45] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [13:31:06] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer) | |
| [13:34:28] | danielk22: | taylorr: You should be able to find the culprit by just putting an assert on the check availability call being made in the UI thread. You might want to look at "myth_FileIsDVD()" and "myth_FileIsBD()" |
| [13:36:59] | danielk22: | taylorr: I have commented those two out in mythtv-rec2 since they cause up to two RemoteFile::Exists() queries to be issued on ProgramInfo::SetPathname() which is supposed to be a UI thread safe method (i.e. it's supposed to touch neither the DB nor communicate over the network.) |
| [13:38:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:39:51] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [13:39:58] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [13:39:59] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [13:39:59] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [13:42:13] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [13:51:21] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [13:54:39] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [13:54:39] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [13:54:39] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [14:01:04] | danielk22: | markk: I got clarification from Nick for the HDHR. For DVB countries the HDHR modulation string contains a the bandwidth, tuning type and in some cases the symbol rate in addition to the modulation scheme. |
| [14:01:57] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [14:03:06] | j-rod|afk is now known as j-rod | |
| [14:05:43] | dblain (dblain!~dblain@mythtv/developer/dblain) has left #mythtv () | |
| [14:06:22] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [14:07:36] | martin___ (martin___!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection) | |
| [14:11:10] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [14:20:23] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 248 seconds) | |
| [14:26:31] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [14:32:46] | aloril (aloril!~aloril@84.249.126.153) has joined #mythtv | |
| [14:32:50] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [14:41:10] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has quit (Ping timeout: 260 seconds) | |
| [14:50:34] | taylorr: | danielk22: I'm also seeing very bursty network/ringbuffer traffic on a remote frontend |
| [14:50:54] | taylorr: | in one case I see large spikes in activity around every 16 seconds |
| [14:51:06] | taylorr: | these spikes cause VDPAU playback to stutter |
| [14:55:49] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [15:09:26] | markk: | danielk22: ok – so what does that mean? :) |
| [15:11:38] | markk: | taylorr: any idea whether the bitrate stuff is relevant? I looked at the code a little after you signed off this morning (last night your time) and I suspect there will be issues if the initial stream scan produces a lower bitrate than it should. |
| [15:15:42] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [15:16:31] | kth (kth!~kth@unaffiliated/kth) has quit (Client Quit) | |
| [15:33:10] | zzattack` (zzattack`!zzattack@237-89-ftth.onsneteindhoven.nl) has joined #mythtv | |
| [15:36:04] | zzattack` (zzattack`!zzattack@237-89-ftth.onsneteindhoven.nl) has quit (Client Quit) | |
| [15:36:10] | abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has joined #mythtv | |
| [16:25:50] | anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has quit (Quit: leaving) | |
| [16:27:28] | taylorr: | markk: dunno, I thought the ringbuffer code was built to adjust to bad bitrate values |
| [16:39:45] | anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has joined #mythtv | |
| [16:41:24] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 258 seconds) | |
| [16:42:56] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [16:44:05] | danielk22: | markk: Those are all parameters we save in DTVMultiplex and hence in the DB. I just need to write a to/from HDHR format functions, and a DB update to fix existing dtv_multiplex entries in the DB (i.e. t8qam64 means we need to put 8 in the bandwidth column and qam_64 in the modulation column.) |
| [16:45:11] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:47:31] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:47:31] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [16:47:32] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:47:40] | danielk22: | markk: The only real complication is that we don't currently save the tuner_type in dtv_multiplex currently, to tell us whether we need a 't' or an 'a' as the first letter. But I'm sure that can be worked around. |
| [16:49:34] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 264 seconds) | |
| [17:10:49] | andreax (andreax!~andreaz@p57B92F5D.dip.t-dialin.net) has joined #mythtv | |
| [17:12:44] | weta (weta!~aross@CPE485b390978ce-CM00222ddf42dd.cpe.net.cable.rogers.com) has joined #mythtv | |
| [18:03:51] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit (Quit: Taking dog for a fur cut.) | |
| [18:07:16] | iamlindoro: | GreyFoxx: #9791's conclusion by the user is likely correct, as it works with last week's master (I've been too afraid to update due to all the recent major changes) |
| [18:08:29] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 240 seconds) | |
| [18:10:11] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [18:29:43] | GreyFoxx: | I used that all the time, (Using W and the menu) but I'll give it a shot as soon as I get home |
| [18:58:42] | fbnts (fbnts!~root@93-97-20-155.zone5.bethere.co.uk) has joined #mythtv | |
| [19:00:24] | fbnts: | Hi, I recently had my aerial installed on the roof (it used to be sat on a box in the attic) I was hoping to get an improved signal for my DVB-T card but its about the same. Most the time its ok but I occasionally get 10–15 minutes of interference and I was hoping to find a way to see the exact signal quality etc. |
| [19:00:36] | fbnts: | Does anyone know what the outputs of femon actually mean? |
| [19:00:42] | iamlindoro: | wrong channel |
| [19:01:05] | fbnts: | ah bugger sorry |
| [19:01:28] | fbnts (fbnts!~root@93-97-20-155.zone5.bethere.co.uk) has left #mythtv () | |
| [19:28:28] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [19:29:56] | andreax1 (andreax1!~andreaz@p57B95DE7.dip.t-dialin.net) has joined #mythtv | |
| [19:30:43] | andreax (andreax!~andreaz@p57B92F5D.dip.t-dialin.net) has quit (Ping timeout: 250 seconds) | |
| [19:38:46] | martin____ (martin____!~quassel@h-165-113.A155.priv.bahnhof.se) has joined #mythtv | |
| [19:43:50] | aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 276 seconds) | |
| [19:56:02] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [20:01:42] | iamlindoro: | Beirdo: Triggering of the buildbot broken? |
| [20:01:52] | iamlindoro: | s/bot/bots/ |
| [20:02:06] | iamlindoro: | Looks like last was on the 17th |
| [20:15:19] | len (len!~quassel@184-97-168-55.mpls.qwest.net) has joined #mythtv | |
| [20:17:59] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 240 seconds) | |
| [20:18:11] | Gibby_ (Gibby_!~Gibby@204.118.10.244) has joined #mythtv | |
| [20:18:27] | Gibby_ is now known as Gibby | |
| [20:24:13] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 248 seconds) | |
| [20:36:48] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [20:39:16] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.) | |
| [20:40:34] | stuarta: | iamlindoro: looks like the server that hosts the master buildbot got rebooted last night |
| [20:49:08] | stuarta: | tisn't that |
| [20:49:16] | ** stuarta goes to bed ** | |
| [20:49:25] | skd5aner: | stuartm: ping? |
| [20:59:41] | cattelan is now known as cattelan_away | |
| [21:05:43] | Beirdo: | iamlindoro: should be working fine. I'll have to check it |
| [21:06:45] | taylorr: | danielk22, Captain_Murdoch: I figured why the readahead thread stops writing data to the ringbuffer for long periods is because we aren't reading any data from the ringbuffer for long periods of time |
| [21:07:26] | taylorr: | so the decoder must not be calling av_read_frame for long periods of time which shouldn't happen |
| [21:07:37] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [21:07:45] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [21:08:10] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out) | |
| [21:12:24] | Beirdo: | iamlindoro: very good catch. Missed restarting the feeder that listens to github |
| [21:12:38] | Beirdo: | should be good to go now |
| [21:13:10] | Beirdo: | of course, my slaves at home are misbehaving. |
| [21:13:27] | Beirdo: | so maybe my DSL did eat itself |
| [21:15:21] | Beirdo: | I just told github to re-submit the last 3 changes. It seems to be up |
| [21:15:39] | Beirdo: | And now I am putting in rc.local to start this stuff automatically :) |
| [21:15:46] | iamlindoro: | Beirdo: Cool, thanks-- just wanted to verify that my libbluray updates compiled across the board |
| [21:18:18] | Beirdo: | no problem. It will compile on the 32bit now, and the other two in a few hours when I get home and make my network unscrew itself |
| [21:18:36] | martin____ (martin____!~quassel@h-165-113.A155.priv.bahnhof.se) has quit (Remote host closed the connection) | |
| [21:19:02] | taylorr: | danielk22, Captain_Murdoch: I thought av_read_frame() would trigger a ReadPriv() in ringbuffer.cpp but it doesn't seem to correlate |
| [21:19:18] | taylorr: | any ideas who calls ReadPriv() in ringbuffer.cpp? |
| [21:27:26] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [21:27:26] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [21:27:26] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:30:41] | stuartm: | skd5aner: ? |
| [21:39:37] | skd5aner: | stuartm: hey, nothing important, but I remembered several months back you were research some metadata sources for mythmusic, and one of them you were looking at was musicbrainz |
| [21:39:55] | skd5aner: | wanted to let you know they did a complete re-write of all their backend schema, website, and web services over the weekend |
| [21:40:01] | skd5aner: | just in case you pick back up on that |
| [21:40:17] | stuartm: | skd5aner: oh cool, I'll take another look then |
| [21:40:48] | stuartm: | well as long as they launched it at the weekend and it wasn't written in a weekend ;) |
| [21:41:02] | skd5aner: | stuartm: new web service – http://wiki.musicbrainz.org/XML_Web_Service/Version_2 |
| [21:41:18] | skd5aner: | and NGS (next generation) release notes – http://wiki.musicbrainz.org/?title=Server_Release_Notes/20110516 |
| [21:41:49] | skd5aner: | stuartm: hah – planned for 5 years, developed and executed over the last 2 |
| [21:41:53] | stuartm: | their web ui frustrated me before, but primarily I was disappointed because they didn't support genre information |
| [21:42:21] | skd5aner: | stuartm: they were bragging about beating Duke Nukem Forever and Perl6 with their release ;) |
| [21:42:44] | stuartm: | skd5aner: thanks, I've bookmarked those |
| [21:42:46] | skd5aner: | honestly, I loved their web UI, but I know that I was probably a minorty |
| [21:43:36] | stuartm: | skd5aner: it wasn't very intuitive and getting at the information I wanted meant drilling down through multiple layers |
| [21:43:47] | skd5aner: | honestly, I don't like the new webui, but probably because it's massively different than before and the info that, imho, was easy to get to isn't as much anymore for the sake of cleanliness I believe |
| [21:44:35] | skd5aner: | either way – for the greater good – they want to evolve into even more of a music encyclopedia |
| [21:44:40] | iamlindoro: | stuartm: A cursory glance suggests they still don't do genre |
| [21:44:47] | skd5aner: | yea – they don't... |
| [21:45:20] | stuartm: | ah, sucky :( Still maybe it would be a useful resource for some users all the same |
| [21:45:25] | skd5aner: | I think they believe it's too subjective – what you call rock, I call Adult Top 40 ;) |
| [21:45:52] | iamlindoro: | But the data returned would be easily bent into shape for use in the metadata classes... but then someone would need to do the plumbing in mythmusic to actually use them |
| [21:46:10] | iamlindoro: | Not that there's much work to do to make a plugin support them |
| [21:46:41] | stuartm: | personally I need a way to quickly build a playlist which will separate out the classical from the indie rock/alternative from the metal from the folk/country and the jazz (not much of that) |
| [21:46:45] | skd5aner: | I leverage a plugin for their picard tagger that goes and looks up the most popular tags on last.fm for an artist AND track, and then compares them against a whitelist of approved genre's, and applies the genre tag that way... I also do major and minor genres |
| [21:47:57] | stuartm: | I know it's not easy to put everything into a genre category, at least not when people insist on inventing new genres all the time just because they don't want to admit they listen to 'pop' or whatever |
| [21:48:42] | skd5aner: | stuartm: the plugin is based off of something like this – http://tiptoes.hobby-site.com/mbz/lastfm/wordlists.html |
| [21:49:03] | stuartm: | but all the same it's pretty easy to classify music into maybe a dozen super-categories (at most) |
| [21:49:21] | skd5aner: | look at the "Major Genres" in that link above |
| [21:50:15] | stuartm: | yeah |
| [21:53:02] | skd5aner: | stuartm: oh, and here's the link to the plugin – maybe leverage the funcationality it has to use the last.fm web services in order to determine genre(s) based off of tag popularity – it's in python |
| [21:53:03] | skd5aner: | http://forums.musicbrainz.org/viewtopic.php?id=1795 |
| [21:53:54] | skd5aner: | or the most simple one here – http://musicbrainz.org/doc/Picard_Plugins |
| [21:54:02] | skd5aner: | s/most/more |
| [22:13:22] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (*.net *.split) | |
| [22:13:22] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has quit (*.net *.split) | |
| [22:13:22] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has quit (*.net *.split) | |
| [22:14:59] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [22:18:35] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [22:18:35] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [22:19:03] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has quit (*.net *.split) | |
| [22:19:03] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has quit (*.net *.split) | |
| [22:19:32] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [22:19:32] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [22:37:46] | j-rod is now known as j-rod|afk | |
| [22:38:11] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [22:47:28] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [23:32:39] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:59:50] | abqjp (abqjp!~abqjp@71-38-214-217.albq.qwest.net) has quit (Quit: abqjp) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.