Monday, August 26th, 2013, 00:13 UTC | ||
[00:13:49] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
[00:40:57] | dgeary2 (dgeary2!~debian@120.21.78.52) has quit (Read error: Connection reset by peer) | |
[00:43:52] | stichnot: | gigem, stuartm: From my original caption/subtitle overhaul work, I recall that at least where the OSD is concerned, the VDPAU painter is somewhat lax about clipping. I.e., I thought everything was fine when using VDPAU, but then Xv users reported excess clipping. |
[00:50:09] | jya: | stuartm: I've seen this with most themes… the default one (Terra) is probably the worse, because even with the right size, often I see the progress being outside the container |
[00:54:18] | jya: | danielk: right now when ThreadFileWriter gets feed too much data, too quickly, it simply stops writing and you end up with corrupted/missing data. I want to change the behaviour that instead of just stopping to write, we now wait until there's enough space in the buffer... |
[00:55:27] | jya: | while I can see this introducing issues for code expecting TFW to write things very quickly, it will solve another.. We really just are replacing an error with another. Except now there's no missing data which I believe is more important |
[01:07:09] | jya: | wagnerrp: did you see my patch to housekeeper.cpp? |
[01:07:21] | jya: | i can commit it myself if you prefer... |
[01:08:57] | wagnerrp: | something about the reference not being decremented properly? |
[01:09:01] | wagnerrp: | you can go ahead and commit it |
[01:10:26] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
[01:17:38] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
[01:21:41] | stichnot (stichnot!~stichnot@ppp-68-126-151-208.dsl.pltn13.pacbell.net) has joined #mythtv | |
[01:21:41] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
[01:21:41] | stichnot (stichnot!~stichnot@ppp-68-126-151-208.dsl.pltn13.pacbell.net) has quit (Changing host) | |
[01:24:00] | jya: | ok then… thanks |
[01:27:51] | wagnerrp: | although as mentioned, it shouldn't make any difference |
[01:28:04] | wagnerrp: | those tasks should be persistent for the duration of the application |
[01:28:18] | wagnerrp: | they shouldn't need to get cleaned up until the application terminates |
[01:31:10] | jya: | yes… everywhere the code properly handle increasing and decreasing the reference count. but somehow, the ref count is increased whenever it's pulled from the queue…. ive been tracking various leaks for a few days, and i just encountered that one. didn't check the context or how serious it was. |
[01:31:20] | wagnerrp: | jya: i see what you're pointing at now |
[01:31:34] | wagnerrp: | i increment it when i add it to the queue, and then increment it again when pulling it back out |
[01:31:44] | jya: | that's right.. |
[01:32:10] | wagnerrp: | and never decrement it when exiting the thread |
[01:32:20] | jya: | i should make a RefCountedQueue like I did a RefCountedList; then you don't even have to worry about increasing/decreasing counter, it's done automatically |
[01:32:29] | wagnerrp: | hang on before you commit it |
[01:32:59] | jya: | it is decremented when pulled from the queue, by the ReferenceLocker |
[01:34:06] | wagnerrp: | ok, the reference locker isn't incrementing a third time when it spawns |
[01:34:08] | wagnerrp: | nevermind |
[01:34:11] | jya: | we have refcount +1 when added to the taskMap.. then +1 when added to the taskQueue; then +1 when removed from the taskQueue, and -1 when used. |
[01:34:25] | wagnerrp: | right |
[01:34:32] | jya: | so basically, it goes +1 whenever its used.. so after a few minutes it will be +20 etc |
[01:34:44] | wagnerrp: | i was thinking there was a third +1 in the reference counter, but there isnt |
[01:35:18] | jya: | i got thrown away a bit with the ReferenceLocker as I didn't know what it was (similar to my RefCountHandler) |
[01:35:41] | jya: | had I known that type existed, I would have done things differently in the metadata… but that's another topic |
[01:36:29] | jya: | well, there is a 3rd +1, the balance is +1 to the task whenever it's used.. keeps increasing |
[01:45:05] | jya: | stuartm: re #11717; the placeholder image (the image shown when no image is defined) is being fully redrawn when you move the cursor. So now that none of the other images are redrawn unnecessarily, it makes the image placeholder blinking very obvious |
[02:29:54] | jya: | the new nzmqt causes sigabort every single time now… |
[02:30:36] | jya: | upgrading a major component such as this after a beta is really a bad idea... |
[02:43:42] | nyloc (nyloc!~quassel@p3EE2C9E5.dip0.t-ipconnect.de) has joined #mythtv | |
[02:44:28] | _nyloc_ (_nyloc_!~quassel@p3EE2D7FC.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
[02:54:27] | dgeary2 (dgeary2!~debian@120.21.78.52) has joined #mythtv | |
[02:55:22] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out) | |
[02:59:07] | dgeary2 (dgeary2!~debian@120.21.78.52) has quit (Read error: Connection reset by peer) | |
[02:59:40] | dgeary2 (dgeary2!~debian@120.21.78.52) has joined #mythtv | |
[03:00:58] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
[03:02:52] | dgeary2 (dgeary2!~debian@120.21.78.52) has quit (Read error: Connection reset by peer) | |
[03:12:08] | dgeary2 (dgeary2!~debian@120.21.78.52) has joined #mythtv | |
[03:15:44] | jya: | well, can't figured it out why it crashes. it's during the initialisation within nzmqt; you end up with a QVector whose size is -32.. realloc on it causes an exception |
[03:17:46] | dgeary2 (dgeary2!~debian@120.21.78.52) has quit (Read error: Connection reset by peer) | |
[03:19:02] | joki (joki!~joki@p54862A9D.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
[03:24:07] | joki (joki!~joki@p54863A40.dip0.t-ipconnect.de) has joined #mythtv | |
[03:27:56] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds) | |
[03:29:22] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
[03:45:43] | jya: | i reverted that change, can't figure out why it crashes, and as it's upstream I can't really be bothered either finding out the cause. |
[04:23:00] | stichnot: | jya: I assume it's on the Mac that it's crashing? |
[04:23:16] | jya: | haven't tried on my main system no |
[04:23:47] | jya: | i tried with different version of llvm (as I was using xcode 5) so went back to xcode 4.6 |
[04:23:52] | jya: | then tried with gcc |
[04:24:02] | jya: | thinking that may have been a compiler bug |
[04:24:09] | jya: | crash always in the same place |
[04:25:45] | jya: | I could try on my ubuntu VM… but I think I've spent enough time troubleshooting the issue already… haven't done much today because of it |
[04:28:56] | stichnot: | I agree that updating that component was pretty risky this close to the release |
[04:40:29] | jya: | managed another deadlock in logging server :( if mythbackend is killed just when it's respawning mythlogserver, then it blocks forever |
[04:41:34] | jya: | which is more of an issue on mac, because mythlogserver gets respawned often |
[04:47:21] | jya: | is there a way to test if an event loop is running ? |
[04:49:04] | jya: | when exiting the backend, cleanup() disconnects all currently connected mythsocket ; but does so using a Qt::BlockingQueuedConnection.. As we're in the cleanup() call, the event loop isn't running anymore. So mythSocket::DisconnectFromHost is stuck forever, and the backend never exits |
[04:50:39] | jya: | I guess it's just an issue of deleting an object in a different thread than the one connecting it... |
[05:11:17] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has joined #mythtv | |
[06:10:08] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
[06:50:38] | jya: | wagnerrp: sometimes exiting the backend takes a very long time… depending on when you stop it |
[06:52:05] | jya: | if the housekeeper has started a job, the destructor wait for that job to complete… Tasks like retrieiving the theme list; or scanning the metadata in the background (takes about 2 minutes here). mean you send a kill to the backend, and only after they all complete will it exit |
[06:53:21] | jya: | on my ubuntu machine, it's not uncomon to take a while… time sudo service mythtv-backend stop -> real 0m30.053s |
[06:53:23] | laga (laga!~laga@h1626373.stratoserver.net) has joined #mythtv | |
[07:36:15] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
[08:37:50] | wagnerrp: | jya: there is a mechanism to allow an early-out for those sorts of things, but currently the mythfilldatabase task is the only one that uses it |
[08:38:19] | wagnerrp: | artwork update would be trivial to add, following that model |
[08:38:41] | wagnerrp: | theme update would be a bit different since i believe that's all internal |
[08:45:49] | wagnerrp: | that one would probably be best hooking into mythdownloadmanager and aborting the download |
[08:56:12] | wagnerrp: | jya: this should be close, but i'm not going to be able to test/commit it until at least friday |
[08:56:18] | wagnerrp: | http://pastebin.com/X8VYc1v2 |
[08:57:31] | jya: | that looks good you quickly going over it |
[08:58:45] | jya: | would have to make sure there that MDM is still running |
[08:59:17] | jya: | where it's being called in the backend destructor is relevant upon the order |
[08:59:41] | jya: | you don't want to restart MDM with GetMythDownloadManager() if it got destroyed earlier |
[09:00:12] | wagnerrp: | the lock on m_running is tight, but not explicit |
[09:00:19] | wagnerrp: | so there could be a small window for that sort of error |
[09:00:41] | jya: | those access are going to be atomic ; so it doesn't really matter |
[09:01:06] | jya: | and if it's not running, MDM::cancelDownload will have no effect |
[09:02:18] | wagnerrp: | there's also a chance the thread could have fired off and not yet started the download when the call to terminate comes |
[09:02:40] | ** wagnerrp heads to the airport at way-too-early AM ** | |
[09:18:06] | paul-h (paul-h!~Paul@176.27.236.54) has joined #mythtv | |
[09:25:38] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Remote host closed the connection) | |
[09:29:20] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
[09:37:24] | yunosh (yunosh!~jan@horde/jan) has joined #mythtv | |
[10:08:57] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
[10:38:21] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 245 seconds) | |
[11:03:18] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
[11:03:57] | stuartm: | jya: ok, I see what's going wrong with the progess bar, I'll push a fix later today |
[11:12:54] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
[11:29:50] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
[11:58:52] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
[12:11:26] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has joined #mythtv | |
[12:24:24] | Splat1 (Splat1!~Splat1@ec2-50-17-220-173.compute-1.amazonaws.com) has joined #mythtv | |
[12:29:00] | paul-h: | peper03: any thoughts on #9703 it's more your area of expertise :) |
[12:29:00] | ** MythLogBot http://code.mythtv.org/trac/ticket/9703 ** | |
[12:37:38] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
[12:45:50] | nyloc (nyloc!~quassel@p3EE2C9E5.dip0.t-ipconnect.de) has quit (Remote host closed the connection) | |
[12:48:09] | nyloc (nyloc!~quassel@p3EE2C9E5.dip0.t-ipconnect.de) has joined #mythtv | |
[12:56:19] | stichnot (stichnot!~stichnot@32.172.232.183) has joined #mythtv | |
[12:56:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
[12:56:19] | stichnot (stichnot!~stichnot@32.172.232.183) has quit (Changing host) | |
[13:04:31] | paul-h: | Anybody able to test the 6 channel audio samples here http://code.mythtv.org/trac/ticket/10087#comment:3 they all play fine for me but I only have a stereo audio out to test with |
[13:13:07] | jya: | paul-h: I'll be able to test them tomorrow or later tonight… depending on how I go on the stuff I'm doing |
[13:18:31] | paul-h: | cool thanks |
[13:23:52] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
[13:26:03] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Connection reset by peer) | |
[13:26:41] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
[13:50:28] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
[13:59:46] | Splat1 (Splat1!~Splat1@ec2-50-17-220-173.compute-1.amazonaws.com) has left #mythtv ("Leaving") | |
[14:06:50] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
[14:08:03] | jya: | how do you set so the log are written to a file ? (trying to debug my mythlogserver-less build) |
[14:11:28] | jya: | ah found it… it's the path you set, not the logfile name |
[14:20:41] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
[15:08:23] | jya: | any qmake expert here? |
[15:09:21] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has joined #mythtv | |
[15:22:24] | yoyolala (yoyolala!~yoyolala@unaffiliated/yoyolala) has joined #mythtv | |
[15:28:19] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
[15:34:27] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
[15:34:27] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
[15:34:27] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
[15:49:40] | SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has quit (Ping timeout: 256 seconds) | |
[15:50:59] | SmallR2002 (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv | |
[15:53:20] | stuartm: | so I've just had multiple logserver instances started, one using a huge amount of cpu which makes me thing that bug should be a blocker for 0.27 |
[16:03:53] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
[16:08:59] | dekarl (dekarl!~dekarl@p4FCEF270.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
[16:09:03] | dekarl1 (dekarl1!~dekarl@p4FE84373.dip0.t-ipconnect.de) has joined #mythtv | |
[16:10:19] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Ping timeout: 256 seconds) | |
[16:12:26] | jya: | stuartm: which bug |
[16:12:27] | jya: | ? |
[16:14:49] | stuartm: | fe or be starting multiple instances of the logserver, see #11784 and #11230 |
[16:14:49] | ** MythLogBot http://code.mythtv.org/trac/ticket/11784 ** | |
[16:14:49] | ** MythLogBot http://code.mythtv.org/trac/ticket/11230 ** | |
[16:15:49] | stuartm: | if you have two or more instances running, then one will start using 80–90% cpu and generally grinding the system to a halt |
[16:16:09] | jya: | weird... |
[16:16:35] | jya: | i can see that mythlogserver is polling very often; the wait being 90ms |
[16:16:50] | jya: | it's in an eventloop so it could be made much slower |
[16:17:09] | jya: | though, it does fit my purpose where I do not want a qeventloop to be running |
[16:17:26] | jya: | I've added a configure option --disable-mythlogserver |
[16:18:01] | jya: | it simulates a similar thing as having mythlogserver; except that instead of having a thread feeding zeromq |
[16:18:15] | jya: | it feeds a thread that does the same job as what mythlogserver was doing |
[16:19:00] | stichnot (stichnot!~stichnot@216.239.45.84) has joined #mythtv | |
[16:19:00] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
[16:19:00] | stichnot (stichnot!~stichnot@216.239.45.84) has quit (Changing host) | |
[16:19:33] | jya: | but why it would be started as in those bug is very bizarre… only thing I could think of is that the ping the client send to check of mythlogserver is running is somehow blocked |
[16:19:41] | jya: | could it be a selinux issue? |
[16:20:28] | jya: | and what is this nvidia-tls thing? |
[16:20:41] | stuartm: | not using selinux here, could be that the running MLS is hung or just slow to respond to the ping and we assume no response is forthcoming? |
[16:20:48] | Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv | |
[16:21:18] | stuartm: | I think the nvidia stuff is just a red-herring |
[16:21:45] | stuartm: | "The nvidia-tls libraries (/usr/lib/libnvidia-tls.so.x.y.z and /usr/lib/tls/libnvidia-tls.so.x.y.z); these files provide thread local storage support for the NVIDIA OpenGL libraries (libGL, libGLcore, and libglx). Each nvidia-tls library provides support for a particular thread local storage model (such as ELF TLS), and the one appropriate for your system will be loaded at run time." |
[16:21:56] | jya: | it waits about 10s the first time… would have to be *very* slow |
[16:22:14] | jya: | as usual with Beirdo code, I find very few thing to criticise… it's very neat code |
[16:23:22] | stuartm: | yeah, code is good, approach though may be over-engineered for our needs |
[16:24:25] | jya: | the only thing that can't be beaten with this approach, is that you will indeed receive the logs when the application is crashing... |
[16:26:13] | jya: | I could always try to add a configuration disabling mls… and only output to the console then |
[16:27:04] | rsiebert_ (rsiebert_!~quassel@e179130048.adsl.alicedsl.de) has joined #mythtv | |
[16:27:54] | jya: | I would push my changes now, but it's 2:30AM here, I'm exhausted and won't be there to handle any build issue |
[16:28:31] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Connection reset by peer) | |
[16:30:24] | rsiebert (rsiebert!~quassel@e179131186.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
[16:40:01] | stuartm: | the logs aren't always that helpful in the event of a crash, 95 times out of 100 it's the backtrace alone that reveals the problem |
[16:40:43] | SteveGoodey: | jya: Don't you ever rest? Burnout waiting to happen :-) |
[16:51:31] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
[16:56:57] | knightr: | Are there still problems with the MythDownloadManager? |
[16:58:44] | knightr: | mythfilldatabase can't communicate with TWS but if I use another program I can contact TWS web service and get an answer... |
[17:01:31] | knightr: | (while mythfilldatabase reports a download error...) |
[17:03:16] | xris (xris!~xris@xris.forevermore.net) has quit (Excess Flood) | |
[17:03:39] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
[17:11:15] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
[17:12:05] | Tobbe5178534 (Tobbe5178534!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
[17:12:05] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
[17:12:32] | Tobbe5178534 (Tobbe5178534!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
[17:12:44] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
[17:16:51] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
[17:51:07] | stichnot: | stuartm: Why is MythUIType::GetAllChildren() not declared as const? |
[17:54:07] | stuartm: | best guess, because it's returning a pointer to m_childrenList instead of a copy |
[17:54:46] | stuartm: | but ... |
[17:55:35] | stichnot: | so it's more of a conservative indication to the caller? |
[17:57:52] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
[17:58:39] | stuartm: | stichnot: TBH I don't really know, or cannot remember |
[17:59:13] | stuartm: | but I'd be wary about having a const method return a non-const pointer to a class member |
[18:00:30] | stichnot: | OK. I was mostly just curious after my const Dump() method had to be non-const because of this |
[18:00:32] | stuartm: | the original incarnation of GetAllChildren() was written by Thor, by the look of it, the only thing I've ever changed was to switch from QVector to QList |
[18:00:52] | stichnot: | I see |
[18:02:29] | stuartm: | it's possible that the pointer could be made const, or better yet, return a copy – there's little benefit to providing a pointer to the list and potential for thread safety issues if the result were used outside the UI thread |
[18:03:22] | stuartm: | then again, the contents of the list is just as volatile, so it wouldn't be any safer |
[18:04:49] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
[18:04:57] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
[18:13:36] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has joined #mythtv | |
[18:33:51] | stichnot: | stuartm: I'm looking for some advice/feedback on subtitle/caption performance work. The basic idea is to spread the drawing work over multiple Pulse() calls to minimize frame drops. The drawing work naturally breaks down into individual MythUIType objects – one MythUISimpleText and one MythUIShape per "chunk". The subtitle splits into chunks at line boundaries and at formatting changes. ... |
[18:33:53] | stichnot: | ...I initially create the MythUIType objects with a NULL parent, and then reparent them to the SubtitleScreen during successive Pulse() calls (using a simple cost model to determine how much work to do in each Pulse() call). This works well, except that I also need to delay deletes by the same amount as the display was delayed, otherwise you can end up with annoying rapid flashing behavior... |
[18:33:54] | stichnot: | ...on "real-time" captions. |
[18:33:56] | stichnot: | Unfortunately, my current implementation is kind of messy, with various extra layers of caching on top of the MythUIType objects. I was thinking of a potentially cleaner approach where objects are initially created as not visible, and deletions are automatically deferred by the same amount it took to initially become visible. This would be done by subclassing MythUISimpleText and MythUIShape and |
[18:33:57] | stichnot: | pushing the messy layers into those subclasses. One small consequence would be to make DeleteChild() and DeleteAllChildren() virtual. |
[18:33:59] | stichnot: | Any thoughts on this? |
[18:35:33] | stichnot: | Also, it's unfortunate that Pulse() is hard-coded to 72Hz. It means I have no real control over whether I'm allowing enough time for the next frame, since there might be 2 or 3 Pulse() between two frames. |
[18:46:59] | stuartm: | there's not unfortunately a good value for Pulse() that would suit all video frame rates e.g. 25fps PAL, 30fps NTSC, 24fps |
[18:47:06] | stuartm: | though 72 is a multiple of that last one |
[18:49:14] | stuartm: | I don't mind you making Delete() virtual or sub-classing widgets if that's what it takes |
[18:51:00] | peper03: | stuartm: 600 would work (http://www.wolframalpha.com/input/?i=lowest+c . . . C+25+and+30) but whether that's a "good" value is another matter :) |
[18:51:27] | stuartm: | I can't think of a better solution right now, although I'd obviously jump at a simpler and more elegant approach if one could be found |
[18:51:51] | stuartm: | peper03: redrawing the screen at 600 fps might draw a few complaints ;) |
[18:52:01] | stuartm: | pun not intended |
[18:52:44] | peper03: | Because the refresh is too low for the golden-eyed crowd? :) |
[18:55:53] | peper03: | That said, what is the relationship between Pulse() and the fps? Is it really 1:1? |
[18:56:33] | stuartm: | stichnot: how come you need to override DeleteChild() and DeleteAllChildren()? |
[18:58:38] | peper03: | Ah, this is just for overlays and such? Not for video rendering? (Never looked at this stuff before). |
[19:00:46] | stuartm: | peper03: it's the UI refresh rate, which includes the OSD |
[19:02:27] | peper03: | Where is the top of the chain? Everything just seems to be calling MythUIType::Pulse, but I'm obviously too blind to find the original call. |
[19:03:41] | stuartm: | a very long time ago the very arbitrary figure of 70Hz was chosen, no-one really knows why, and since then we've been stuck with it |
[19:04:44] | stuartm: | peper03: MythMainWindow::animate() |
[19:05:55] | stuartm: | which is itself called by a timer – drawTimer |
[19:06:14] | stuartm: | stichnot: and it is 70Hz, not 72Hz |
[19:07:21] | stuartm: | in theory we could change it, even make it flexible but we'd need to migrate themes over or perform some conversions at runtime as present animations are based on the 70Hz figure |
[19:08:41] | stuartm: | ideally animations would be time based, e.g. move 100px in 5 seconds, not move X pixels every Pulse() to a maximum of 100 |
[19:08:45] | peper03: | Yes, I see. Ok, would it be possible to change that timer on the fly to match the current video framerate (or, say 2x fps) or do the various implementations of Pulse() assume that calls are 1000/70 ms apart? |
[19:09:26] | stuartm: | some parts currently work on the 70Hz assumption, like the animations I just mentioned |
[19:09:40] | peper03: | Yes, presumably they must if they want to move a certain distance in a certain time. |
[19:11:05] | stuartm: | if themes actually stated the time to take, we could average the movement over calls no matter what the framerate – i.e. we could make the framerate adjustable, even slowing it down when the machine is idle or when trying to sync with video |
[19:12:21] | peper03: | So the themes currently define animations along the lines of the "move X pixels every Pulse()" example? |
[19:12:37] | stuartm: | yes |
[19:13:14] | stuartm: | which would of course cause animations to speed up/down if the Pulse() rate was raised/lowered |
[19:13:39] | peper03: | That complicates things, then. |
[19:16:34] | stuartm: | it's just possible that it's simply a matter of converting the figure specified in the themes into a unit of speed would work, themes could continue to work on the basis of 70Hz, but we just convert that internally as the frame rate changes |
[19:17:15] | danielk22: | stuartm: Doing time based animations is a solved problem, but is not as trivial as move x in y seconds. Think of a bouncing ball, if you skip the keyframe where the ball actually touches the ground humans will not process it as a bouncing ball, but rather as a weirdly floating one. |
[19:17:31] | danielk22: | But it might work for the simple stuff we do in MythUI. |
[19:18:25] | stuartm: | right, it gets complicated by the rounding required, and for the image animations that's especially problematic |
[19:20:45] | stuartm: | I'm not volunteering to make the changes, at least not at the moment, there are other things which need attention and which don't involve quite so many late nights and splitting headaches |
[19:21:05] | peper03: | Presumably as long as you make sure you show the first and last keyframe and keep the generated ones evenly spaced, you should be alright? (There's probably some case where that still won't work, though). |
[19:22:45] | stuartm: | image based animations in general are pretty coarse, in the order of 1–2 fps instead of 25, and they are all key-frames since they consist of a bunch of separate image files rather than video |
[19:23:27] | stuartm: | if you skip an image chances are that it's going to look very wrong, as danielk22 notes |
[19:24:34] | danielk22: | peper03: You need to find the C0's and C1's in the generating function + minima and maxima. |
[19:24:37] | stuartm: | but since their frame rates are so small, you'd probably never need to skip frames in practice and you could build in some leeway to the end time |
[19:25:37] | stuartm: | for movement animations it's easier to lose a px here and there, but your start/end points must be reached |
[19:26:44] | peper03: | stuartm: Yes, it was movement animations I was thinking of. |
[19:30:27] | stuartm: | it would be easier to avoid those rounding issues if the animations were based on say 150Hz instead of 70Hz, that would let us do 25fps, 30fps and say 60fps for the UI |
[19:31:29] | stuartm: | wait, that would be 300Hz not 150 |
[19:32:36] | stuartm: | only that wouldn't really work because then themers would need to start defining movement by fractions of a pixel! |
[19:33:39] | stichnot: | stuartm: sorry, I got pulled away from lunch, catching up now... |
[19:33:41] | stuartm: | I can already feel that headache starting |
[19:33:59] | stuartm: | stichnot: you can ignore the last 30 minutes :) |
[19:34:15] | dekarl1 is now known as dekarl | |
[19:34:18] | peper03: | stuartm: Just skimming over the code (and as I said, I've never looked into any of this). MythUIImage and MythUIAnimation don't appear to be assuming 70Hz. MythUIImage waits for a specific delay to have elapsed. MythUIAnimation queries the frequency from MythMainWindow. |
[19:36:01] | peper03: | stichnot: Sorry, hijacked the conversation! |
[19:37:13] | dekarl: | stuartm, 300Hz is was to low. you need 600 to support 24p ;) |
[19:37:19] | dekarl: | s/was/way/ |
[19:37:50] | dekarl: | if glxgears can do it so can we! |
[19:38:00] | stuartm: | peper03: well as danielk22 hinted, it's already solved, I've just got a very bad memory |
[19:38:18] | stuartm: | well, at least partially solved |
[19:42:01] | stichnot: | stuartm: The subtitlescreen.cpp that I inherited directly calls DeleteChild() and DeleteAllChildren() when clearing captions. Should it be doing something different? |
[19:42:44] | stichnot: | stuartm, peper03: I'm actually interested in the 70Hz issue... |
[19:44:30] | stichnot: | I could probably do something simple by tracking video loop ticks and making sure to limit caption work between video loop ticks rather than between drawTimer ticks |
[19:44:47] | stuartm: | stichnot: not necessarily, I just could think why you'd need to override those, are you intending to start a timer or something in those methods and if so, why not do that in the screen instead? |
[19:45:07] | stuartm: | stichnot: I'm just trying to understand what you're proposing a little better |
[19:47:39] | stichnot: | Yeah, the overridden DeleteChild() would start a countdown which it would check during its overridden Pulse() and delete itself when necessary. I'm finding it overly messy to keep all these caches at the screen level. |
[19:50:13] | stichnot: | dekarl: what about 29.97, 59.94, etc? what we really need is 90000 |
[19:50:45] | dekarl: | anyone good with PHP? Schedule::merge() in http://code.mythtv.org/cgit/mythweb/commit/?i . . . 73d72b2b7cef is supposed to merge in default values from the recording schedule template only if they are not set already, but somehow thats not working properly |
[19:54:23] | stoffel (stoffel!~quassel@pD9E4050A.dip0.t-ipconnect.de) has quit (Remote host closed the connection) | |
[19:57:55] | stichnot: | stuartm: Currently there is one cache, m_708imageCache, that tracks MythUIType objects, and also m_expireTimes for subtitles to expire after a certain timecode, also m_avSubCache for resizing during Adjust Subtitle Zoom. In my current (too-messy) code, I added a cache of objects waiting to be drawn (reparented), plus a cache of deferred delete countdown values. I think all these caches... |
[19:57:57] | stichnot: | ...could be pushed into the MythUIType subclasses and managed with appropriate subclassing, plus iterating over GetAllChildren() as necessar. |
[19:58:30] | stuartm: | dekarl: is the intent not to overwrite any existing values? |
[19:59:46] | stuartm: | !$this->$name seems wrong, might use !isset($this->$name) instead |
[20:01:59] | peper03: | paul-h: Hard to analyse #9703 as I can't seem to create an image. I just keep getting 'MythBurn: failed to get file details for:...' errors |
[20:01:59] | ** MythLogBot http://code.mythtv.org/trac/ticket/9703 ** | |
[20:02:16] | stuartm: | if the intention is to check that the variable actually exists in $this class, then use property_exists($this, $name) |
[20:03:11] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
[20:04:25] | stuartm: | dekarl: if all else fails, throw some prints in there to see what's going on, i.e. I'd start by checking that get_object_vars($prog) actually contains what it should – var_dump(get_object_vars($prog)); |
[20:06:47] | stuartm: | dekarl: oh, and to check that $value contains something it should be "isset($value) && !empty($value)" |
[20:09:14] | stuartm: | just isset() might be appropriate if empty values e.g. "" are considered valid |
[20:10:38] | stichnot: | stuartm: if you don't have objections in principle to making DeleteChild() and DeleteAllChildren() virtual for a good reason, I'll see where that takes me. |
[20:10:58] | stichnot: | though thinking about it, I could always just call my own version of DeleteChild() etc |
[20:13:03] | stuartm: | stichnot: no objections, just a vague nagging doubt ;) |
[20:13:23] | stuartm: | but that's my problem, not yours :) |
[20:21:02] | yoyolala (yoyolala!~yoyolala@unaffiliated/yoyolala) has quit (Ping timeout: 240 seconds) | |
[20:22:46] | stichnot: | stuartm: thanks, I'll see where this takes me. |
[20:23:19] | yoyolala (yoyolala!~yoyolala@unaffiliated/yoyolala) has joined #mythtv | |
[20:24:26] | sraue_ (sraue_!~stephan@77-239-48-1.dyn.cable.fcom.ch) has joined #mythtv | |
[20:25:06] | sraue_ is now known as sraue | |
[20:25:18] | sraue (sraue!~stephan@77-239-48-1.dyn.cable.fcom.ch) has quit (Changing host) | |
[20:25:19] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
[20:33:48] | stichnot: | stuartm: btw, I also found and fixed some basic performance issues in the cc708 decoding/processing code, but for the most part I think the drawing is always going to be the bottleneck, especially when we allow attractive but expensive effects like outlinesize, so it's most effective to try to spread the bursty work over more time. |
[20:36:51] | dekarl: | stuartm, ty. now I see it... 0 is a valid value... if(!0) ... isset($this->$name). not sure on the emptyness check |
[20:39:50] | stichnot: | stuartm: Drawing captions with e.g. outlinesize=3 is definitely much more expensive than no outline, at least in part because of the way it draws 24 additional copies of the text over the perimeter of a 7x7 pixel square. Do you think it's 24x more expensive, or does it depend on painter optimizations, or what? |
[20:45:36] | stuartm: | stichnot: I don't think there's much optimisation in the painters for that, but maybe there's a more efficient way of doing it – I'm not sure whether rendering two strings – one slightly bigger in the outline colour below the other was ever tried |
[20:46:53] | stichnot: | I think you'd have to somehow render the outline string character by character, otherwise the character spacing will be totally wrong |
[20:47:17] | stichnot: | I was wondering if you could sample fewer points along the perimeter and still get decent results |
[20:47:57] | stuartm: | googling, some people suggest using http://qt-project.org/doc/qt-4.8/qpainterpath.html#addText to draw text with an outline – might be worth looking into |
[20:48:17] | stuartm: | stichnot: that much was tried and the results weren't very good |
[20:49:32] | stuartm: | but then it had to work equally well for 60pt text as 11pt text, so for subtitles a lower number could work |
[20:50:06] | stuartm: | subtitles don't have to look so good either |
[20:50:57] | danielk22: | I would only expect drawing the same string 24x to take 1.05x the time of drawing it once. The rendering only needs to be done once then it is just blitting. |
[20:52:16] | stichnot: | stuartm: I disagree, subtitles have to look awesome :) |
[21:01:03] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
[21:02:17] | stichnot: | danielk22: our code in MythPainter::DrawTextPriv() calls QPainter::drawText() 24 times with the same text on the same object. Is there an expectation that QPainter will do some kind of caching, or can/should we be doing it? |
[21:03:45] | stichnot: | stuartm: btw, for outlinesize and shadowoffset, it would be nice if the values could be some sort of percentage rather than absolute number of pixels |
[21:05:49] | danielk22: | I'd bet that was the expectation of when that code was written. These days the theory may be that the application should do that caching. |
[21:13:39] | stuartm: | stichnot: I'll see what I can do :) |
[21:32:42] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
[21:33:02] | joltman (joltman!~joltman@unaffiliated/joltman) has joined #mythtv | |
[21:37:07] | joltman: | i've done a channel scan, and mapped the channels to the correct XMLID on Schedules Direct |
[21:38:09] | joltman: | however, there are some channels that aren't updating their guide data. I've tried a mythfilldatabase --do-channel-updates |
[21:38:38] | joltman: | and --only-update-channels |
[21:39:16] | joltman: | neither of these are showing data for these channels. I've even gone a week into the future to see if there is any data, but there isn't. What am I doing wrong? |
[21:46:59] | jheizer: | joltman: MythTV development channel. For user support, please /join #mythtv-users |
[21:47:22] | joltman: | sorry! |
[21:49:30] | stichnot: | stuartm: not asking you to do any work for that of course... but do you think extending fontdef to allow <outlinesize>10%</outlinesize> <shadowoffset>-20%,20%</shadowoffset> is sensible? |
[21:49:37] | joltman (joltman!~joltman@unaffiliated/joltman) has left #mythtv () | |
[21:52:05] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 245 seconds) | |
[21:54:58] | stichnot: | with the percentages being specified with respect to something like QFontMetrics::maxWidth() and QFontMetrics::height() |
[21:55:00] | stuartm: | stichnot: behaviour at smaller point/pixel sizes might surprise some |
[21:57:35] | stuartm: | stichnot: not the specified pixel/point size? |
[21:57:37] | stichnot: | true. On the flip side, I think there is also some surprise today with larger pixel sizes – an outlinesize of 2 is quite different at 1920x1080 compared to 640x480 |
[21:59:12] | stuartm: | stichnot: that would suggest that the outline isn't being scaled properly relative to the base resolution? |
[21:59:16] | stichnot: | stuartm: In the case of adjustable subtitle zoom factor, I think my suggestion might be better. Without the zoom factor, I think the two are pretty much equivalent |
[21:59:29] | stuartm: | I think it's fine, we might just want to include a note in the wiki about the loss of precision with percentages generally |
[22:00:02] | stichnot: | Today, the outline size is (I believe) an absolute number of pixels, with no relation to the theme base size, display resolution, etc |
[22:03:44] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
[22:03:52] | stuartm: | that's a bug then, it should be scaled with the font not absolute |
[22:04:05] | stuartm: | an oversight |
[22:05:09] | paul-h: | peper03: you probably just need to update. One of the ffmpeg re-syncs broke mytharchivehelper which was only fixed recently |
[22:05:41] | paul-h (paul-h!~Paul@176.27.236.54) has quit (Quit: Konversation terminated!) | |
[22:19:43] | stichnot: | stuartm: that makes sense. I'll look at that post-release, since one wants to give themers plenty of time to adjust outlines and shadows as needed |
[22:20:44] | stichnot: | oh I see you created a ticket... I think the milestone ought to be post 0.27 though |
[22:26:15] | yoyolala (yoyolala!~yoyolala@unaffiliated/yoyolala) has quit (Quit: leaving) | |
[22:26:32] | stichnot: | stuartm: also, for captions/subtitles, suddenly increasing the absolute outlinesize will likely lead to frame dropping for some users (until I get performance improvements in) |
[22:27:25] | stuartm: | well that sucks :) OK, I'll push it back to 0.28 |
[22:28:19] | stuartm: | I think I'll look at an alternative approach for drawing the outline hinted at in some QT forums |
[22:28:22] | stichnot: | Even without the caption performance risk, the change would affect existing themes, and it would be nice to give themers more time to react |
[22:30:21] | stichnot: | At the very least, it seems that MythPainter::DrawTextPriv() should be able to call QPainter::drawText() just once and then implement our own blitting |
[22:30:35] | stuartm: | shouldn't affect existing themes in a negative way, since themers should have tested their themes at their native resolutions, if anything they'll currently appear incorrectly for users |
[22:31:42] | stichnot: | stuartm: yeah, that's a good point. |
[22:32:22] | stuartm: | stichnot: twice, since we need to render the outline/shadow in a different colour/alpha, but yes it shouldn't need to call drawText multiple times for the same string |
[22:33:02] | stichnot: | yeah, once for the basic string, once for the shadow, and hopefully once for the outline |
[22:37:45] | stichnot: | stuartm: Go ahead and make the change for 0.27 if you see fit. It occurred to me that if any subtitle performance problems arise, I can coerce it back to the equivalent absolute pixels in the subtitle code, until any subtitle performance problems get resolved. |
[22:57:28] | rsiebert_ (rsiebert_!~quassel@e179130048.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds) | |
[23:01:05] | rsiebert (rsiebert!~quassel@e179130048.adsl.alicedsl.de) has joined #mythtv | |
[23:11:27] | jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has quit (Ping timeout: 276 seconds) | |
[23:23:02] | jams (jams!~jams@cpe-24-92-85-1.wi.res.rr.com) has joined #mythtv | |
[23:30:18] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Ping timeout: 276 seconds) | |
[23:32:43] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 268 seconds) | |
[23:36:30] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
[23:36:30] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
[23:36:30] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
[23:43:00] | OldEnK (OldEnK!~OldEnK@75-167-207-32.cdrr.qwest.net) has joined #mythtv | |
[23:43:30] | OldEnK (OldEnK!~OldEnK@75-167-207-32.cdrr.qwest.net) has left #mythtv () |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.