| Friday, May 6th, 2011, 00:03 UTC | ||
| [00:03:00] | wagnerrp: | danielk22, sphery: ive been working on breaking up programs/mythbackend/mainserver.cpp as a side piece of code that i needed to write for the jobqueue |
| [00:03:17] | wagnerrp: | so far, ive broken out all of the fileserver duties, along with the delete thread |
| [00:03:47] | wagnerrp: | as ive got it set up currently, it gets its own thread, but it only gets a single thread, and any additional files simply get put into a pool that the thread deals with |
| [00:04:14] | wagnerrp: | the thread just then self terminates when there is nothing left in the queue for it to deal with |
| [00:09:42] | Beirdo: | Yay |
| [00:09:57] | Beirdo: | I sense some fun merging ahead :) |
| [00:17:03] | Cougar (Cougar!~cougar@2001:ad0:2:5:21c:c0ff:fe18:f2d2) has joined #mythtv | |
| [00:23:42] | ** Captain_Murdoch thinks he'll start working on converting the delete threads into a queue so we can have 4 different implementations. :) ** | |
| [00:29:01] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit () | |
| [00:29:14] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Ping timeout: 240 seconds) | |
| [00:36:21] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [00:40:21] | wagnerrp: | maybe we can have a vote, or charity raffle to decide |
| [00:43:28] | Beirdo: | heheeh |
| [00:43:48] | noahric (noahric!~noahric@nat/google/x-avflvlriftdnjyic) has left #mythtv () | |
| [00:49:32] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [00:49:57] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [00:49:57] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [00:49:57] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:20:28] | Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv | |
| [01:22:37] | danielk22: | I think an immediate unlink followed by a single thread doing the truncating sounds the most efficient (though I do worry a bit about what happens in all of these implementations if a single mount goes out to lunch..) |
| [01:23:28] | danielk22: | The ideal implementation would also truncate on all filesystem on each wakeup, but only truncate one file per filesystem. |
| [01:25:01] | danielk22: | I don't think there is any need for the delete thread to terminate until shutdown so long as it blocks without waking up when there is nothing to do... (I don't mind wasting 8K on the stack and another 8K elsewhere ;). |
| [01:26:58] | danielk22: | For now, I think we should use either Beirdo's implementation with the reserve/release calls added, or my implementation.. and then consider wagnerrp's for later. |
| [01:28:40] | Beirdo^2: | I don't think he's ready to merge anyways |
| [01:30:15] | wagnerrp: | danielk22: correct, this is still a long way off from being ready |
| [01:30:27] | wagnerrp: | long way being several months minimum |
| [01:30:52] | wagnerrp: | for now, and possibly for 0.25, a quicker solution would be better |
| [01:32:49] | wagnerrp: | danielk22: the reason for it auto-terminating is just due to a complaint by markk a while back, that we needlessly have too many threads |
| [01:33:00] | wagnerrp: | and self termination was a fairly trivial feature to add |
| [01:36:34] | danielk22: | I think markk was probably more annoyed at the number of threads rather than the longevity of them.. But in all honesty he and the rest of us need to get used to threads sooner or later, hardware reality is pushing us there. |
| [01:44:11] | Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has quit (Quit: Bye) | |
| [01:44:22] | danielk22: | Hardware reality in terms of how many cycles you can burn waiting for a response from a hard disk or other resource, the number of cores is still only a small factor. We can lower _our_ thread count by pushing things onto the OS threads (using writev() instead of write()), but those interfaces unfortunately don't make the code much simpler. |
| [01:45:13] | Beirdo: | yeah, I think it was more the memory use of the many stacks that he was grumbling about primarily |
| [01:45:51] | danielk22: | Beirdo: 8KB ? |
| [01:45:54] | Beirdo: | dunno about QThreads, but pthreads default is 8MB |
| [01:46:06] | Beirdo: | per thread |
| [01:46:25] | Beirdo: | I found this out when debugging my bot and trying to figure out what all the memory was for. |
| [01:46:32] | danielk22: | that's not real unless you use it... |
| [01:47:17] | Beirdo: | there is that |
| [01:48:28] | markk: | danielk22: I was concerned with the number of threads in the frontend (and probably still am) – though I'm not really sure if I should be. Last time a checked a few weeks ago, playing back a video used 17 threads in the frontend. as of today it is 20 (give or take a couple for software vs hardware decoding) |
| [01:49:22] | danielk22: | markk: That is a little concerning.. The original design was something like 3 threads per video.. what are the rest doing? |
| [01:49:46] | markk: | I only really noticed because my main dev box (the same one I've been using for about 4–5 years) really struggles with gdb... |
| [01:50:05] | Beirdo: | we have a total of 91 threads + qrunnables in the source tree (not counting ffmpeg) |
| [01:50:20] | Beirdo: | of course, not all are used at all times |
| [01:52:21] | Beirdo: | markk: thanks for the warning cleanup. I was looking at doing that this weekend, but you beat me to it :) |
| [01:52:37] | danielk22: | Beirdo: I've been trying over the last few years to eliminate all the CPU sucking usleep() busy loops. So most really should be sleeping 99.99% of the time. |
| [01:52:51] | markk: | danielk22: UI, decoder (* X), audio, upnp * 3, tv browser help, readahead, mythsystem manager, mythsignalsystemmanager, mythsystemiohandler *2, mythsignallingtimer, download manager and a number of 'worker' threads (presumably Qt related) |
| [01:53:24] | Beirdo: | workers are likely HTTP server workers |
| [01:53:26] | danielk22: | markk: so most of those aren't really video related.. |
| [01:55:04] | danielk22: | I think of the video playback related threads as read-ahead, decoder, audio & UI. There used to be another (video display). |
| [01:55:26] | markk: | sorry – video playback wasn't really my point. Just the general explosion in the number of threads. but as I said, I'm not really sure if it is an issue or not. google seems to suggest the overhead should be small |
| [01:57:11] | markk: | with Qt Lighthouse we should be able to get the frontend up and running on iOS devices (for example) – but I'm not sure how many iOS apps there are with 17 threads |
| [01:58:36] | danielk22: | markk: Yeah, overhead should be small as long as they block well. On the order of 8K real mem on 64 bit OS's. Everytime I've run powertop in the last 3 years our CPU usage has been dropping. |
| [02:00:08] | danielk22: | AFAIK Apple now allows threads on iOS apps.. But we'd need to do some optimization for that CPU (though Janne has run the MythTV frontend on a very puny ARM chip..) |
| [02:00:35] | Beirdo: | I do see 8MB stack segments on my current mythbackend, BTW |
| [02:01:19] | Beirdo: | as you said though, it's not really real until you use it |
| [02:01:39] | danielk22: | Beirdo: I don't doubt they show up in the virtual memory, I just doubt it has much of an effect of the resident memory. |
| [02:02:38] | Beirdo: | likely makes more of an issue on a 32-bit system where memory is limited to 3G virt per process, but we'd have a long way to go to hit that in "wastage", I'd think |
| [02:03:41] | danielk22: | Beirdo: You have ~ 2^64 vmem vs. maybe ~ 2^36 of resident memory (the stack allocations are smaller on 32 bit systems..) |
| [02:04:13] | Beirdo: | yeah. That's true |
| [02:07:35] | danielk22: | BTW OSX and Linux allow setting the default stack with limit or ulimit -a (depending on shell). I wonder how low you could make it before you get segfault ;] |
| [02:08:14] | markk: | Beirdo: sorry missed you there – no problem. nice job on the merge btw – pretty painless all told:) (though I think mheg is broken) |
| [02:09:12] | Beirdo: | yeah, I think mheg's less broken though, and thanks |
| [02:09:23] | Beirdo: | waiting for more reports of breakage |
| [02:10:38] | Beirdo: | the one that got reported, we have fixed as best I can tell |
| [02:11:13] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:14:24] | danielk22: | FYI 32 KB VMEM for the stack allows me to navigate around and play video.. |
| [02:17:47] | Beirdo: | not bad. if we ever cared, we could likely trim them to 512k stacks or soemthing |
| [02:20:03] | danielk22: | We used to require bigger stacks, but converted some of the larger stack usages to the heap when playing with MythTV on ARM a while back. |
| [02:21:51] | Beirdo: | yeah, I love it when people stuff a 1MB object on the stack |
| [02:32:38] | taylorr: | markk: speaking of threads – I've been trying to figure out why random pauses are occuring during playback, got a feeling something is blocking the UI thread but not sure how to figure it out |
| [02:33:03] | danielk22: | taylorr: you're not using NFS are you? |
| [02:33:11] | taylorr: | no |
| [02:33:35] | GreyFoxx: | Taylor: Is this during videos via mythvideo or recordings:? |
| [02:33:49] | taylorr: | I reverted some ringbuffer changes and it seems to help – the ringbuffer changes definitely made nfs playback worse |
| [02:34:07] | taylorr: | GreyFoxx: both |
| [02:34:39] | GreyFoxx: | I found the reason for odd pauses I had seen during playback of content from mythvideo but not from recordings |
| [02:35:33] | taylorr: | so you are seeing the pauses too? what was the reason for the mythvideo pauses? |
| [02:35:47] | GreyFoxx: | mythvideo was in the background downloading the screenshots/covers for a TV series I had imported. And everytime a file finished downloading it sems to be triggering a gui reload of the list |
| [02:36:04] | Beirdo: | ahh |
| [02:36:13] | GreyFoxx: | and it would cause a slight delay in nvideo playback to made it slightly out of sync with the audio and would cause a pause |
| [02:36:41] | GreyFoxx: | only reason I really noticed was because I had finally ripped all 9 seasons of Everybody loves raymond I had got from xmas |
| [02:36:48] | taylorr: | heh, seems like the recordings have a similar problem since it queues a few fanart transactions right before playback and they are executed during playback |
| [02:36:49] | iamlindoro: | Note that it does *not* trigger a reload of the list |
| [02:36:51] | GreyFoxx: | and it had like 9 * 24 shows |
| [02:37:11] | iamlindoro: | All it does is set the image on the buttonlistitem-- a full reload of the list is not triggered |
| [02:37:26] | GreyFoxx: | Iv'e seen the same "reload" or redraw before as items were loaded |
| [02:37:53] | GreyFoxx: | it might not reload the list, but something is causing a redraw or something similar |
| [02:38:17] | taylorr: | no matter what the UI thread during playback is very sensitive to interruptions so we should be very careful about having functions execute during playback |
| [02:38:42] | GreyFoxx: | I first noticed it when I had VNC'd into the box and as I saw the logs go by showing the downloads finishing and at the same time VNC would redraw the whole screen |
| [02:38:57] | iamlindoro: | What VNC does and what is actually happening are two different things ;) |
| [02:39:18] | GreyFoxx: | Yes, but the redraw only triggered when a covershot finished downloading, every single time |
| [02:39:43] | GreyFoxx: | and then when watching a video, every single time a cover finished downloading , there would be a tiny pause/stutter in video playback |
| [02:39:45] | iamlindoro: | Anyway, just didn't want there to be a misleading understanding-- a reload or the list does not occur when metadata downloads return. The only thing that is called is a setimage on the buttonlist item if the item received is in the current buttonlist |
| [02:40:20] | iamlindoro: | again, I think you are conflating unrelated items |
| [02:40:42] | iamlindoro: | more likely it's the fact that metadata lookup/download returns an event that needs handling |
| [02:41:05] | GreyFoxx: | could certainly be, and I'm not saying the download itself is doing osmething wrong |
| [02:41:20] | GreyFoxx: | but I was able to reproduce it so if anything I know I can trigger it |
| [02:43:37] | markk: | taylorr: I've been keeping an eye on the various pause discussions. it's a bit of a needle in a haystack to be honest and the underlying cause may be different in each case. |
| [02:44:46] | taylorr: | markk: it sure seems related to the UI thread getting blocked |
| [02:45:10] | Beirdo: | I've been seeing less of a glitch in playback at the end of recordings in the new-logging branch. I'm thinking that the logging in the UI thread may have been blocking it for short times. |
| [02:45:20] | taylorr: | markk: it's actually pausing when there are plenty of decoded frames ready for display |
| [02:46:18] | taylorr: | wouldn't the logging been present in the old playback thread before it was merged with the UI thread? |
| [02:46:27] | iamlindoro: | It's really just a double edged sword-- We're told that nothing should block the UI thread, but to do anything useful with UI related data in non-UI threads, it needs to be passed back to the main thread-- so what to do? |
| [02:46:56] | Beirdo: | taylorr: possibly, but maybe more logging was added too? |
| [02:47:19] | taylorr: | iamlindoro: that's the million dollar question :) |
| [02:48:30] | markk: | taylorr: my original working assumption was that it was backend load but it does seem to be caused directly in the frontend. First up, I think it would be useful for people to try running without any plugins. then maybe add in a little event debugging in mythmainwindow and tv_play. see if someone can correlate the pause to an event |
| [02:49:16] | taylorr: | markk: good idea, I'll go ahead and remove all my plugins |
| [02:49:17] | Beirdo: | mine seem to coincide with preview generation |
| [02:49:40] | iamlindoro: | so the common theme here seems to be "event handling/customEvent in general" |
| [02:50:03] | Beirdo: | I think that would be a fair summation, yes |
| [02:50:05] | markk: | maybe intercept some of those preview generation and other UI update events in tv_play. (and when I say intercept, I mean kill!) |
| [02:50:10] | iamlindoro: | as preview generation returns are handled exactly the same way as completeed meta lookups |
| [02:51:02] | iamlindoro: | It would be a shame to drop some of them entirely |
| [02:51:18] | iamlindoro: | although obviously playback comes first |
| [02:51:44] | Beirdo: | yeah, not sure what the fix would be |
| [02:51:54] | GreyFoxx: | drop them if in the middle of playback, set a flag and when playback is over reload the whole list? Or something like that ? |
| [02:52:29] | markk: | but if the UI isn't showing, we don't need them. if we've missed something and the current code doesn't reload, force a reload |
| [02:52:41] | GreyFoxx: | yeah |
| [02:52:41] | markk: | yeah – just like GreyFoxx said :) |
| [02:53:03] | iamlindoro: | markk, right, obviously we don't need them, just need to account for the fact that they happened-- a reload is a little unsightly but I don't have a better solution |
| [02:53:08] | Captain_Murdoch: | iamlindoro, currently libmythui does a RemoteFile::LastModified() check on myth:// images when they are loaded, and that lastModified() call is happening in the UI thread it appears. |
| [02:53:57] | iamlindoro: | Captain_Murdoch, interesting |
| [02:54:30] | markk: | iamlindoro: can you point me to where the metadata lookup return event is handled? |
| [02:54:42] | iamlindoro: | markk, videodlg.cpp ::customEvent |
| [02:54:59] | Captain_Murdoch: | for Watch Recordings, it looks like the fanart timer sometimes fires after playback starts, which can cause a hickup. I have an attempted patch to stop that, but taylorr said it didnt' fix it for him. I need to look further. |
| [02:59:46] | markk: | iamlindoro: hrm – difficult for the tv_play object to intercept that event (for whatever reason) – as it would mean libmythtv depended on MythVideo (I think – although I can't see where ThumbnailDLEvent is defined) |
| [03:01:01] | iamlindoro: | markk, You want imagedlevent |
| [03:01:14] | iamlindoro: | libmythmetadata/metadataimagedownload.h |
| [03:01:49] | iamlindoro: | sounds like you may be looking at the customevent for the wrong class |
| [03:01:58] | iamlindoro: | you want the actual videodialog::customEvent |
| [03:02:50] | Beirdo: | and this time (just now), it looks like a burst of ASK_RECORDING events from the backend |
| [03:03:07] | markk: | iamlindoro: :) thanks |
| [03:03:16] | iamlindoro: | np |
| [03:03:28] | danielk22: | taylorr: does this happen more when a recording is going on? i've been wondering if the way we handle the position map could cause problems.. |
| [03:03:32] | iamlindoro: | Just remember how I helped when we find out the issue is some huge embarassing mistake I've made ;) |
| [03:03:50] | Beirdo: | hehe |
| [03:04:06] | taylorr: | danielk22: happens with just playback and no recordings or jobs being processed on the backend |
| [03:04:31] | GreyFoxx: | Ok, so I commented out the SetImage in the videodlg customEvent and the pause still happens |
| [03:05:08] | iamlindoro: | GreyFoxx, right-- because it's the event, not the image setting |
| [03:05:29] | iamlindoro: | ie, the customEvent in general is handled in the UI thread |
| [03:06:09] | iamlindoro: | And presumably playback, being in the UI thread, depends on the same event loop |
| [03:06:40] | iamlindoro: | so handling an event-- ANY event-- could theoretically disturb playback. Or, I might be talking crazy talk :) |
| [03:06:46] | danielk22: | taylorr: hmm, ok that eliminates most of the causes for events.. and without NFS involved it also pretty much eliminates the ringbuffer code... I dunno what's left.. Maybe if you watch TV with -v network feeding a terminal you can correlate the pause with something... |
| [03:07:05] | markk: | GreyFoxx: as iamlindoro just pointed out to me, you probably want VideoDialog::customEvent – which eventaully calls VideoDialog::UpdateItem – which has a string SetImage calls |
| [03:07:33] | danielk22: | iamlindoro: yes, but you'd need to take > 2 ms for it to be likely.. |
| [03:10:26] | taylorr: | I'm still experiencing pauses with the plugins removed |
| [03:12:46] | markk: | taylorr: try adding a simple debug of the event type in tv_play (TV::eventFilter) |
| [03:16:08] | Captain_Murdoch: | taylorr can you see what this patch does to your hickups after starting playback due to the remote SG file check? http://www.bc2va.org/chris/tmp/mythuiimage_loadcache.diff |
| [03:16:37] | taylorr: | markk: ok, compiling now |
| [03:17:06] | taylorr: | Captain_Murdoch: after debugging the event type I'll give it a go |
| [03:19:11] | Captain_Murdoch: | ok, thanks. that will make it skip the LastModified check in the UI thread and just try to load myth:// images in another thread even if they are in the local cache. current code checks the local cache for all images which necesitates a lastModified check to see if the cache is up to date. |
| [03:20:58] | markk: | taylorr: might need to put that debug into tv::event as well |
| [03:34:37] | markk: | taylorr: the only non-timer event (1) I'm getting during regular playback is 65534 – which I'm guessing is preview generation (as I can trigger a host of them if I go into playbackbox on another frontend) |
| [03:37:37] | Captain_Murdoch: | so theoretically, with events processed in the main/UI thread, it would be possible to DOS attack a remote FE playing a recording by sending lots of events which it would stop to process. |
| [03:37:39] | taylorr: | markk: are you seeing the pauses too? |
| [03:38:30] | Captain_Murdoch: | of course you can do that now but in different ways. |
| [03:38:35] | markk: | taylorr: no |
| [03:46:18] | sphery: | Granted, my production system is 0.24-fixes, but it seems I only get pauses when watching while recordings occur, and they seem to only happen when current recordings finish and new recordings start. I just assumed it was from system events (Recording pending/started/finished) and/or recording_list_change or whatever is sent out to tell the frontend to update the list and pull new previews, etc. or something like that. |
| [03:47:25] | sphery: | but that may be what you're all saying--any event can cause issues (and the flurry of events happening when multiple recordings end and start all at the same time may be enough to trigger it) |
| [03:49:07] | taylorr: | markk: I see the event type 65535 too but they don't correlate to the pauses |
| [03:49:53] | markk: | sphery: I think we need to identify, in your case, whether the pause is (a) the backend getting overloaded (b) the events disrupting playback or (c) the events then triggering some image loading or other work. hopefully (c), in which case it should be easy enough to fix |
| [03:50:03] | taylorr: | markk: wait, does that even handler get executed immediately? |
| [03:53:13] | markk: | taylorr: I think it should be synchronous |
| [03:54:01] | taylorr: | markk: if that's the case then I don't see any events that would cause a problem as I'm assuming event = 1 is something normal |
| [03:54:33] | markk: | though maybe the image loading is in a different thread – and hence asynchronous... |
| [03:55:22] | taylorr: | should I just do an immediate return if the event = 65534 |
| [03:55:53] | markk: | worth a shot |
| [04:06:41] | markk: | taylorr: this is what I've been using to check events : http://pastebin.ca/2054432 |
| [04:08:57] | taylorr: | markk: ok, I'll try running with that patch tomorrow – going to finish the test with intercepting the 65534 event |
| [04:16:09] | Captain_Murdoch: | markk, mythui image loading should be in the background unless we've already got it in our disk or mem cache in which case it happens in the calling thread. I think the bigger issue is a RemoteFile::LastModified check() that currently happens in the calling thread for myth:// images such as fanart, etc.. the patch I linked above for taylorr to test makes it so that for myth:// images, we don't bother checking to see if the image |
| [04:16:09] | Captain_Murdoch: | is in the cache if it's a myth:// image, we just fire off the background thread to do that check and load. The RemoteFile::LastModified() check does use the existing MBE connection to check the remote file, but even then, it could take a short while to find and stat the file on the MBE, all the while blocking the calling thread on the FE. |
| [04:22:08] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv | |
| [04:22:58] | taylorr: | Captain_Murdoch: I'll try your patch tomorrow – time for sleep |
| [04:23:07] | Captain_Murdoch: | taylorr, ok, thanks. ditto on the sleep. |
| [04:29:38] | markk: | Captain_Murdoch: thanks, I was assuming the image loading was in the background – good to have it confirmed:) |
| [05:02:04] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [05:17:39] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [05:56:55] | Goga777 (Goga777!~Goga777@shpd-92-101-138-73.vologda.ru) has joined #mythtv | |
| [06:01:55] | Goga777 (Goga777!~Goga777@shpd-92-101-138-73.vologda.ru) has quit (Read error: Connection reset by peer) | |
| [06:08:19] | andreax (andreax!~andreaz@p57B92951.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [06:12:10] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [06:29:21] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [06:42:20] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [07:01:29] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (Ping timeout: 240 seconds) | |
| [07:02:37] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv | |
| [07:23:30] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [07:30:03] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [07:30:51] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [07:37:27] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [07:37:27] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Read error: Connection reset by peer) | |
| [07:37:31] | MythBuild_ (MythBuild_!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [07:37:38] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [07:42:32] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Client Quit) | |
| [07:42:39] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [07:59:46] | Goga777 (Goga777!~Goga777@shpd-95-53-164-113.vologda.ru) has joined #mythtv | |
| [08:00:35] | Goga777 (Goga777!~Goga777@shpd-95-53-164-113.vologda.ru) has quit (Remote host closed the connection) | |
| [08:00:49] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 246 seconds) | |
| [08:12:26] | simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:13:02] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [08:38:21] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:54:47] | simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has quit (Quit: KVIrc 4.0.0 Insomnia http://www.kvirc.net/) | |
| [08:54:55] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:57:48] | len (len!~quassel@184-97-168-55.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [09:24:06] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [10:02:12] | sailerboy (sailerboy!~sailerboy@2607:f358:1:fed5:22:0:ece3:d738) has quit (Read error: Operation timed out) | |
| [10:04:15] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 248 seconds) | |
| [10:05:02] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:59] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:11:50] | Goga777 (Goga777!~Goga777@shpd-95-53-188-140.vologda.ru) has joined #mythtv | |
| [11:45:48] | Goga777 (Goga777!~Goga777@shpd-95-53-188-140.vologda.ru) has quit (Remote host closed the connection) | |
| [11:49:26] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [11:49:52] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [11:49:52] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [11:49:52] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [12:24:27] | skd5aner: | Just to go with the conversation last night regarding pauses during playback... I would like to throw out there that I see pauses during playback often when another recording starts on either of my backends. I think sphery mentioned he had seen this too (I think it was sphery). |
| [12:27:52] | danielk22: | skd5aner: Those cases are more explainable as there is both a flurry of events, and in some circumstances the system is actually overloaded. |
| [12:28:14] | stuarta: | i'm the other case, when i've seen it, it was more like tralph said, i've still got decoded frames available but the display thread is blocked |
| [12:30:45] | skd5aner: | danielk22: yea, make sense... however – it wasn't something I had really seen exhibited until 0.23 or 0.24 (don't remember exactly when it started to exhibit itself). |
| [12:35:58] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [12:36:03] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [12:36:03] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Client Quit) | |
| [12:50:23] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Read error: Operation timed out) | |
| [12:50:50] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [12:54:10] | danielk22: | skd5aner: It happened before 0.23 & 0.24, it was just a more rare. We used to have dedicated thread for displaying video frames but it would have been very difficult to continue doing so while supporting MythUI overlays. |
| [12:55:05] | skd5aner: | gotcha |
| [12:55:41] | skd5aner: | thanks – just wanted to throw it out there given the nature of the discussion – definitely the most noticable problem I see on a daily basis :) |
| [12:56:00] | danielk22: | This means we need to be a lot more diligent about making sure events processing doesn't block the UI thread. (Before the threading changes long running event processing were still a problem as it meant you weren't processing keyboard/lirc events.. But now it's also very visible..) |
| [12:56:23] | danielk22: | Being visible does make it a bit easier to debug, so there is a bright side :) |
| [12:56:33] | skd5aner: | :) |
| [12:59:22] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [13:17:37] | stoffel (stoffel!~quassel@87.180.200.170) has joined #mythtv | |
| [13:21:28] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:51:18] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [13:54:35] | sphery: | danielk22: Oh, I probably should have mentioned that in my setup, I have 2 dedicated backends and 1 dedicated frontend, and the frontend gets the video through mythproto, but I still get the pauses when recordings end/start. |
| [13:55:45] | skd5aner: | yea, I use mythproto/streaming too (no longer rely on NFS) |
| [13:56:12] | skd5aner: | one dedicated mbe and one sbe/fe (with an hdpvr attached to it) |
| [13:56:18] | skd5aner: | all storage on MBE |
| [14:06:55] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has quit (Ping timeout: 248 seconds) | |
| [14:13:29] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection) | |
| [14:14:02] | kormoc_afk (kormoc_afk!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [14:14:03] | kormoc_afk is now known as kormoc | |
| [14:17:20] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has joined #mythtv | |
| [14:17:45] | j-rod|afk is now known as j-rod | |
| [14:56:59] | davide_: | danielk22: i took a good look and can't see where schedLock would be held when ChangeRecordingEnd() is called. do you remember how you produced the problem? e.g. was it during normal use, previewing schedule changes, or running --testsched, etc.? |
| [15:35:22] | danielk22: | davide_: It was when changing the end time of an in progress recording but I'm not able to reproduce now. There must have been something else going on. |
| [15:37:58] | danielk22: | skd5aner: sphery: There is a post about a ringbuffer tweak being effective in mythtv-dev.. if that work for you I can take a look at that again. The algorithm we use to dynamically scale the read-ahead assumes that if there is a long gap between reads it is because the bitrate is low.. |
| [15:38:29] | danielk22: | but if the reads from disk are so slow that we're actually blocking on reads that can cause the same symptom.. |
| [15:39:56] | davide_: | danielk22: ok. i'd put the lock back in ChangeRecordingEnd() and readdress it if it deadlocks again. |
| [15:40:23] | danielk22: | davide_: will do. |
| [15:40:49] | sphery: | danielk22: Interesting. I'll make make that change on my production system and see what happens. |
| [15:43:57] | danielk22: | skd5aner: sphery: I copied over some OS read-ahead and cache hint changes from mythtv-rec2, which should help with LiveTV watching; but the scaling is pretty much the same as it's been since Bruce first wrote it (with me just adding defaults for HD streams since he mostly just accounted for 2–4 Mbps SD streams.) |
| [15:45:16] | skd5aner: | cool, I'm still running fixes, but yes... I do notice the pauses at show changes with livetv as well, but assumed that was a different issue |
| [15:46:37] | skd5aner: | heh – yea, funny to think it's been that long since bjm was around |
| [15:46:50] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [15:55:19] | abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has joined #mythtv | |
| [16:07:08] | danielk22: | davide_: I misremembered the deadlock.. it looks like was in the scheduler itself and due to a bug only applicable to the recording branch (now fixed..) sorry about the noise. |
| [16:07:36] | davide_: | danielk22: np. |
| [16:23:41] | xxtjaxx (xxtjaxx!~andreas@kde/developer/marschke) has joined #mythtv | |
| [16:24:03] | thwg2005 (thwg2005!~thwg2005@cpe-70-113-127-152.austin.res.rr.com) has joined #mythtv | |
| [16:25:10] | xxtjaxx: | Hi I downloaded myth 0.24. Is it necessary to compile and install your version of ffmpeg? I'd really like to use my debian ffmpeg. If you really depend on your version of ffmpeg please be specific about the particular changes to it. |
| [16:26:38] | stuarta: | yes you need to use ours, there are lots of changes |
| [16:36:30] | wagnerrp: | xxtjaxx: we now carry ffmpeg in a separate folder as an independent build |
| [16:36:53] | wagnerrp: | the latest sync puts our internal version against a version some time in late february |
| [16:37:20] | wagnerrp: | you should be able to diff our version against the upstream version |
| [16:38:08] | andreax (andreax!~andreaz@p57B929F1.dip.t-dialin.net) has joined #mythtv | |
| [16:39:23] | JohnFlux (JohnFlux!~johnflux@konversation/developer/JohnFlux) has joined #mythtv | |
| [16:39:27] | JohnFlux: | Hi all |
| [16:41:07] | JohnFlux (JohnFlux!~johnflux@konversation/developer/JohnFlux) has left #mythtv ("Konversation terminated!") | |
| [16:50:25] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [16:50:54] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:50:54] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [16:50:55] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [16:58:30] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 260 seconds) | |
| [17:00:01] | Goga777 (Goga777!~Goga777@shpd-95-53-178-35.vologda.ru) has joined #mythtv | |
| [17:00:11] | _gunni_ (_gunni_!~Gunni@koln-4db44f39.pool.mediaWays.net) has joined #mythtv | |
| [17:10:19] | dekarl (dekarl!~dekarl@tmo-102-122.customers.d1-online.com) has joined #mythtv | |
| [17:10:25] | xxtjaxx: | wagnerrp: ah so it isnt compiled after a regular configure that fine |
| [17:11:39] | wagnerrp: | xxtjaxx: no, it is compiled and installed as part of mythtv |
| [17:11:53] | wagnerrp: | however it is NOT installed on top of any existing ffmpeg install |
| [17:12:01] | wagnerrp: | we use our own non-conflicting names |
| [17:13:09] | wagnerrp: | what i mean in saying that it is an independent build is that it is kept in mythtv/external/FFmpeg, largely intact |
| [17:13:09] | xxtjaxx: | ah thanks |
| [17:13:52] | wagnerrp: | while old version of mythtv broke it up and placed it in mythtv/libs/libav[codec|format|util] |
| [17:14:19] | wagnerrp: | in this new fashion, it will be a lot easier to just do a large diff on the source to see the changes |
| [17:15:45] | wagnerrp: | from there, you should be able to extract our changes into a patchset, and maintain you own branch |
| [17:16:29] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:18:52] | sphery: | or better, just use the version that MythTV is developed to work with, since it has no effect on your system ffmpeg/packages/... :) |
| [17:43:57] | dekarl (dekarl!~dekarl@tmo-102-122.customers.d1-online.com) has quit (Ping timeout: 240 seconds) | |
| [17:45:43] | stoffel (stoffel!~quassel@87.180.200.170) has quit (Ping timeout: 258 seconds) | |
| [17:47:08] | danielk22: | Does anyone have a clue as to the socket errors people are seeing? I looked through my logs and there aren't any. My logs only go back 14 days, but I'm assuming I'd see it in that time frame if it were happening here. |
| [17:48:48] | danielk22: | Hmm, does everyone seeing the problem run with slave backends? |
| [17:58:27] | sphery: | danielk22: Pretty sure that in at least some of the cases, the socket errors are just the symptom, and the real problem is that the backend has deadlocked. I think even users with single combined frontend/backend systems have seen them--but those are probably when mythpreviewgen tries to connect to the (deadlocked) backend. |
| [17:58:59] | sphery: | I wouldn't be suprised if we have multiple issues, however, that are all being grouped into the "socket errors" category (because that's all people see in the log files) |
| [18:01:52] | sailerboy (sailerboy!~sailerboy@ipv61.sailerboy.net) has joined #mythtv | |
| [18:08:33] | kwmonroe_ (kwmonroe_!~kwmonroe@32.97.110.64) has joined #mythtv | |
| [18:08:57] | kwmonroe_ (kwmonroe_!~kwmonroe@32.97.110.64) has quit (Read error: Connection reset by peer) | |
| [18:11:45] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [18:20:13] | noahric (noahric!~noahric@nat/google/x-avflvlriftdnjyic) has joined #mythtv | |
| [18:20:17] | noahric (noahric!~noahric@nat/google/x-avflvlriftdnjyic) has left #mythtv () | |
| [18:33:33] | Beirdo: | jya: if you're around... audiooutpututil.cpp won't compile on linux-ppc |
| [18:34:04] | Beirdo: | lack of bswap... and we have libmythtv/bswap.h that should cover it, I'd think, but I'm not sure :) |
| [18:34:44] | Beirdo: | anyways, I have a buildbot slave running on my Powerbook G4 as of last night (and I realized today I forgot to put sshd on it) – running Ubuntu 10.10 |
| [18:35:20] | Beirdo: | stuarta: we should work on getting the OSX buildslave up too sometime :) |
| [18:57:24] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Ping timeout: 258 seconds) | |
| [18:58:05] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [18:58:52] | stoffel (stoffel!~quassel@p57B4C8AA.dip.t-dialin.net) has joined #mythtv | |
| [19:26:41] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit (Ping timeout: 240 seconds) | |
| [19:27:03] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [19:36:34] | stuarta: | Beirdo: yeah we should. i've been quite slack on that front |
| [19:39:13] | Goga777 (Goga777!~Goga777@shpd-95-53-178-35.vologda.ru) has quit (Remote host closed the connection) | |
| [19:41:25] | stuarta: | i'm out for the weekend, but will try to have a look at it next week |
| [19:41:43] | stuarta: | will have to finish off the build profile stuff in osx-packager.pl that i started |
| [19:41:57] | stuarta: | that's kinda a pre-req |
| [19:47:09] | Beirdo: | yeah. We'll get it going soon enough :) |
| [19:47:20] | Beirdo: | life keeps getting in the way and all |
| [19:50:17] | stuarta: | the basic theory was to add support for a single repository where all the tarballs are downloaded to |
| [19:50:52] | stuarta: | and then convert the "what to build" array into several different profiles for the different builds we want to do |
| [19:50:57] | stuarta: | dinner time |
| [19:51:01] | Beirdo: | ahh |
| [19:53:43] | sphery: | jya: On http://code.mythtv.org/trac/ticket/9579#comment:4 , when I took it, I thought it was a reference to the animation rate in mythui, and I planned to reduce that to 30 (or 24 or 12 or something based on display refresh rate), but it's sounding like it's PulseAudio related, so I was wondering if you'd like to take it (as I won't be any use in the audio code :). |
| [20:14:17] | jpabq_ (jpabq_!~abqjp@71-37-158-25.albq.qwest.net) has joined #mythtv | |
| [20:14:18] | abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [20:15:12] | abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has joined #mythtv | |
| [20:18:33] | SteveGoodey (SteveGoodey!~steve@host86-147-177-88.range86-147.btcentralplus.com) has joined #mythtv | |
| [20:18:44] | jpabq_ (jpabq_!~abqjp@71-37-158-25.albq.qwest.net) has quit (Ping timeout: 260 seconds) | |
| [20:30:33] | stoffel (stoffel!~quassel@p57B4C8AA.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [20:38:49] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has quit (Ping timeout: 240 seconds) | |
| [20:41:24] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has joined #mythtv | |
| [20:48:40] | len (len!~quassel@184-97-168-55.mpls.qwest.net) has joined #mythtv | |
| [21:08:29] | _gunni_ (_gunni_!~Gunni@koln-4db44f39.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 5507, sources date: 20110110, built on: 2011-03-07 17:15:32 UTC 5507 http://www.kvirc.net/) | |
| [21:16:02] | SteveGoodey (SteveGoodey!~steve@host86-147-177-88.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:22:11] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds) | |
| [21:24:15] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [21:25:28] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [21:30:44] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit () | |
| [21:36:02] | xxtjaxx: | Hi! I setup mythbox and piped the Query from mythtv/database/mc.sql into my mysql. Now when I start the xbmc mythbox plugin it says access denied. Any help from you folks? |
| [21:39:36] | wagnerrp: | nope, we dont support mythbox, and this is the develoment channel anyway, user support is over at #mythtv-users |
| [21:39:51] | wagnerrp: | for mythbox support, see #xbmc |
| [21:42:29] | xxtjaxx: | Sorry my fault. |
| [21:47:53] | abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has quit (Quit: abqjp) | |
| [21:49:03] | abqjp (abqjp!~abqjp@71-37-158-25.albq.qwest.net) has joined #mythtv | |
| [21:55:44] | amstan (amstan!~amstan@75-119-242-93.dsl.teksavvy.com) has joined #mythtv | |
| [21:55:52] | amstan (amstan!~amstan@75-119-242-93.dsl.teksavvy.com) has left #mythtv ("Konversation terminated!") | |
| [21:57:19] | j-rod is now known as j-rod|afk | |
| [22:07:54] | thwg2005 (thwg2005!~thwg2005@cpe-70-113-127-152.austin.res.rr.com) has left #mythtv () | |
| [22:24:59] | jya: | sphery: I can have a look ; there use to be a usleep in there... |
| [22:25:42] | sphery: | thanks--it's definitely out of my league |
| [22:32:20] | jya: | i have to check why the usleep got removed ; it was there in 0.23 ; and I haven't looked much in this WriteAudio code in a while |
| [22:52:50] | Beirdo: | jya: you see my mention of the audiooutpututil.cpp issue with ppc? |
| [23:14:00] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has joined #mythtv | |
| [23:14:00] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [23:14:00] | stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [23:14:15] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds) | |
| [23:16:22] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 252 seconds) | |
| [23:18:32] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Quit: brfransen) | |
| [23:29:24] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [23:48:23] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Quit: brfransen) | |
| [23:50:46] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [23:50:46] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [23:50:46] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:50:49] | jya: | Beirdo: where? |
| [23:55:16] | wagnerrp: | about 5 hours ago |
| [23:55:38] | wagnerrp: | something about issues with bswap |
| [23:55:40] | jya: | ok.. I found it.. |
| [23:56:37] | wagnerrp: | the master-linux-ppc builds are now tested through the buildbot |
| [23:58:03] | jya: | It's weird it won't compile ; because I remember specifically that we added change for 0.24 to finally work with debian PPC which wouldn't work with 0.23 |
| [23:58:18] | jya: | and audiooutpututil.cpp hasn't changed since |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.