MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aca20031, aloril, amessina, Anssi, Beirdo, Captain_Murdoch, CeilingKitten, cesman, Chutt, clever, coling, Cougar, David_Miller, dblain, dekarl, dgeary2, ElmerFudd, fetzerch, ghoti_, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe_____, joki, jpabq, jpabq_, jpharvey__, jst, jwhite, jya, kc, kenni, knightr, knightr_, kormoc, kurre2, kwmonroe, MaverickTech, moparisthebest, MythBuild, MythLogBot, neufeld, Nothing4You, peper03, poptix, purserj, robink, rsiebert_, Seeker`, seld, Sharky112065, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, tonsofpcs, tris, wagnerrp, wahrhaft_, wilmoore-misc, wolfgang4, XDS2010_, xris, _charly_, _nyloc_
Sunday, August 4th, 2013, 00:04 UTC
[00:04:46] kwmonroe` is now known as kwmonroe
[00:14:02] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 256 seconds)
[00:14:03] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[00:15:23] jr3us (jr3us!~jr3us2@cpe-098-026-209-039.triad.res.rr.com) has left #mythtv ()
[00:30:54] Captain_Murdoch: jpabq, thanks. script has been modified to package them for 0.27 so they'll show up in a while.
[01:46:23] joki (joki!~joki@p54862B1D.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[01:51:53] joki (joki!~joki@p54861AAA.dip0.t-ipconnect.de) has joined #mythtv
[02:20:27] _nyloc_ (_nyloc_!~quassel@p4FE4DE4B.dip0.t-ipconnect.de) has joined #mythtv
[02:24:43] nyloc (nyloc!~quassel@p4FE4CDD2.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[02:30:11] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 264 seconds)
[02:30:41] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:55:18] htpc (htpc!~htpc@c-24-34-23-78.hsd1.ma.comcast.net) has quit (Quit: Leaving)
[02:55:21] wagnerrp_ is now known as wagnerrp
[04:01:04] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[04:02:19] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:19:50] jya: stuartm: an annoying visual artefacts I'm seeing with full screen notifications. When I play something via airplay, and the artwork is shown in full screen. At first it's about a dozen pixels below the top. So you can see what's behind. Over time, the picture goes up and after a second or two end up in the right position filling the screen completely.
[04:19:56] jya: Any ideas what could cause it?
[04:49:15] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[04:54:11] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:59:18] CeilingKitten (CeilingKitten!~CeilingKi@206-248-153-92.dsl.teksavvy.com) has quit (Ping timeout: 245 seconds)
[07:11:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds)
[07:15:26] CeilingKitten (CeilingKitten!~CeilingKi@206-248-157-46.dsl.teksavvy.com) has joined #mythtv
[08:33:55] stuartm: jpabq: I'll take a look
[08:34:49] stuartm: jya: is there any animation defined for that screen?
[08:38:04] stuartm: gigem: would it be possible to add a 'This day' filter?
[08:43:29] len (len!~quassel@75-161-179-129.mpls.qwest.net) has quit (Remote host closed the connection)
[08:43:44] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has joined #mythtv
[08:43:56] jya: stuartm: no there isn't
[08:43:57] jya: https://github.com/MythTV/mythtv/blob/master/ . . . -ui.xml#L169
[08:44:56] stuartm: ok, no idea about the cause, but I'll give it some thought
[08:55:02] jya: have you been able to reproduce it ?
[08:55:17] jya: I'll try to find a simple example for you to reproduce it
[08:56:38] stuartm: that would be useful, thanks
[08:58:31] stoffel (stoffel!~quassel@pD9E405B2.dip0.t-ipconnect.de) has joined #mythtv
[09:04:05] jya_: oh, the new refresh is much faster… However, the default image placeholder (the image showing when there is no artwork defined). does redraw slowly every single time
[09:16:29] jya_: stuartm: do you have an iPhone or iPad ?
[09:16:35] stuartm: no
[09:17:01] jya_: iTunes ? (so it's easyer to reproduce with photo sharing)
[09:17:21] stuartm: 'fraid not
[09:17:46] jya_: a windows pc ? could download iTunes and import a few songs and artwork...
[09:18:00] stuartm: nope
[09:18:14] jya_: not even a windows PC ?? (vmware whatever..)
[09:18:39] stuartm: haven't had a copy of windows here for 7–8 years
[09:19:42] stuartm: I dived head first into linux and didn't look back :)
[09:20:24] jya_: it seems to happen when I provide directly a QImage to the mythscreen
[09:21:06] jya_: so it's not something I can reproduce using mythutil or the frontend service API
[09:21:30] jya_: well, i can't reproduce using a local image file or a URL
[09:21:40] jya_: but with a QImage, happens almost all the time
[09:28:02] stichnot (stichnot!~stichnot@adsl-68-127-28-24.dsl.pltn13.pacbell.net) has joined #mythtv
[09:28:02] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[09:28:02] stichnot (stichnot!~stichnot@adsl-68-127-28-24.dsl.pltn13.pacbell.net) has quit (Changing host)
[09:32:12] stuartm: weird
[09:33:43] paul-h (paul-h!~Paul@176.253.145.244) has joined #mythtv
[09:39:12] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[09:49:44] paul-h: stuartm: the articles button list in MythCenter-wide's MythNews seems to have disappeared
[09:50:16] paul-h: I assume it related to your recent optimisations in that area?
[09:52:04] stoffel (stoffel!~quassel@pD9E405B2.dip0.t-ipconnect.de) has quit (Remote host closed the connection)
[09:58:05] stuartm: paul-h: John reported something similar, I'm investigating now
[10:08:20] paul-h: stuartm: I think the MythNews problem may be something unrelated doesn't look like the articles list is being updated properly
[10:09:13] stuartm: paul-h: that would be good, I was struggling to understand how it could be related
[10:09:47] stuartm: browsing through the mythnews sites list the articles do get shown, but only for one feed BBC News – Science
[10:10:46] paul-h: Yeah exactly what I'm seeing
[10:12:59] paul-h: The update times aren't changing except for the one feed that is working which makes me think the new articles aren't being downloaded
[10:14:22] stuartm: I see the following in the log – QNetworkReplyImplPrivate::error: Internal problem, this method must only be called once.
[10:31:32] paul-h: it's working OK in my fork which I last merged with upstream/master on Wednesday at 18:47 so it a recent regression
[10:40:52] stuartm: paul-h: http://code.mythtv.org/cgit/mythtv/commit/?id . . . d87398beeaa3 ??
[10:47:52] stuartm: although that would be a week before Wednesday
[10:52:18] paul-h: Reverting that commit does fix it though
[10:53:18] stuartm: paul-h: noticed a bug with the miniplayer last night, if you pause the music before starting to watch a video/recording, when you exit the music is unpaused – seems that it doesn't distinguish between music that was paused by the user and that which was paused automatically when unpausing
[10:59:58] stuartm: jpabq: I've reverted that commit as with the other optimisations it wasn't really needed – I briefly considered just excluding images and not textareas from the Reset(), which fixed the bug you identified but in the end I decided it wasn't worth it
[11:00:55] paul-h: I've noticed that as well I think it's a recent regression possibly related to jya's changes to how the music player is stopped when tv playback is started at least I've never seen it until recently
[11:01:49] paul-h: I've also got into the position of both the music player and live tv playing at the same time
[11:01:57] stuartm: jpabq: the movement of DisplayState() in particular rendered the earlier commit largely obsolete
[11:05:20] paul-h: The strange thing is I've already got http://code.mythtv.org/cgit/mythtv/commit/?id . . . d87398beeaa3 in my fork and it appears to be working OK I wonder if your MythImage changes are tickling the bug somehow?
[11:12:24] Dorward (Dorward!~Dorward@70.75.112.87.dyn.plus.net) has left #mythtv ()
[11:17:25] dekarl1 (dekarl1!~dekarl@p4FCEF53F.dip0.t-ipconnect.de) has joined #mythtv
[11:19:59] dekarl (dekarl!~dekarl@p4FCEF6CE.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds)
[11:24:17] stuartm: I'm unable to imagine a link between the failure to download the rss feed and the changes I made
[11:26:25] stuartm: the closest I can get is that mythnews is possibly doing it's own image caching of remote images within the theme search path and 2becf206c broke that? However that seems unlikely
[11:27:19] dgeary2 (dgeary2!~debian@pa49-187-81-165.pa.nsw.optusnet.com.au) has joined #mythtv
[11:29:44] dekarl1 is now known as dekarl
[11:33:18] stuartm: paul-h: are you running both the fork and master on the same machine? Same version of QT etc?
[11:34:20] stuartm: deleting the mythnews cache under ~/.mythtv has helped here, several feeds are now working again
[11:49:30] jya: stuartm: commit 997f7aa10fca9adbe76a7bdf24d4d87398beeaa3 may very well expose a prior bug that just got unhidden. I re-use the exact same code as before to cancel a download. however, with some version of Qt, or depending on how it's been compiled. calling abort() on a http connection, will either crash or be ignored.
[11:50:16] jya: so it could be that before it was just ignored and it got cancelled elsewhere like in the destructor…. Now that it's properly aborted, it could be that the abort is also done elsewhere an extra time...
[11:50:25] jya: will have a look. Do you have a way to easily reproduce it?
[11:52:47] jya: i can see the potential here of abort being called, when MythDownloadInfo::IsDone being set, it could cause abort to be called later… though I don't know if that can actually happen in practice.
[11:52:55] jya: paul-h: I will look at the pause business
[11:54:15] stuartm: paul-h: what jya just said made me look at NewSite – it appears we're calling cancelDownload() twice, once in deleteLater() and a second time in the destructor which seems wrong – it might not be the cause of this bug but ...
[12:01:19] stuartm: jya: was the download cancelled by a Queued connection previously? That seems like the problem here, we call CancelDownload(url) before a call to queueDownload(url) – those would cancel each other out because the cancellation does occur until control returns to the event loop
[12:04:31] stuartm: yep, confirmed that as the problem
[12:05:55] stuartm: we add to the download queue and it's then immediately cancelled because the requests are now handled out of sequence
[12:10:27] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[12:12:58] stuartm: fwiw, in this particular instance we could change mythnews to abort if there is already a queued download instead of stopping the one already in the queue
[12:13:59] stuartm: but the new behaviour of MDM is counter-intuitive and may potentially cause bugs elsewhere
[13:13:44] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:20:37] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:30:09] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[13:47:30] knightr: stuartm, Hi! Is there anything that would delay the release of the Beta tonight and if not could you please do it?
[13:49:31] stuartm: the MythDownloadManager bug is a blocker atm
[13:50:18] knightr: thank you! So that's what MDM stands for...
[13:51:21] knightr: was your problem with static while listening to music resolved?
[13:51:22] dekarl: stuartm: nice work on the image flickering. (just updated to 6401cd3). Now I just need to figure out why remote recording playback sometimes takes a minute to start :)
[13:52:46] dekarl: meh, all the CRC Errors are back, have some refactorings that are not pushed yet :( DVBRead mpeg/pespacket.cpp:161 (VerifyCRC) PESPacket: Failed CRC check 0xdb0daf78 != 0x6e5fc211 for StreamID = 0x83
[13:53:58] dekarl: looks like http://pastebin.com/j9euF0JH is needed, too
[14:14:53] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has quit (Ping timeout: 240 seconds)
[14:23:52] stuartm: knightr: actually no, it wasn't
[14:26:19] stuartm: I'm not sure I'd make the beta release contingent on that, it's very annoying yes but it doesn't affect every track and I don't know how many people are experiencing it
[14:26:47] stuartm: I don't even know if it's a regression in master or whether it's been present in an earlier release e.g. 0.26
[14:27:11] stuartm: but it would be good to have it fixed for the first RC
[14:35:38] dekarl: frontend log: when starting playback of a recording http://paste.ubuntu.com/5947665/
[14:45:02] stuartm: jya: as a fix I'd suggested the addition of a 'cancellation' queue, CancelDownload() would move from the downloadqueue to the cancellation queue, which could then be safely emptied when control passed to the event loop
[14:46:05] stuartm: that would be minimally invasive and quick to write
[14:53:58] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[15:08:36] paul-h: stuartm: the good news is the flickering on the Search for Music Stream has gone :) The bad news is scrolling in the list is painfully slow, page up/down now takes 3 or 4 seconds before the list is updated :(
[15:11:03] stuartm: paul-h: it's as fast as it ever was here, updates pretty much instantly
[15:12:47] stuartm: the icons can take a few seconds to load, but that's not new since they are being fetched from a remote server in the background
[15:13:16] stuartm: once cached they load instantly
[15:16:50] dekarl: paul-h, should this work for shoutcast parsing? <metadataformat>Hit Radio FFH: %a – %t</metadataformat>
[15:19:53] stuartm: if anything, the cached icons should be displaying faster now and there shouldn't be any slowdowns as a result of the changes ...
[15:21:40] paul-h: stuartm: on the search for streams screen?
[15:22:46] stuartm: yes
[15:23:23] dekarl: nvm, I think I found the answer ;) http://code.mythtv.org/doxygen/shoutcast_8cpp_source.html#l00875
[15:23:43] stuartm: fwiw, I notice from the logs that a lot of the icons – MythUIHelper: LoadScaleImage(http://i.radionomy.com/Documents/Radio/201202 . . . 810.s60.jpg) failed to load remote image
[15:23:43] paul-h: Strange it's painfully slow to scroll easily 4 seconds to page down
[15:26:04] stuartm: paul-h: hmm, if I hold down PgDown then suddenly it becomes slow, but if I move one page at a time it's fast
[15:26:43] stuartm: is that list working from a local cache or parsing a remote source?
[15:28:35] paul-h: stuartm: It assumes the image disk cache will cache them for us so they should be downloaded once and loaded from there after that
[15:29:11] stuartm: sorry, I mean the list data itself, not the images
[15:30:18] paul-h: It's loaded from the installed streams.xml
[15:32:02] stuartm: hmm, I wonder if thinks we've cached images that we weren't able to download
[15:37:13] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds)
[15:40:31] paul-h: dekarl: ah! I see the FIXME wonder why that was commented out
[15:42:00] cocoa117 (cocoa117!~cocoa117@78-105-86-201.zone3.bethere.co.uk) has joined #mythtv
[15:50:17] stuartm: paul-h: are you seeing this issue with the MDM changes reverted?
[15:54:44] paul-h: I'm using clean master on my dev machine and still see the slow scrolling
[16:02:45] stuartm: I'm just wondering if the MDM changes are somehow related, since we use MDM to fetch remote images
[16:03:13] stuartm: anyway, I see at least one bug, it doesn't explain the slow scrolling since it's not a new bug, but it needs fixing
[16:04:44] stuartm: we are able to queue up multiple downloads of the same file in MDM – multiple list items using the same image and as a result we waste both time and bandwidth hitting the server twice for each image (last modified checks and actual download)
[16:06:24] stuartm: ideally if we tried to add the same image to the download queue, MDM would be smart enough to recognise that and just notify us when the first has download
[16:07:51] stuartm: Captain_Murdoch: any thoughts on that? Looking at the code the only catch is that it assumes a single caller per url/destination – we could change that to a list of pointers instead?
[16:08:25] paul-h: stuartm: I still see the slow scrolling with the MDM changes reverted
[16:10:04] stuartm: paul-h: ok thanks, at this point it might help to revert my recent commits in turn to see which if any are responsible – I'd start with d5500332
[16:10:16] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[16:10:17] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[16:10:17] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[16:17:42] paul-h: stuartm: with d5500332 reverted scrolling is fast but the icons are having a hard time keeping up with the scrolling they do update but sometimes several seconds after scrolling finishes
[16:20:27] stuartm: yeah, that's because we're queing up lots of them
[16:22:35] stuartm: OK 1) so for some reason d5500332 is the cause but it's not clear why yet 2) there is an issue in the way that we queue up images even if we no longer need to display them 3) we're launching multiple download requests for the same image and MDM isn't smart enough to combine those into one
[16:26:08] rsiebert_ (rsiebert_!~quassel@e179129243.adsl.alicedsl.de) has joined #mythtv
[16:28:59] rsiebert (rsiebert!~quassel@g225058019.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds)
[16:34:55] stuartm: Captain_Murdoch: about?
[16:36:16] Solaris444 (Solaris444!~chatzilla@mail.picodata.net) has joined #mythtv
[16:36:51] Solaris444: Hi, is paul-h around?
[16:39:06] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[16:39:57] HelloWorld321 (HelloWorld321!~vw@cpe-172-250-246-28.socal.res.rr.com) has joined #mythtv
[16:44:59] HelloWorld321: I have added an extra two directories to my mythtv-backend for videos ... and then I decided that I don't really want them. I don't see a delete anywhere, and I haven't been able to locate the configuration file. How do I delete videos directories from my media libraries?
[16:45:21] HelloWorld321: I know: I'll rename them to /dev/null/
[16:47:06] HelloWorld321: sry, wrong channel
[16:49:49] paul-h: Solaris444: ?
[16:49:58] Solaris444: Hi paul-h
[16:50:22] Solaris444: Just wanted to touch base with you about that theme problem i discovered.
[16:50:52] paul-h: You'll have to remind me
[16:51:07] Solaris444: When I go to retrieve details for a movie in my gallery, if several options match the file name, it no longer shows the year the film came out OR the subtitle for it.
[16:51:46] Solaris444: There's no way to tell which one you're selecting when there are several movies of the same primary name
[16:52:37] Solaris444: It works in the Mythbuntu theme, but none of the MythCentre* themes.
[16:52:55] paul-h: Yeah I remember now
[16:53:02] Solaris444: yup
[16:53:33] Solaris444: You asked me to find out what changes were necessary by examining the MythBuntu theme. We noticed there was a reference to an external template in the Mythbuntu theme
[16:53:41] Solaris444: That was not present in the MythCentre* themes.
[16:53:52] Solaris444: Thing is, I was unable to track down any other reference to this template.
[16:54:43] Solaris444: So I was not able to submit any changes. I was hoping you'd be able to help.
[16:56:31] paul-h: Yeah It would probably be quicker if I just try to fix it myself and have you test it
[17:01:54] Solaris444: thanks mate.
[17:02:00] Solaris444: Do you need an email address for me?
[17:05:32] paul-h: If I can reproduce the problem I'll just commit the required changes so just keep an an eye on the commits list
[17:08:47] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has joined #mythtv
[17:08:56] Solaris444: will do.
[17:09:01] Solaris444: I can reproduce the problem easily
[17:09:07] Solaris444: thanks paul-h
[17:26:35] sphery: wagnerrp: stuartm fixed the redirect for the docs, so it's all good now. Thanks, though.
[17:36:01] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[17:44:29] HelloWorld321 (HelloWorld321!~vw@cpe-172-250-246-28.socal.res.rr.com) has left #mythtv ()
[17:55:17] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has quit (Quit: Konversation terminated!)
[18:01:55] paul-h: dekarl: MythMusic will now use the metadata format you specify. I used '%r: %a – %t -' for the stream at http://streams.ffh.de/radioffh/mp3/hqlivestream.m3u which I guess is the stream you wanted to use
[18:03:41] gigem: stuartm: Adding a 'This day' filter is fairly easy. Getting the translation done at this late time is tougher. I'd also have to increase the number of allowed filters and change my own configuration since I have a custom filter in the last current slot, but neither of those is that big a deal. What is your use case? Do you really expect to use it enough instead of using an occasional power search rule?
[18:03:48] gigem: kenni, knightr: ^^^
[18:06:58] stuartm: gigem: there are programmes here that have generic descriptions and for which there are multiple repeats, a 'this time' filter won't work since the timing isn't fixed and a 'this week' filter doesn't work either but a 'this day' would work well
[18:08:20] stuartm: the thing is, if it would work for me, then I can imagine that there are a lot of other people who would benefit from it – at least in the UK
[18:09:37] stuartm: one example is the 'Film Review' which is shown on a 24 hour news channel, it may move times depending on the news schedule but it's always shown on a Friday at some point
[18:10:38] stuartm: news shows in general seem to fit the profile
[18:11:03] len (len!~quassel@75-161-179-129.mpls.qwest.net) has joined #mythtv
[18:11:55] stuartm: it's basically a trade off between the 'This time' filter which is too rigid and the 'This week' filter which is too wide
[18:12:27] stuartm: gigem: doesn't need to be added for 0.27, I just wondered if it was feasible
[18:29:43] knightr: gigem, If it's something that has to go in you have until the first RC...
[18:31:18] knightr: (originally something like august 10–11 (depending on when and where it was published...))
[18:31:30] dekarl: paul-h: close enough: http://streams.ffh.de/radioffh/aac/hqlivestream.m3u ;)
[18:37:29] stuartm: I need a sanity check here, https://github.com/MythTV/mythtv/blob/master/ . . . helper.h#L25
[18:39:31] stuartm: kCacheCheckMemoryOnly is mutually exclusive of kCacheIgnoreDisk – right? So why is it used as an argument to LoadCacheImage() which only checks for kCacheForceStat and kCacheIgnoreDisk?
[18:51:18] Solaris444 (Solaris444!~chatzilla@mail.picodata.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/2013062200])
[18:55:34] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 248 seconds)
[19:09:40] cesman (cesman!~cesman@pool-108-23-186-248.lsanca.fios.verizon.net) has joined #mythtv
[19:09:41] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[19:09:41] cesman (cesman!~cesman@pool-108-23-186-248.lsanca.fios.verizon.net) has quit (Changing host)
[19:23:00] len (len!~quassel@75-161-179-129.mpls.qwest.net) has quit (Remote host closed the connection)
[19:33:06] gigem: stuartm, knightr: Just about anything that can be done in a power search rule without joining additional tables can be done with a filter. I just wanted to gauge how useful it would be. With the current implementation, the number of filters is limited. I know of a way to remove the limit, but I don't want to tackle that unless and until it's needed. Anyway, if you guys want it for 0.27, I'll be happy to
[19:33:08] gigem: add it this week.
[19:45:19] dekarl: stuartm: hmm, I think it checks for (cacheMode == kCacheNormal), too.
[19:47:07] stuartm: dekarl: it was definitely wrong, I've refactored it now and fix the specific case where it should have been using kCacheIgnoreDisk instead of kCacheCheckMemoryOnly
[19:48:20] stuartm: I just need to check that it's working as intended, but it's made a dramatic improvement to the speed browsing screens like the "Search for Music Stream" one paul-h mentioned where we're loading lots of images from the internet
[19:48:53] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.1)
[19:48:54] stuartm: heh, I say that and then it starts to slow down again :(
[19:49:48] gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has joined #mythtv
[19:49:48] gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has quit (Changing host)
[19:49:48] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[20:50:16] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 264 seconds)
[21:03:29] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[21:04:52] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Read error: Connection reset by peer)
[21:14:51] dgeary2_ (dgeary2_!~debian@pa49-187-82-246.pa.nsw.optusnet.com.au) has joined #mythtv
[21:18:40] dgeary2 (dgeary2!~debian@pa49-187-81-165.pa.nsw.optusnet.com.au) has quit (Ping timeout: 276 seconds)
[21:26:03] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has joined #mythtv
[21:36:16] stuartm: paul-h: situation with the music stream search should be much better now
[21:38:05] stuartm: I think I've done about all the tweaking I can for 0.27, but I spotted a few things that could still be improved for 0.28, they just require more invasive work
[21:41:49] stuartm: the option to cancel queued image downloads is a big one, as is making the cache aware of the cache expiry time for internet images and some general re-factoring of the image cache as it's become a little messy with the additions made since it was first created
[22:09:23] SteveGoodey (SteveGoodey!~steve@host86-151-111-43.range86-151.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:23:25] paul-h: stuartm: thanks, it's definitely a lot faster when scrolling it's back to how it was but without the flicker :)
[22:23:58] paul-h: the only concern now is why isn't the default icon being shown for those icons that cannot be downloaded
[22:31:18] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (Ping timeout: 241 seconds)
[22:31:40] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has joined #mythtv
[22:34:03] paul-h: I though I'd found a great radio stream finder api until I realised they wanted us to pay for it $250.00/Month for 25 to 50k api hits/month
[22:36:28] cocoa117 (cocoa117!~cocoa117@78-105-86-201.zone3.bethere.co.uk) has quit (Quit: Leaving)
[22:42:13] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds)
[22:52:54] paul-h: jya: I've found a radio station (Radionomy – Guitar Spirit) that often displays the crackly audio problem that stuartm is having, could be some sort of clipping because the problem is only noticeable on the louder tracks
[23:08:54] paul-h (paul-h!~Paul@176.253.145.244) has quit (Quit: Konversation terminated!)
[23:28:17] dgeary2_ is now known as dgeary2
[23:42:09] jya: stuartm: about MDM and using a download queue, we have talked about it and the change is far more intrusive, and slower as you now need to check for things that ultimately are rarely use. The way things are deleted are done in a similar fashion as they've always been done: except that now , it's always done in the same thread.
[23:43:07] jya: so no new behaviour is to be expected compare to before. If you have a bug, it was always there… Will see what can be done so calling cancel download multiple times isn't a problem
[23:46:46] jya: stuartm: before cancelDownload was called directly, no queue. which is what caused crashes (you can't call QTcp::abort() from a different thread than the one that created it the object.
[23:47:03] stuartm: jya: it's a new bug, it's because you've made the deletion delayed, I've already pushed a fix
[23:47:08] jya: So I disagree when you say that there's a new behaviour… There isn't a new behaviour (unless saying that it now doesn't crash is a new behaviour). What you are saying as always occurred (being out of sequence)… Just look at what the changes does
[23:47:17] jya: that is incorrect.
[23:47:22] jya: the deletion isn't delayed
[23:47:30] stuartm: yes it is
[23:47:53] jya: no it is not… the call is blocking until it is processed by the event loop
[23:48:14] jya: so it occurs exactly like before, just done by a different thread
[23:48:21] stuartm: using a QueuedConnection for the signal/slot means that it's not actually performed until control returns to the event loop
[23:48:27] stuartm: it's not blocking
[23:49:00] stuartm: anyway, it's now fixed so all is well again
[23:51:04] jya: i still disagree with your analysis on being a new behaviour… the logic is the same as it's always been (may have been incorrect)
[23:51:36] stuartm: you'd want to use Qt::BlockingQueuedConnection if you wanted it to block there
[23:51:52] jya: well, that all that would have been required then...
[23:52:08] stuartm: it used to block, now it doesn't ... ergo new behaviour
[23:52:11] jya: weird, I was 100% sure I had made it be a blocking call
[23:52:53] jya: we have a different definition of blocking… nothing was blocked before. It just loop and deleted a thing (which cause a 50% chance of crash on my system here)
[23:53:59] jya: should have only changed it to Qt::BlockingQueuedConnection ; then it would have been identical to before without new code, now members being added
[23:55:17] stuartm: if I knew you're intent there that's exactly what I would have done
[23:56:01] jya: sorry, I had to go to bed early… partied all night earlier.. was totally wrecked
[23:58:23] jya: stuartm: the reason I thought it was a blocking call, I used the same logic as I do in the MythCoreContext::WantPlayback() bit… https://github.com/MythTV/mythtv/blob/master/ . . . xt.cpp#L1403
[23:58:24] stuartm: anyway, documentation on the signal type is here – http://qt-project.org/doc/qt-4.8/qt.html#ConnectionType-enum
[23:58:42] jya: and as you can see I'm using Qt::BlockingQueuedConnection
[23:59:08] stuartm: right, easy mistake, no harm done in the end
[23:59:34] jya: i certainly dislike the idea of having introduced a bug when I'm supposed to fix them
[23:59:55] stuartm: nobody likes it, but it happens :)

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